Sitemap WordPress qui n’est pas indexé : causes courantes et solutions

Ce que signifie réellement « sitemap non indexé »

Les gens disent « mon sitemap n’est pas indexé » quand ils veulent dire une des quatre choses suivantes :

• Google ne peut pas récupérer le sitemap (réseau, DNS, TLS, authentification, robots, WAF, 4xx/5xx, boucles de redirection).
• Google le récupère mais ne peut pas l’analyser (mauvais content-type, HTML au lieu de XML, XML cassé, problèmes gzip, fichiers trop volumineux, dates invalides, URL invalides).
• Google l’analyse mais ignore les URL (bloquées par robots, noindex, discordance canonique, soft 404, doublons, faible qualité, signaux de spam).
• Google indexe certaines URL mais pas d’autres (budget de crawl, URLs facettées, mauvais maillage interne, contenu mince, gonflement par paramètres).

Un sitemap n’est pas une garantie d’indexation. C’est un indice. Un bon indice facilite la découverte et la priorisation ; un mauvais indice n’est que du bruit qui se fait déprioriser. Votre travail est de le rendre récupérable, analysable et digne de confiance.

Une réalité opérationnelle : « Soumis » ou même « Succès » dans Search Console n’est pas un test binaire. C’est le statut d’une étape dans une chaîne multi-étapes. Traitez-le comme un HTTP 200 renvoyé par un reverse proxy : agréable, mais pas la preuve que l’application fonctionne.

Faits et contexte historique (pourquoi c’est plus difficile que ça en a l’air)

• Les sitemaps sont relativement récents. Le protocole XML Sitemaps a été introduit en 2005 ; avant cela, la découverte reposait surtout sur les liens et la chance.
• Les moteurs de recherche traitent les sitemaps comme des indices, pas des commandes. Ce lastmod que vous mettez est consultatif ; s’il semble peu fiable, il est déprécié.
• Google prend en charge les fichiers d’index de sitemaps depuis des années car un seul sitemap est limité (généralement 50 000 URLs et ~50 Mo non compressés). Les gros sites doivent splitter.
• WordPress n’a livré un sitemap natif qu’à WordPress 5.5 (2020). Avant cela, les plugins dominaient—et certains entrent encore en conflit avec le cœur.
• Robots.txt précède les sitemaps de plus d’une décennie. Il date du milieu des années 1990, et il ruine encore discrètement le SEO moderne quand quelqu’un colle un blocage « temporaire » en production.
• Les balises canoniques ont changé la donne. Si l’URL de votre sitemap n’est pas d’accord avec votre canonical, Google fait souvent confiance au canonical et ignore l’entrée du sitemap.
• Les CDN sont devenus une infrastructure par défaut. Formidable pour la latence. Aussi formidable pour mettre en cache la mauvaise chose indéfiniment si vous le laissez faire.
• Les bugs de migration HTTPS sont éternels. Les mélanges http/https dans les sitemaps restent l’une des pannes « ça a l’air ok pour un humain » les plus courantes.
• Les WAF et la mitigation de bots sont maintenant courants. Beaucoup de préréglages « sécurité » défient Googlebot avec du JS/CAPTCHA—puis vous vous demandez pourquoi la découverte s’effondre.

Mode d’emploi de diagnostic rapide (première/Deuxième/Troisième)

Première étape : confirmer ce que Google tente de récupérer

1. Dans Search Console, vérifiez l’URL exacte du sitemap que vous avez soumis (http vs https, www vs apex, slash final, chemin).
2. Vérifiez le statut de récupération du sitemap et le « Dernier accès ». Si « Impossible de récupérer », arrêtez de théoriser et commencez l’HTTP.
3. Choisissez une URL du sitemap qui devrait être indexée. Inspectez-la dans Search Console (URL Inspection) et notez : « Crawled as », « Indexing allowed? », « User-declared canonical », « Google-selected canonical ».

Deuxième étape : reproduire depuis l’extérieur avec curl

1. Récupérez le sitemap avec curl et suivez les redirections. Vérifiez le code de statut, le content-type et le début du corps.
2. Vérifiez qu’il est XML (ou XML compressé en gzip), pas HTML, pas une page de connexion, pas une page d’erreur mise en cache.
3. Validez que la chaîne de redirections est courte et stable (1–2 sauts maximum).

Troisième étape : tracer la panne dans votre pile

1. Vérifiez les logs serveur pour les tentatives de récupération par Googlebot et les réponses (codes de statut, octets, user agent, emplacement edge si derrière CDN).
2. Vérifiez robots.txt, les balises meta robots et les en-têtes HTTP (X-Robots-Tag).
3. Vérifiez les conflits de plugins (sitemap natif vs Yoast/Rank Math) et les couches de cache renvoyant des variantes erronées.

Si vous réalisez ces trois phases dans cet ordre, vous trouverez généralement le goulot d’étranglement en moins de 20 minutes. Si vous sautez directement à « réinstaller le plugin SEO », vous réinitialisez juste l’imprimante.

Modes de panne qui empêchent l’indexation du sitemap

1) L’URL du sitemap est « correcte » dans votre tête, incorrecte en réalité

WordPress peut exposer plusieurs endpoints de sitemap selon le cœur et les plugins :

• Core: /wp-sitemap.xml (et index associés).
• Yoast: /sitemap_index.xml
• Rank Math: /sitemap_index.xml (même chemin, générateur différent)

Désordre fréquent : vous soumettez /wp-sitemap.xml mais un plugin désactive le core et sert autre chose, ou votre reverse proxy réécrit le chemin et renvoie une page d’erreur HTML en 200. Google ne « devine » pas. Il échoue ou ignore.

2) Robots.txt bloque le sitemap ou les URL qu’il contient

Bloquer la récupération du sitemap est évident. Bloquer les URL listées dans le sitemap est plus sournois : le sitemap peut être récupéré et analysé, mais aucune de ses URL n’est éligible au crawl.

3) Noindex, X-Robots-Tag ou un en-tête de sécurité ferment la porte

Les sites WordPress accumulent souvent du noindex à trois endroits :

• Balise meta dans le HTML (<meta name="robots" content="noindex">), souvent activée par « Décourager les moteurs de recherche » ou un réglage de plugin SEO.
• En-tête HTTP (X-Robots-Tag: noindex), généralement défini par des règles nginx/Apache ou un plugin de sécurité.
• Directives robots dans robots.txt qui interdisent le crawl.

4) Discordance canonique et variantes d’URL dupliquées

Si votre sitemap liste http://example.com/page mais que la page a un canonical https://www.example.com/page/, Google traitera souvent l’entrée du sitemap comme un indice de faible qualité. Multipliez cela par des milliers et le sitemap devient du bruit de fond.

5) Le sitemap renvoie du HTML (ou JSON) au lieu de XML

Cela arrive à cause du cache, de challenges WAF, du « mode maintenance » ou de pages forçant la connexion. Votre navigateur peut rendre quelque chose qui paraît plausible ; Googlebot voit une variante différente. Si votre CDN fait de la variation par appareil ou par bot, félicitations : vous avez créé un split-brain.

6) 200 OK avec une charge d’erreur (échecs doux)

Opérationnellement, le pire bug est un 200 OK avec un corps qui dit « Erreur ». Certains plugins et thèmes font ça. Certains reverse proxies le font quand l’amont est down et qu’une page mise en cache est servie. Google analysera les données inutiles et passera à autre chose.

7) Chaînes de redirection, boucles et « normalisation » trop zélée

Trois redirections ne sont pas une stratégie. Les longues chaînes gaspillent le budget de crawl et cassent parfois la récupération. Les boucles de redirection sont explicites et pourtant surviennent encore parce que quelqu’un a « corrigé » www→apex et apex→www à des couches différentes.

8) Erreurs serveur et limitation de débit

Googlebot est poli, mais il se retire si vous renvoyez des 429 ou des 5xx incohérents. Si la récupération du sitemap renvoie des 503 pendant les pics, Search Console peut afficher des échecs intermittents. Cela se traduit par une découverte retardée, et « découverte retardée » devient « non indexé » dans le langage exécutif.

9) Sitemaps volumineux et génération lente

La génération dynamique de sitemaps peut être coûteuse sur WordPress. Si générer /sitemap_index.xml déclenche de lourdes requêtes base de données et expire derrière votre proxy, vous verrez une sortie partielle, du XML tronqué ou des 504. Fractionner les sitemaps aide, mais la mise en cache et la pré-génération aident davantage.

10) Mauvaise hygiène du lastmod (érosion de confiance)

Si chaque URL affiche le même timestamp lastmod, tous les jours, pour toujours, Google apprend que c’est sans intérêt. Si votre sitemap prétend toujours « tout a changé », Google l’ignorera comme le garçon qui criait au déploiement.

Idée paraphrasée de Werner Vogels : Tout échoue tout le temps ; construisez des systèmes qui tolèrent l’échec et récupèrent rapidement. Cela s’applique au plumbing SEO aussi : concevez pour la justesse, l’observabilité et la dégradation gracieuse.

Petite blague #1 : Un sitemap qui « s’indexe lui-même » est comme un pager qui accuse réception de ses propres alertes—réconfortant, mais inutile.

Tâches pratiques : commandes, sorties et décisions (12+)

Ces tâches supposent que vous avez un accès shell depuis un hôte pouvant atteindre votre site (un bastion, un runner CI, ou même votre serveur web). Remplacez example.com par votre domaine. L’important n’est pas la commande exacte ; c’est la décision que vous prenez à partir de la sortie.

Task 1: Fetch the sitemap and verify status, redirects, and content-type

cr0x@server:~$ curl -sSIL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/sitemap_index.xml
HTTP/2 301
location: https://www.example.com/sitemap_index.xml

HTTP/2 200
content-type: application/xml; charset=UTF-8
cache-control: max-age=300

Ce que cela signifie : Une redirection vers l’hôte canonique, puis un 200 avec content-type XML. C’est sain.

Décision : Si vous voyez 403/503/429, corrigez d’abord l’edge/WAF/les limites de débit. Si le content-type est text/html, allez chasser la couche qui renvoie du HTML.

Task 2: Confirm the body is actually XML (not a login page)

cr0x@server:~$ curl -sS -A "Googlebot" https://www.example.com/sitemap_index.xml | head -n 5


  
    https://www.example.com/post-sitemap.xml

Ce que cela signifie : Démarre par la déclaration XML et un nœud sitemapindex. Bien.

Décision : Si vous voyez du HTML (<!doctype html>) ou une page « Veuillez activer les cookies », votre WAF/CDN sert la mauvaise variante aux bots.

Task 3: Validate sitemap XML well-formedness quickly

cr0x@server:~$ curl -sS https://www.example.com/post-sitemap.xml | xmllint --noout -
cr0x@server:~$ echo $?
0

Ce que cela signifie : Code de sortie 0 signifie que le XML est bien formé.

Décision : Un code non nul signifie XML cassé. Corrigez la génération (plugin/thème), la troncature (timeouts), ou la compression (gzip double) avant toute autre chose.

Task 4: Check for accidental noindex via HTTP headers

cr0x@server:~$ curl -sSI https://www.example.com/ | egrep -i "x-robots-tag|location|content-type"
content-type: text/html; charset=UTF-8
x-robots-tag: noindex, nofollow

Ce que cela signifie : Votre site entier est en noindex au niveau des en-têtes.

Décision : Supprimez ou restreignez cet en-tête. S’il vient de nginx/Apache, corrigez la config. S’il vient d’un plugin de sécurité, désactivez la fonctionnalité ou appliquez une liste blanche.

Task 5: Check robots.txt fetch and contents (including sitemap directive)

cr0x@server:~$ curl -sS https://www.example.com/robots.txt
User-agent: *
Disallow: /wp-admin/
Disallow: /
Sitemap: https://www.example.com/sitemap_index.xml

Ce que cela signifie : Disallow: / bloque tout. La directive sitemap ne l’emporte pas.

Décision : Retirez le disallow global (sauf si vous voulez vraiment cacher le site). Si un staging en a besoin, ne copiez pas robots.txt de staging en prod.

Task 6: Check the sitemap URLs for mixed host/protocol and redirects

cr0x@server:~$ curl -sS https://www.example.com/post-sitemap.xml | grep -Eo "[^<]+" | head
http://example.com/hello-world/
http://example.com/about/
http://example.com/contact/

Ce que cela signifie : Le sitemap émet des http et le domaine apex, pas votre canonical https://www.

Décision : Corrigez les réglages Site URL/Home URL de WordPress, les paramètres de plugin, et tout filtre codé en dur. Puis resoumettez le sitemap. Ne comptez pas sur des redirections comme « solution ».

Task 7: Sample a URL from the sitemap and verify canonical and robots meta

cr0x@server:~$ curl -sS https://www.example.com/hello-world/ | egrep -i "

Ce que cela signifie : Le canonical correspond à l’URL et elle est indexable.

Décision : Si le canonical pointe ailleurs ou si la meta robots affiche noindex, corrigez le template/les règles du plugin SEO. Si c’est intentionnel (archives de tags, recherche interne), retirez ces URLs du sitemap.

Task 8: Detect if the sitemap is being gzipped or double-compressed

cr0x@server:~$ curl -sSI -H "Accept-Encoding: gzip" https://www.example.com/post-sitemap.xml | egrep -i "content-encoding|content-type"
content-type: application/xml; charset=UTF-8
content-encoding: gzip

Ce que cela signifie : Gzip est activé ; c’est acceptable.

Décision : Si vous voyez du contenu gzippé mais que le corps n’est pas réellement gzip (ou gzip dans gzip), corrigez les réglages de compression serveur/CDN. Googlebot est patient, pas devin.

Task 9: Confirm the sitemap is not blocked by basic auth or IP allowlists

cr0x@server:~$ curl -sSIL https://www.example.com/sitemap_index.xml | head
HTTP/2 401
www-authenticate: Basic realm="Restricted"

Ce que cela signifie : Le sitemap est protégé par authentification. Google ne peut pas le récupérer.

Décision : Retirez l’auth pour les chemins publics ou protégez seulement les zones admin. Si c’est un environnement de staging, ne soumettez pas son sitemap.

Task 10: Check nginx access logs for Googlebot sitemap fetches and status codes

cr0x@server:~$ sudo grep -E "Googlebot|sitemap" /var/log/nginx/access.log | tail -n 5
203.0.113.10 - - [27/Dec/2025:10:21:12 +0000] "GET /sitemap_index.xml HTTP/2.0" 200 1249 "-" "Googlebot/2.1"
203.0.113.10 - - [27/Dec/2025:10:21:13 +0000] "GET /post-sitemap.xml HTTP/2.0" 503 182 "-" "Googlebot/2.1"

Ce que cela signifie : L’index a été récupéré, mais un sitemap enfant échoue de manière intermittente avec un 503.

Décision : Stabilisez l’origine pour les sitemaps enfants (timeouts, saturation PHP-FPM, base de données). Google considérera les hôtes de sitemap instables comme peu fiables.

Task 11: Look for PHP-FPM saturation that causes intermittent 504/503

cr0x@server:~$ sudo tail -n 8 /var/log/php8.2-fpm.log
[27-Dec-2025 10:21:13] WARNING: [pool www] server reached pm.max_children setting (20), consider raising it
[27-Dec-2025 10:21:13] WARNING: [pool www] child 1942 said into stderr: "script_filename = /var/www/html/index.php"

Ce que cela signifie : Votre pool PHP est saturé. La génération de sitemap peut provoquer le basculement lors des crawls.

Décision : Ajoutez du cache pour les endpoints de sitemap, augmentez la capacité prudemment, ou réduisez les requêtes DB coûteuses. Ne montez pas simplement pm.max_children sans calcul mémoire.

Task 12: Verify WordPress “Discourage search engines” setting via wp-cli

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp option get blog_public
0

Ce que cela signifie : WordPress est configuré pour décourager l’indexation (connexion fréquente avec des noindex via plugins/thèmes ou impact sur robots).

Décision : Positionnez-le à 1 en production, puis confirmez la sortie effective des en-têtes/meta/robots.

cr0x@server:~$ wp option update blog_public 1
Success: Updated 'blog_public' option.

Task 13: Confirm which sitemap generator is active (plugin conflicts)

cr0x@server:~$ wp plugin list --status=active
+--------------------+--------+-----------+---------+
| name               | status | update    | version |
+--------------------+--------+-----------+---------+
| wordpress-seo      | active | none      | 22.5    |
| rank-math          | active | available | 1.0.225 |
| wp-super-cache     | active | none      | 1.12.3  |
+--------------------+--------+-----------+---------+

Ce que cela signifie : Deux plugins SEO actifs. C’est comme ça qu’on obtient des canoniques opposés, des sitemaps opposés et des responsabilités partagées.

Décision : Choisissez un plugin SEO. Désactivez l’autre. Puis confirmez l’endpoint sitemap et le comportement canonique à nouveau.

Task 14: Verify that the sitemap isn’t cached incorrectly by your CDN

cr0x@server:~$ curl -sSI https://www.example.com/sitemap_index.xml | egrep -i "cf-cache-status|age|via|x-cache"
cf-cache-status: HIT
age: 86400

Ce que cela signifie : Le CDN sert un sitemap mis en cache depuis un jour. Cela peut être acceptable—sauf s’il a mis en cache une page d’erreur ou du contenu obsolète après une migration.

Décision : Purgez les URLs de sitemap, définissez un TTL raisonnable, et envisagez des exceptions « Cache Everything ». Les sitemaps peuvent être mis en cache, mais pas indéfiniment erronés.

Task 15: Check database performance impact if sitemaps are dynamic

cr0x@server:~$ mysql -NBe "SHOW FULL PROCESSLIST" | head
12345	root	localhost	wp	Query	2	Sending data	SELECT ID, post_title FROM wp_posts WHERE post_status='publish' ORDER BY post_modified DESC LIMIT 50000

Ce que cela signifie : La génération du sitemap peut exécuter des requêtes lourdes. Sur des DB partagées, cela entre en concurrence avec les chargements de pages.

Décision : Mettez en cache la sortie du sitemap, pré-générez-la, ou optimisez les requêtes/indexes. Si votre endpoint sitemap est « lent », Googlebot l’apprendra et viendra moins souvent.

Trois mini-récits d’entreprise tirés du terrain

Mini-récit 1 : L’incident causé par une fausse hypothèse

Ils ont migré un site marketing WordPress derrière un CDN et un nouveau WAF brillant. L’équipe a supposé : « Si la page d’accueil fonctionne dans un navigateur, Google peut la crawler. » Cette hypothèse avait sa place dans un musée à côté de Netscape.

Search Console a commencé à montrer des erreurs de récupération du sitemap. Le responsable SEO a escaladé, l’équipe plateforme a haussé les épaules, et tout le monde a pointé du doigt. L’URL du sitemap renvoyait 200 et semblait correcte—dans un navigateur normal. Lorsqu’on la récupérait avec un user agent bot, le WAF servait une page de challenge JavaScript. Toujours 200. Toujours « ok » pour quiconque ne l’analysait pas comme du XML.

La correction a été embarrassante de simplicité : une règle WAF pour autoriser les crawlers vérifiés à récupérer les endpoints sitemap et les chemins clés sans challenge. Le vrai travail a été d’instaurer la discipline : tests curl en CI, un contrôle synthétique « bot fetch », et une politique « les contrôles de sécurité doivent être observables ».

Après le changement, l’indexation a récupéré lentement sur plusieurs jours. Ce délai a provoqué plus de drame que la panne elle-même. Mais c’est le principe : le crawling est finalement consistant, et la chaîne a du backoff. Si votre organisation ne supporte pas la gratification différée, ne cassez pas la découverte.

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre société a voulu accélérer les choses en mettant tout en cache à l’edge. Leur règle CDN : mettre en cache le HTML 24 heures, ignorer les query strings, et « optimiser » le contenu. Le site paraissait rapide. Les tableaux de bord sont devenus verts. Tout le monde a fêté et est rentré chez soi tôt.

Puis ils ont lancé une nouvelle gamme de produits et mis à jour des centaines de pages. En interne, les pages étaient à jour. En externe, Googlebot voyait principalement l’ancien contenu. Le sitemap s’est mis à jour à l’origine, mais le CDN continuait de servir un index sitemap ancien avec des valeurs lastmod obsolètes—et parfois une réponse 503 mise en cache que l’origine avait renvoyée pendant un déploiement.

Search Console a rapporté des anomalies : « Le sitemap peut être lu, mais a des erreurs », et les URLs restaient « Découvertes – actuellement non indexées » plus longtemps que d’habitude. L’équipe a essayé de « forcer l’indexation » en resoumettant, ce qui n’a rien fait, car la récupération frappait toujours l’objet edge obsolète.

La solution : définir un comportement de cache explicite pour les endpoints sitemap (TTL court, pas de transformation, cache-key incluant l’hôte, et purge au déploiement). Ils ont aussi arrêté la mise à jour automatique du lastmod pour les pages inchangées car cela entraînait Google à l’ignorer. Le site est devenu légèrement moins « parfait » pour Lighthouse. L’indexation est redevenue beaucoup plus prévisible. Choisissez vos batailles.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Dans une grande entreprise, WordPress n’était qu’une des nombreuses plateformes. Ils avaient une politique terne : chaque nom d’hôte public doit avoir un « runbook de crawlabilité » standard et un contrôle automatisé hebdomadaire qui valide robots, sitemap, et quelques pages canoniques. Pas d’exceptions. Pas de héros.

Un vendredi, un changement DNS destiné au staging a fuité en production : le domaine apex a commencé à rediriger vers un hôte de maintenance pour un sous-ensemble d’utilisateurs. Les navigateurs fonctionnaient parfois grâce au HSTS en cache et au routage en happy-path. Googlebot, cependant, suivait les redirections comme s’il était payé au saut et atterrissait sur une page 404 renvoyant 200 (parce que bien sûr).

Le contrôle automatisé l’a détecté en quelques minutes. Pas parce qu’il était intelligent—parce qu’il était ennuyeux : fetch curl, validation XML, vérification du canonical, alerte sur un content-type non XML. L’astreinte a eu un diff clair de ce qui avait changé, et a rollbacké le DNS avant que la chaîne de crawl ne se retire complètement.

Rien de dramatique ne s’est produit. Et c’est le but. La meilleure panne SEO est celle qui ne devient pas une réunion.

Petite blague #2 : La seule chose plus optimiste qu’un sitemap est le plan de projet qui dit « indexation : 2 jours ».

Erreurs courantes : symptôme → cause racine → correctif

« Impossible de récupérer » dans Search Console

• Symptôme : Search Console affiche « Impossible de récupérer » ou « Échec de la récupération ».
• Cause racine : 401/403 provenant du WAF, authentification, blocages géographiques, listes d’accès IP ; 5xx dû à l’instabilité de l’origine ; problèmes DNS/TLS.
• Correctif : Reproduisez avec curl en utilisant un UA Googlebot ; vérifiez les logs d’accès ; mettez en liste blanche le trafic bot pour les endpoints sitemap ; stabilisez l’origine et retirez l’auth des chemins publics.

« Le sitemap est HTML » ou « Format invalide »

• Symptôme : Search Console se plaint du format, ou rapporte des erreurs d’analyse.
• Cause racine : CDN/WAF renvoie un challenge HTML, une page de connexion, ou une page de maintenance ; timeout PHP tronque le XML.
• Correctif : Assurez content-type: application/xml ; contournez les transformations pour les routes sitemap ; ajoutez du cache pour la génération du sitemap ; augmentez les timeouts en amont seulement si vous traitez aussi la lenteur.

« Succès » mais les URLs ne sont pas indexées

• Symptôme : Le statut du sitemap est « Succès », mais la couverture montre « Découvert – actuellement non indexé » ou « Crawlé – actuellement non indexé ».
• Cause racine : URLs bloquées par robots/noindex ; discordance canonique ; contenu mince/dupliqué ; maillage interne faible ; trop d’URLs de faible valeur.
• Correctif : Choisissez des URLs représentatives et inspectez-les ; retirez le noindex et corrigez les canonicals ; élaguer les sitemaps pour n’y mettre que des URLs dignes d’indexation ; améliorez le maillage interne vers les pages à forte valeur.

Seuls certains sitemaps fonctionnent (fichier d’index ok, sitemaps enfants échouent)

• Symptôme : L’index sitemap est récupéré, mais un sitemap enfant échoue de façon intermittente ou renvoie des 5xx.
• Cause racine : génération dynamique lourde ; PHP-FPM saturé ; DB lente ; cache incohérent ; limitation de débit.
• Correctif : Mettez en cache la sortie des sitemaps enfants ; pré-générez ; séparez par type de post/date ; optimisez PHP-FPM et la DB ; ajoutez de la supervision sur les endpoints sitemap.

L’indexation s’est effondrée après une migration HTTPS ou de domaine

• Symptôme : Les URLs disparaissent ; Search Console montre des problèmes de duplicata et de canonical alternatif.
• Cause racine : variantes mixtes http/https et www/apex dans le sitemap ; anciens canonicals ; boucles de redirection ; normalisation d’hôte incohérente entre CDN et origine.
• Correctif : Choisissez un hôte/protocole canonique ; mettez à jour les réglages WordPress ; régénérez les sitemaps ; gardez les redirections simples et cohérentes à une seule couche ; auditez les balises canoniques.

Massif « Exclu par la balise ‘noindex’ »

• Symptôme : La couverture montre de nombreux URLs exclus à cause du noindex.
• Cause racine : l’option « Décourager les moteurs de recherche » activée ; templates de plugin SEO appliquant noindex aux posts ; en-tête HTTP X-Robots-Tag défini globalement.
• Correctif : Confirmez avec curl ; corrigez à la couche la plus étroite responsable ; puis retirez le noindex du sitemap (ne listez pas ce que vous refusez d’indexer).

« L’URL soumise semble être un Soft 404 »

• Symptôme : Google traite des pages comme soft 404 alors qu’elles renvoient 200.
• Cause racine : contenu mince, templates « aucun résultat », contenu bloqué pour les bots, ou pages d’erreur renvoyant 200.
• Correctif : Renvoyez correctement 404/410 pour le contenu manquant ; évitez le cloaking ; améliorez le contenu réel et le maillage interne ; retirez les URLs inutiles des sitemaps.

Listes de vérification / plan pas-à-pas

Étape par étape : rendre le sitemap récupérable et digne de confiance

1. Choisissez un générateur de sitemap. Le core ou un seul plugin. Désactivez les autres. Les conflits ne sont pas de la « redondance ».
2. Verrouillez votre hôte/protocole canonique. Décidez du https et soit www soit l’apex. Appliquez-le avec une règle de redirection unique à l’edge ou à l’origine (pas les deux qui se battent).
3. Validez le comportement de l’endpoint sitemap. 200, content-type XML, cache raisonnable, pas de transformations, pas d’auth, pas de challenges.
4. Validez les sitemaps enfants. Échantillonnez aléatoirement 5 sitemaps enfants et 10 URLs. Si vous n’échantillonnez pas, vous faites confiance à la partie la plus optimiste de votre pile.
5. Retirez les URLs de faible valeur des sitemaps. Pas d’archives de tags sauf si ce sont de véritables landing pages de valeur. Pas de recherche interne. Pas de pages paginées inutiles. Pas de variantes paramétriques.
6. Corrigez les discordances robots/noindex/canonical. Ne listez pas d’URLs que vous désavouez, noindexez ou canonicalisez ailleurs. C’est une perte de temps pour tout le monde.
7. Rendez la génération de sitemap bon marché. Cachez la sortie. Si elle est dynamique et coûteuse, pré-générez ou utilisez un cache d’objets. Le trafic Googlebot ne doit pas être votre test de charge.
8. Resoumettez le sitemap après des changements réels. Pas par rituel. Resoumettez quand vous avez changé l’endpoint, l’hôte, le protocole, ou retiré des blocages.
9. Surveillez-le comme une API. Des contrôles synthétiques qui valident le content-type et la parseabilité XML battent l’attente passive de Search Console.

Checklist opérationnelle : avant d’accuser Google

• Pouvez-vous récupérer le sitemap depuis un client non-navigateur ?
• Retourne-t-il du XML et se valide-t-il ?
• Y a-t-il des réponses 4xx/5xx/429 dans les logs pour les chemins sitemap ?
• Robots.txt est-il permissif pour le contenu que vous voulez indexer ?
• Les URLs échantillons renvoient-elles des signaux indexables (pas de noindex, canonical conforme) ?
• Votre CDN met-il en cache ou transforme les réponses sitemap ?
• Avez-vous récemment déployé, migré, changé le DNS ou activé un mode WAF ?

Hygiène minimale « connue bonne » pour un sitemap

• Utilisez des URLs absolues dans <loc>, uniquement l’hôte canonique.
• Divisez les sitemaps quand ils sont volumineux ; utilisez un index sitemap.
• Ne mettez lastmod que lorsque le contenu change réellement.
• N’incluez pas d’URLs qui sont noindex, redirigées, ou bloquées par robots.
• Servez avec le bon content-type et un cache stable.

FAQ

Pourquoi Search Console dit « Succès » mais mes pages ne sont toujours pas indexées ?

Parce que « Succès » signifie que Google a récupéré et analysé le sitemap. L’indexation dépend des URLs elles-mêmes : robots/noindex, choix canonique, qualité perçue, doublons et programmation de crawl.

Quel sitemap dois-je soumettre pour WordPress : wp-sitemap.xml ou sitemap_index.xml ?

Soumettez celui que votre site sert réellement comme index sitemap autoritaire. Si vous utilisez un plugin SEO qui fournit /sitemap_index.xml, soumettez celui-ci. Si vous vous reposez sur le core, soumettez /wp-sitemap.xml. Ne soumettez pas les deux sauf si vous aimez les signaux dupliqués.

Un CDN peut-il casser l’indexation d’un sitemap ?

Absolument. Les CDN peuvent mettre en cache des sitemaps obsolètes, transformer le contenu, ou servir des challenges aux bots. Rendez les endpoints sitemap prévisibles : TTL court, pas de réécriture HTML, pas de challenges bot, et purge au déploiement/migration.

Ai-je besoin d’une directive Sitemap dans robots.txt ?

Ça aide mais n’est pas requis si vous soumettez dans Search Console. C’est néanmoins utile car d’autres crawlers l’utilisent, et c’est un point de repère utile en debug.

Dois-je inclure les archives catégories/tags dans mon sitemap ?

Seulement si ces pages sont de véritables pages d’atterrissage avec un contenu unique et utile. Si elles sont fines, dupliquées ou générées automatiquement, noindexez-les et retirez-les du sitemap.

À quelle fréquence mon sitemap doit-il se mettre à jour ?

Quand le contenu significatif change. Évitez de mettre à jour le lastmod pour chaque URL à chaque requête ; cela entraîne les moteurs à ignorer vos timestamps. Cachez le sitemap et régénérez-le sur les événements de publication/mise à jour.

Le réglage WordPress « Décourager les moteurs de recherche » bloque-t-il complètement l’indexation ?

Il peut, selon votre thème/plugins et la façon dont ils l’implémentent. Considérez-le comme une alerte rouge en production. Vérifiez les signaux effectifs avec curl : meta robots et tout en-tête X-Robots-Tag.

Quelle est la façon la plus rapide de savoir si Googlebot est bloqué ?

Vérifiez vos logs d’accès pour des requêtes avec le UA Googlebot sur les chemins sitemap et les pages clés, puis vérifiez les codes de statut et les octets. Combinez cela avec un curl utilisant un UA Googlebot depuis l’extérieur de votre réseau.

Les redirections dans un sitemap importent-elles ?

Oui. Quelques redirections ne vous tueront pas, mais les sitemaps devraient lister les URLs finales canoniques. Si tout redirige, vous gaspillez le budget de crawl et signalez une mauvaise hygiène.

Mon sitemap contient plus de 50 000 URLs. Est-ce un problème ?

Ça devient un problème si c’est un seul fichier. Divisez-le et utilisez un index sitemap. Plus important : vérifiez que ces URLs méritent l’indexation. Les grands sitemaps masquent souvent un problème de qualité, pas technique.

Conclusion : prochaines étapes qui font réellement la différence

Si vous voulez que votre sitemap WordPress favorise l’indexation, cessez de le traiter comme un artefact SEO magique et commencez à le traiter comme un endpoint API avec des consommateurs stricts.

1. Exécutez le mode d’emploi de diagnostic rapide : confirmez l’URL exacte, faites-lui un curl comme Googlebot, puis vérifiez les logs et les directives.
2. Corrigez d’abord la récupérabilité : 200 OK, XML correct, pas d’auth, pas de challenges WAF, pas de cirque de redirections.
3. Corrigez ensuite les signaux de confiance : cohérence canonique, alignement noindex/robots, et n’incluez que les URLs que vous voulez réellement indexer.
4. Rendez-le opérationnel : surveillez les endpoints sitemap, cachez intelligemment, et testez la crawlabilité après chaque migration ou changement CDN/sécurité.

Faites cela, et « non indexé » cesse d’être un mystère angoissant pour devenir un incident simple avec cause racine et ticket de correction. Comme ça devrait toujours être.