Le robots.txt WordPress idéal en 2026 (ce qu'il faut vraiment mettre dedans)

Un bon robots.txt WordPress fait environ cinq lignes. Bloquez /wp-admin/, autorisez admin-ajax.php, indiquez votre plan de site aux robots, et arrêtez-vous là — les listes de blocage tentaculaires de 40 lignes que l’on trouve sur les forums cassent surtout le rendu ou ne servent à rien. Le fichier complet :

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Remplacez le domaine et, si vous utilisez une extension SEO qui reprend la main sur les plans de site, faites pointer la ligne Sitemap vers l’index de cette extension. C’est tout. Si votre fichier est plus long que cela, les lignes supplémentaires vous coûtent probablement quelque chose.

WordPress en génère déjà un — jusqu’à ce que vous créiez un vrai fichier

WordPress fournit un robots.txt virtuel. Quand une requête arrive sur /robots.txt et qu’aucun fichier réel n’existe à la racine web, WordPress intercepte la requête et imprime une réponse en mémoire. Rien n’est écrit sur le disque. La sortie par défaut est le blocage de wp-admin ci-dessus, plus une ligne Sitemap: pour wp-sitemap.xml que le cœur émet depuis WordPress 5.5.

Deux éléments modifient cette sortie. Si la case Réglages → Lecture → Demander aux moteurs de recherche de ne pas indexer ce site est cochée, WordPress remplace tout par Disallow: /, ce qui bloque l’intégralité du site. Cette case est de loin la cause la plus fréquente d’un site qui disparaît de la recherche après une mise en ligne. Ensuite, les extensions et les thèmes peuvent modifier la sortie virtuelle via le filtre robots_txt : c’est ainsi que les extensions SEO injectent leurs propres lignes de sitemap et leurs règles.

Vient maintenant la partie qui fait perdre des après-midi entiers. Un fichier robots.txt physique à la racine web écrase tout cela en silence. Votre serveur web trouve un fichier réel sur le disque, le sert, et WordPress ne se charge jamais. Le générateur virtuel ne tourne pas. Le filtre robots_txt ne se déclenche pas. L’éditeur de robots.txt de votre extension SEO peut très bien continuer à vous montrer une belle interface avec les bonnes règles, rien de tout cela n’atteint un robot.

Où vivent les règles	Modifiable dans l’administration WordPress	Ce qui l’emporte sur une requête réelle
Virtuel (aucun fichier sur le disque)	Oui, via le filtre robots_txt ou une extension	Uniquement si aucun fichier physique n’existe
Fichier physique à la racine web	Seulement si l’extension écrit sur le disque	Toujours

Alors avant de déboguer quoi que ce soit : ouvrez https://votresite.com/robots.txt dans un navigateur, puis connectez-vous en SFTP ou via le gestionnaire de fichiers de votre hébergeur et vérifiez si un vrai robots.txt se trouve à côté de wp-config.php et de .htaccess. Si oui, c’est ce fichier votre robots.txt. Modifiez-le là, ou supprimez-le et laissez WordPress reprendre la main — mais choisissez. Faire tourner les deux, c’est ainsi que des sites se retrouvent avec une URL de sitemap périmée que personne ne retrouve.

Pourquoi /wp-admin/ est bloqué mais admin-ajax.php autorisé

/wp-admin/ contient le tableau de bord. Ces URL n’ont aucun intérêt dans les résultats de recherche et les explorer consomme du budget d’exploration sur des pages qui redirigent vers un écran de connexion. Bloquer ce répertoire ne fait débat pour personne.

admin-ajax.php se trouve dans ce répertoire mais n’est pas une page d’administration. C’est le point d’entrée qu’utilisent extensions et thèmes pour traiter les requêtes AJAX côté public : boutons « charger plus », grilles de produits filtrées, calculateurs, formulaires. Si un robot ne peut pas y accéder, il ne voit pas les contenus chargés par ces fonctionnalités, et Google affiche votre page telle que la verrait un visiteur avec la fonctionnalité cassée.

Savoir si Google a réellement besoin de récupérer admin-ajax.php sur votre site précis dépend de l’usage qu’en fait votre partie publique. Réponse honnête : sur beaucoup de sites modernes cela n’a aucune importance, parce que le thème passe par l’API REST sur /wp-json/. La ligne Allow est une assurance gratuite contre un vrai risque de panne, pas un facteur de classement. Gardez-la, elle ne coûte rien.

Ne bloquez pas /wp-content/ ni /wp-includes/

C’est le pire conseil robots.txt encore en circulation, et il date d’une époque où Google n’affichait pas les pages.

/wp-content/ contient vos thèmes, vos extensions, vos fichiers envoyés — les feuilles de style, les scripts et les images qui font ressembler vos pages à des pages. /wp-includes/ contient le JavaScript du cœur dont dépendent des extensions. Google affiche vos pages dans un navigateur sans interface avant de les juger. Bloquez ces répertoires et le moteur de rendu obtient une page sans CSS et sans images. Ce que Google évalue devient alors un mur de texte sans style à la mise en page cassée, ce qui influe sur sa compréhension de votre contenu et sur sa note d’ergonomie mobile.

Si vous avez hérité d’un fichier contenant ces lignes, supprimez-les :

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Vous pouvez constater les dégâts vous-même dans l’outil d’inspection d’URL de la Google Search Console. Lancez un test en direct sur n’importe quelle page, regardez la capture d’écran du rendu et vérifiez la liste des ressources de la page à la recherche d’éléments bloqués. Si votre CSS apparaît comme bloqué, vous tenez la cause.

La directive Sitemap

Une ligne, une URL absolue, et elle peut se trouver n’importe où dans le fichier — elle n’est rattachée à aucun groupe User-agent.

Sitemap: https://example.com/wp-sitemap.xml

Utilisez l’URL qui répond réellement. Le cœur de WordPress sert wp-sitemap.xml. La plupart des extensions SEO désactivent les plans de site du cœur et servent leur propre index à un autre emplacement, généralement sitemap_index.xml. Chargez votre URL dans un navigateur avant de la valider : une ligne Sitemap pointant vers une 404 est pire que pas de ligne du tout, parce qu’elle a l’air correcte lors d’un audit.

Lister plusieurs plans de site est possible, un par ligne. Soumettre vos sitemaps dans la Search Console reste utile en parallèle ; la directive robots.txt est le moyen pour les robots qui ne voient jamais votre compte Search Console de les trouver.

Le robots.txt n’est ni un noindex ni une protection

Ces deux malentendus causent l’essentiel des dégâts liés au robots.txt.

Bloquer une URL ne la retire pas de Google. Le robots.txt régit l’exploration. Si un autre site pointe vers une URL bloquée, Google peut indexer l’URL elle-même — vous obtenez un résultat réduit à l’adresse brute et à une mention indiquant qu’aucune information n’est disponible. Et il existe un piège plus vicieux : si une page porte déjà une balise meta noindex et que vous la bloquez ensuite dans le robots.txt, Google ne peut plus l’explorer, ne peut plus voir le noindex, et la page peut rester indexée indéfiniment. Pour retirer une page, autorisez l’exploration et servez une balise meta robots noindex dans l’en-tête de la page, ou un en-tête HTTP X-Robots-Tag. Google a cessé de prendre en charge les directives noindex à l’intérieur du robots.txt en 2019.

Bloquer un chemin ne le protège pas. Votre robots.txt est public par définition. Y lister /fichiers-clients-prives/ indique à chaque visiteur et à chaque scanner exactement où chercher, et le respect des règles est volontaire : Google les honore, les robots hostiles non. Tout ce qui doit être protégé exige une authentification, une restriction par IP ou des règles serveur dans .htaccess, pas une ligne dans un fichier texte qui désigne la cible.

Les règles qui valent le coup, et celles à laisser tomber

Deux ajouts sont réellement utiles sur beaucoup de sites. Bloquer le chemin des résultats de recherche empêche les robots de générer une infinité d’URL sans valeur à partir de votre moteur de recherche interne. Bloquer un chemin de panier ou de commande sous WooCommerce garde les URL à paramètres de session hors de l’exploration.

Disallow: /?s=
Disallow: /search/

À éviter :

• Crawl-delay — Google l’ignore purement et simplement. Utilisez les réglages de fréquence d’exploration de la Search Console si vous avez un vrai problème de charge serveur.
• Bloquer /feed/ ou /trackback/ — ce sont des URL inoffensives, et les flux sont utiles.
• Les longues listes de noms de robots individuels — la plupart des robots que l’on cherche à bloquer ne s’identifient de toute façon pas honnêtement.
• Bloquer /wp-json/ — c’est peut-être ce que votre thème utilise pour afficher son contenu.

Construisez le fichier avec le générateur de robots.txt WordPress, qui produit la version minimale correcte et vous laisse ajouter les règles de recherche et de boutique sans écrire la syntaxe à la main.

Après modification

Chargez https://votresite.com/robots.txt directement et vérifiez que les octets servis correspondent à ce que vous attendez — pas à ce que l’éditeur de votre extension vous montre. Lancez ensuite une inspection d’URL en direct dans la Search Console sur une page normale et vérifiez qu’aucune ressource CSS ou JavaScript ne revient bloquée. Google met le robots.txt en cache environ une journée : une correction ne prend donc pas effet instantanément, et une erreur non plus. Ce délai est la raison pour laquelle il vaut mieux vérifier soigneusement plutôt que tester en production et attendre.