Perdre 99 % de ses pages indexées en trois semaines n'arrive pas par hasard. Voici l'analyse détaillée d'un cas réel — un site de contenu géographique passé de 372 000 à un peu plus de 1 000 pages indexées — et la méthode que nous avons appliquée pour reconstruire un socle sain. Le raisonnement vaut pour tout site qui génère des pages à grande échelle.
Ce que montrait la courbe
Le rapport « Pages » de la Search Console racontait une histoire sans ambiguïté : une chute quasi verticale sur environ trois semaines. Pas une érosion lente, pas un plateau — un effondrement. Sur le total des URL connues, une écrasante majorité tombait dans la catégorie « Explorée, actuellement non indexée ».
Cette catégorie est la plus mal comprise de la Search Console. Elle ne signifie pas « Google n'a pas réussi à voir la page ». Elle signifie l'inverse : Google a exploré la page, l'a comprise, et a décidé de ne pas l'indexer. C'est un verdict de qualité, pas un incident technique. Quand elle concerne quelques pages, c'est normal. Quand elle concerne des centaines de milliers d'URL d'un coup, c'est un signal que le moteur a réévalué le site entier à la baisse.
Les deux causes, et pourquoi l'une a déclenché l'autre
1. La sur-génération de pages quasi-dupliquées
Le site générait des pages par combinaison de critères : {ville}-{code postal}/{catégorie}/{sous-critère}. Mécaniquement, cela produisait plus d'un million de pages, dont l'immense majorité n'avait quasiment aucun contenu propre — la même trame, avec deux ou trois variables changées. Aux yeux de Google, ce sont des pages « doorway » : des pages créées pour capter du trafic de longue traîne, sans valeur ajoutée réelle pour l'utilisateur qui arrive dessus.
Un moteur tolère une certaine dose de contenu généré. Mais quand le ratio bascule — quand 95 % des pages d'un domaine sont des variations creuses — il ne se contente pas d'ignorer ces pages : il révise à la baisse la confiance qu'il accorde au domaine entier. C'est le mécanisme du système « Helpful Content ». La sanction n'est pas locale, elle est globale.
2. Le bug auto-infligé : un noindex piloté par une API en temps réel
Voici le déclencheur du crash, et la leçon la plus importante. Sur les pages « ville », la balise noindex était calculée dynamiquement à partir d'un appel API en direct : « si cette ville a zéro résultat, on met la page en noindex ». L'intention était bonne — éviter d'indexer des pages vides. L'implémentation était un piège.
Sous la charge d'un crawl intensif, l'API interne saturait. Elle renvoyait alors des réponses vides — non pas parce que la ville n'avait aucun résultat, mais parce que le service était momentanément débordé. Le code interprétait cette réponse vide comme « zéro résultat » et appliquait un noindex sur des pages parfaitement valides. Plus Google crawlait vite, plus l'API saturait, plus de pages passaient en noindex à tort. Un cercle vicieux parfait.
La règle à retenir : une directive d'indexation ne doit jamais dépendre d'une ressource qui peut échouer au moment du rendu. Un noindex doit être déterministe et reproductible. S'il dépend d'un appel réseau, une panne transitoire devient une désindexation permanente.
La méthode de reconstruction
Sortir d'une désindexation massive ne se fait pas en « demandant une réindexation ». Il faut retirer la cause, puis reconstruire la confiance. Voici les étapes que nous avons suivies.
Étape 1 — Rendre les directives d'indexation déterministes
Nous avons supprimé toute dépendance à l'API en temps réel pour le calcul du noindex. À la place, une liste construite hors-ligne par une tâche planifiée : elle distingue proprement « zéro résultat confirmé » d'une « erreur réseau ». Le rendu d'une page ne fait plus qu'une lecture locale, instantanée et fiable. Une panne d'API ne peut plus provoquer de désindexation.
Étape 2 — Passer le sitemap en liste blanche
Plutôt que de soumettre toutes les URL possibles et de laisser Google trier, nous avons inversé la logique : le sitemap ne contient que les pages dont on a confirmé la valeur (au moins un résultat réel). C'est une liste blanche, alimentée par la même tâche hors-ligne. On ne demande à Google d'indexer que ce qu'on est prêt à défendre.
Étape 3 — Dégrader proprement au lieu de renvoyer des erreurs
Quand l'API échoue, la page ne doit pas renvoyer une 404 ou une 500. Nous avons ajouté un magasin local de données de secours : en cas d'échec, la page se rend en mode dégradé avec un statut 200, à partir des données locales. Le happy path reste inchangé ; seul le cas d'échec est rattrapé. Google ne voit jamais d'erreur serveur.
Étape 4 — Réduire volontairement la surface
Contre-intuitif mais décisif : nous avons fait passer les millions de pages de dernier niveau en noindex, follow et nous les avons sorties du sitemap. Elles restent explorables et maillées (pour la découverte), mais ne sont plus candidates à l'indexation. L'objectif : concentrer le budget de crawl et le capital de confiance sur quelques milliers de pages excellentes plutôt que de les diluer sur un million de pages moyennes.
Le principe directeur
La philosophie qui sous-tend toute la reconstruction tient en une phrase : 100 000 pages excellentes valent mieux que 560 000 pages moyennes. Google ne récompense pas le volume ; il récompense la proportion de pages qui méritent d'exister. Un site qui génère massivement paie toujours, à un moment, le prix de la dilution.
Si vous exploitez un site à pages générées, posez-vous trois questions avant chaque déploiement :
- Chaque page apporte-t-elle quelque chose qu'un utilisateur ne trouverait pas en trois clics ailleurs ?
- Mes directives d'indexation sont-elles déterministes, ou dépendent-elles d'une ressource faillible ?
- Mon sitemap est-il une liste blanche de pages que je défends, ou un déversoir de tout ce que le code peut produire ?
La récupération, dans notre cas, a été progressive : Google réévalue lentement, sur plusieurs semaines, à mesure qu'il re-crawle un site assaini. Il n'y a pas de bouton « annuler ». La seule voie est de mériter à nouveau l'indexation, page par page.