Avant d’explorer un site, un robot de moteur de recherche bien élevé consulte d’abord ce fichier pour connaître les zones que l’éditeur préfère ne pas voir explorées : un espace d’administration, un dossier temporaire, une zone de recherche interne qui génère des pages sans intérêt pour l’indexation. C’est une convention respectée par les robots légitimes, mais jamais une véritable barrière de sécurité.
Syntaxe de base
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://exemple.fr/wp-sitemap.xml
Dans WordPress
WordPress génère un fichier robots.txt virtuel par défaut si aucun fichier physique n’existe à la racine, filtrable via le hook robots_txt, et bloque automatiquement l’indexation du dossier /wp-admin/ à l’exception du point d’entrée AJAX nécessaire au fonctionnement de certains scripts publics. Le réglage « Visibilité par les moteurs de recherche » du menu Réglages agit lui aussi sur ce fichier généré.
Pièges fréquents
Bloquer une URL dans robots.txt empêche son exploration, mais pas nécessairement son indexation : une page déjà connue par lien externe peut malgré tout apparaître dans les résultats, sans description, si elle n’est pas explorable. Pour retirer réellement une page des résultats, il faut une balise noindex sur la page elle-même, ce qui suppose justement qu’elle reste explorable par le robot, en contradiction directe avec un blocage dans robots.txt. Une règle Disallow: / laissée par mégarde après une migration depuis un environnement de recette bloque d’un coup l’exploration de tout le site, un incident fréquent et particulièrement coûteux en visibilité.