Un client m'a appelé un mardi matin au printemps dernier — la vraie panique dans la voix. Il gérait un site de listings immobiliers, 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 algorithmique. Pas d'action manuelle. Pas de déploiements récents dont il se souvenait. C'est tout… disparu.
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, c'est ouvrir le rapport Pages dans Google Search Console. Pas l'ancien rapport de couverture — Google a mis à jour cela en 2023, et la nouvelle vue Pages détaille les pages indexées par rapport aux non-indexées avec des codes de raison appropriés. Prenez une capture d'écran le premier jour. Vous avez besoin d'une base de 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 pas 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 une catastrophe de configuration. J'ai vu des développeurs traiter les deux de la même façon et perdre des semaines à chasser la mauvaise chose.
Les raisons que je vois le plus souvent sur les grands sites
- Crawlé — actuellement pas indexé : Google a visité la page mais a décidé qu'elle n'en valait pas la peine d'être indexée. Généralement du contenu peu fourni, des doublons ou des pages qui n'obtiennent pas de liens externes ou 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 pas indexé : Google a trouvé l'URL (probablement dans votre sitemap) mais n'a pas encore pris la peine de la crawler. C'est un problème de budget de crawl, 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 à ce sujet 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 sur un gros client e-commerce — environ 28 000 pages de produits — et nous ne comprenions pas pourquoi Google ne crawlait que 3 000 pages par jour. Le site était rapide. Le sitemap était propre. Tout avait l'air correct en surface.
Il s'avère que le site générait des milliers d'URLs de navigation facettée — ?colour=red&size=large&sort=price — qui étaient crawlables, non canonicalisées correctement, et qui consumaient 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 budget de crawl est essentiellement le nombre d'URLs que Googlebot est prêt à crawler sur votre site dans un laps de temps donné. La documentation de Google sur le budget de crawl vaut vraiment le coup d'être lue — ils sont honnêtes sur le fonctionnement. En bref : 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
- Extrayez 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 uniquement 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 à un endroit où personne ne l'attend. Et certains plugins SEO — Yoast, Rank Math, même AIOSEO — ont leurs propres bascules noindex au niveau des types de contenu, au niveau des taxonomies, et au niveau des pages individuelles. 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 retournant une directive noindex. Exportez la liste. Ensuite, croisez-la avec vos groupes d'URL importants — pages produits, pages services, articles de blog, peu importe 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 à votredomaine.com/robots.txt. Cherchez des 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 rendre les pages correctement — ce qui peut causer des défaillances de rendu qui ressemblent à des problèmes d'indexation mais qui 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 motif que je vois constamment : un site avec WooCommerce propose des produits accessibles via plusieurs chemins d'URL — /product/red-shoes/, /product-category/footwear/red-shoes/, et parfois /shop/red-shoes/. Chacun possède une balise canonical, mais si ces canonicals pointent vers des URLs légèrement différentes (HTTP vs HTTPS, barre oblique finale vs pas de barre oblique, www vs sans-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'auteur, les pages de tag avec deux posts, 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éfinir un seuil de nombre de posts — j'exclue 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.documented limits here.
Sur le site de listes de propriétés du début de cet article, le sitemap avait 41 000 URLs incluant toutes les archives de tags, toutes les pages de pagination, et — ça 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 pointant vers elle, Googlebot risque de ne jamais la trouver en premier lieu — même si elle figure 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 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 — 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 canoniques — 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 des pages — les pages qui s'arrêtent 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 indexée il y a six mois peut être supprimée si elle n'a reçu aucun lien entrant, n'est pas lié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 recrawle, réévalue, et décide parfois que les pages précédemment indexées ne répondent plus à ses 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 répondent lentement — constamment au-delà de 2-3 secondes pour la réponse serveur initiale — Googlebot déprioritise leur 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 quoi que ce soit d'autre en matière de vitesse. Un plugin de cache bon marché comme WP Rocket fait une différence mesurable. Core Web Vitals sont importants pour les classements, mais TTFB est important 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'archives minces, Google apprend à traiter votre sitemap comme du bruit. Gardez vos sitemaps serrés et de haute qualité. Considérez-le comme une sélection é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 pour des milliers d'URLs. Ça ne passe pas à l'échelle 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.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 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 du trafic organique — et sur un site de propriétés de 40 000 pages, c'est de l'argent réel. Maîtrisez les bases avant de chasser quoi que ce soit d'exotique. C'est presque jamais exotique.