Robots.txt : le fichier qui peut empêcher Google d’indexer votre site

Un site qui peine à se faire indexer cherche souvent la cause du côté du contenu, des backlinks ou du crawl budget. Le coupable est parfois beaucoup plus simple : un fichier robots.txt de quelques lignes, déposé à la racine du domaine, qui interdit poliment à Googlebot de visiter une partie du site. La directive est respectée, les pages restent invisibles, et l’auteur du site cherche pendant des semaines une explication compliquée à un problème qui se règle en trois caractères.

Le fichier robots.txt fait partie des plus anciens standards du web. Sa logique est simple, ses effets sont radicaux, et ses pièges sont nombreux. Tour d’horizon des erreurs qui sabotent l’indexation Google et de la manière de les détecter.

À quoi sert robots.txt (et ce qu’il ne fait pas)

Le fichier robots.txt est un protocole d’exclusion volontaire. Placé à la racine d’un domaine (https://exemple.com/robots.txt), il indique aux robots des moteurs de recherche quelles URLs ils peuvent ou ne peuvent pas crawler. Le mot est important : robots.txt parle de crawl, pas d’indexation.

Robots.txt empêche Google de visiter une URL, pas de l’indexer. Si l’URL est connue par d’autres canaux (backlink externe, sitemap, lien interne), elle peut apparaître dans les résultats de recherche avec un titre vide et la mention « Aucune information disponible pour cette page ». Pour empêcher l’indexation, il faut une balise noindex dans le HTML, pas un Disallow dans robots.txt.

Cette confusion est la première source de pages fantômes dans Search Console. Bloquer un dossier dans robots.txt empêche Googlebot de lire les balises de la page, y compris la balise noindex qui aurait pu la désindexer proprement. Résultat : la page reste indexée mais avec un contenu illisible pour le moteur.

La structure du fichier

Un robots.txt suit une grammaire stricte. Quatre directives concentrent l’essentiel des cas réels.

Le fichier est lu de haut en bas, par bloc User-agent. Un bloc générique User-agent: * s’applique à tous les robots qui n’ont pas de bloc dédié. Les directives sont sensibles à la casse pour les chemins et tolèrent les wildcards * et $ sur les principaux moteurs.

Les cinq erreurs qui bloquent l’indexation

Les retours d’audit montrent une concentration sur un nombre limité d’erreurs. Cinq cas reviennent en boucle.

1. Disallow: / oublié en production

Le grand classique. Pendant le développement, le site bloque tout pour éviter d’être indexé. La mise en ligne ne change pas le robots.txt. Le site passe en production avec un Disallow: / sur tous les agents. Aucune URL ne se fait crawler. Aucune page nouvelle ne s’indexe. Le diagnostic prend cinq secondes une fois qu’on regarde le fichier, et plusieurs semaines quand on cherche ailleurs.

2. Blocage des ressources CSS et JS

Bloquer /wp-includes/, /wp-content/plugins/ ou des dossiers d’assets prive Googlebot des fichiers qui composent l’apparence du site. Le moteur juge alors la page sur un rendu dégradé, parfois illisible. Sur un site fortement dépendant du JavaScript, l’effet est massif sur le classement et l’indexation.

3. Disallow utilisé pour désindexer

Cas déjà décrit plus haut. Pour retirer une page de l’index, il faut autoriser le crawl et poser une balise noindex. Bloquer la page dans robots.txt fige le statut existant : si elle était indexée, elle reste indexée, sans que Google puisse mettre à jour les informations.

4. Wildcards mal placés

La directive Disallow: /*? bloque toutes les URLs avec paramètres, y compris des pages de filtres légitimes. Les wildcards sont puissants mais imprécis. Un test sur quelques URLs réelles évite la surprise.

5. Robots.txt qui renvoie une 5xx

Si le serveur répond 500 ou 503 sur la requête robots.txt, Google considère que le crawl est temporairement interdit pour tout le site. Une erreur serveur prolongée sur ce fichier paralyse l’exploration. Le statut 4xx, lui, est interprété comme une absence de fichier (donc autorisation totale), ce qui est sans effet négatif.

Disallow vs noindex : la décision en deux questions

Pour trancher entre robots.txt et balise meta robots, deux questions suffisent.

• Veux-tu économiser du crawl ? Sur des sections sans valeur SEO (espace client, panier, recherche interne), Disallow évite que Googlebot dépense du budget de crawl à les explorer. Pertinent pour les gros sites où l’indexation des pages stratégiques dépend du budget alloué.
• Veux-tu retirer une page de l’index ? Réponse : balise noindex en HTML ou en-tête HTTP X-Robots-Tag. Surtout pas Disallow, qui empêche Google de voir la balise.

La règle simple : robots.txt pour gérer le crawl en amont, balise noindex pour gérer l’indexation en aval. Les deux ne se remplacent pas, ils se complètent.

Vérifier son robots.txt

Trois étapes pour auditer sereinement.

Lire le fichier brut

Ouvrir https://votre-site.fr/robots.txt dans un navigateur. Le contenu doit être lisible, court (rarement plus de 30 lignes pour un site classique), sans Disallow: / sauf intention claire. Vérifier que le sitemap est déclaré et pointe vers la bonne URL.

Tester avec Search Console

L’outil de test du robots.txt dans Google Search Console permet de saisir une URL et vérifier si elle est autorisée ou bloquée pour Googlebot. À utiliser en priorité sur les pages stratégiques (catégories, fiches produits, articles piliers).

Auditer l’ensemble du site

Pour un diagnostic global, un audit d’indexabilité remonte les pages bloquées par robots.txt, celles avec un noindex, les redirections en chaîne et les erreurs serveur. Plus rapide que de cliquer sur chaque URL.

Cas particuliers à connaître

Sous-domaines

Chaque sous-domaine a son propre robots.txt. blog.exemple.com/robots.txt est indépendant de exemple.com/robots.txt. Oublier de poser un fichier sur un sous-domaine de production conduit Google à crawler sans restriction, ce qui est souvent souhaité, mais peut révéler des sections sensibles non protégées par ailleurs.

Sites multilingues

Pour un site avec sous-dossiers (/fr/, /en/), un seul robots.txt à la racine s’applique. Pour un site avec sous-domaines linguistiques, chaque langue gère son fichier.

Migration de domaine

Lors d’un changement de domaine, le robots.txt de l’ancien site doit autoriser le crawl pendant toute la phase de redirection (souvent six à douze mois). Bloquer trop vite empêche Google de découvrir et propager les redirections 301.

Staging et préproduction

Un environnement de staging accessible publiquement doit bloquer tous les robots avec un Disallow: /. Mieux : protéger le sous-domaine par mot de passe pour éviter qu’un lien externe accidentel ne fasse découvrir la version de test.

Ce qu’un robots.txt bien fait contient

Pour un site WordPress moyen, un fichier minimaliste suffit largement. Bloquer l’admin, autoriser le reste, déclarer le sitemap.

Tout ajout au-delà de cette base devrait répondre à un besoin précis et documenté. Les robots.txt longs et compliqués sont souvent l’accumulation de directives empilées par différents prestataires sur plusieurs années, sans cohérence d’ensemble. Une revue annuelle du fichier, en confrontant chaque ligne à un cas d’usage actuel, suffit à maintenir la propreté.

En résumé

Robots.txt ne contrôle que le crawl, pas l’indexation. Sa mauvaise compréhension produit deux symptômes opposés : des pages censées être désindexées qui restent dans l’index, et des sections entières absentes des résultats de recherche à cause d’un blocage non intentionnel. Le fichier mérite trois minutes de relecture régulière, surtout après une mise en production, une migration ou un changement de prestataire SEO. Trois caractères mal placés à la racine d’un domaine peuvent annuler des mois de travail éditorial.