Le trafic a chuté : lire le rapport d’indexation avant de paniquer

Quand le trafic organique décroche, le premier réflexe est de soupçonner une mise à jour de l’algorithme ou une pénalité. Dans la grande majorité des cas, la cause est beaucoup plus mécanique, et elle est visible en trois minutes dans le rapport d’indexation de la Search Console : des pages ont cessé d’être indexées, ou n’ont jamais commencé à l’être.

Avant de réécrire quoi que ce soit, il faut donc répondre à une question binaire : vos pages sont-elles encore dans l’index ? Si elles n’y sont pas, aucun travail éditorial ne servira à rien. Cet article explique comment lire ce rapport, quels motifs sont du bruit, lesquels demandent une action, et quelles sont les cinq causes qui expliquent presque toutes les chutes que nous voyons en audit.

Chute de position ou chute d’indexation, ce n’est pas le même problème

La distinction se fait en deux minutes et elle oriente tout le reste. Dans le rapport de performances de la Search Console, comparez les impressions et le nombre de pages qui en génèrent. Si les impressions baissent mais que le nombre de pages reste stable, vous avez un problème de positionnement : vos pages sont toujours là, elles ressortent moins haut. Si le nombre de pages qui reçoivent des impressions s’effondre, vous avez un problème d’indexation.

Le second cas est plus grave et plus facile à corriger, ce qui est une bonne nouvelle. Plus grave parce qu’une page désindexée ne rapporte rien du tout, quel que soit son contenu. Plus facile parce que la cause est presque toujours technique, identifiable et réversible.

Lire le rapport d’indexation sans paniquer

Le rapport d’indexation des pages affiche deux nombres et une liste de motifs. Le premier chiffre à ne pas surinterpréter est celui des pages non indexées. Sur un site qui a quelques années, il est normal qu’il dépasse largement le nombre de pages indexées. Ce qui compte, c’est la répartition par motif, et le sens dans lequel elle évolue.

Les motifs qui sont du bruit

Quatre motifs peuplent la liste sans qu’il y ait quoi que ce soit à faire. « Page avec redirection » regroupe toutes vos anciennes URL qui pointent désormais ailleurs : c’est le comportement attendu, et le volume grossit à chaque renommage. « Autre page avec balise canonique correcte » désigne des doublons que vous avez vous-même déclarés. « Bloquée par le fichier robots.txt » couvre en général l’administration et les points d’API. « Introuvable » sur d’anciennes adresses est sain si ces pages ont réellement disparu.

Un ordre de grandeur pour situer : sur un site multilingue avec quelques années d’historique et plusieurs vagues de renommage, il n’est pas anormal que les redirections représentent à elles seules plusieurs centaines d’URL non indexées. Ce n’est pas un problème, c’est de la mémoire.

Les motifs qui demandent une action

Trois motifs méritent d’être ouverts un par un. « Exclue par la balise noindex » doit correspondre exactement aux pages que vous avez volontairement exclues. Si le volume dépasse cette liste, quelque chose applique un noindex que vous n’avez pas demandé. « Explorée, actuellement non indexée » signifie que Google a lu la page et a décidé qu’elle ne valait pas une place : c’est un signal de qualité, pas de configuration. « Introuvable » sur des URL récentes ou toujours liées depuis votre site trahit des liens internes cassés.

Les cinq causes d’une chute d’indexation

Par ordre de fréquence dans les audits, les voici, avec le moyen de les confirmer.

1. Un noindex parti en production

C’est de loin la cause la plus fréquente, et la plus rapide à vérifier. Une balise posée sur l’environnement de préproduction qui part en production avec le reste, un gabarit dupliqué qui embarque l’en-tête d’un autre, un garde-fou automatique qui exclut des pages selon un critère mal calibré. Le contrôle tient en une commande : afficher le code source de la page et chercher la balise meta robots, ou lire l’en-tête HTTP X-Robots-Tag, que Google documente dans sa page sur les métadonnées de page valides.

Attention au cas particulier des règles automatiques. Un mécanisme qui désindexe des pages selon un test de qualité peut disqualifier bien plus large que prévu si le test est trop strict. Le symptôme caractéristique : une chute nette et datée, portant sur un sous-ensemble cohérent de pages, sans aucune modification éditoriale associée.

2. Une préproduction ouverte au crawl

Un sous-domaine de préproduction accessible sans authentification, avec un robots.txt permissif et un sitemap fonctionnel, est une invitation. Google l’explore, découvre des centaines d’URL, les écarte de l’index si un noindex les protège, et consomme au passage le budget d’exploration qui aurait dû aller sur vos vraies pages.

Exemple relevé lors d’un audit récent : sur 1 805 URL connues de Google, 1 183 étaient non indexées, et 614 d’entre elles provenaient d’un sous-domaine de préproduction laissé ouvert. Plus de la moitié du volume « non indexé » n’avait donc aucun rapport avec le site de production. Le correctif n’est pas un noindex, qui laisse le crawl se produire, mais une authentification, ou à défaut un robots.txt propre à cet environnement et un sitemap qui renvoie une erreur.

3. Une refonte sans plan de redirections

Si les adresses ont changé sans que chaque ancienne URL soit redirigée en 301 vers son équivalente, le référencement acquis part avec elles. La redirection globale vers la page d’accueil, souvent choisie par facilité, revient à repartir de zéro : Google la traite comme une page introuvable déguisée.

Google documente précisément ce scénario dans son guide de migration de site avec changement d’URL : préparer la table de correspondance avant la mise en ligne, conserver les redirections au moins un an, et surveiller le rapport d’indexation dans les semaines qui suivent. Nous détaillons la méthode complète dans notre article sur la refonte de site internet.

4. Un robots.txt trop large

Une règle de blocage ajoutée pour exclure un répertoire technique peut, par un caractère générique mal placé, couvrir bien plus. Le fichier robots.txt se teste directement dans la Search Console, et cette vérification devrait figurer dans la recette de toute mise en production.

5. Du contenu absent de la version mobile

Google indexe le web à partir de la version mobile des pages. Un contenu masqué, tronqué derrière un bouton qui ne charge qu’au clic, ou chargé uniquement sur ordinateur est un contenu que Google ne voit pas. Le symptôme est une perte de positions sur des requêtes longues, sans désindexation apparente : la page reste dans l’index, mais amputée de la moitié de son texte.

Le piège qui empêche de corriger

Une confusion mérite d’être levée, parce qu’elle produit exactement l’inverse de l’effet recherché. Le robots.txt contrôle l’exploration, pas l’indexation. Une page interdite d’exploration peut rester dans les résultats si d’autres pages pointent vers elle, affichée sans description puisque le robot n’a jamais pu lire son contenu.

Surtout, Google précise qu’une page bloquée dans le robots.txt ne peut pas être désindexée : l’instruction noindex se trouve dans la page, et le robot ne la lit jamais. Pour retirer une page de l’index, il faut donc faire l’inverse de l’intuition : la laisser explorable et lui poser un noindex. Bloquer d’abord garantit qu’elle restera indéfiniment.

Se servir de l’inspection d’URL correctement

L’outil qui répond le plus vite est l’inspection d’URL, accessible depuis la barre de recherche en haut de la Search Console. Collez une adresse, et vous obtenez le verdict pour cette page précise : indexée ou non, à quelle date elle a été explorée pour la dernière fois, quelle URL canonique Google a retenue, et si une balise noindex a été détectée. C’est la façon la plus directe de confirmer une hypothèse sur un cas particulier.

Le bouton « Tester l’URL en direct » mérite une mention à part, parce qu’il résout le problème d’attente. Le rapport reflète l’état de la dernière exploration, qui peut dater de plusieurs semaines ; le test en direct va chercher la page maintenant et montre ce que Google voit à cet instant. C’est donc l’outil à utiliser juste après un correctif, pour vérifier que la balise a bien disparu, sans attendre le passage suivant du robot.

La demande d’indexation, en revanche, est souvent mal comprise. Elle place l’URL dans une file d’attente prioritaire, sans garantie ni délai annoncé, et le quota journalier est faible. Elle est utile pour une poignée de pages stratégiques après une correction. Elle ne sert à rien pour rattraper une désindexation massive : dans ce cas, c’est le sitemap et la correction de la cause qui font le travail.

Détectée ou explorée, la nuance qui change le diagnostic

Deux motifs se ressemblent et pointent vers des problèmes opposés. « Détectée, actuellement non indexée » signifie que Google connaît l’URL mais n’est pas encore venu la lire : c’est un sujet de budget d’exploration, souvent lié à un site trop volumineux par rapport à son autorité, ou à des milliers d’URL de faible valeur qui saturent le crawl. « Explorée, actuellement non indexée » signifie qu’il est venu, qu’il a lu, et qu’il a décidé de ne pas indexer : c’est un sujet de qualité ou de duplication.

La confusion coûte cher, parce que les correctifs sont opposés. Dans le premier cas, il faut réduire le nombre d’URL inutiles et renforcer le maillage interne vers les pages importantes. Dans le second, réécrire ou fusionner. Traiter l’un avec la méthode de l’autre ne produit aucun effet.

La méthode de diagnostic, en six étapes

• Séparer position et indexation. Impressions stables mais pages en baisse, ou l’inverse ? La réponse détermine tout le reste.
• Ouvrir le rapport d’indexation et trier par motif. Chercher lequel a bougé, et à quelle date. La courbe par motif est plus parlante que le total.
• Dater la rupture. Une chute nette avec une date précise renvoie vers un déploiement, pas vers un algorithme. Comparer avec l’historique des mises en production est souvent suffisant pour trouver le coupable.
• Vérifier le noindex sur trois pages représentatives. Code source et en-têtes HTTP. Trois minutes, et cela élimine ou confirme la cause la plus fréquente.
• Contrôler le sitemap. Le nombre d’URL déclarées doit correspondre à ce que vous voulez indexer. Google explique dans sa documentation sur les sitemaps qu’il s’agit d’un signal, pas d’une garantie, mais un écart important entre déclaré et indexé est un indice fiable.
• Attendre avant de conclure. Google met plusieurs semaines à réexplorer un site entier. Un correctif déployé aujourd’hui ne se lit pas dans le rapport demain.

Quand c’est vraiment un problème de qualité

Si aucun des cinq points précédents n’explique la chute et que le motif « Explorée, actuellement non indexée » domine, alors le sujet devient éditorial. Google a lu ces pages et jugé qu’elles n’apportaient pas assez pour mériter une place. C’est fréquent sur trois profils de pages : les traductions automatiques non relues, les pages générées à partir d’un même gabarit sans contenu distinctif, et les articles courts qui répètent ce que dit déjà le reste du web.

Le réflexe utile est alors de regrouper plutôt que de multiplier. Deux articles qui visent la même intention de recherche se concurrencent : les fusionner et rediriger l’un vers l’autre vaut mieux que de les laisser se diluer. Et la performance de la page compte aussi dans l’équation, sujet que nous traitons dans notre article sur les Core Web Vitals.

Ce que nous en retenons

Une chute de trafic organique se diagnostique avant de se traiter, et le diagnostic est presque toujours plus rapide qu’on ne le craint. Dans la plupart des cas que nous voyons, la réponse tient dans une date de déploiement et une balise. Le travail éditorial ne vient qu’après, une fois qu’on a la certitude que les pages sont bien dans l’index.

Si votre trafic a décroché et que le rapport d’indexation ne vous parle pas, nous faisons ce diagnostic en une demi-journée : lecture des motifs, datation de la rupture, vérification technique et liste de corrections classée par impact. Parlons-en.