Un fichier de deux lignes peut suffire à rendre invisible un site entier sur Google. Le robots.txt, c’est exactement ça : un fichier texte de quelques octets, souvent créé à la va-vite, et qui décide quelles pages les moteurs de recherche ont le droit d’explorer. Quand il contient une erreur, il n’y a ni alerte rouge, ni message d’avertissement visible. Le trafic organique chute, parfois pendant des semaines, avant que quelqu’un ne pense à vérifier ce petit fichier posé à la racine du serveur.
Dans cet article
- Une directive Disallow: / placée par erreur bloque l’intégralité d’un site pour tous les robots d’exploration
- Le robots.txt doit être accessible à l’URL https://votredomaine.fr/robots.txt exactement, sinon Google le considère comme absent ou permissif
- Confondre Disallow et Noindex dans le robots.txt est l’une des erreurs les plus répandues, car la directive Noindex n’y est plus supportée depuis 2019
- Un fichier robots.txt mal encodé (BOM UTF-8, retours chariot Windows) peut être mal interprété par Googlebot sans générer d’erreur visible
- Bloquer les fichiers CSS et JS dans le robots.txt empêche Google de rendre la page et dégrade le positionnement depuis 2015
- La Search Console permet de tester chaque directive avant mise en production grâce à l’outil de test du robots.txt
Sommaire
- Ce que fait réellement le robots.txt (et ce qu’il ne fait pas)
- Erreur numéro un : le Disallow: / qui bloque tout
- Confondre Noindex et Disallow : une directive fantôme
- Bloquer les CSS, JS et ressources statiques
- Erreurs de syntaxe et d’encodage qui passent inaperçues
- Les erreurs spécifiques à WordPress, Shopify et Wix
- Tableau récapitulatif des erreurs et de leur impact
- Diagnostiquer et corriger son robots.txt
- Questions fréquentes sur le robots.txt
Ce que fait réellement le robots.txt (et ce qu’il ne fait pas)
Le robots.txt est un fichier texte placé à la racine d’un site web. Son rôle est simple : il indique aux robots d’exploration (Googlebot, Bingbot, etc.) quelles parties du site ils sont autorisés à parcourir et lesquelles ils doivent ignorer. C’est un protocole de bonne volonté, pas un mécanisme de sécurité. Un robot malveillant peut parfaitement l’ignorer.
Ce fichier ne protège pas les données sensibles. Si une page contient des informations confidentielles, la bloquer dans le robots.txt ne suffit pas : elle reste accessible à quiconque connaît l’URL. Pour protéger du contenu, il faut une authentification côté serveur ou une restriction par mot de passe.
Autre confusion fréquente : le robots.txt n’empêche pas l’indexation. Google peut indexer une URL bloquée par le robots.txt s’il la découvre via un lien externe, même s’il ne peut pas en explorer le contenu. Le résultat dans les SERP affichera alors un titre générique et aucune meta description. Pour empêcher l’indexation, c’est la balise meta robots noindex ou l’en-tête HTTP X-Robots-Tag qu’il faut utiliser. J’ai détaillé ce mécanisme dans mon article sur les pages non indexées par Google.
Selon la spécification robots.txt documentée par Google, le fichier doit être servi en texte brut (type MIME text/plain), accessible en HTTP 200, et situé exactement à la racine du domaine. Un robots.txt qui renvoie une erreur 404 est traité comme s’il n’existait pas, ce qui signifie que tout le site est ouvert au crawl.
Voir aussi Taux de rebond : pourquoi un chiffre élevé n’est pas toujours mauvais
Erreur numéro un : le Disallow: / qui bloque tout
C’est l’erreur la plus dévastatrice et, paradoxalement, l’une des plus courantes. Deux lignes suffisent à rendre un site entièrement invisible :
User-agent: *
Disallow: /Cette directive indique à tous les robots (User-agent: *) de ne parcourir aucune page du site (Disallow: /). Quand je récupère un site en audit, c’est souvent la première chose que je vérifie. Dans environ un cas sur cinq, ce Disallow global est un vestige de la phase de développement : le développeur l’a mis en place pour empêcher Google d’indexer le site de staging, puis a oublié de le retirer au moment de la mise en production.
Les conséquences sont invisibles à l’œil nu. Le site fonctionne parfaitement pour les visiteurs humains. Mais côté SEO, Googlebot cesse progressivement de crawler les pages, qui disparaissent des résultats de recherche en quelques jours à quelques semaines. Le trafic organique s’effondre, et comme aucune erreur technique n’apparaît dans le navigateur, la cause reste souvent inexpliquée pendant longtemps.
La bonne pratique : au moment de chaque mise en production, vérifier systématiquement le robots.txt. Si le site était en préprod avec un blocage global, il faut remplacer ce fichier par un robots.txt adapté à la production. C’est un point que j’intègre désormais dans toutes mes checklists de refonte pour éviter les pertes de trafic.
Confondre Noindex et Disallow : une directive fantôme
Pendant des années, certains référenceurs utilisaient une directive Noindex: dans le robots.txt pour empêcher l’indexation de certaines URL. Google a supporté cette directive de façon non officielle, mais en septembre 2019, il a officiellement cessé de la prendre en compte. Depuis cette date, écrire Noindex: /dossier-secret/ dans le robots.txt n’a strictement aucun effet.
Le piège, c’est que cette ligne ne provoque pas d’erreur de syntaxe. Le fichier reste valide, la directive est simplement ignorée en silence. Beaucoup de sites conservent encore ces lignes héritées, persuadés que leurs pages sensibles sont protégées de l’indexation alors qu’elles ne le sont plus du tout.
La confusion va plus loin. Bloquer une URL avec Disallow empêche le crawl, mais pas l’indexation. Si Google trouve un lien vers cette URL sur un autre site, il peut l’ajouter à son index avec un titre deviné et aucune description. C’est souvent pire que de laisser la page être crawlée normalement, car le résultat dans les SERP est peu engageant et peut nuire à l’image de marque.
Pour véritablement empêcher l’indexation, il faut utiliser la balise <meta name="robots" content="noindex"> dans le code HTML de la page, ou l’en-tête HTTP X-Robots-Tag: noindex. Et attention au piège logique : si la page est bloquée par le robots.txt, Google ne peut pas lire la balise noindex qu’elle contient. Il faut donc autoriser le crawl tout en demandant le noindex dans le HTML. Ce sujet rejoint directement la question de l’intention de recherche : chaque page doit avoir un objectif clair, y compris celui de ne pas être indexée.
Bloquer les CSS, JS et ressources statiques
Avant 2015, bloquer les fichiers CSS et JavaScript dans le robots.txt était une pratique courante. L’idée était de concentrer le budget de crawl sur les pages HTML et d’éviter que Googlebot ne perde du temps sur des fichiers statiques. Depuis que Google utilise un moteur de rendu basé sur Chrome pour évaluer les pages, cette pratique est devenue contre-productive.
Quand Googlebot ne peut pas accéder aux fichiers CSS et JS, il ne peut pas rendre la page correctement. Il voit une version dégradée, souvent sans mise en page, sans contenu chargé dynamiquement, et parfois avec un contenu complètement différent de ce que voient les utilisateurs. Google peut alors considérer que le site pratique le cloaking (afficher un contenu différent aux robots et aux humains), ce qui peut entraîner une pénalité manuelle.
Les directives à surveiller sont celles qui bloquent les répertoires de thèmes, les dossiers de plugins, ou les CDN internes :
Disallow: /wp-content/themes/
Disallow: /wp-content/plugins/
Disallow: /wp-includes/Ces trois lignes empêchent Google de charger la quasi-totalité des ressources front-end d’un site WordPress. Le résultat dans l’outil de test d’URL de la Search Console est édifiant : la page apparaît comme une page blanche ou avec du texte brut sans style. Cela impacte directement les Core Web Vitals mesurés par Google et, par extension, le positionnement.
La règle actuelle est simple : ne jamais bloquer les ressources nécessaires au rendu visuel. Les seules ressources qu’il est pertinent de bloquer sont celles qui n’apportent rien au contenu visible (scripts de tracking, pixels de conversion, fichiers internes d’administration).
Voir aussi GA4 : configurer les événements qui comptent vraiment pour une PME
Erreurs de syntaxe et d’encodage qui passent inaperçues
Le robots.txt a une syntaxe minimaliste, mais cette simplicité est trompeuse. Plusieurs erreurs de forme passent complètement inaperçues et modifient le comportement du fichier de façon silencieuse.
Le BOM UTF-8
Certains éditeurs de texte (notamment Notepad sur Windows) ajoutent un Byte Order Mark (BOM) au début du fichier. Ce caractère invisible (\xEF\xBB\xBF) peut empêcher Googlebot de lire correctement la première ligne du fichier. Si la première directive est un User-agent, elle peut être ignorée, et toutes les règles associées deviennent inopérantes. La solution : utiliser un éditeur qui permet d’enregistrer en UTF-8 sans BOM (VS Code, Sublime Text, Notepad++).
Les retours à la ligne Windows
Les fichiers créés sous Windows utilisent \r\n (CR+LF) comme retour à la ligne, tandis que les serveurs Linux attendent \n (LF seul). Dans la plupart des cas, Google gère correctement les deux formats. Mais certains robots moins tolérants peuvent mal interpréter les directives. Par précaution, il vaut mieux toujours utiliser le format LF.
Les espaces et la casse
La spécification précise que les directives User-agent, Disallow, Allow et Sitemap sont insensibles à la casse pour le nom de la directive, mais les chemins d’URL sont sensibles à la casse. Écrire Disallow: /Admin/ ne bloque pas /admin/. Cette distinction piège régulièrement les webmasters qui travaillent sur des serveurs Windows (insensibles à la casse par défaut) avant de déployer sur Linux.
Les wildcards mal utilisées
Google supporte deux caractères spéciaux dans les chemins : * (joker, correspond à toute séquence de caractères) et $ (fin de chaîne). Mais ces caractères ne font pas partie de la spécification originale du protocole. Bingbot et d’autres robots ne les interprètent pas toujours de la même façon. Une règle comme Disallow: /*.pdf$ (bloquer tous les PDF) fonctionne avec Google mais peut être ignorée par d’autres moteurs. Pour un blocage fiable sur tous les moteurs, il vaut mieux bloquer le répertoire contenant les fichiers plutôt que d’utiliser des wildcards complexes.
Les erreurs spécifiques à WordPress, Shopify et Wix
WordPress
WordPress génère un robots.txt virtuel par défaut si aucun fichier physique n’existe à la racine. Ce fichier par défaut contient des règles basiques qui bloquent /wp-admin/ tout en autorisant /wp-admin/admin-ajax.php. Le problème survient quand un plugin de sécurité ou de SEO écrase ce fichier avec ses propres règles, parfois en ajoutant des blocages excessifs.
J’ai vu des sites WordPress où un plugin de sécurité avait ajouté des dizaines de lignes de Disallow pour protéger des répertoires sensibles. Le résultat : Google ne pouvait plus accéder aux images du dossier /wp-content/uploads/, ce qui empêchait l’indexation dans Google Images et dégradait le rendu des pages.
Autre piège WordPress : la case à cocher « Demander aux moteurs de recherche de ne pas indexer ce site » dans Réglages > Lecture. Cette option ajoute un Disallow: / dans le robots.txt virtuel et une balise noindex sur toutes les pages. Elle est souvent cochée en développement et oubliée en production.
Shopify
Sur Shopify, le robots.txt est géré automatiquement par la plateforme. Il bloque par défaut les pages de panier, de checkout, et les collections filtrées. Depuis 2021, Shopify permet de personnaliser le robots.txt via un fichier robots.txt.liquid dans le thème. Mais toute erreur de syntaxe Liquid dans ce fichier peut casser le robots.txt entier et le remplacer par une page d’erreur HTML, que Google interprétera comme un fichier permissif (tout est autorisé).
Wix
Sur Wix, le robots.txt est entièrement géré par la plateforme et n’est pas directement modifiable par l’utilisateur. Wix génère automatiquement les règles et la référence au sitemap. Le risque principal est de créer des pages masquées via les paramètres de visibilité de Wix sans comprendre que cela ne les bloque pas nécessairement dans le robots.txt. Les deux mécanismes sont indépendants.
Tableau récapitulatif des erreurs et de leur impact
| Erreur | Impact SEO | Fréquence | Correction |
|---|---|---|---|
| Disallow: / oublié après la préprod | Critique : tout le site disparaît des SERP | Très fréquente | Retirer la ligne, vérifier en Search Console |
| Directive Noindex dans le robots.txt | Élevé : la page reste indexable malgré l’intention | Fréquente | Utiliser la balise meta noindex dans le HTML |
| Blocage des fichiers CSS et JS | Élevé : Google ne peut pas rendre la page | Fréquente sur WordPress | Autoriser /wp-content/themes/ et /wp-includes/ |
| BOM UTF-8 en début de fichier | Modéré : première directive potentiellement ignorée | Occasionnelle | Enregistrer en UTF-8 sans BOM |
| Mauvaise casse dans les chemins | Modéré : le blocage ne s’applique pas à l’URL réelle | Occasionnelle | Vérifier la casse exacte des URL sur le serveur |
| Robots.txt en erreur 404 ou 500 | Variable : 404 = tout ouvert ; 500 = tout bloqué | Rare | S’assurer que le fichier est bien servi en HTTP 200 |
| Absence de directive Sitemap | Faible : Google peut trouver le sitemap autrement | Très fréquente | Ajouter Sitemap: https://domaine.fr/sitemap.xml |
| Wildcards incompatibles entre moteurs | Modéré : règles ignorées par certains robots | Occasionnelle | Préférer les blocages par répertoire |
Diagnostiquer et corriger son robots.txt
Étape 1 : vérifier l’accessibilité
La première chose à faire est de taper https://votredomaine.fr/robots.txt dans un navigateur. Le fichier doit s’afficher en texte brut, sans mise en forme HTML, et le serveur doit renvoyer un code HTTP 200. Si le serveur renvoie une redirection (301 ou 302), Google suivra la redirection, mais certains robots ne le font pas. Si le serveur renvoie une erreur 5xx, Google considère par précaution que tout le site est bloqué et cesse de crawler pendant la durée de l’erreur.
Étape 2 : utiliser l’outil de test de la Search Console
La Google Search Console propose un outil de test du robots.txt (dans l’ancien rapport, mais toujours accessible). Il permet de saisir n’importe quelle URL du site et de vérifier si elle est autorisée ou bloquée par les directives actuelles. C’est le moyen le plus fiable de valider ses règles avant de les mettre en production.
Étape 3 : croiser avec le rapport de couverture
Dans la Search Console, le rapport « Pages » (anciennement « Couverture ») indique les URL exclues avec le motif « Bloquée par le fichier robots.txt ». Si des pages importantes apparaissent dans cette liste, c’est le signe d’un problème dans le robots.txt. Ce rapport est particulièrement utile après une refonte de site ou un changement de CMS.
Étape 4 : vérifier la cohérence avec le sitemap
Un piège classique consiste à lister des URL dans le sitemap XML tout en les bloquant dans le robots.txt. C’est contradictoire : le sitemap dit « crawle cette page » tandis que le robots.txt dit « ne crawle pas cette page ». Google signale ces incohérences dans la Search Console, mais ne choisit pas toujours le comportement attendu. La règle est simple : toute URL présente dans le sitemap doit être autorisée par le robots.txt.
Étape 5 : le modèle de robots.txt recommandé
Pour la plupart des sites, un robots.txt efficace tient en quelques lignes :
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://votredomaine.fr/sitemap.xmlCe modèle bloque l’accès à l’administration WordPress (inutile pour le SEO), autorise l’endpoint AJAX (nécessaire pour certains plugins front-end), et indique l’emplacement du sitemap. C’est suffisant pour 90 % des sites vitrine. Pour un site e-commerce, il faudra adapter les règles pour bloquer les pages de filtres à facettes, les paniers, et les pages de compte client, tout en laissant les pages produits et catégories accessibles.
Ce travail sur le robots.txt s’inscrit dans une démarche SEO globale. Si vous partez de zéro, j’ai détaillé l’ordre des chantiers SEO qui rapporte pour ne rien oublier.
Les erreurs à ne jamais commettre lors d’une correction
Quand on corrige un robots.txt, la tentation est de tout ouvrir d’un coup. Mais retirer un Disallow qui était en place depuis longtemps peut provoquer un afflux soudain de crawl sur des pages qui n’étaient pas prêtes : pages de staging encore en ligne, anciennes URL avec du contenu dupliqué, ou pages de test. Avant de supprimer un Disallow, il faut vérifier que les pages concernées sont prêtes à être indexées, qu’elles renvoient un contenu correct, et que leurs balises meta robots sont bien configurées.
De même, ne modifiez jamais le robots.txt en même temps que d’autres changements techniques majeurs (migration HTTPS, changement de domaine, refonte). Si un problème survient, il sera impossible de déterminer quelle modification en est la cause. Les changements du robots.txt doivent être isolés, documentés, et testés avant déploiement. Sur ce sujet, la RFC 9309 publiée par l’IETF formalise le protocole d’exclusion des robots et constitue la référence technique officielle.
Un dernier conseil que j’applique systématiquement : après chaque modification du robots.txt, je demande une nouvelle exploration des URL concernées via l’outil d’inspection d’URL de la Search Console. Cela permet de vérifier en quelques minutes que Google interprète les nouvelles règles comme prévu, plutôt que d’attendre le prochain passage naturel du crawler. Cette rigueur dans le suivi rejoint la logique d’un bon maillage interne : chaque élément technique doit être cohérent avec l’ensemble de la structure du site.
N’oubliez pas non plus de vérifier vos title et meta description sur les pages que vous ouvrez au crawl : si elles étaient bloquées depuis longtemps, ces balises sont peut-être obsolètes ou absentes.
À retenir
- Vérifiez votre robots.txt à chaque mise en production : tapez votredomaine.fr/robots.txt dans le navigateur et contrôlez qu’il ne contient pas de Disallow: /
- Ne comptez jamais sur le robots.txt pour empêcher l’indexation : utilisez la balise meta noindex dans le HTML ou l’en-tête X-Robots-Tag
- Autorisez systématiquement les fichiers CSS, JS et images pour que Google puisse rendre vos pages correctement
- Testez chaque modification dans l’outil de test de la Search Console avant de la déployer en production
- Assurez-vous que toute URL présente dans votre sitemap XML n’est pas bloquée par le robots.txt
Questions fréquentes
Le robots.txt empêche-t-il vraiment l’indexation d’une page ?
Non. Le robots.txt empêche le crawl (l’exploration), pas l’indexation. Google peut indexer une URL bloquée par le robots.txt s’il la découvre via un lien externe. La page apparaîtra alors dans les résultats sans titre ni description exploitables. Pour empêcher l’indexation, il faut utiliser la balise meta noindex dans le HTML de la page ou l’en-tête HTTP X-Robots-Tag.
Quand le robots.txt renvoie une erreur serveur (5xx), Google applique le principe de précaution et considère que tout le site est bloqué. Il cesse temporairement de crawler les pages jusqu’à ce que le fichier redevienne accessible. C’est l’inverse du comportement en cas d’erreur 404, où Google considère qu’il n’y a aucune restriction et crawle tout le site librement.Que se passe-t-il si mon fichier robots.txt renvoie une erreur 500 ?
Ce n’est pas obligatoire, car Google peut découvrir le sitemap via la Search Console ou par convention (sitemap.xml à la racine). Cependant, c’est une bonne pratique qui facilite la découverte du sitemap par tous les moteurs de recherche, y compris ceux qui ne disposent pas d’un outil webmaster équivalent. Une seule ligne suffit : Sitemap: https://votredomaine.fr/sitemap.xml.Faut-il ajouter la directive Sitemap dans le robots.txt ?
La méthode la plus fiable est de consulter le rapport « Pages » dans la Google Search Console. Il liste les URL exclues avec le motif « Bloquée par le fichier robots.txt ». Si des pages de contenu, des fiches produits ou des catégories apparaissent dans cette liste, il faut corriger les directives. L’outil de test du robots.txt permet ensuite de vérifier chaque URL individuellement.Comment savoir si mon robots.txt bloque des pages importantes ?
Oui, chaque sous-domaine possède son propre robots.txt. Le fichier robots.txt de www.domaine.fr ne s’applique pas à blog.domaine.fr ni à shop.domaine.fr. Chaque sous-domaine doit avoir son propre fichier à sa racine. C’est une source d’oubli fréquente lors de la mise en place d’un blog ou d’une boutique sur un sous-domaine séparé.Peut-on avoir un robots.txt différent par sous-domaine ?
Non. Google ignore complètement la directive Crawl-delay. Pour réguler la vitesse de crawl de Googlebot, il faut utiliser le paramètre de vitesse de crawl dans la Search Console (section Paramètres > Vitesse d’exploration). En revanche, Bing et Yandex respectent la directive Crawl-delay, ce qui peut être utile si le serveur a des ressources limitées.Les directives Crawl-delay fonctionnent-elles avec Google ?
Thomas Lefèvre est développeur freelance full-stack à Paris depuis 2015, spécialisé WordPress sur mesure, no-code et SEO technique. Sur Synergie.Web il documente les outils testés sur de vrais projets, sans partenariat commercial.
À lire aussi
Impressions, clics et position moyenne : ce que chaque chiffre cache
Une impression ne signifie pas que l'internaute a vu la page, un clic ne garantit pas une visite utile, et la…
Search Console : lire le rapport performances sans se tromper d’indicateur
Le rapport de performances de la Google Search Console affiche quatre métriques principales : clics,…
Avis Google : les obtenir sans les acheter et répondre aux négatifs
Les avis Google représentent le premier critère de confiance pour 76 % des consommateurs avant un achat…
SEO local : optimiser sa fiche Google Business pour le pack local
Une fiche Google Business Profile correctement renseignée augmente de 70 % la probabilité d'apparaître dans…
Acheter des backlinks : ce que Google détecte et ce qu’il laisse passer
Acheter des backlinks reste la pratique la plus débattue du référencement naturel, et aussi celle qui expose…
Netlinking : à quoi reconnaît-on un lien qui sert réellement
Un site qui reçoit 200 backlinks peut stagner en page 3, tandis qu'un concurrent avec 15 liens bien placés…
