// guide pilier
Robots.txt et indexation : ce qu'il faut savoir.
Bloquer le crawl n'empêche pas l'indexation. Distinguer robots.txt de noindex, maîtriser la syntaxe Disallow et Allow, éviter les pièges qui cassent le rendu mobile, configurer proprement WordPress.
À quoi sert robots.txt (et ce qu'il ne fait pas).
Le fichier /robots.txt placé à la racine d'un domaine indique aux robots de crawl (Googlebot, Bingbot, etc.) quelles URLs récupérer et lesquelles ignorer. C'est un protocole défini par le Robots Exclusion Protocol et standardisé par l'IETF en 2022 (RFC 9309).
// à retenir
Disallow empêche le crawl, pas l'indexation. Une page bloquée par robots.txt mais linkée depuis l'extérieur peut apparaître dans Google sans contenu, juste avec son URL. Pour empêcher l'apparition dans les résultats, utiliser noindex sur une page crawlable.
Ce que robots.txt fait
- Empêcher Googlebot de récupérer (crawler) certaines URLs : économise du crawl budget sur les gros sites.
- Déclarer la localisation du sitemap XML : facilite la découverte par tous les moteurs de recherche.
- Différencier les règles selon le bot : autoriser Googlebot mais bloquer un crawler agressif d'analyse SEO concurrent, par exemple.
Ce que robots.txt ne fait PAS
- Désindexer une page. Disallow empêche le crawl, mais l'URL peut rester ou apparaître dans Google si elle est linkée. Pour désindexer, utiliser
noindex(voir statuts d'exclusion GSC). - Sécuriser des données privées. Le fichier est public (n'importe qui peut lire
votresite.com/robots.txt), il révèle au contraire les chemins sensibles. Pour protéger, utiliser une authentification serveur. - Forcer le respect par tous les bots. C'est une convention. Les bots malveillants l'ignorent. Bloquer côté firewall ou User-agent serveur si besoin réel.
Syntaxe : Disallow, Allow, User-agent, Sitemap.
Le fichier robots.txt suit une syntaxe simple : un ou plusieurs blocs User-agent suivis de directives Disallow et Allow. Une ligne Sitemap peut être placée n'importe où dans le fichier.
Exemple minimal
User-agent: *
Allow: /
Sitemap: https://exemple.com/sitemap.xml
Lecture : tous les bots (*) sont autorisés à tout crawler. Le sitemap est déclaré pour faciliter la découverte des URLs.
Exemple typique
User-agent: *
Disallow: /admin/
Disallow: /panier/
Disallow: /recherche/
Allow: /admin/public/
User-agent: AdsBot-Google
Disallow:
Sitemap: https://exemple.com/sitemap.xml
Sitemap: https://exemple.com/sitemap-news.xml
Lecture : tous les bots évitent /admin/, /panier/ et /recherche/, sauf /admin/public/ (exception via Allow). Le bot AdsBot-Google a un bloc dédié sans Disallow (rien bloqué pour lui). Deux sitemaps déclarés.
Les 4 directives officielles
User-agent
Identifie le ou les bots ciblés par les règles qui suivent. * = tous les bots. Sinon nom exact : Googlebot, Bingbot, Googlebot-Image.
Disallow
Interdit le crawl du chemin indiqué. Disallow: / bloque tout le site. Disallow: (vide) ne bloque rien.
Allow
Autorise le crawl d'un chemin, utile pour faire une exception dans un dossier bloqué par Disallow. La règle la plus spécifique l'emporte.
Sitemap
Déclare l'URL absolue d'un sitemap XML. Indépendant des blocs User-agent. Plusieurs lignes Sitemap possibles.
Directives non standard à éviter
Crawl-delay n'est pas reconnu par Google (uniquement Bing et Yandex). Noindex dans robots.txt a été supporté informellement avant 2019, puis retiré officiellement. Ne plus l'utiliser. Pour ajuster la fréquence de crawl Google, passer par GSC > Paramètres > Fréquence de crawl.
Wildcards * et terminaison $.
Deux caractères spéciaux supportés par Google et la plupart des moteurs majeurs : * (n'importe quelle séquence) et $ (fin de chaîne). Indispensables pour gérer les paramètres d'URL, les filtres et les extensions de fichiers.
Le wildcard *
User-agent: *
Disallow: /*?tri=
Disallow: /*?couleur=
Disallow: /*/preview/
Bloque toutes les URLs qui contiennent ?tri= ou ?couleur= n'importe où dans le path (paramètres de filtres e-commerce). Bloque aussi /n-importe-quoi/preview/. Utile pour la faceted navigation qui multiplie les variantes d'URL d'un même contenu.
La terminaison $
User-agent: *
Disallow: /*.pdf$
Disallow: /*.xls$
Allow: /docs/public/*.pdf$
Bloque toutes les URLs qui se terminent par .pdf ou .xls, sauf les PDFs publics dans /docs/public/. Sans le $, /*.pdf bloquerait aussi /document.pdf?download=1 mais aussi toute URL qui contient ".pdf" suivi d'autres caractères, ce qui peut être imprévisible.
Cas concrets fréquents
- E-commerce avec filtres :
Disallow: /*?bloque toutes les URLs avec paramètres de query string. - Pages de session :
Disallow: /*sessionid=évite l'indexation de variantes avec ID de session. - Tracking UTM :
Disallow: /*?utm_bloque les URLs avec paramètres UTM (à coupler avec canonical sur la version propre).
User-agents Google et règles d'application.
Google utilise plusieurs bots spécialisés. Cibler le bon User-agent permet d'affiner les règles : autoriser Googlebot mais bloquer un crawler concurrent, exclure les images du crawl d'images, autoriser AdsBot pour préserver la qualité des annonces.
Les User-agents Google principaux
Googlebot
Bot principal pour le crawl web standard. Englobe Googlebot Smartphone (mobile-first depuis 2024) et Googlebot Desktop. Ne pas bloquer sauf raison explicite.
Googlebot-Image
Crawl spécifique pour Google Images. Bloquer ce bot exclut les images du moteur d'images, sans affecter le ranking web.
AdsBot-Google
Vérifie la qualité des landing pages des annonces Google Ads. Bloquer ce bot dégrade le Quality Score et peut faire chuter les annonces.
Googlebot-News
Crawl pour Google News. Pertinent uniquement pour les sites éditoriaux inscrits dans Google News Publisher Center.
Règle d'application : le plus spécifique gagne
Quand plusieurs blocs User-agent existent, Googlebot lit uniquement le bloc le plus spécifique qui le concerne, pas la combinaison. Si un bloc User-agent: Googlebot existe, Googlebot ignore complètement le bloc User-agent: *.
User-agent: *
Disallow: /admin/
Disallow: /panier/
User-agent: Googlebot
Disallow: /admin/
Lecture : Googlebot lit uniquement son bloc dédié. Il bloque /admin/ mais PAS /panier/ (qui n'est listé que dans le bloc *). Erreur classique : croire que les règles s'additionnent. Pour Googlebot, dupliquer toutes les règles dans le bloc dédié.
Cas WordPress 2026.
WordPress génère un robots.txt virtuel par défaut. La plupart des plugins SEO (Yoast, Rank Math, SEOPress) le surchargent. La configuration recommandée a évolué depuis le passage au mobile-first indexing : ne plus bloquer les répertoires qui contiennent CSS, JS et images. Détails plus bas et dans le guide indexation WordPress.
À ne plus faire en 2026
# Configuration obsolète, à NE PAS utiliser
User-agent: *
Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-admin/
Bloquer /wp-content/ empêche Googlebot de récupérer les CSS du thème, les JS, les images uploadées. Conséquence : Google ne peut pas vérifier le rendu responsive, et le site est déclassé sur mobile. /wp-includes/ contient aussi des fichiers JS critiques (jQuery, etc.).
Configuration recommandée 2026
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
# Bloquer les pages utilitaires sans valeur SEO
Disallow: /?s=
Disallow: /author/
Disallow: /trackback/
Disallow: /*/feed/
Disallow: /*?replytocom
Sitemap: https://exemple.com/sitemap_index.xml
Lecture : seul /wp-admin/ est bloqué (avec exception pour admin-ajax.php qui sert à des fonctionnalités front). /wp-content/ et /wp-includes/ restent accessibles. Les pages parasites SEO (recherche interne, archives auteur, flux RSS) sont exclues.
Pièges WordPress fréquents
- Robots.txt physique vs virtuel : si un fichier
robots.txtexiste physiquement à la racine, WordPress n'utilise plus le virtuel. Vérifier ce qui est servi viacurl https://exemple.com/robots.txt. - "Décourager les moteurs" en Réglages > Lecture : cette case ajoute
Disallow: /au robots.txt virtuel. À décocher impérativement avant la mise en production. - Plugin de cache : certains plugins (WP Super Cache, W3 Total Cache) génèrent des URLs de variantes que Google peut crawler inutilement. Bloquer les URLs de cache si exposées.
- WooCommerce : ajouter
Disallow: /panier/,Disallow: /commande/,Disallow: /mon-compte/. Ces pages n'ont aucune valeur SEO et consomment du crawl budget.
Tester son robots.txt avec GSC.
L'ancien testeur robots.txt de Search Console a été retiré en 2023. La méthode actuelle passe par l'inspection d'URL, qui indique si une URL est bloquée par robots.txt et permet de tester le rendu réel par Googlebot.
- 01
Inspection d'URL dans GSC
Search Console > barre de recherche en haut > coller l'URL à tester. Si la page est bloquée par robots.txt, le rapport indique "Bloquée par robots.txt" dans la section "Indexation". Cliquer sur "Tester l'URL en direct" pour vérifier la règle qui bloque exactement, et le bot concerné.
- 02
Voir la page testée
Toujours dans l'inspection d'URL > "Tester l'URL en direct" > "Voir la page testée" > onglet "Plus d'infos" > "Ressources de la page". Liste toutes les ressources (CSS, JS, images) bloquées par robots.txt. Si des CSS ou JS apparaissent ici, le rendu mobile est dégradé : à corriger en priorité.
- 03
Tester avec un parser tiers
Pour valider la syntaxe globale du fichier, utiliser des outils comme TechnicalSEO Robots.txt Tester ou Screaming Frog en mode "List > robots.txt". Permet de tester en batch des dizaines d'URLs contre un robots.txt en draft avant déploiement.
Les 6 erreurs courantes.
Six pièges qui sabotent l'indexation ou le rendu mobile. À auditer systématiquement sur tout robots.txt avant déploiement.
01 Bloquer CSS, JS ou images
Disallow sur /wp-content/, /themes/, /assets/ ou /*.css$. Empêche Googlebot de rendre la page correctement, casse l'indexation mobile-first. Vérifier via GSC > Inspection URL > "Voir la page testée".
02 Croire que Disallow désindexe une page
Disallow empêche le crawl, pas l'indexation. Une page bloquée mais linkée externalement reste dans Google avec un titre vide. Pour désindexer : laisser le crawl ouvert, ajouter <meta name="robots" content="noindex"> dans le HTML.
03 Oublier la directive Sitemap
Sans Sitemap: https://exemple.com/sitemap.xml, les moteurs de recherche autres que Google et Bing (Yandex, DuckDuckGo, Brave) découvrent les URLs plus lentement. Toujours déclarer le sitemap en URL absolue.
04 Casse incorrecte sur les chemins
Disallow: /Admin/ ne bloque PAS /admin/. Les chemins sont sensibles à la casse côté Linux. Toujours respecter la casse exacte des URLs réelles. Erreur fréquente sur les sites migrés depuis Windows.
05 Fichier mal placé
Le robots.txt doit être à la racine exacte du domaine : https://exemple.com/robots.txt. Pas dans /seo/robots.txt ou /blog/robots.txt. Chaque sous-domaine a son propre robots.txt : blog.exemple.com/robots.txt est distinct de exemple.com/robots.txt.
06 Conflits multi-User-agent mal compris
Googlebot lit uniquement le bloc le plus spécifique qui le concerne, pas l'addition. Si un bloc User-agent: Googlebot existe, le bloc User-agent: * est ignoré pour Googlebot. Toujours dupliquer les règles communes dans chaque bloc dédié.
Questions fréquentes.
Robots.txt vs noindex : lequel utiliser ?
Deux outils, deux usages. Robots.txt (Disallow) : empêche Googlebot de crawler une URL, économise du crawl budget, mais ne désindexe pas. La page peut quand même apparaître dans Google si elle est linkée de l'extérieur (avec un titre vide ou générique). Meta noindex : autorise le crawl, mais interdit l'indexation. C'est le seul moyen fiable d'empêcher une page d'apparaître dans les résultats. Règle simple : pour cacher du contenu de Google, utiliser noindex. Pour économiser du crawl sur des sections inutiles (filtres, panier, recherche interne), utiliser Disallow.
Une page bloquée par robots.txt peut-elle apparaître dans Google ?
Oui. C'est la confusion la plus fréquente. Si une page bloquée par Disallow reçoit un backlink externe ou interne, Google peut quand même l'indexer, sans titre ni snippet (juste son URL). Le résultat affichera "Aucune information n'est disponible pour cette page". Pour empêcher totalement l'apparition dans Google, retirer le Disallow, laisser Googlebot crawler, et ajouter <meta name="robots" content="noindex"> dans le HTML. Sinon Google ne pourra jamais lire le noindex puisqu'il ne peut pas crawler la page.
Google respecte-t-il vraiment robots.txt ?
Oui pour les directives Disallow concernant le crawl : Googlebot ne récupère pas les URLs bloquées. Mais robots.txt est une convention, pas une sécurité : un bot malveillant peut l'ignorer. Pour protéger des données sensibles, utiliser une authentification serveur (HTTP Basic Auth, login). Le robots.txt n'est pas non plus une garantie de désindexation : Google peut afficher l'URL dans les résultats même bloquée (cf. question précédente). Documentation officielle : developers.google.com.
Faut-il un robots.txt même si tout le site est public ?
Oui, c'est recommandé même pour un site 100 % public. Trois raisons. (1) Sans robots.txt, chaque requête sur /robots.txt renvoie un 404, ce qui pollue les logs serveur. (2) C'est l'endroit standard pour déclarer le sitemap (Sitemap: https://exemple.com/sitemap.xml), facilite la découverte par Google, Bing et autres. (3) Permet d'exclure rapidement les sections inutiles (panier, recherche interne, comptes utilisateurs) si elles apparaissent. Un robots.txt minimal acceptable : User-agent: * + Allow: / + Sitemap: ....
Comment bloquer un répertoire entier ?
Avec Disallow: /chemin/. Le slash final est important : Disallow: /admin/ bloque tout ce qui est sous /admin/ (admin/login, admin/users, etc.). Sans slash final, Disallow: /admin bloque aussi les URLs qui commencent par "admin" (admin-panel, administration). Pour autoriser une exception dans un dossier bloqué, ajouter Allow: ensuite : par exemple Disallow: /private/ + Allow: /private/public-doc.pdf. La règle Allow la plus spécifique l'emporte sur le Disallow plus général.
Robots.txt est-il sensible à la casse ?
Oui pour les chemins, non pour les directives. Les directives (User-agent, Disallow, Allow, Sitemap) sont insensibles à la casse : disallow ou DISALLOW fonctionnent. Les chemins sont sensibles : Disallow: /Admin/ ne bloque PAS /admin/. Erreur classique sur les sites migrés depuis Windows IIS vers Linux où la casse devient stricte. Toujours respecter la casse exacte des URLs réelles. Vérifier avec une URL test dans GSC > Inspection URL si le blocage prend effet.
Faut-il mettre le sitemap dans robots.txt ?
Oui, fortement recommandé. Ajouter une ligne Sitemap: https://exemple.com/sitemap.xml (URL absolue, pas relative). Avantages : facilite la découverte automatique du sitemap par Google, Bing, Yandex et autres moteurs sans devoir le soumettre manuellement à chaque outil. Plusieurs sitemaps possibles : ajouter une ligne Sitemap: par fichier, ou utiliser un sitemap index. La directive Sitemap est indépendante des blocs User-agent : à placer en début ou fin de fichier, peu importe.
Comment empêcher l'indexation d'une page déjà indexée ?
Procédure en 3 étapes. (1) Ne PAS bloquer la page dans robots.txt : Google doit pouvoir la recrawler pour voir la nouvelle directive. (2) Ajouter <meta name="robots" content="noindex"> dans le <head> de la page (ou un header HTTP X-Robots-Tag: noindex). (3) Pour accélérer, utiliser GSC > Suppressions > Nouvelle demande pour cacher temporairement (6 mois). La désindexation définitive prend de quelques jours à quelques semaines selon la fréquence de crawl. Une fois désindexée, le Disallow peut être réajouté pour économiser du crawl.
// passer à l'action
Diagnostiquer une URL bloquée.
Vérifier en 10 secondes si une URL est bloquée par robots.txt, par noindex, par canonical ou par tout autre signal d'indexabilité.