On a diagnostiqué un WordPress de 8 000 articles qui avait un sitemap indexé à 100 %, une Search Console au vert, et pourtant 62 % de ses URLs produit n’avaient pas vu de crawl depuis plus de deux semaines. Le coupable ? Un fichier robots.txt vieux de quatre ans qui laissait passer le sitemap sans interdire les facettes paginées. Le sitemap, lui, listait tout, archive par archive, auteur par auteur, tag par tag. Résultat : Googlebot passait son temps à ramper des pages sans trafic, et les articles frais attendaient leur tour.
Le sitemap que personne ne lit vraiment
La plupart des sitemaps WordPress sont des annuaires téléphoniques qu’on dépose dans la Search Console en espérant que « Google fasse le tri ». Chaque URL listée est une suggestion de crawl. En proposer 30 000 inutiles consomme le budget alloué pour rien. Un sitemap efficace ne contient que des URLs canoniques, en 200, non redirigées, hors noindex. Le reste est du bruit.
Votre robots.txt n’est pas un outil de confidentialité
Ici, on va vouvoyer parce que c’est une question d’architecture qui engage la stratégie de visibilité tout entière. Trop d’administrateurs WordPress considèrent le robots.txt comme un fichier capable de « cacher » des dossiers à Google. C’est faux, et ce depuis des années.
Google peut indexer une page même si elle est interdite dans robots.txt. Si un lien pointe vers cette page depuis un autre site, ou depuis un contenu public, Googlebot enregistre l’URL et peut l’afficher dans les résultats en mode dégradé (« aucune information n’est disponible pour cette page », parce que le robot n’a pas pu la crawler). Le bon outil pour empêcher l’indexation, c’est la balise meta robots noindex ou l’en-tête HTTP X-Robots-Tag. Le robots.txt, lui, contrôle la visite, pas l’indexation. La confusion entre crawl et index reste l’une des premières causes de présence fantôme en SERP.
Pour un WordPress bien tenu, on interdit dans le robots.txt les chemins purement techniques qui n’ont aucune chance de produire du contenu utile : /cgi-bin, /wp-admin, /wp-includes, /wp-content/plugins, /wp-content/cache. On peut aussi y bannir les paramètres de suivi et les facettes triées (?orderby=, etc.) pour éviter les boucles de crawl. En revanche, on ne désindexe pas un répertoire sensible par cette voie. Si vous voulez masquer un staging, un accès client ou un PDF confidentiel, c’est une authentification ou un noindex qu’il faut poser, pas une ligne dans robots.txt.
Ce qui coince avec la génération automatique d’un sitemap WordPress
Les plugins historiques comme XML Sitemap Generator ont rendu service à une époque où WordPress n’embarquait pas de sitemap natif. Aujourd’hui, WordPress génère un sitemap de base via /wp-sitemap.xml. Ce sitemap natif est fonctionnel, mais il manque cruellement de granularité. Il exclut mal les contenus non pertinents, ne permet pas de définir des priorités différenciées par type de contenu, et ne segmente pas le sitemap lorsqu’on franchit le seuil des 50 000 URLs.
Les plugins modernes (comme Yoast SEO, Rank Math, ou The SEO Framework) offrent plus de contrôle. Pourtant, même avec eux, on observe un comportement par défaut qui consiste à tout inclure. Par exemple, ils génèrent souvent des sitemaps séparés pour les catégories, les étiquettes, les auteurs. Or, sur un site e-commerce avec des milliers de produits, la page auteur n’a généralement aucune raison d’être indexée.
Là où l’automatisation devient vraiment gênante, c’est quand les URLs listées ne correspondent pas à la structure canonique du site. Une migration de permaliens non propagée dans les règles du sitemap, un lastmod qui ne reflète pas la vraie date de modification du contenu, et Googlebot se met à recrawler des pages sans changement ou, pire, ignore des mises à jour parce que le signal lastmod est périmé.
💡 Conseil : Sur un site de plus de 10 000 URLs, segmentez le sitemap par type de contenu stratégique et vérifiez mensuellement que les nouvelles URLs apparaissent dans les 24 heures.
Choisir une structure de sitemap que Googlebot exploite vraiment
Ce paragraphe ne vient pas en introduction, il tombe directement dans le vif. Un sitemap index XML (qui pointe vers plusieurs sitemaps fils) fonctionne mieux qu’un fichier monolithique une fois qu’on a dépassé quelques centaines d’URLs. Google lit le sitemap index, y trouve des sous-fichiers, et peut traiter leur contenu en parallèle. Si votre sitemap principal contient 50 000 URLs, vous perdez en visibilité sur les rapports de couverture : un taux d’indexation global de 82 % ne vous dit pas si les fiches produit sont toutes indexées alors que les articles de blog, eux, stagnent.
La segmentation idéale sur un WordPress mature ressemble à ceci :
post-sitemap.xml: articles et pages utiles, excluant les contenus orphelins ou de moins de 300 mots si vous avez une stratégie de contenu qui le justifie.product-sitemap.xml: fiches produit aveclastmodreflétant le stock ou la mise à jour du prix.category-sitemap.xml: uniquement les catégories qui portent un contenu éditorial distinct.image-sitemap.xml: à condition que vos images hébergées sur/wp-content/uploads/aient un contexte fort, sinon ce sitemap dilue les signaux.
Quand vous livrez ce sitemap index dans votre robots.txt via une directive Sitemap:, Googlebot repère immédiatement la structure. Ajoutez un ping de mise à jour via l’API Indexing chaque fois qu’un contenu important change, plutôt que d’attendre la visite spontanée du bot.
Les signaux lastmod et changefreq sont facultatifs mais utiles si vous les maintenez à jour. Un lastmod faux ou figé est pire qu’aucun lastmod : Google peut alors choisir de recrawler des URLs inchangées plus souvent que nécessaire, ou au contraire snober des pages fraîches. Sur WordPress, n’hésitez pas à désactiver changefreq — Google l’ignore depuis longtemps pour la plupart des sites.
Ce qui se passe quand le duo sitemap + robots.txt déraille
Souvent, on découvre le problème par accident, en épluchant les logs Apache parce qu’un produit en promotion n’apparaît toujours pas dans les résultats après 48 heures. Le cas typique : le sitemap référence des URLs en https, mais un reste de règle dans le fichier .htaccess redirige ces URLs avec un paramètre de session vers une version en http. Le robots.txt interdit les URLs en http, et Googlebot ne crawle jamais la version correcte. Résultat : la page produit est dans le sitemap, jamais crawlée, jamais indexée.
Autre mésaventure fréquente : plusieurs sitemaps déclarés dans la Search Console, dont certains ne sont plus à jour. Google peut continuer à interroger un vieux sitemap déposé manuellement, même s’il n’est plus référencé dans le robots.txt. Supprimer l’ancien sitemap de la console et ne laisser que celui qui est déclaré dans le robots.txt évite ce crawl zombie.
Sur un site à fort volume, le simple fait de laisser un sitemap historique contenant 20 000 URLs redirigées (301) consomme du crawl pour rien. Google suit la redirection, atterrit sur la nouvelle URL, et repart. À chaque recrawl. Le plus insidieux, c’est que ces redirections ne bloquent pas l’indexation, donc la Search Console peut afficher « indexée » alors que Googlebot brûle une partie de son passage à suivre des chaînes de redirects.
⚡ Pour résumer : un audit trimestriel du couple sitemap/robots.txt prend une heure. Sans lui, vous pouvez perdre 30 % d’efficacité de crawl sans jamais le voir dans les indicateurs classiques.
Intégrer la vérification dans votre routine de performance
Si vous optimisez vos Core Web Vitals sans contrôler ce que Googlebot voit, vous courez après des gains marginaux. Un LCP qui passe de 2,8s à 1,9s ne servira à rien si la page met huit jours à être recrawlée après sa mise à jour. La boucle crawl → rendering → indexation → classement est indissociable du travail sur la rapidité d’affichage, un point qu’on développe dans notre dossier sur l’optimisation Core Web Vitals.
Mettez en place une vérification mensuelle automatisée :
- Récupérer les sitemaps déclarés dans la Search Console et s’assurer qu’ils correspondent à ceux listés dans
robots.txt. - Vérifier qu’aucune URL contenue dans le sitemap ne renvoie un code 3xx ou 4xx (un simple script Python avec
aiohttpet l’API Sitemap fait l’affaire). - Contrôler que les URLs interdites par
robots.txtne sont pas liées depuis les pages principales. - Surveiller le rapport « État de l’indexation » de la Search Console pour repérer les baisses soudaines.
⚠️ Attention : Un sitemap qui renvoie un 404 ou une erreur serveur pendant plus de 48 heures peut déclencher une désindexation massive. Activez une alerte de monitoring HTTP sur cette URL.
Cette vigilance s’apparente au choix d’un outil de développement : une fois qu’on a goûté à la précision d’un environnement configuré avec soin, on ne revient pas en arrière. Certains débats techniques comme Claude Code versus Cursor IDE montrent qu’une configuration sur mesure bat souvent l’automatisme aveugle. Pour votre sitemap, c’est pareil : le plugin par défaut fait le job, mais le job sur mesure sauve votre indexation quand le site grossit.
Un dernier point : si votre WordPress s’appuie sur un état React côté backoffice, la gestion de l’état interne peut impacter la génération des sitemaps si elle est mal isolée. Même si on sort du cadre strict de WordPress, comprendre comment un State Management avec Zustand gère la synchronisation des données permet d’éviter des sitemaps partiels lorsque le contenu est piloté par une API externe. La leçon est identique : centralisez la source de vérité de vos URLs.
Questions fréquentes
Est-ce que Google AMP impose des règles particulières pour le sitemap ?
Oui, pour les pages AMP, il est conseillé de les inclure dans un sitemap séparé ou de les signaler via la balise link rel="amphtml". Avec l’évolution d’AMP vers les pages rapides standards, ce besoin s’estompe, mais si vous maintenez des AMP dédiées, vérifiez qu’elles sont crawlables et que le sitemap les liste correctement, sans créer de concurrence avec la version canonique.
Faut-il déclarer manuellement le sitemap dans la Search Console si on l’a dans le robots.txt ?
Non, ce n’est pas obligatoire, mais la Search Console peut accuser un délai de détection. Déclarer le sitemap manuellement offre un feedback immédiat sur les erreurs de parsing et accélère la prise en compte initiale. Une fois le sitemap stable, la directive Sitemap: dans robots.txt suffit.
Un sitemap trop lourd peut-il ralentir le crawl des autres pages ? Oui, indirectement. Si Google passe du temps à traiter un sitemap volumineux avec beaucoup d’URLs redirigées ou d’erreurs, il peut réduire la fréquence de visite sur les autres parties du site. Un sitemap propre améliore la répartition du crawl budget, surtout sur les sites à plusieurs milliers d’URLs.
