Comment diagnostiquer pourquoi vos URL WordPress n'apparaissent pas dans l'index Google ?

Pourquoi cette déclaration cible-t-elle spécifiquement WordPress ?

WordPress génère par défaut une architecture de sitemaps imbriqués depuis la version 5.5. Le sitemap principal (wp-sitemap.xml) ne contient pas directement vos URL, mais renvoie vers des sitemaps secondaires (posts, pages, taxonomies). C'est une structure logique à grande échelle, mais elle introduit un niveau d'abstraction supplémentaire.

Cette hiérarchie peut masquer des problèmes d'indexation. Si vous consultez uniquement le sitemap racine, vous ne verrez que des références à d'autres fichiers XML — pas vos contenus. Un crawler mal configuré ou une erreur de génération à n'importe quel niveau de cette cascade peut bloquer la découverte de centaines d'URL sans que vous ne le remarquiez immédiatement.

L'opérateur site: est-il vraiment fiable pour diagnostiquer l'indexation ?

Google suggère d'utiliser site:votredomaine.com pour identifier si un site est indexé. Soyons honnêtes : c'est un premier filtre, pas une vérité absolue. L'opérateur site: donne une estimation, pas un inventaire exhaustif. Les résultats peuvent fluctuer d'un jour à l'autre sans que votre index réel n'ait bougé.

Pour un diagnostic sérieux, il faut croiser plusieurs sources : Search Console (rapport Couverture), logs serveur, analyse des sitemaps soumis. L'opérateur site: vous dira « oui, Google connaît ton domaine », mais ne vous dira jamais pourquoi telle URL manque ou reste en « Découverte, non indexée » depuis trois mois.

Quel est le vrai problème dans cette structure hiérarchique ?

Le nœud du problème, c'est que chaque niveau de sitemap introduit un point de défaillance potentiel. Si wp-sitemap-posts-post-1.xml renvoie une 404 ou contient des URL canonicalisées ailleurs, Googlebot peut tout simplement ignorer ce fichier. Et vous, côté admin, vous ne le saurez que si vous vérifiez manuellement chaque sitemap enfant.

WordPress génère ces sitemaps dynamiquement. Ça signifie qu'un plugin mal codé, un cache agressif ou une règle de réécriture .htaccess maladroite peut casser la génération sans lever aucune alerte visible. Le sitemap principal reste accessible, mais les enfants retournent du vide ou des erreurs 500. Google crawl, trouve rien, et vous ne comprenez pas pourquoi vos nouveaux posts ne remontent pas.

• Architecture en cascade : un sitemap parent pointe vers plusieurs sitemaps enfants spécialisés (posts, pages, catégories).
• Opérateur site: comme premier filtre : utile pour confirmer une présence globale, inutile pour un diagnostic fin.
• Points de rupture multiples : chaque niveau de sitemap peut dysfonctionner indépendamment.
• Génération dynamique : dépend du bon fonctionnement de WordPress, thème, plugins, serveur.
• Vérification manuelle indispensable : consulter chaque sitemap enfant listé dans le sitemap racine pour détecter erreurs ou incohérences.

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, c'est un rappel banal mais nécessaire. En pratique, beaucoup de sites WordPress souffrent d'une méconnaissance totale de leur structure de sitemaps. Les référenceurs installent Yoast ou Rank Math, qui désactivent souvent le sitemap natif de WordPress et en génèrent un autre. Résultat : deux sitemaps cohabitent (ou se marchent dessus), et personne ne sait lequel Google crawl réellement.

Cela dit, la recommandation d'utiliser site: comme outil de diagnostic reste superficielle. Elle ne dit rien sur les URLs découvertes mais non indexées, sur les problèmes de canonicalisation, sur les soft 404 détectés par Google. C'est un conseil générique qui évite soigneusement d'aborder les vraies galères : pagination mal gérée, taxonomies explosées, duplicate content interne.

Quelles sont les limites non dites de cette approche ?

Google ne mentionne pas que l'architecture de sitemaps WordPress est souvent polluée par défaut. Les sitemaps natifs incluent les pages d'auteur, les archives de dates, parfois même les fichiers média — du bruit que vous ne voulez probablement pas indexer. Si vous ne configurez rien, vous envoyez à Googlebot un catalogue bordélique.

Autre silence assourdissant : aucune mention du crawl budget. Sur un gros site WordPress (10 000+ pages), une structure de sitemaps mal optimisée peut diluer les ressources de crawl sur des URL inutiles. Google crawl vos sitemaps d'auteurs avant vos articles de fond, et ensuite vous vous demandez pourquoi vos contenus stratégiques mettent trois semaines à être indexés. [A vérifier] que l'ordre de crawl suive réellement l'ordre des sitemaps enfants — Google n'a jamais documenté ça précisément.

Dans quels cas cette recommandation ne suffit-elle pas ?

Sur un site WordPress headless (API, Nuxt/Next en front), la génération de sitemaps côté serveur peut être totalement custom. Les règles standards ne s'appliquent plus. Si vous servez vos sitemaps depuis un CDN avec cache agressif, Google peut recevoir des versions périmées pendant des jours sans que vous ne le sachiez.

Et que dire des sites multilingues ou multi-régions ? WordPress + WPML ou Polylang génère des sitemaps par langue, mais la coordination entre hreflang et sitemaps est rarement propre. Vous pouvez avoir toutes vos URL dans les sitemaps et rester non indexé parce que Google détecte des incohérences de balisage international. L'opérateur site: ne vous montrera jamais ce problème.

Que faut-il vérifier concrètement sur votre installation WordPress ?

Première action : identifiez quel sitemap est réellement actif. Visitez /sitemap.xml et /sitemap_index.xml pour voir ce qui répond. Comparez avec ce que vous avez déclaré dans la Search Console. Si vous trouvez plusieurs sitemaps différents, désactivez le superflu — un seul doit régner.

Ensuite, ouvrez chaque sitemap enfant listé dans le sitemap principal. Vérifiez qu'ils retournent bien du contenu, pas une 404 ou une redirection. Testez au moins trois ou quatre sitemaps secondaires pour détecter un pattern de défaillance. Si wp-sitemap-posts-post-2.xml plante, il y a fort à parier que les suivants aussi.

Comment croiser les données pour un diagnostic fiable ?

L'opérateur site: vous donne une vue d'ensemble floue. Pour du précis, exportez le rapport de couverture de la Search Console. Filtrez les URL « Découvertes, actuellement non indexées » et croisez avec votre sitemap : ces URL sont-elles dedans ? Si oui, pourquoi Google refuse-t-il de les indexer ? Souvent, c'est un problème de qualité perçue, de contenu léger, ou de duplication interne.

Analysez aussi vos logs serveur. Googlebot crawl-t-il réellement les sitemaps enfants que vous pensez prioritaires ? Si vous constatez que Google ne touche jamais wp-sitemap-taxonomies-category-1.xml, c'est peut-être qu'il le juge inutile — ou qu'un robots.txt mal foutu le bloque sans que vous ne le sachiez.

Quelles erreurs courantes faut-il absolument éviter ?

Ne soumettez jamais plusieurs versions du même sitemap (avec et sans www, http et https, URL absolues et relatives). Google ne sait pas laquelle prioriser et ça brouille le crawl. Normalisez tout avant soumission.

Évitez aussi de laisser WordPress générer des sitemaps pour des types de contenu que vous ne voulez pas indexer (pièces jointes, pages auteur sur un blog mono-auteur). Chaque URL inutile dans un sitemap est une invitation à gaspiller du crawl budget. Configurez votre plugin pour exclure ce bruit dès la génération.

• Vérifier quel sitemap est déclaré dans la Search Console et s'assurer qu'il correspond au sitemap réellement servi par WordPress.
• Ouvrir manuellement les sitemaps enfants listés dans le sitemap racine pour détecter erreurs 404, 500 ou contenu vide.
• Croiser le rapport de couverture Search Console avec le contenu des sitemaps pour identifier les URL découvertes mais non indexées.
• Analyser les logs serveur pour vérifier que Googlebot crawl bien les sitemaps prioritaires et ne se perd pas dans du bruit.
• Désactiver la génération de sitemaps pour les types de contenu non stratégiques (auteurs, dates, médias si non pertinents).
• Tester la cohérence entre sitemap, canonicals, hreflang sur un échantillon d'URL critiques.