Fiche incident

Indexation bloquée sur Magento - Causes & solutions

Rédigé par Soulaimane Aattar — 850+ interventions e-commerce documentées Mis à jour le 14 juin 2026 Versions concernées : Magento 2.3.x, 2.4.x (Open Source et Adobe Commerce), Adobe Commerce Cloud, et anciennes versions Magento 1.x

Tes nouvelles fiches produits n'apparaissent plus dans Google, le trafic organique chute, et la Search Console affiche des pages "Bloquée par le fichier robots.txt" ou "Exclue par la balise noindex". Sur une boutique Magento, ce blocage d'indexation est presque toujours une erreur de configuration silencieuse, pas un problème de contenu : un réglage resté en mode staging, une règle Disallow trop large, ou un cache Magento qui sert encore l'ancien robots.txt.

L'enjeu est direct : chaque jour où tes pages catalogue restent désindexées, ce sont des positions perdues que les concurrents récupèrent, et une réindexation qui prendra des semaines une fois corrigée. Ce guide t'amène du symptôme exact (message GSC, en-tête HTTP) à la cause Magento précise, puis au correctif avec les commandes à lancer. Pas de théorie sur le SEO : un protocole de diagnostic d'incident.

Contexte technique

Magento 2 gère neuf indexers (catalog_product_price, catalog_category_product, cataloginventory_stock, customer_grid, etc.) qui alimentent les tables _index_ optimisées pour la lecture. Un lock MySQL prolongé, un cron qui meurt silencieusement, ou une extension tierce qui appelle save() en boucle sur des produits suffisent à bloquer indéfiniment le reindex. La commande bin/magento indexer:status doit être monitorée en permanence : tout statut « processing » qui persiste plus d'une heure est un signal d'alerte.

magento indexer invalidreindex magento errormagento catalogue bug

Cet incident peut impacter votre chiffre d’affaires.

Si ce problème touche le checkout, la disponibilité ou la performance, la perte de revenu peut être immédiate.

Note expert BugRescue

Ne lancez jamais bin/magento indexer:reindex en production en pic de trafic. Le verrouillage peut dégrader le catalogue pendant plusieurs minutes. Privilégiez un reindex granulaire par indexer concerné.

Prise en charge par des experts avec 15+ ans d’expérience e-commerce.

Équipe senior full-stack PrestaShop, WooCommerce, Magento, Shopify et WordPress. Intervention rapide sur incidents critiques et stabilisation durable — France, Maroc, Belgique et Suisse.

Symptômes : comment confirmer le diagnostic

Avant de toucher à quoi que ce soit, confirme que tu as bien un blocage d'indexation côté crawl/index, et pas un simple problème de contenu dupliqué ou de canonical. Trois sources te donnent un signal fiable : la Search Console, les en-têtes HTTP de tes pages, et le contenu de ton robots.txt servi en production.

Les messages de la Search Console à reconnaître ne veulent pas dire la même chose. "Bloquée par le fichier robots.txt" signifie que Googlebot ne peut même pas crawler l'URL. "Indexée malgré le blocage par le fichier robots.txt" signifie que l'URL est connue (liée ailleurs) mais indexée sans contenu, ce qui est presque toujours indésirable. "Exclue par la balise noindex" signifie que Google a bien crawlé la page mais a obéi à un meta robots ou un en-tête X-Robots-Tag noindex.

Pages produits ou catégories qui disparaissent du SERP "site:tondomaine.com" alors qu'elles existent et répondent en 200.
Rapport Pages (Couverture) GSC : pic soudain de "Bloquée par le fichier robots.txt" ou "Exclue par la balise noindex".
Outil d'inspection d'URL GSC : verdict "L'URL n'est pas sur Google" avec motif crawl/index explicite.
Chute du trafic organique corrélée à une date de déploiement ou de migration staging -> production.
Présence de <meta name="robots" content="NOINDEX,NOFOLLOW"> dans le <head> de toutes les pages (vue source navigateur).
tondomaine.com/robots.txt qui renvoie des Disallow couvrant /catalog/product/view/ ou la racine /.

Impact business immédiat

Un blocage d'indexation sur Magento n'est pas un bug visible par le client sur la boutique : le site fonctionne, les commandes passent. Le dommage est invisible jusqu'à ce que le chiffre d'affaires organique s'effondre, ce qui le rend dangereux. La perte se chiffre sur plusieurs semaines car même après correction, Google met du temps à recrawler et reclasser des milliers d'URL catalogue.

Concrètement, plus le blocage dure, plus les positions acquises se vident et plus la reconstruction est longue. Un noindex global laissé en place après une migration peut effacer la quasi-totalité du trafic SEO d'une boutique en deux à trois semaines, le temps que Google repasse sur les pages et applique la directive.

Disparition progressive des pages catalogue de l'index Google, donc du trafic organique non-marque.
Perte de positions durement acquises, récupérées par les concurrents pendant le blocage.
Délai de réindexation long après correctif : recrawl par lots, pas instantané.
Budget de crawl gaspillé si Googlebot bute sur des Disallow ou des pages noindex en masse.
Impact direct sur le ROI des contenus catégorie/blog optimisés qui ne remontent plus.

Causes classées par probabilité

Sur Magento, l'ordre des causes est assez stable. Les deux premières couvrent la grande majorité des incidents post-déploiement.

Garde en tête la distinction qui guide tout le diagnostic : un Disallow dans robots.txt empêche le crawl mais pas l'indexation, alors qu'un meta robots noindex (ou un en-tête X-Robots-Tag) empêche réellement l'indexation. Confondre les deux conduit à appliquer le mauvais correctif.

1. Staging oublié (cause n°1). Le champ Default Robots est resté sur NOINDEX, NOFOLLOW après le passage staging -> production. Magento injecte alors <meta name="robots" content="NOINDEX,NOFOLLOW"> dans le <head> de toutes les pages.
2. Règle Disallow trop large dans le robots.txt. Présence de Disallow: /catalog/product/view/ ou Disallow: /catalog/category/view/ (parfois hérités d'un "robots.txt par défaut" copié-collé) qui bloquent les fiches produits/catégories non réécrites, voire Disallow: / qui bloque tout.
3. Cache Magento non vidé. Le robots.txt et la sortie HTML sont mis en cache : tu corriges le réglage en admin mais Google reçoit encore l'ancienne version.
4. Site resté en mode developer/staging au niveau application (deploy:mode), avec des comportements de rendu ou des en-têtes inattendus.
5. Extension SEO tierce (ou module de layered navigation) qui réinjecte un noindex sur les pages à facettes ou écrase la config native.
6. Blocage au niveau infrastructure : règle Fastly/CDN, .htaccess ou nginx renvoyant un X-Robots-Tag: noindex global (fréquent sur les environnements de préprod migrés en l'état).

Diagnostic : les commandes à lancer

Procède dans l'ordre : du plus rapide à confirmer (HTTP/robots.txt) vers la configuration Magento. L'objectif est d'isoler si le blocage vient d'un meta noindex, d'un en-tête X-Robots-Tag, ou d'une règle robots.txt, puis de savoir où il est généré.

Commence par inspecter ce que Googlebot reçoit réellement sur la home et sur une fiche produit. Un X-Robots-Tag dans l'en-tête HTTP est invisible dans le code source : seul curl -I le révèle.

Vérifier les en-têtes HTTP (cherche X-Robots-Tag)

# Home
curl -I https://tonsite.com/

# Une fiche produit qui ne s'indexe plus
curl -I https://tonsite.com/url-de-ta-fiche-produit.html

# Si tu vois cette ligne, le blocage vient de l'en-tête HTTP, pas de Magento admin :
# x-robots-tag: noindex, nofollow

Chercher le meta robots noindex dans le HTML rendu

# Récupère le <head> et grep la balise robots
curl -s https://tonsite.com/ | grep -i 'name="robots"'
curl -s https://tonsite.com/url-de-ta-fiche-produit.html | grep -i 'name="robots"'

# Sortie qui confirme le "staging oublié" :
# <meta name="robots" content="NOINDEX,NOFOLLOW"/>

Inspecter le robots.txt servi en production

# Ce que Google lit réellement (sortie générée + mise en cache par Magento)
curl -s https://tonsite.com/robots.txt

# Repère les lignes dangereuses :
#   Disallow: /              -> tout est bloqué
#   Disallow: /catalog/product/view/   -> fiches produits non réécrites bloquées
#   Disallow: /catalog/category/view/  -> catégories non réécrites bloquées

Vérifier le mode et l'état Magento (en SSH)

# Le site est-il resté en mode developer/staging ?
php bin/magento deploy:mode:show
# Attendu en prod : Current application mode: production

# État du cache (le robots.txt et le HTML sont cachés)
php bin/magento cache:status

Confirmer la valeur Default Robots en base

-- Lit la config Search Engine Robots stockée en base
SELECT path, value, scope, scope_id
FROM core_config_data
WHERE path LIKE 'design/search_engine_robots/%';

-- path 'design/search_engine_robots/default_robots' avec value 'NOINDEX,NOFOLLOW'
-- = c'est ta cause. La valeur de prod attendue est 'INDEX,FOLLOW'.

Solutions pas-à-pas

Applique le correctif qui correspond à ce que ton diagnostic a confirmé. Dans tous les cas Magento, la dernière étape obligatoire est de vider le cache, sinon Google continue de recevoir l'ancienne version.

Cas A : meta noindex global (staging oublié). C'est la correction la plus fréquente.

Connecte-toi à l'admin Magento : Content > Design > Configuration.
Édite le scope concerné (Website ou Global, pas Store View : le réglage Search Engine Robots n'est pas disponible au niveau Store View).
Ouvre la section Search Engine Robots et passe le champ Default Robots de NOINDEX, NOFOLLOW à INDEX, FOLLOW.
Enregistre, puis vide le cache : System > Cache Management > Flush Magento Cache, ou en CLI php bin/magento cache:flush.
Cas B (Disallow trop large) : dans la même section, édite le champ "Edit custom instruction of robots.txt File", supprime les lignes Disallow: /, Disallow: /catalog/product/view/ et Disallow: /catalog/category/view/, garde uniquement les Disallow techniques (checkout, customer, cart, catalogsearch, etc.), enregistre et vide le cache.
Recharge tonsite.com/robots.txt et refais curl -I + le grep meta robots pour vérifier que le blocage a disparu.
Cas C (mode application) : si deploy:mode:show renvoie developer, repasse en production avec php bin/magento deploy:mode:set production puis php bin/magento setup:upgrade et php bin/magento cache:flush.
Demande le recrawl : dans la Search Console, outil d'inspection d'URL > saisis l'URL > "Demander une indexation". Fais-le sur quelques URL pilotes (home, top catégories, top produits) ; le reste sera recrawlé via le sitemap.
Vérifie que le sitemap est bien déclaré : la dernière ligne du robots.txt doit contenir Sitemap: https://tonsite.com/sitemap.xml, et le sitemap doit être soumis dans GSC.

robots.txt Magento 2 propre et sûr (custom instruction)

User-agent: *
Allow: /media/
Allow: /static/
Allow: /pub/media/
Allow: /pub/static/
Disallow: /checkout/
Disallow: /customer/
Disallow: /cart/
Disallow: /catalogsearch/
Disallow: /wishlist/
Disallow: /review/
Disallow: /sendfriend/
Disallow: /catalog/product_compare/
Disallow: /app/
Disallow: /bin/
Disallow: /dev/
Disallow: /lib/
Disallow: /var/
Disallow: /report/
Disallow: /*?dir=
Disallow: /*?limit=
Disallow: /*?mode=
Disallow: /*?order=
Disallow: /*?price=
Disallow: /*?SID=
Disallow: /*?___store=
Disallow: /*?___from_store=
Sitemap: https://tonsite.com/sitemap.xml

Important : pour DÉSINDEXER une page, pas de noindex dans robots.txt

# Google n'autorise PAS la directive noindex dans robots.txt.
# Pour vraiment désindexer une page déjà indexée :
#  1) NE PAS la bloquer via Disallow (sinon Google ne verra jamais le noindex)
#  2) Laisser Google la crawler avec :
#     <meta name="robots" content="noindex, follow">
#     ou l'en-tête HTTP : X-Robots-Tag: noindex
#  3) Une fois désindexée, tu peux re-bloquer le crawl si besoin.

Spécificités par version

Le chemin de configuration et le mode de génération du robots.txt diffèrent selon la version et l'hébergement.

Identifie ton contexte avant d'appliquer un correctif, surtout sur Adobe Commerce Cloud où le fichier n'est pas généré là où tu l'attends.

Magento 2.3.x / 2.4.x : configuration sous Content > Design > Configuration > section Search Engine Robots (champ Default Robots + custom instruction + bouton Reset to Defaults). robots.txt généré dynamiquement par l'admin, pas par un fichier statique à la racine.
Magento 1.x (et très anciennes versions 2) : chemin System > Configuration > Design > HTML Head > Default Robots. Logique identique (les 4 valeurs INDEX/NOINDEX x FOLLOW/NOFOLLOW) mais interface différente.
Adobe Commerce Cloud : le robots.txt est stocké dans pub/media/ et servi via une redirection Fastly (VCL). Vider le cache applicatif ne suffit pas toujours : il faut aussi purger Fastly. Vérifie qu'aucune règle CDN ne renvoie un X-Robots-Tag global.
Open Source on-premise : robots.txt généré à la racine web ; cache:flush suffit après modification en admin.
Toutes versions : après changement de la custom instruction, le robots.txt est mis en cache. Si curl renvoie encore l'ancienne version, lance php bin/magento cache:flush (et purge le CDN le cas échéant) avant de conclure que le correctif a échoué.

Quand appeler un expert

Tu peux régler seul un staging oublié ou une règle Disallow en quelques minutes avec les étapes ci-dessus. Fais-toi accompagner quand le blocage persiste après avoir vidé le cache et corrigé la config, quand l'en-tête X-Robots-Tag: noindex vient de l'infra (Fastly/nginx/.htaccess) et non de Magento, quand une extension SEO réinjecte un noindex que tu n'arrives pas à localiser, ou quand des milliers d'URL sont à réindexer sans perdre le budget de crawl.

Si après diagnostic tu confirmes un blocage côté CDN ou un comportement de rendu lié au mode application, et que le chiffre d'affaires organique continue de chuter, l'équipe BugRescue (Soulaimane Aattar, fondateur) peut prendre le relais pour isoler la source exacte et sécuriser la réindexation sans casser le SEO existant.

FAQ

Où se trouve le fichier robots.txt dans Magento 2 ?

Il n'existe pas en tant que fichier statique à éditer : Magento 2 génère le robots.txt dynamiquement depuis l'admin (Content > Design > Configuration > Search Engine Robots, champ "Edit custom instruction of robots.txt File"). Sur Adobe Commerce Cloud, la sortie est stockée dans pub/media/ et servie via Fastly. Après toute modification, vide le cache (php bin/magento cache:flush) sinon Google reçoit encore l'ancienne version.

Pourquoi mes pages produits Magento ne sont-elles pas indexées ?

Les deux causes les plus fréquentes : le champ Default Robots resté sur NOINDEX, NOFOLLOW après une migration staging vers production (un meta noindex est alors injecté dans toutes les pages), ou une règle Disallow trop large dans le robots.txt comme Disallow: /catalog/product/view/ qui bloque le crawl des fiches non réécrites. Vérifie d'abord avec curl -I et un grep du meta robots sur une fiche concernée.

Que signifie "Indexée malgré le blocage par le fichier robots.txt" ?

Google connaît l'URL (parce qu'elle est liée ailleurs) mais ne peut pas la crawler à cause d'un Disallow, donc il l'indexe sans son contenu. C'est presque toujours indésirable. Pour corriger : retire le Disallow afin que Google puisse crawler la page, puis applique un meta noindex si tu veux la désindexer, ou laisse-la en index si elle doit ranker.

robots.txt, meta robots ou X-Robots-Tag : lequel utiliser ?

robots.txt (Disallow) contrôle le crawl, pas l'indexation, et Google n'y autorise pas la directive noindex. Pour empêcher l'indexation d'une page, utilise un meta robots noindex dans le HTML ou un en-tête HTTP X-Robots-Tag: noindex (idéal pour les PDF et fichiers non-HTML). Règle d'or : ne bloque jamais via Disallow une page que tu veux désindexer, sinon Google ne verra jamais le noindex.

Comment forcer Google à réindexer une page Magento corrigée ?

Après avoir corrigé la config et vidé le cache Magento (et purgé le CDN sur Cloud), va dans la Search Console > outil d'inspection d'URL, saisis l'URL et clique sur "Demander une indexation". Fais-le sur tes pages prioritaires ; pour le reste du catalogue, assure-toi que le sitemap.xml est soumis et déclaré dans le robots.txt, le recrawl se fera par lots.

Faut-il bloquer /catalogsearch/ dans le robots.txt Magento ?

Oui. Les résultats de recherche interne (/catalogsearch/) génèrent des pages de faible qualité et dupliquées qui peuvent déclencher un filtre type Panda. Bloque /catalogsearch/ ainsi que les paramètres de tri et filtrage (?dir=, ?limit=, ?mode=, ?order=, ?price=). En revanche, ne bloque jamais /catalog/product/view/ ni /catalog/category/view/ : ce sont tes pages à indexer.