Webcreatix

Gérer le fichier robots.txt correctement : le guide qui évite le crash SEO

Un `Disallow: /` mal copié dans le robots.txt peut faire chuter votre trafic à zéro, sans aucune alerte. Découvrez comment gérer ce fichier minuscule qui peut tout faire basculer.

Gérer le fichier robots.txt correctement : le guide qui évite le crash SEO

Vous avez déjà vu cette scène : un site entier disparaît de Google du jour au lendemain, et le webmaster jure qu'il n'a rien touché. Dans neuf cas sur dix que j'ai rencontrés, le coupable tient en une ligne, mal orthographiée, dans un fichier que personne n'a relu depuis des mois. Le robots.txt. Ce petit fichier texte que tout le monde crée une fois, oublie, puis se rappelle à ses dépens.

Je vais être direct : bien gérer le fichier robots.txt n'a rien de glamour, mais c'est l'une des rares choses qu'un mauvais copier-coller peut transformer en catastrophe silencieuse. Un Disallow: / collé par erreur, et votre trafic organique tombe à zéro sans le moindre message d'erreur. Pas d'alerte. Pas de crash. Juste le silence.

Points clés à retenir

  • Le robots.txt vit obligatoirement à la racine du domaine, sinon il est ignoré.
  • Il contrôle l'exploration, pas l'indexation : une URL bloquée peut quand même apparaître dans les résultats.
  • Les wildcards * et l'ancre $ changent tout dans une règle Disallow, souvent pour le pire.
  • Un fichier physique sur le serveur a la priorité sur un fichier généré par une extension WordPress.
  • AdsBot ignore la règle de blocage global : un User-agent: * trop large ne suffit pas à tout protéger.
  • Testez systématiquement après chaque modification. Toujours.

Gérer le fichier robots.txt, c'est quoi au juste ?

Un fichier robots.txt est un protocole d'exclusion. Un standard de courtoisie, pas une loi. Vous dites aux robots d'exploration où ils peuvent aller et où ils ne doivent pas mettre les pieds. C'est tout.

Le hic, c'est que ce n'est pas un mécanisme de sécurité. J'ai vu des développeurs y mettre des chemins d'administration en pensant cacher quelque chose. Mauvaise idée. Le fichier est public, n'importe qui peut lire votre liste et en déduire ce que vous essayez de protéger. C'est comme planter un panneau « ne pas regarder » devant un coffre-fort.

Où se trouve-t-il exactement ?

Toujours à la racine. https://votredomaine.com/robots.txt. Pas dans un sous-dossier, pas dans /assets/. Si vous le mettez ailleurs, les robots l'ignorent purement et simplement. Comment trouver le robots.txt d'un site concurrent ? Tapez son nom de domaine suivi de /robots.txt dans la barre d'adresse. C'est aussi simple que ça, et c'est souvent très instructif.

La syntaxe exacte, avec un exemple qui marche

Voici un fichier robots.txt propre, celui que je déploie par défaut sur un site e-commerce :

User-agent: *
Disallow: /panier/
Disallow: /commande/
Disallow: /*?tri=
Allow: /images/

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

Décortiquons. User-agent: * cible tous les robots. Disallow liste ce qu'ils ne doivent pas explorer. Allow crée une exception quand une règle plus large bloque trop. Et le Sitemap indique l'emplacement de votre plan de site.

Les wildcards et l'ancre $

C'est ici que les gens se blessent. L'astérisque * remplace n'importe quelle séquence de caractères. Le symbole $ marque la fin d'une URL.

  • Disallow: /*.pdf$ bloque tous les PDF, où qu'ils soient.
  • Disallow: /dossier/* bloque tout ce qui suit /dossier/.
  • Disallow: /page bloque /page mais pas /page-2.

Vous voyez la nuance ? Une barre oblique finale change tout. J'ai passé une après-midi entière à comprendre pourquoi une section de blog restait indexée malgré un Disallow: /blog. Il me manquait l'astérisque.

Exploration ou indexation : ne confondez plus les deux

Voilà l'erreur de compréhension la plus répandue. Bloquer une URL dans le robots.txt empêche un robot de la lire. Cela ne l'empêche pas de la référencer.

Exploration ou indexation : ne confondez plus les deux

Comment est-ce possible ? Si un autre site pointe vers votre page bloquée, Google peut indexer l'URL sur la seule base du lien, sans jamais avoir vu le contenu. Vous vous retrouvez avec une page dans les résultats, sans titre, sans description, sans rien. Pire qu'un mauvais snippet : un espace vide.

Pour bloquer réellement l'indexation, vous avez besoin d'une balise meta robots noindex ou d'un en-tête X-Robots-Tag. Et attention au piège classique : noindex + Disallow sur la même page annule le noindex, puisque le robot ne peut pas lire l'instruction qu'il doit suivre. Si vous voulez désindexer, laissez la page explorable le temps que Google assimile le noindex, puis seulement ensuite vous pourrez la bloquer.

Mécanisme Contrôle l'exploration Contrôle l'indexation Où il se place
robots.txt Oui Non Racine du domaine
Meta robots Partiellement Oui Dans le code HTML de la page
X-Robots-Tag Partiellement Oui En-tête HTTP (utile pour les non-HTML)

Robot.txt WordPress : fichier physique ou virtuel ?

Sur WordPress, la question revient sans arrêt. Deux options s'offrent à vous.

La première : un fichier physique que vous déposez à la racine via FTP. La seconde : un fichier virtuel généré par une extension comme SEOPress ou Yoast, modifiable depuis l'administration.

Le point que personne ne précise assez : si un fichier physique existe, il écrase le fichier virtuel. J'ai déjà perdu une heure à modifier les réglages d'une extension sans comprendre pourquoi rien ne changeait. Un vieux robots.txt traînait à la racine depuis une migration. Supprimez-le si vous voulez reprendre la main via l'interface.

La règle de blocage global ne protège pas tout le monde

Information que je n'ai quasiment jamais vue expliquée ailleurs : un blocage global (Disallow: /) ne s'applique pas à tous les robots. AdsBot, celui qui analyse les pages de destination publicitaires, passe outre. De même, certains robots d'images comme Googlebot-Image ont leurs propres règles.

Traduction concrète : si vous bloquez tout en croyant arrêter la publicité, vous vous trompez. Il faut cibler les user-agents un par un.

Tester son robots.txt : l'étape qu'on saute trop souvent

Modifier son fichier sans le tester, c'est jouer à la roulette russe avec son référencement. La bonne nouvelle, c'est que les outils existent et qu'ils sont gratuits.

  • Le testeur de robots.txt intégré à la Search Console vous dit en quelques secondes si une URL est bloquée.
  • L'inspection d'URL vous montre la version du fichier effectivement lue par Google, en cache.
  • Un simple curl https://votredomaine.com/robots.txt depuis un terminal confirme ce que le serveur renvoie réellement.

Ce dernier point compte : j'ai vu un fichier parfait côté CMS qui renvoyait une erreur 404 à cause d'une règle de réécriture mal configurée. Personne ne s'en était rendu compte pendant des mois.

Que faire en cas de conflit entre directives ?

Robots.txt, meta robots, X-Robots-Tag, canonique : quand tout se contredit, lequel gagne ?

La règle de base : la directive la plus restrictive pour l'exploration l'emporte, mais la plus précise pour l'indexation gagne. Un noindex dans le HTML prime sur un Disallow qui, de toute façon, ne l'aurait pas lu. En cas de doute, testez. Ne devinez jamais sur ce sujet.

Et si un robot décide de vous ignorer ?

Question inconfortable, mais réelle. Le robots.txt n'a aucune valeur contractuelle. Un robot peut parfaitement décider de ne pas s'y conformer. Les grands moteurs jouent le jeu parce que c'est leur intérêt, mais un scraper agressif s'en moque éperdument.

Si votre problème est un aspirateur de contenu tiers, le robots.txt n'est pas votre solution. Passez au filtrage côté serveur, au rate limiting, ou à un pare-feu applicatif. C'est un autre métier, mais c'est le seul qui fonctionne face à un robot mal intentionné.

Les erreurs que je vois le plus souvent

  1. Un Disallow: / laissé en place après une phase de maintenance.
  2. Une majuscule dans le chemin. Les URL sont sensibles à la casse, /Dossier n'est pas /dossier.
  3. Un fichier déplacé hors racine après une refonte du site.
  4. Plusieurs règles User-agent identiques qui se contredisent, sans que personne ne sache laquelle s'applique.
  5. Un Sitemap déclaré avec un domaine différent de celui où se trouve le fichier.

La cinquième est sournoise et je l'ai commise. Un plan de site avec le préfixe www déclaré depuis un fichier servi sans www. Google a fini par s'en accommoder, mais l'incohérence a ralenti la découverte de nouvelles pages pendant des jours.

Les erreurs que je vois le plus souvent

Ce qu'il faut vraiment garder en tête

Le robots.txt n'est pas un réglage qu'on pose une fois pour toutes. C'est un document vivant, qui doit refléter l'état réel de votre site. Chaque nouvelle section, chaque refonte, chaque changement de domaine mérite qu'on y jette un œil.

La prochaine fois que votre trafic plonge sans explication, avant de blâmer une mise à jour d'algorithme, ouvrez ce fichier. Il y a de bonnes chances que la réponse soit là, écrite noir sur blanc depuis des mois, par vous, sans que vous l'ayez remarqué.

Et si vous ne retenez qu'une chose : testez après chaque modification. Cette habitude de dix secondes vaut tous les audits du monde.

Yannick Rossignol

Yannick Rossignol

Yannick Rossignol est un spécialiste reconnu du référencement local, du netlinking et de l'analyse de mots-clés. Il accompagne les entreprises dans le développement de leur visibilité en ligne en optimisant leur présence géolocalisée et en construisant des stratégies de liens de qualité. Passionné par la donnée et les comportements de recherche, il met son expertise au service de résultats concrets et durables.

Voir tous les articles →

Articles similaires