SEO technique : comment configurer un fichier robots.txt sans erreur

Un client m'appelle un vendredi soir, affolé. Son site a disparu de Google. Pas une chute de position : disparu, envolé, plus rien. Je regarde, je teste l'URL, et là je tombe sur un robots.txt de trois lignes qui contient un seul caractère de trop. Trois jours plus tard, tout était revenu. Trois jours de trafic évaporés pour une barre oblique mal placée.

Voilà pourquoi je considère le fichier robots.txt comme le fichier le plus dangereux de toute votre configuration SEO technique. Il ne fait rien de spectaculaire. Il ne fait pas monter vos pages. Mais mal écrit, il peut fermer la porte à votre site entier du jour au lendemain.

Qu'est-ce qu'un fichier robots.txt, vraiment ?

Ce n'est pas un fichier de sécurité. Ce n'est pas une protection. C'est un panneau de signalisation planté à l'entrée de votre domaine, qui dit aux crawlers : ici tu peux passer, là non. Un robot bien élevé le lit avant de commencer à parcourir votre site.

Le hic, c'est que le panneau n'a aucune valeur légale. Un crawler qui l'ignore fait ce qu'il veut. Les grands moteurs le respectent par convention. Un aspirateur de contenu mal codé, non. Je reçois régulièrement des messages de gens qui pensent avoir « protégé » un dossier sensible en le listant dans leur robots.txt. Mauvaise nouvelle : ce fichier est public, et tout ce que vous y écrivez indique précisément où chercher ce que vous ne voulez pas montrer.

Ce que le robots.txt ne fait pas

Il n'empêche pas l'indexation. C'est la confusion numéro un. Si une page est bloquée à l'exploration mais qu'un lien externe pointe vers elle, Google peut parfaitement l'afficher dans les résultats, sans contenu, juste avec un titre deviné. Et là, vous avez le pire des deux mondes : une page invisible pour vous, indexée pour Google, impossible à corriger proprement parce que le robot ne peut plus lire la balise noindex qu'elle contient.

Pour retirer une page de l'index, la bonne commande est <meta name="robots" content="noindex">. Le robots.txt gère l'exploration. Le noindex gère l'indexation. Ne mélangez pas les deux outils.

Comment écrire la syntaxe sans se tromper

Un fichier robots.txt ne tolère aucune approximation. Une majuscule mal placée, un espace de trop, et la directive est ignorée en silence. Pas d'erreur, pas d'alerte. Le robot lit, ne comprend pas, passe à la ligne suivante.

Voici ce que j'utilise quand je veux autoriser tout le monde sauf une zone :

User-agent: *
Disallow: /admin/
Disallow: /panier/
Allow: /admin/public/

Sitemap: https://exemple.com/sitemap.xml

Trois choses à observer. Le User-agent: * signifie « tous les robots ». Disallow interdit, Allow réautorise. Et l'ordre compte : la directive la plus longue l'emporte. Si vous interdisez /admin/ puis autorisez /admin/public/, un robot qui comprend la règle ira bien explorer le sous-dossier public. C'est un réflexe que j'ai mis du temps à intégrer, et qui m'a valu plusieurs erreurs avant de comprendre la logique.

Les jokers et les expressions régulières

Deux caractères spéciaux changent la donne. L'astérisque * remplace n'importe quelle chaîne. Le dollar $ marque la fin d'une URL.

• Disallow: /*.pdf$ bloque tous les PDF du site sans toucher au reste.
• Disallow: /recherche interdit aussi les URL qui commencent par ce mot, comme /recherche-avancee.
• Disallow: /*?session= élimine les URL de session, un classique des sites e-commerce.
• Disallow: tout court — sans rien après — autorise l'accès à l'ensemble.

L'absence de valeur derrière une directive a un sens précis. Disallow: vide signifie « je ne bloque rien ». Beaucoup de gens l'écrivent en croyant bloquer, et obtiennent l'inverse exact.

Robots.txt et robots IA : ce qui a changé

En 2026, la question que l'on me pose le plus souvent n'est plus « comment bloquer Google » mais « comment gérer ChatGPT et les autres ». Le sujet a pris une ampleur que personne n'anticipait il y a quelques années. Les éditeurs qui veulent apparaître dans les réponses génératives doivent laisser passer les bons agents ; ceux qui refusent de servir leur contenu gratuitement aux modèles peuvent les couper.

La mécanique reste identique : une directive User-agent par robot, avec ses propres règles.

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: PerplexityBot
Allow: /

User-agent: *
Allow: /

Dans cet exemple, je bloque le robot d'entraînement d'OpenAI, je bloque celui d'Anthropic, mais j'autorise Perplexity à indexer. C'est un choix. Je ne prétends pas qu'il soit universel. Ce que je remarque, en revanche, c'est que bloquer un crawler d'entraînement et bloquer un crawler de recherche sont deux décisions distinctes, et que beaucoup de sites confondent les deux — ils coupent tout, puis s'étonnent de ne plus être cités nulle part.

Attention à un point technique : les noms de ces agents évoluent. OpenAI utilise plusieurs user-agents avec des rôles différents. Si le blocage est critique pour votre stratégie, vérifiez la documentation officielle de chaque éditeur plutôt que de recopier une liste trouvée sur un forum il y a deux ans.

Où placer le fichier, et comment le publier

À la racine du domaine. Toujours. Pas dans un sous-dossier, pas avec un autre nom. Un fichier qui répond sur https://exemple.com/robots.txt est valide. Un fichier sur https://exemple.com/blog/robots.txt n'est jamais lu par les robots qui explorent le domaine principal.

Un cas particulier à connaître : le robots.txt virtuel. Sur WordPress, plusieurs extensions SEO génèrent le fichier à la volée, sans créer de fichier physique sur le serveur. C'est pratique, mais ça crée un conflit classique. Si un vrai robots.txt existe sur le serveur en plus du virtuel, c'est lui qui gagne. J'ai déjà vu quelqu'un modifier pendant une heure les réglages de son extension sans comprendre pourquoi rien ne changeait : le fichier physique écrasait tout.

Méthode	Avantages	Limites
Fichier physique à la racine	Contrôle total, lisible par tous les outils	Nécessite un accès FTP ou serveur
Génération via extension (virtuel)	Aucune manipulation technique	Écrasé par un fichier physique s'il existe
Panneau du CMS	Rapide à modifier	Fonctionnalités parfois bridées

Une fois en ligne, testez. Ouvrez l'URL dans votre navigateur. Si vous voyez le contenu en clair, c'est bon. Si vous tombez sur une page 404, aucun robot ne le lira, et vous avez un problème silencieux que rien ne signalera.

Les erreurs qui coûtent cher

Le Disallow: / est de loin le champion des catastrophes. Une barre oblique, et vous fermez tout. Je l'ai fait une fois, sur un site de taille moyenne, un vendredi après-midi. Le temps que je m'en aperçoive, le lundi matin, plusieurs pages avaient déjà été désindexées. Elles sont revenues, mais avec un délai que je n'ai pas contrôlé.

Autres pièges que je rencontre régulièrement :

• Bloquer le dossier CSS ou JavaScript, ce qui dégrade l'affichage du site pour les robots et peut faire chuter vos évaluations.
• Oublier de déclarer le Sitemap, alors que c'est la ligne la plus utile du fichier.
• Laisser une ligne Disallow orpheline sans User-agent au-dessus : elle ne s'applique à personne.
• Bloquer une URL après y avoir mis un noindex : le robot ne lit plus la balise, elle ne sert plus à rien.
• Confondre Disallow: /dossier et Disallow: /dossier/. Le premier bloque aussi /dossier-ancien. Le second, non.

Le point commun de toutes ces erreurs ? Elles sont invisibles. Aucun message d'erreur, aucune alerte dans la console. Le fichier fait son travail en silence, y compris quand ce travail consiste à détruire votre trafic. C'est précisément pour ça que je le relis deux fois avant chaque mise en ligne, et que je le teste toujours en navigation privée après.

Comment vérifier que mon robots.txt fonctionne ?

Trois méthodes suffisent, et je les enchaîne toujours dans cet ordre. D'abord, ouvrez l'URL dans un navigateur : le contenu doit s'afficher en texte brut. Ensuite, utilisez le testeur d'URL de Google Search Console : il vous dit précisément si une page donnée est bloquée ou autorisée, en tenant compte de toutes les règles. Enfin, lisez le fichier à voix haute en vérifiant chaque ligne contre votre intention. Ça paraît bête. Ça m'a sauvé plus d'une fois.

Le robots.txt peut-il empêcher Google d'indexer une page ?

Non, et c'est une nuance que beaucoup ratent. Bloquer une URL à l'exploration ne la retire pas de l'index. Pour une vraie suppression, la balise noindex est la seule réponse fiable. Et surtout, vous ne pouvez pas combiner les deux sur la même page : si le robot ne peut pas explorer l'URL, il ne verra jamais la balise. C'est un piège logique dans lequel tombent énormément de sites.

Cibler un robot spécifique par son nom

Chaque robot a un identifiant. Googlebot, Bingbot, GPTBot, ClaudeBot. Pour lui appliquer des règles différentes du reste, il suffit de créer un bloc User-agent à son nom avant le bloc générique. Le robot cherche son nom en priorité ; s'il ne le trouve pas, il retombe sur l'astérisque. Cette hiérarchie est simple, mais elle explique la majorité des comportements inattendus quand plusieurs blocs cohabitent dans le même fichier.

Ce que je conseille de garder en tête

Un robots.txt bien écrit, c'est deux minutes de travail et zéro décoration. Il n'améliore rien par lui-même. Il empêche simplement le pire. Et le pire, dans ce domaine, prend rarement la forme d'un piratage : il prend celle d'un fichier qu'on a touché un jour de fatigue et qu'on a oublié de relire.

Alors la prochaine fois que vous ouvrez l'éditeur pour y ajouter une ligne, posez-vous une seule question : si cette règle bloque exactement le contraire de ce que je veux, est-ce que je m'en rendrais compte ? Si la réponse est non, testez avant de publier. Le fichier ne vous préviendra pas.