Un client m'a appelé un mardi matin au printemps dernier, la panique bien audible dans sa voix. Il gérait un site d'annonces immobilières, environ 42 000 pages, et Google Search Console venait de lui dire que seules 5 800 d'entre elles étaient indexées. Il avait perdu environ 86 % de ses pages indexables, apparemment du jour au lendemain. Pas de mise à jour d'algorithme. Pas d'action manuelle. Pas de déploiement récent dont il se souvenait. Elles avaient simplement... disparu.
Point clé : Quand un site WordPress de 40 000 pages n'a que 6 000 pages indexées, la cause est presque toujours l'architecture : les URLs à facettes, les templates minimalistes et le gaspillage de crawl, pas une pénalité Google.
J'ai vu ce scénario exact plus de fois que je ne peux le compter, à travers nos 12 000+ constructions WordPress chez Seahawk. Et ce qui est exaspérant, c'est que la perte d'indexation sur les grands sites a rarement une seule cause. C'est habituellement trois ou quatre petites défaillances qui s'accumulent silencieusement jusqu'à ce que quelque chose s'effondre.
Voici comment je le diagnostique réellement.
---
Commencez Par Google Search Console, Mais Ne Vous Arrêtez Pas Là
La première chose que je fais toujours est d'ouvrir le rapport Pages dans Google Search Console. Pas l'ancien rapport Coverage, Google a mis à jour cela en 2023, et la nouvelle vue Pages ventile les pages indexées et non indexées avec des codes de raison appropriés. Prenez une capture d'écran le premier jour. Vous avez besoin d'une ligne de base.
Les codes de raison sont extrêmement importants. « Crawlée, actuellement non indexée » est un problème complètement différent de « Exclue par la balise 'noindex' ». L'un est un problème de signal de qualité ; l'autre est un désastre de configuration. J'ai vu des développeurs traiter les deux identiquement et perdre des semaines à poursuivre la mauvaise piste.
Les raisons que je vois le plus souvent sur les grands sites
- Crawlée, actuellement non indexée : Google a visité la page mais a décidé qu'elle ne valait pas la peine d'être indexée. Habituellement du contenu mince, des quasi-doublons, ou des pages qui n'attirent pas de backlinks ou de liens internes.
- Découverte, actuellement non indexée : Google a trouvé l'URL (probablement dans votre sitemap) mais ne s'est pas encore donné la peine de la crawler. C'est un problème de budget de crawl, pas un problème de contenu.
- Exclue par la balise 'noindex' : Quelqu'un, peut-être vous, peut-être un plugin, a ajouté une directive noindex. Plus de détails ci-dessous.
- Doublon, Google a choisi un canonique différent : Vos balises canoniques pointent quelque part d'inattendu, ou Google les ignore.
- Page avec redirection : Une page qui devrait être indexable redirige quelque part, correctement ou non.
Ne regardez pas juste les totaux. Téléchargez la liste complète pour chaque code de raison en CSV. Sur un site de 40 000 pages, vous devez pouvoir trier et filtrer.
---
Le Budget de Crawl Est Réel et Il Tuera les Gros Sites
En 2019, Seahawk travaillait avec un grand client e-commerce, environ 28 000 pages de produits, et nous ne pouvions pas comprendre pourquoi Google ne crawlait que environ 3 000 pages par jour. Le site était rapide. Le sitemap était propre. Tout semblait bon en surface.
Il s'avère que le site générait des milliers d'URLs de navigation à facettes, ?colour=red&size=large&sort=price, qui étaient crawlables, pas correctement canonicalisées, et qui consommaient l'allocation de crawl de Googlebot avant même qu'il n'atteigne les vraies pages produit.
Le crawl budget est essentiellement le nombre d'URLs que Googlebot est disposé à crawler sur votre site dans un laps de temps donné. La documentation officielle de Google sur le crawl budget mérite vraiment d'être lue, ils sont honnêtes sur son fonctionnement. La version courte : si vous le gaspillez sur des URLs poubelle, les pages importantes ne se font pas crawler.
Comment Auditer Vraiment le Budget de Crawl
- Extrayez vos logs serveur. Pas les stats de crawl de Google, les vrais logs serveur. Des outils comme Screaming Frog Log File Analyser vous permettent de filtrer uniquement les hits de Googlebot.
- Regardez quel pourcentage des visites de Googlebot atterrissent sur des URLs qui vous importent vraiment. Si c'est en dessous de 60 %, vous avez un problème de budget.
- Trouvez les patterns d'URL qui consomment le plus de crawls. Triez par fréquence. Les principaux coupables sont presque toujours : navigation facettée, pagination sur les archives paginées, paramètres d'ID de session, et pages d'archives de catégories/tags vides.
- Réparez la source, pas juste le symptôme. Disallow dans robots.txt pour les paramètres qui ne devraient jamais être crawlés. Balises canonical pour tout le reste.
Sur ce projet e-commerce, nous avons bloqué les URLs facettées via robots.txt et ajouté rel="canonical" à toutes les vues filtrées. En six semaines, les pages indexées sont passées de 8 000 à 24 000. Même contenu. Googlebot a juste enfin pu y accéder.
---
Le désastre noindex (ça arrive plus souvent qu'on ne le pense)
Je dois en parler parce que je l'ai provoqué moi-même. Pas mon meilleur moment. Lors d'une migration staging-vers-production pour un site d'actualités en 2021, nous avons oublié de décocher « Décourager les moteurs de recherche d'indexer ce site » dans WordPress Paramètres → Lecture. Le site s'est retrouvé en ligne avec un noindex site-wide. Il a fallu onze jours avant que le client remarque que le trafic organique avait chuté dramatiquement.
WordPress cache cette case à cocher dans un endroit auquel personne ne s'attend. Et certains plugins SEO, Yoast, Rank Math, même AIOSEO, ont leurs propres bascules noindex au niveau du type de post, au niveau de la taxonomie, et au niveau de la page individuelle. N'importe lequel d'entre eux peut silencieusement noindex de vastes portions de votre site.
Comment vérifier le noindex à grande échelle
Lancez Screaming Frog sur l'ensemble du site et filtrez les pages renvoyant une directive noindex. Exportez la liste. Puis recoupez-la avec vos groupes d'URLs importants, pages produit, pages de service, articles de blog, tout ce qui compte pour l'entreprise.
Vérifiez aussi votre robots.txt sur yourdomain.com/robots.txt. Recherchez les règles Disallow : trop larges. J'ai vu des règles comme Disallow: /wp-content/ qui bloquent le CSS et le JS dont Google a besoin pour renderer correctement les pages, ce qui peut causer des échecs de rendering qui ressemblent à des problèmes d'indexation mais qui sont en réalité Googlebot voyant une page cassée.
---
Les balises Canonical qui dysfonctionnent silencieusement
Les canonicals sont le tueur d'indexation le plus sournois sur les gros sites WordPress. Parce qu'elles ont l'air correctes en isolation et ne révèlent leurs dégâts qu'à grande échelle.
Voici un motif que je vois constamment : un site avec WooCommerce a des produits accessibles via plusieurs chemins d'URL, /product/red-shoes/, /product-category/footwear/red-shoes/, et parfois /shop/red-shoes/. Chacun a une balise canonical, mais si ces canonicals pointent vers des URLs légèrement différentes (HTTP vs HTTPS, slash final vs pas de slash final, www vs non-www), Google les traite comme des signaux pointant vers des pages différentes et refuse de les consolider.
La solution est ennuyeuse mais nécessaire :
- Auditez chaque structure d'URL que génère votre installation WordPress. Utilisez le site crawl de Screaming Frog → filtrez par "Canonical" → exportez.
- Vérifiez les protocoles non concordants, les barres obliques finales et les variations de sous-domaine.
- Assurez-vous que votre canonical correspond exactement à votre URL préférée, caractère par caractère.
Rank Math et Yoast génèrent tous les deux des balises canonical automatiquement, mais aucun des deux plugins ne connaît vos redirects .htaccess ni la normalisation d'URL de votre CDN. Vous devez vérifier le canonical rendu, pas simplement ce que le plugin croit produire. Récupérez la page avec un outil comme httpstatus.io et inspectez les en-têtes de réponse réels et le HTML.
---
Les Plans XML Sont Souvent Inexacts sur les Gros Sites
La plupart des plugins SEO WordPress génèrent les sitemaps automatiquement. La plupart d'entre eux incluent aussi des URLs que vous ne voulez pas dans votre sitemap, les pages paginées (/page/2/, /page/3/), les archives d'auteur, les pages de tag avec deux posts dessus, les pages d'attachement.
Un sitemap devrait être une liste courte de vos meilleures pages, les plus canonical. Pas un vidage de chaque URL que WordPress a jamais générée.
Les règles d'hygiène de sitemap que j'applique réellement
- Exclure les pages d'archives paginées. Toujours.
- Exclure les pages d'archives auteur sauf s'il s'agit d'un site multi-auteurs où les pages auteur ont une véritable valeur de contenu.
- Exclure les archives de tags sauf si les tags sont gérés éditorialement et ont un contenu significatif.
- Définissez un seuil de nombre de posts, j'exclus généralement toute page d'archive avec moins de cinq posts.
- Diviser les grands sitemaps en index de sitemaps. Gardez les fichiers sitemap individuels sous 10MB et sous 50 000 URLs. Google a documenté les limites ici.
Sur le site d'annonces immobilières du début de cet article, le sitemap avait 41 000 URLs incluant chaque archive de tag, chaque page de pagination, et, ça me fait toujours mal de le dire, la page de connexion WordPress. Nettoyez-le d'abord. Toujours.
---
La liaison interne est un problème d'indexation
Les gens ne pensent pas à la liaison interne comme un outil d'indexation. Ils devraient.
Si une page n'a aucun lien interne pointant vers elle, Googlebot ne la trouvera peut-être jamais en premier lieu, même si elle est dans votre sitemap. Les sitemaps indiquent à Google qu'une URL existe. Les liens internes indiquent à Google qu'une URL a de l'importance. Ce sont des signaux différents.
Sur les gros sites de contenu, les pages orphelines pullulent. Un article de blog publié il y a trois ans, lié depuis les archives des posts mais jamais lié depuis aucun autre post, verra sa fréquence de crawl chuter à pratiquement rien au fil du temps.
J'utilise le rapport « Orphan Pages » de Screaming Frog (sous Site Structure) pour identifier les pages du sitemap qui n'ont zéro lien interne pointant vers elles. Ensuite, je reviens sur le contenu pour trouver des endroits logiques où ajouter des liens. Pas des liens forcés, vraiment des liens pertinents. Ça prend du temps mais l'impact sur l'indexation est réel.
---
Une Checklist de Diagnostic Systématique
Si je devais la remettre à un développeur junior chez Seahawk, voici l'ordre dans lequel je la leur ferais parcourir :
- Extraire Google Search Console → Rapport Pages → télécharger toutes les URL non indexées avec les codes de raison.
- Vérifier le robots.txt pour les disallows accidentels trop larges.
- Vérifier que la case WordPress "Décourager les moteurs de recherche" est décochée.
- Lancer Screaming Frog et filtrer pour les directives noindex au niveau de la page.
- Vérifiez les balises canoniques, le rendu, pas les paramètres du plugin.
- Consultez les journaux serveur et vérifiez la distribution du crawl de Googlebot selon les types d'URL.
- Auditez le sitemap XML pour repérer les URL inutiles (pagination, archives vides, variantes non-canoniques).
- Exécutez le rapport Pages orphelines et identifiez les pages non liées en interne.
- Vérifiez la navigation à facettes ou les URL basées sur des paramètres qui génèrent des chemins dupliqués crawlables.
- Vérifiez la vitesse des pages, les pages qui expirent régulièrement sont déprioritisées par Googlebot.
N'essayez pas de corriger tout d'un coup. Corrigez une catégorie de problème, attendez trois à quatre semaines le recrawl de Google, mesurez, puis passez à la suivante. Si vous changez tout simultanément, vous ne saurez jamais ce qui a vraiment fonctionné.
---
FAQ
Pourquoi les pages sont-elles indexées une semaine et supprimées la suivante ?
L'index de Google n'est pas statique. Il réévalue constamment les pages en fonction des signaux de qualité, de la fraîcheur et de l'efficacité du crawl. Une page qui a été indexée il y a six mois peut être supprimée si elle n'a reçu aucun lien, n'est pas liée en interne ou si l'évaluation de la qualité de votre domaine par Google a changé. C'est particulièrement courant après une migration de site ou une refonte majeure du contenu. Google recrawle, réévalue et décide parfois que les pages précédemment indexées ne répondent plus aux critères.
La vitesse du site affecte-t-elle l'indexation ?
Oui, plus directement que la plupart des gens ne le réalisent. Si les pages mettent du temps à répondre, régulièrement plus de 2-3 secondes pour la réponse initiale du serveur, Googlebot déprioritisera leur crawl. À grande échelle, cela signifie que les pages lentes ne sont tout simplement pas crawlées assez fréquemment pour rester indexées. Corrigez votre Time to First Byte (TTFB) avant de vous inquiéter de toute autre question liée à la vitesse. Un plugin de cache bon marché comme WP Rocket fait une différence mesurable. Core Web Vitals ont de l'importance pour les classements, mais TTFB a de l'importance pour le crawl.
Trop de pages dans un sitemap peuvent-elles nuire à l'indexation ?
Pas directement, mais un sitemap gonflé avec des URLs de faible qualité dilue le signal que vous envoyez à Google sur ce qui compte. Si votre sitemap contient 40 000 URLs et 30 000 d'entre elles sont des pages d'archive minces, Google apprend à traiter votre sitemap comme du bruit. Gardez les sitemaps serrés et de haute qualité. Pensez-y comme à une curation éditoriale, pas comme à un inventaire d'URLs.
Dois-je utiliser l'outil d'inspection des URLs de Google pour demander manuellement l'indexation ?
Pour les pages individuelles importantes, oui, absolument. Mais n'essayez pas de demander manuellement l'indexation de milliers d'URLs. Ça ne monte pas en charge et Google a dit que ça ne donne pas de traitement spécial aux URLs demandées manuellement à long terme. Corrigez les problèmes de crawl et de qualité sous-jacents et laissez le crawling naturel de Google faire le travail. Utilisez l'inspection manuelle pour vérifier que des pages spécifiques peuvent être indexées, pas pour forcer l'indexation de tout.
---
La vérité honnête c'est que le diagnostic d'indexation n'est pas un travail glamour. C'est des feuilles de calcul, des fichiers journaux et beaucoup d'attente. Mais sur un grand site, même récupérer 20% de vos pages indexées perdues peut signifier un saut significatif dans le trafic organique et sur une propriété immobilière de 40 000 pages, c'est de l'argent réel. Maitrisez les bases avant de chasser quoi que ce soit d'exotique. C'est presque jamais exotique.