J’ai passé trois ans à me tromper avec les fichiers robots.txt. Le premier site que j’ai lancé en 2020, j’ai copié-collé un extrait trouvé sur un forum : Disallow: /. Résultat : mon site a été complètement déréférencé pendant six semaines. Mon trafic organique est passé de 0 à… 0. Mais au moins j’ai appris la leçon : un fichier mal rédigé, c’est pire que pas de fichier du tout.
Aujourd’hui, je gère une vingtaine de sites, du petit blog WordPress aux grosses structures e-commerce. Et je te jure que le fichier robots.txt reste l’un des outils les plus sous-estimés – et surtout les plus mal utilisés – du SEO classique.
Ce guide n’est pas une énième liste de directives copiées d’un manuel. C’est le résultat de mes erreurs, de mes tests en conditions réelles, et de ce que j’ai vu marcher (ou pas) sur mes propres projets.
Points clés à retenir
- Le fichier robots.txt ne bloque PAS l’indexation – il bloque seulement l’exploration par les robots
- Une seule erreur de syntaxe peut désindexer 100 % de ton site
- Google traite les wildcards comme
*et$, mais pas tous les moteurs - Toujours tester avant de mettre en production – Google Search Console est ton ami
- Les conflits avec les balises
meta robotspeuvent créer des bugs invisibles - Le crawl budget est une vraie ressource – ne la gaspille pas sur des pages poubelles
C’est quoi exactement un fichier robots.txt (et pourquoi tu devrais t’y intéresser) ?
Avouons-le : la première fois que j’ai vu un fichier robots.txt, j’ai cru que c’était un truc de développeur paranoïaque. Genre, « Cachez vos fichiers sensibles des méchants robots ». En réalité, c’est beaucoup plus banal – et beaucoup plus stratégique.
Un fichier robots.txt, c’est un petit fichier texte placé à la racine de ton site (ex : monsite.com/robots.txt). Il donne des instructions aux robots d’exploration (crawlers) comme Googlebot, Bingbot ou Yandex. Tu leur dis quoi explorer, quoi ignorer, et où trouver ton plan de site.
Mais attention : ce n’est PAS un système de sécurité. Les crawlers obéissants (Googlebot, Bingbot) respectent les règles, mais d’autres (certains robots malveillants ou scrapers) les ignorent complètement. Ne cache jamais des données confidentielles derrière robots.txt.
La nuance que tout le monde oublie : exploration ≠ indexation
J’ai vu des clients paniquer parce qu’ils avaient mis Disallow: /admin/ dans leur fichier, et leurs pages admin apparaissaient encore dans Google. Normal : le fichier robots.txt empêche l’exploration, mais pas l’indexation. Si une page est déjà indexée avant que tu ne bloques son exploration, elle peut rester dans l’index – même si Googlebot ne peut plus la visiter. Pour vraiment cacher une page, tu utilises meta robots: noindex.
Un jour, j’ai bloqué par erreur une page produit importante dans robots.txt, mais elle était encore dans l’index via un lien externe. Résultat : Google l’a gardée, mais sans pouvoir la crawler. Le titre affiché était « Aucune information disponible » – un cauchemar UX. Depuis, je fais toujours attention à ne pas mélanger les outils.
La syntaxe de base : ce que tu dois absolument connaître
Franchement, la syntaxe est simple – c’est tellement basique que les développeurs la regardent souvent de haut. Mais c’est justement là que le bât blesse : une erreur de syntaxe sur une seule ligne, et c’est tout ton site qui peut partir en vrille.
Voici les directives essentielles que j’utilise quotidiennement :
| Directive | Usage | Exemple |
|---|---|---|
User-agent | Cible un moteur ou tous (*) | User-agent: Googlebot |
Disallow | Bloque l’accès à un chemin | Disallow: /wp-admin/ |
Allow | Autorise malgré un Disallow (prioritaire) | Allow: /wp-admin/admin-ajax.php |
Sitemap | Donne le chemin vers le sitemap XML | Sitemap: https://monsite.com/sitemap.xml |
Et là, je vois déjà les puristes dire : « Mais on peut utiliser * et $ pour des patterns ! » Oui, mais attention :
*correspond à n’importe quelle séquence de caractères. Exemple :Disallow: /*.pdf$bloque tous les PDF. Mais Google seulement interprète le$comme « fin d’URL ».- Bing, lui, ne comprend pas le
$. Si tu veux bloquer les PDF sur tous les moteurs, utilise :Disallow: /*.pdf(sans$).
Mon conseil : écris toujours en pensant à Googlebot en priorité, mais si tu vises le marché international, teste aussi sur Bing et Yandex.
Exemple concret : fichier robots.txt pour WordPress
J’ai un site WordPress que j’optimise depuis 2021. Voici le fichier que j’utilise – et qui a fait passer mon crawl budget de 15 pages/jour à plus de 80 pages/jour sur Google.
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Allow: /wp-admin/admin-ajax.php
Disallow: /*/feed/
Disallow: /*/trackback/
Disallow: /*.pdf$
Sitemap: https://monsite.com/sitemap.xml
User-agent: Googlebot-Image
Allow: /wp-content/uploads/
User-agent: Googlebot-Video
Allow: /wp-content/uploads/Explication rapide : je bloque tout l’admin (/wp-admin/) et les fichiers système (/wp-includes/), mais j’autorise admin-ajax.php parce que certains plugins en ont besoin pour les appels AJAX. Je bloque les flux RSS et trackbacks (inutiles pour le SEO). Et je laisse Googlebot-Image explorer mes images – ça marche du tonnerre pour le trafic image.
Comment prioriser l’exploration avec robots.txt (le vrai sujet)
Bon, la base, tu l’as. Mais le vrai défi, c’est de ne pas laisser Googlebot perdre son temps sur des pages inutiles. Sur un site e-commerce de 5000 produits, avec 15 filtres de catégorie et des pages de tags, le crawl budget devient une ressource précieuse.
J’ai testé ça sur un site de vente de meubles (mon projet le plus ambitieux) : au début, Googlebot crawlé 800 URL par jour, mais 70 % étaient des pages de filtres vides (ex : /categorie/?couleur=rouge&prix=100-200 qui n’avaient aucun produit). Résultat : les pages produits réelles étaient crawless une fois par semaine.
J’ai ajouté ces lignes :
Disallow: /*?*
Disallow: /*/page/
Allow: /*?*&page=Petite explication : Disallow: /*?* bloque quasi toutes les URL avec paramètres d’URL. Mais j’ai ajouté Allow: /*?*&page= pour laisser passer la pagination – parce que parfois les pages 2, 3, 4 des catégories sont importantes. Résultat : le crawl budget a augmenté de 40 %, et les ventes organiques ont grimpé de 12 % en deux mois.
Les 3 erreurs que j’ai faites (et que tu vas éviter)
- Mettre un Disallow: / sur tout le site – exactement ce que j’ai fait au début. Googlebot ne vient plus du tout. Solution : si tu veux bloquer un dossier, fais-le avec des règles spécifiques, jamais tout le site.
- Bloquer les fichiers CSS/JS – ça peut sembler logique (pourquoi faire crawler des fichiers techniques ?), mais Google a besoin de tes CSS et JS pour comprendre la mise en page et l’interactivité. Si tu les bloques, ton site peut être interprété comme une page vide. Vérifie dans Google Search Console l’onglet « Ressources bloquées ».
- Oublier le sitemap – la directive
Sitemap:dans le fichier permet à Google de trouver ton plan de site plus rapidement. Sans ça, il doit deviner ou utiliser la Search Console pour le soumettre. Je mets toujoursSitemap:dans la première sectionUser-agent: *.
Comment tester un fichier robots.txt avant de le mettre en ligne
J’ai appris à la dure : ne jamais modifier un fichier robots.txt directement en production sans l’avoir testé. Mon erreur la plus récente : j’avais mis un espace après Disallow: sans slash, ce qui a rendu la règle invalide. Google l’a interprétée comme « autoriser tout ».
Voici mon workflow aujourd’hui :
- Je crée le fichier dans un éditeur de texte (pas Word, pas Notepad – un vrai éditeur comme VS Code ou Sublime Text).
- Je le teste sur l’outil de test robots.txt de Google Search Console – il vérifie la syntaxe et simule l’exploration d’une URL spécifique.
- Je valide sur des outils comme
robots-txt.comou TechnicalSEO.com/robots-txt. - Je mets en ligne, et je vérifie que les crawlers Google peuvent toujours accéder à mon sitemap et à mes pages importantes (via le rapport « Pages indexées » de Search Console).
Le piège que j’ai vu chez un client : il avait un fichier robots.txt valide, mais un plugin de sécurité (Wordfence) écrasait son contenu avec des règles par défaut. Résultat : son site était partiellement bloqué sans qu’il le sache. Depuis, je vérifie toujours si des plugins modifient le fichier automatiquement.
Exemples concrets pour différents types de sites
Chaque type de site a ses spécificités. Voici ce que j’utilise sur mes projets :
Site e-commerce
Le défi : les filtres de recherche génèrent des centaines d’URL inutiles. Voici une version que j’ai affinée sur un site avec 10 000 produits :
User-agent: *
Disallow: /*?*
Disallow: /categorie/*/page/
Disallow: /comparer/
Disallow: /*?sort=
Allow: /categorie/
Allow: /produit/
Sitemap: https://monsite.com/sitemap.xmlÇa bloque les paramètres d’URL (sauf ceux utiles pour la pagination – j’ai dû ajuster), les pages de comparaison de produits, et les tris. Les pages catégories et produits restent accessibles.
Site médias (actualités, blog)
Pour les sites d’actualités, le crawl budget est critique parce que Google vient très souvent. Je bloque :
- Les pages de tags (
/tag/) – souvent du contenu dupliqué - Les archives d’auteur (
/author/) – inutiles - Les résultats de recherche interne (
/?s=) – ça pompe des ressources
Quand robots.txt et meta robots se battent (et comment les réconcilier)
J’ai déjà vu des sites où une page était bloquée dans robots.txt (Disallow) mais avait une balise <meta name="robots" content="noindex">. Le comportement de Google ? Il suit d’abord robots.txt – donc il ne crawle même pas la page, et la balise noindex n’est jamais lue. La page peut rester dans l’index si elle a été crawless avant.
La règle d’or : si tu veux qu’une page soit vraiment noindex, ne la bloque pas dans robots.txt. Laisse Google la crawl pour qu’il voie la balise. Si tu veux qu’elle soit totalement invisible, alors bloque-la dans robots.txt ET supprime-la de l’index via l’outil de Search Console.
Personnellement, j’ai une check-list :
- Pages sensibles (admin, login) →
Disallowdans robots.txt + pas de lien public - Pages de faible valeur (tags, filtres) →
Disallowdans robots.txt +noindexsur les pages déjà indexées - Pages vraiment importantes →
Allowdans robots.txt, pas denoindex
Les pièges syntaxiques qui m’ont coûté des semaines
Je termine avec les erreurs que je vois le plus souvent chez mes lecteurs – et que j’ai moi-même commises :
- Un espace après Disallow: avant le slash – ça rend la règle invalide. Écris
Disallow: /dossier/, pasDisallow: /dossier/. - Des commentaires mal placés – les commentaires commencent par
#et doivent être sur leur propre ligne. Si tu mets un#au milieu d’une ligne, tout ce qui suit peut être ignoré. - User-agent en minuscules – Google détecte
user-agent:comme valide, mais certains crawlers (comme Bingbot) sont moins tolérants. Toujours écrireUser-agent:avec un U majuscule. - Oublier les chemins absolus –
Disallow: dossiersans slash peut être interprété comme un nom de fichier. Toujours commencer par/pour les dossiers.
Et voilà, c’est mon expérience brute. J’ai perdu du temps, j’ai fait des erreurs, mais j’ai fini par comprendre que le fichier robots.txt est un outil de pilotage du crawl budget – pas un gadget de sécurité. Si tu veux vraiment maîtriser ton SEO technique, passe une heure à le configurer correctement. Teste, ajuste, et surveille les résultats dans Google Search Console.
Le meilleur conseil que je puisse te donner ? N’aie pas peur de te tromper – mais teste toujours avant de mettre en ligne. Et si tu veux un générateur, j’ai un petit outil maison que j’utilise pour mes clients. Mais honnêtement, tu peux aussi le faire à la main en suivant ce guide. Bon courage.