En 2013, quand j’ai rédigé la première version de ce guide, les sitemaps XML et le ficher robots.txt ressemblaient à de simples fichiers de configuration qu’on réglait une fois pour toutes. Treize ans plus tard, le crawl budget est devenu la ressource la plus mal comprise des référenceurs techniques, et la moindre erreur dans ces deux fichiers vous coûte des pages non indexées que vous ne récupérerez jamais. La bonne nouvelle : WordPress reste parfaitement capable de produire un sitemap propre et un robots.txt efficace. La mauvaise : la configuration par défaut de la plupart des sites, souvent héritée de plugins populaires, constitue aujourd’hui un frein direct à l’indexation.
J’ai vu un site e-commerce sous WooCommerce perdre progressivement des positions sur ses fiches produits sans qu’aucune pénalité manuelle ne le signale. Le coupable : un sitemap qui listait 18 000 URLs, dont 40 % de pages de tags vides, et un robots.txt autorisant tout, laissant Googlebot s’éparpiller dans des archives de dates sans contenu. Corriger ces deux fichiers a permis de récupérer un crawl utile en moins de deux semaines.
Votre sitemap XML nourrit Googlebot avec du bruit
WordPress embarque depuis la version 5.5 un sitemap de base qui a le mérite d’exister. Le problème surgit quand vous installez Yoast SEO, Rank Math ou un autre plugin SEO : ils activent des sitemaps supplémentaires pour les auteurs, les dates, les médias, les catégories et les étiquettes. Sur un blog de 200 articles, cela peut générer 800 URLs. Sur une boutique WooCommerce avec des centaines de produits et des variations, le sitemap explose.
Le résultat se lit dans la Search Console : des centaines d’URLs « Explorées, actuellement non indexées » ou « Détectée, actuellement non indexée », pendant que vos pages de catégories stratégiques attendent leur tour. Googlebot ne dispose pas d’un temps infini sur votre site. Chaque URL qu’il découvre via le sitemap, mais qu’il juge sans valeur, consomme une part de votre budget crawl et retarde la prise en compte de vos vraies pages.
Ce bruit provient majoritairement de trois types d’URLs :
- Les pages de tags qui regroupent un ou deux articles et ne proposent aucune valeur ajoutée par rapport aux catégories.
- Les archives de dates (mois, année), utiles pour personne.
- Les pages d’auteur, si vous êtes seul à écrire sur le site.
La correction est simple : désactivez les sitemaps des taxonomies inutiles. Si vous utilisez Yoast, le filtre wpseo_sitemap_exclude_taxonomy vous permet d’exclure les étiquettes et les formats de publication. Pour Rank Math, un simple bouton dans l’interface suffit. Le principe reste le même quel que soit l’outil : n’envoyez dans votre sitemap que les URLs qui méritent d’être classées.
Un robots.txt qui bloque le CSS et le JS tue votre rendu
Beaucoup de robots.txt WordPress copiés-collés depuis 2015 contiennent encore cette ligne : Disallow: /wp-content/themes/. À l’époque, on pensait bien faire en empêchant l’indexation des fichiers de thème, pour éviter un supposé duplicate content. Aujourd’hui, cette règle est toxique.
Googlebot a besoin d’accéder à vos fichiers CSS et JavaScript pour comprendre si votre page est utilisable sur mobile, si le contenu principal est visible sans scroll, si les boutons sont cliquables. Bloquer ces ressources, c’est empêcher le moteur de rendu de voir la page telle que l’utilisateur la voit. La conséquence : une évaluation dégradée de vos Core Web Vitals, qui influence directement le classement. Si vous avez passé des heures à optimiser la vitesse de vos pages pour le champ LCP ou l’INP, mais que Googlebot ne peut pas charger votre feuille de style, tous ces efforts sont invisibles dans la SERP.
Le fichier robots.txt doit rester une liste d’interdictions ciblées. Bloquez /wp-admin/, /wp-includes/, le répertoire des plugins s’il contient des fichiers sensibles. Autorisez tout ce qui sert au rendu final de la page. Une règle simple : si supprimer l’autorisation casse l’affichage dans votre navigateur, elle casse aussi l’analyse de Googlebot.
Construire un sitemap qui priorise vos pages, sans magie
⚠️ Attention : Les balises
<priority>et<changefreq>n’ont aucun effet sur Google. Elles sont ignorées depuis des années. Investissez votre énergie ailleurs.
Un sitemap efficace repose sur trois principes.
D’abord, découper en sitemaps secondaires. Un index de sitemap qui référence un sitemap pour les articles, un pour les pages, un pour les produits, un pour les catégories principales permet à Googlebot de cibler les types de contenus selon vos mises à jour. Sur un site e-commerce, vous mettrez à jour le sitemap produit chaque jour, pendant que le sitemap des pages institutionnelles ne bouge pas. Google comprend cette fréquence via la balise lastmod.
Ensuite, exclure les paramètres d’URL qui génèrent du contenu dupliqué ou des tris sans intérêt. Un paramètre ?orderby=price ou ?filter_color=rouge produit une URL différente, mais rarement une page qu’il faut indexer séparément. La solution la plus robuste reste de les gérer au niveau des balises canoniques, mais un sitemap propre permet déjà d’éviter que ces URLs ne soient proposées à l’exploration.
Enfin, générer le sitemap dynamiquement à chaque publication. Les plugins le font, mais si vous avez un site headless avec WordPress en back-end et React en front, vous aurez besoin d’une logique personnalisée. Quand il s’agit d’écrire un script de génération de sitemap sur mesure pour un site découplé, le choix de l’IDE influence directement la vélocité de développement. J’ai comparé Claude Code et Cursor IDE pour ce type de projet : le premier offre une assistance contextuelle plus fine quand on manipule des structures XML complexes via l’API WordPress.
Les directives robots.txt qui comptent vraiment aujourd’hui
Un robots.txt minimal ne se limite pas à interdire l’admin. Voici ce que vous devriez y voir.
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Allow: /wp-content/uploads/
Sitemap: https://www.monsite.fr/sitemap_index.xmlPour les sites e-commerce, ajoutez l’interdiction des URLs avec paramètres d’action (add-to-cart, remove_item) et des pages de compte client. Cela évite de gaspiller du crawl sur des pages qui n’ont aucune chance d’apparaître dans les résultats.
Si vous utilisez un CDN ou un système de cache qui génère des URLs de purge, bloquez-les aussi. Googlebot passe parfois un temps fou à crawler des /wp-content/cache/min/ ou des préfixes de version CSS.
N’oubliez pas les bots IA. La directive User-agent: Google-Extended avec Disallow: / permet de contrôler l’utilisation de votre contenu pour l’entraînement des modèles, sans affecter l’indexation classique. Un choix éditorial que vous devez assumer.
Vérifiez avant que Google ne signale l’erreur
La Search Console propose un outil de test du robots.txt qui vous indique si un blocage empêche le rendu. Utilisez-le, mais ne vous arrêtez pas là.
💡 Conseil : Téléchargez vos logs serveur bruts et filtrez les hits de Googlebot. Vous verrez exactement quelles URLs sont crawlées, à quelle fréquence, et si certaines ressources renvoient un 403 ou un 404 à cause de votre configuration.
J’ai vu un blocage accidentel sur Disallow: /*.js causer une chute d’indexation parce que le thème chargeait un script critique pour le lazy-loading des images. L’outil de test ne montrait qu’un avertissement partiel. Seuls les logs ont permis de repérer le désastre.
En complément, surveillez le rapport « Statistiques d’exploration » de la Search Console. Un pic soudain de « Erreurs serveur » ou « Bloquées par robots.txt » juste après la mise en ligne d’une nouvelle configuration doit déclencher une vérification immédiate. Si vous travaillez avec une équipe de devs, intégrez cette vérification dans votre pipeline de déploiement, au même titre que les tests de performance.
Quand le duo sitemap / robots.txt atteint ses limites
Sur un site à très fort volume (plus de 100 000 URLs), le crawl budget devient une variable d’ajustement permanente. Le sitemap et le robots.txt ne suffisent plus à eux seuls. Vous devez entrer dans une logique d’indexation conditionnelle : balises noindex sur les pages à faible valeur ajoutée, canoniques pointant vers les versions consolidées, suppression des catégories presque vides.
Pour un WordPress headless avec un front React, cette gestion se complique. L’état de l’indexation doit être cohérent entre le back-end et l’affichage client, un peu à la manière d’un state management complexe. Gérer le crawling sur ce type d’architecture rappelle les problématiques de synchronisation qu’on rencontre avec Zustand dans une application React : un état mal défini et c’est toute la cohérence de l’indexation qui s’effondre sur des centaines de milliers d’URLs.
Je recommande de toujours consolider les données de crawl dans un tableau de bord unique, mêlant logs, Search Console et données de trafic organique. Une URL crawlée 50 fois par semaine sans jamais générer un seul clic mérite soit d’être retirée du sitemap, soit d’être améliorée, soit d’être marquée noindex.
Questions fréquentes
Est-il dangereux d’utiliser le sitemap par défaut de WordPress sans plugin SEO ? Non, le sitemap natif est correct pour un petit site. Il liste les articles, les pages et les types de contenu publics. Par contre, il ne gère pas les sitemaps images ou vidéos, et n’offre aucun contrôle fin sur les exclusions. Pour un site qui dépasse 50 URLs, un plugin permet de segmenter et d’affiner.
Faut-il déclarer le sitemap dans le robots.txt OU le soumettre dans la Search Console, ou les deux ? Les deux. La déclaration dans le robots.txt est un signal passif que Googlebot lit lors de chaque passage. La soumission dans la Search Console déclenche une exploration active et vous donne des retours d’erreur. L’un n’empêche pas l’autre, et combiner les deux couvre tous les cas.
Comment savoir si un blocage robots.txt empêche l’indexation d’une page importante ? Utilisez l’outil d’inspection d’URL de la Search Console. Entrez l’URL en question et consultez la section « Couverture ». Si un blocage robots.txt est détecté, l’outil vous montre exactement la ligne concernée. Ensuite, corrigez le fichier, validez le correctif, et demandez une réexploration.
