Un client m'a appelé un mardi matin au printemps dernier — la vraie panique dans la voix. Il gérait un site d'annonces immobilières, environ 42 000 pages, et Google Search Console venait de lui dire que seulement 5 800 étaient indexées. Il avait perdu environ 86 % de ses pages indexables, apparemment du jour au lendemain. Pas de mise à jour algorithmique. Pas d'action manuelle. Pas de déploiement récent dont il se souvenait. Simplement... disparues.
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.When a 40,000-page WordPress site has 6,000 pages indexed, the cause is almost always architecture: faceted URLs, thin templates, and crawl waste, not a Google penalty.
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.WordPress builds. And the maddening thing is that indexation loss on large sites rarely has one cause. It's usually three or four small failures that compound quietly until something collapses.
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, c'est d'ouvrir le rapport Pages dans Google Search Console. Pas l'ancien rapport Coverage — Google l'a mis à jour en 2023, et la nouvelle vue Pages décompose les pages indexées et non indexées avec les vrais codes de raison. Prenez une capture d'écran le premier jour. Vous avez besoin d'une référence.Pages report in Google Search Console. Not the old Coverage report -- Google updated this in 2023, and the new Pages view breaks down indexed vs. non-indexed with proper reason codes. Take a screenshot on day one. You need a baseline.
Les codes de raison sont extrêmement importants. « Crawlé — actuellement non indexé » est un problème complètement différent de « Exclu 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 le mauvais problème.
Les raisons que je vois le plus souvent sur les grands sites
- Crawlé — actuellement non indexé : Google a visité la page mais a décidé qu'elle ne valait pas la peine d'être indexée. Généralement du contenu mince, des quasi-doublons, ou des pages qui ne gagnent pas de backlinks ni de liens internes.: Google visited the page but decided it wasn't worth indexing. Usually thin content, near-duplicates, or pages that don't earn backlinks or internal links.
- Découvert — actuellement non indexé : 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 crawl budget, pas un problème de contenu.: Google found the URL (likely in your sitemap) but hasn't bothered to crawl it yet. This is a crawl budget problem, not a content problem.
- Exclu par la balise « noindex » : Quelqu'un — peut-être vous, peut-être un plugin — a ajouté une directive noindex. Plus sur ce point ci-dessous.: Someone -- possibly you, possibly a plugin -- added a noindex directive. More on this below.
- Doublon, Google a choisi un canonique différent : Vos balises canoniques pointent quelque part d'inattendu, ou Google les ignore.: Your canonical tags are pointing somewhere unexpected, or Google is overriding them.
- Page avec redirection : Une page qui devrait être indexable redirige quelque part, correctement ou non.: A page that should be indexable is redirecting somewhere, either correctly or incorrectly.
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 gros client e-commerce — environ 28 000 pages de produits — et nous n'arrivions pas à comprendre pourquoi Google ne crawlait que environ 3 000 pages par jour. Le site était rapide. Le sitemap était propre. Tout avait l'air correct en surface.
Il s'est avéré 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 épuisaient l'allocation de crawl de Googlebot avant qu'il n'atteigne jamais les vraies pages de produits.?colour=red&size=large&sort=price -- that were crawlable, not canonicalised properly, and eating through Googlebot's crawl allowance before it ever reached the real product pages.
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 propre de Google sur le crawl budget vaut vraiment la peine d'être lue -- ils sont honnêtes sur son fonctionnement. La version courte : si vous le gaspillez sur des URLs inutiles, les pages importantes ne sont pas crawlées.Google's own documentation on crawl budget is genuinely worth reading -- they're honest about how it works. The short version: if you're wasting it on garbage URLs, the important pages don't get crawled.
Comment Auditer Vraiment le Budget de Crawl
- Récupérez vos logs serveur. Pas les stats de crawl de Google -- les logs serveur réels. Des outils comme Screaming Frog Log File Analyser vous permettent de filtrer purement sur les hits de Googlebot.Screaming Frog Log File Analyser let you filter purely for Googlebot hits.
- 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.
robots.txtfor parameters that should never be crawled. Canonical tags for everything else.
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.robots.txt and added rel="canonical" to all filtered views. Within six weeks, indexed pages went from 8,000 to 24,000. Same content. Just Googlebot finally reaching it.
---
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 que personne n'attend. Et certains plugins SEO -- Yoast, Rank Math, même AIOSEO -- ont leurs propres bascules noindex au niveau du type de contenu, au niveau de la taxonomie, et au niveau de chaque page. N'importe lequel d'entre eux peut silencieusement noindex d'énormes portions de votre site.
Comment vérifier le noindex à grande échelle
Lancez Screaming Frog sur le site complet et filtrez pour les pages renvoyant une directive noindex. Exportez la liste. Ensuite, recoupez par rapport à vos groupes d'URLs importants -- pages de produits, pages de services, articles de blog, tout ce qui compte pour l'entreprise.noindex directive. Export the list. Then cross-reference against your important URL groups -- product pages, service pages, blog posts, whatever matters to the business.
Vérifiez aussi votre robots.txt sur votredomaine.com/robots.txt. Cherchez des règles Disallow : trop larges. J'ai vu des règles comme Disallow: /wp-content/ bloquant le CSS et le JS dont Google a besoin pour renvoyer les pages correctement -- ce qui peut causer des échecs de rendu qui ressemblent à des problèmes d'indexation mais sont en réalité Googlebot voyant une page cassée.robots.txt at yourdomain.com/robots.txt. Look for overly broad Disallow: rules. I've seen rules like Disallow: /wp-content/ blocking CSS and JS that Google needs to render pages properly -- which can cause rendering failures that look like indexation problems but are actually Googlebot seeing a broken page.
---
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 schéma 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 canonique, mais si ces canoniques 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./product/red-shoes/, /product-category/footwear/red-shoes/, and sometimes /shop/red-shoes/. Each one has a canonical tag, but if those canonicals point to slightly different URLs (HTTP vs HTTPS, trailing slash vs no trailing slash, www vs non-www), Google treats them as signals pointing to different pages and refuses to consolidate.
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..htaccess redirects or your CDN's URL normalisation. You have to verify the rendered canonical, not just what the plugin thinks it's outputting. Fetch the page with a tool like httpstatus.io and inspect the actual response headers and HTML.
---
Les Plans XML Sont Souvent Inexacts sur les Gros Sites
La plupart des plugins WordPress SEO génèrent des 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'auteurs, les pages de tags avec deux articles dessus, les pages de pièces jointes./page/2/, /page/3/), author archives, tag pages with two posts on them, attachment pages.
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 habituellement 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.documented limits here.
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 -- cela me fait encore mal de le dire -- la page de connexion WordPress. Nettoyez-la 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 qui pointe vers elle, Googlebot risque de ne jamais la trouver 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 compte. Ce sont des signaux différents.matters. Those are different signals.
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 parcours le contenu pour trouver des endroits logiques où ajouter des liens. Pas des liens forcés -- des liens vraiment 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.
robots.txtfor accidental broad disallows. - 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 canonical -- le rendu final, 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 de la page -- les pages qui dépassent régulièrement les délais d'attente 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 indexée il y a six mois peut être supprimée si elle n'a reçu aucun lien, n'est pas linkée en interne, ou si l'évaluation de 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 fait un nouveau crawl, réévalue, et décide parfois que les pages précédemment indexées ne franchissent plus la barre.
La vitesse du site affecte-t-elle l'indexation ?
Oui, beaucoup plus directement que la plupart des gens le réalisent. Si les pages répondent lentement -- régulièrement plus de 2-3 secondes pour la réponse initiale du serveur -- Googlebot les déprioritise lors du crawl. À grande échelle, cela signifie que les pages lentes ne sont tout simplement pas crawlées assez souvent pour rester indexées. Corrigez votre Time to First Byte (TTFB) avant de vous préoccuper de n'importe quel autre aspect lié à la vitesse. Un plugin de cache peu coûteux comme WP Rocket fait une différence mesurable. Les Core Web Vitals comptent pour les classements, mais le TTFB compte pour le crawl.Core Web Vitals matter for rankings, but TTFB matters for crawling.
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 maigres, Google apprend à traiter votre sitemap comme du bruit. Gardez les sitemaps serrés et de haute qualité. Pensez-y comme à une curation éditoriale, pas à 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 ne essayez pas de demander manuellement l'indexation de milliers d'URLs. Ça ne passe pas à l'échelle et Google a dit que ça ne donne pas un traitement spécial aux URLs demandées manuellement à long terme. Corrigez les problèmes de crawl et de qualité sous-jacents et laissez le crawl 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.can be indexed, not to force index everything.
---
La vérité honnête est que le diagnostic d'indexation n'est pas un travail glamour. C'est des feuilles de calcul, des fichiers logs, et beaucoup d'attente. Mais sur un grand site, même récupérer 20% de vos pages indexées perdues peut signifier un bond significatif du trafic organique -- et sur une propriété listings de 40 000 pages, c'est de l'argent réel. Maîtrisez les fondamentaux avant de chasser quelque chose d'exotique. C'est presque jamais exotique.