Comment configurer correctement son fichier robots txt ?

# Comment configurer correctement son fichier robots.txt ?

Le fichier robots.txt représente l’un des éléments techniques les plus stratégiques pour le référencement naturel d’un site web, et pourtant, il reste souvent mal compris ou négligé par de nombreux professionnels du marketing digital. Ce simple fichier texte, placé à la racine de votre domaine, agit comme un gardien qui contrôle l’accès des robots d’exploration aux différentes sections de votre site. Une configuration inadéquate peut avoir des conséquences désastreuses : pages stratégiques bloquées, gaspillage du budget de crawl, ou encore indexation de contenus non pertinents qui diluent la qualité globale de votre présence dans les moteurs de recherche. Selon les données récentes de l’industrie SEO, environ 26% des sites web présentent des erreurs critiques dans leur fichier robots.txt, erreurs qui impactent directement leur visibilité organique. Maîtriser la configuration de ce fichier devient donc un avantage concurrentiel décisif dans un environnement digital où chaque détail technique compte pour se démarquer dans les résultats de recherche.

Anatomie et syntaxe du fichier robots.txt selon le protocole REP

Le protocole d’exclusion des robots (Robots Exclusion Protocol ou REP) constitue le cadre normatif qui régit le fonctionnement du fichier robots.txt depuis sa création en 1994. Ce standard, bien qu’informel à l’origine, est aujourd’hui largement adopté par tous les moteurs de recherche majeurs et définit les règles syntaxiques que vous devez respecter pour communiquer efficacement avec les crawlers. La structure de base repose sur un système de directives simples mais puissantes qui permettent de spécifier quels agents utilisateurs peuvent accéder à quelles ressources. Chaque directive doit être placée sur une ligne distincte, et le fichier doit impérativement être sauvegardé en encodage UTF-8 pour garantir une interprétation correcte des caractères spéciaux. L’ordre des directives a une importance capitale : les règles les plus spécifiques doivent toujours précéder les règles générales pour que les moteurs de recherche appliquent la logique de correspondance appropriée.

Structure des directives user-agent et leurs agents crawlers spécifiques

La directive User-agent représente le point d’entrée de toute configuration robots.txt et identifie le robot d’exploration auquel s’appliquent les règles suivantes. L’utilisation de l’astérisque (User-agent: *) cible tous les robots indistinctement, mais vous pouvez également définir des règles spécifiques pour des crawlers particuliers comme Googlebot, Bingbot, Googlebot-Image, ou encore GPTBot pour contrôler l’accès des intelligences artificielles génératives. Chaque bloc User-agent fonctionne de manière indépendante : si un robot correspond à plusieurs blocs, il appliquera uniquement le bloc le plus spécifique qui le concerne. Par exemple, si vous définissez des règles pour Googlebot et des règles pour User-agent: *, Google utilisera exclusivement les directives du bloc Googlebot et ignorera le bloc générique. Cette granularité permet d’adopter des stratégies différenciées selon les moteurs de recherche et leurs capacités de traitement.

Syntaxe des commandes disallow, allow et leurs patterns de correspondance

Les directives Disallow et Allow constituent le cœur opérationnel du fichier robots.txt en définissant respectivement les chemins interdits et autorisés pour l’exploration. La syntaxe Disallow: /chemin

indique au robot que tout chemin commençant par /chemin ne doit pas être exploré. À l’inverse, Allow sert à réautoriser des ressources précises à l’intérieur d’un répertoire globalement bloqué. Par exemple :

User-agent: *Disallow: /wp-admin/Allow: /wp-admin/admin-ajax.php

Dans cet exemple, tout le répertoire /wp-admin/ est interdit au crawl, à l’exception du fichier admin-ajax.php dont WordPress a besoin pour fonctionner correctement. Lorsque plusieurs règles s’appliquent à une même URL, les moteurs comme Google privilégient en général la directive dont le chemin est le plus long (la plus spécifique). C’est pourquoi vous devez toujours réfléchir en termes de hiérarchie de chemins pour éviter les comportements inattendus.

Implémentation de la directive sitemap dans robots.txt

La directive Sitemap n’appartient pas formellement au protocole REP d’origine, mais elle est aujourd’hui largement supportée par Google, Bing et la plupart des moteurs. Elle permet d’indiquer l’emplacement de votre ou vos fichiers de sitemap XML directement depuis le fichier robots.txt. Cette simple ligne améliore la découverte de vos URL, en particulier sur les sites volumineux ou avec une architecture complexe.

La syntaxe est très simple :

Sitemap: https://www.monsite.com/sitemap.xml

Vous pouvez déclarer plusieurs sitemaps ou un index de sitemaps :

Sitemap: https://www.monsite.com/sitemap-index.xmlSitemap: https://www.monsite.com/sitemap-images.xml

Veillez à toujours utiliser des URL absolues en HTTPS et à ne référencer que des sitemaps valides (codes HTTP 200, sans URL en noindex ni 404). Cette bonne pratique permet aux robots de prioriser plus efficacement l’exploration de vos pages importantes, tout en limitant le gaspillage de crawl sur des contenus secondaires.

Utilisation des wildcards astérisque et dollar pour le pattern matching

Pour affiner la configuration de votre fichier robots.txt, vous pouvez recourir aux caractères génériques (wildcards) * et $, largement interprétés par Google et Bing. L’astérisque * représente une suite de caractères quelconque, tandis que le signe dollar $ indique la fin de l’URL. Combinés, ils offrent un puissant mécanisme de « pattern matching » pour cibler des groupes d’URL partageant une même structure.

Voici quelques exemples concrets :

# Bloquer toutes les URL contenant un paramètre de rechercheDisallow: /*?s=# Bloquer toutes les URLs se terminant par .pdfDisallow: /*.pdf$# Autoriser toutes les feuilles de style CSSAllow: /*.css$

Attention toutefois : tous les crawlers n’interprètent pas ces motifs de la même façon, et certains robots mineurs peuvent ne pas les comprendre du tout. Utilisez ces patterns principalement pour les moteurs majeurs (Google, Bing) et testez systématiquement vos règles à l’aide d’outils spécialisés pour éviter de bloquer par erreur des sections importantes de votre site.

Gestion du crawl-delay et ses implications pour googlebot et bingbot

La directive Crawl-delay permet de spécifier un délai, en secondes, entre deux requêtes consécutives d’un robot sur votre serveur. Elle a historiquement été utilisée pour limiter la charge générée par certains crawlers, notamment sur des infrastructures fragiles ou des sites à fort trafic. Sa forme typique ressemble à :

User-agent: BingbotCrawl-delay: 5

Concrètement, cela signifie que Bingbot devra attendre 5 secondes entre deux requêtes. Cependant, Googlebot n’interprète pas la directive Crawl-delay dans le fichier robots.txt : Google gère automatiquement la fréquence de crawl en fonction de la capacité de votre serveur et de la demande de vos pages. Pour Google, si vous souhaitez ajuster la vitesse d’exploration, vous devez passer par la Search Console (paramètre de limitation de la fréquence de crawl) plutôt que par une directive robots.txt.

En pratique, la directive Crawl-delay reste donc surtout utile pour certains crawlers tiers ou pour Bingbot, et encore, avec parcimonie. Un délai trop élevé peut ralentir fortement la découverte de vos nouveaux contenus. Là encore, posez-vous la question : vaut-il mieux ralentir les robots, ou optimiser votre serveur (cache, CDN, optimisation des requêtes) pour supporter un crawl plus soutenu ?

Placement et accessibilité du fichier robots.txt dans l’architecture serveur

Un fichier robots.txt parfaitement rédigé ne sert à rien s’il n’est pas accessible là où les robots s’attendent à le trouver. Les moteurs de recherche appliquent des règles strictes pour localiser ce fichier, et la moindre erreur de placement peut être interprétée comme une absence pure et simple de directives. C’est pourquoi la configuration serveur et l’accessibilité HTTP de /robots.txt sont des aspects fondamentaux de votre SEO technique.

Configuration de l’emplacement racine et protocole HTTPS

Le fichier robots.txt doit impérativement être placé à la racine du domaine, et non dans un sous-répertoire. L’URL d’accès doit donc suivre le format :

https://www.votresite.com/robots.txt

Si vous travaillez avec plusieurs sous-domaines (par exemple blog.monsite.com ou shop.monsite.com), chacun doit disposer de son propre fichier robots.txt accessible à la racine de ce sous-domaine. Les robots ne « remontent » pas le répertoire pour aller chercher un fichier robots.txt commun à tous les sous-domaines.

Dans un contexte HTTPS first, assurez-vous également que la version HTTP redirige systématiquement vers la version HTTPS en 301, y compris pour /robots.txt. Un robot qui tente d’accéder à http://votresite.com/robots.txt doit être redirigé proprement vers https://votresite.com/robots.txt, sans boucle de redirection ni erreur 4xx. Une mauvaise configuration à ce niveau peut entraîner l’ignorance totale de vos directives, avec tous les risques que cela comporte.

Paramétrage des codes de statut HTTP 200 et gestion des erreurs 404

Pour que vos directives soient prises en compte, votre fichier robots.txt doit renvoyer un code de statut HTTP 200. Un code 404 signifie pour le robot que le fichier n’existe pas, et qu’aucune restriction n’est imposée. Un code 500, quant à lui, peut être interprété comme un problème serveur temporaire, poussant certains crawlers à revenir plus tard sans nécessairement respecter votre configuration.

Il est donc essentiel de vérifier :

• Que /robots.txt renvoie bien un statut 200 et le contenu attendu ;
• Que toute URL alternative (ex. : /robots, /robots.php) ne remplace pas abusivement le fichier texte ;
• Que vos règles de réécriture (.htaccess, Nginx) ne perturbent pas l’accès direct au fichier.

En cas d’absence volontaire de fichier robots.txt, laissez simplement le serveur renvoyer un 404 propre sur cette URL. Évitez les redirections vers la page d’accueil ou d’autres contenus, qui compliquent inutilement l’interprétation par les moteurs de recherche.

Encodage UTF-8 et format de fichier texte brut obligatoire

Le fichier robots.txt doit être un fichier texte brut (plain text), sans balises HTML, sans BOM exotique et sans compression non standard côté serveur. L’encodage recommandé est l’UTF-8 sans BOM, ce qui garantit une interprétation correcte de tous les caractères, y compris les accents présents dans certains chemins d’URL.

Évitez d’éditer votre robots.txt avec des traitements de texte comme Word ou Google Docs, qui peuvent insérer des caractères invisibles ou enregistrer le fichier dans un format propriétaire. Utilisez plutôt un éditeur de code (VS Code, Sublime Text, Notepad++, etc.) et vérifiez que le fichier ne contient pas de lignes vides superflues ou de caractères non imprimables.

Enfin, assurez-vous que le type MIME renvoyé par le serveur est cohérent : text/plain; charset=utf-8 est idéal. Certains environnements mal configurés renvoient text/html pour tous les fichiers, ce qui peut troubler certains robots stricts, même si les principaux moteurs restent relativement tolérants.

Stratégies de blocage pour optimiser le crawl budget SEO

Le véritable enjeu d’un fichier robots.txt bien configuré n’est pas de « cacher » des pages, mais d’optimiser le budget de crawl dont dispose votre site. En orientant les robots vers les contenus stratégiques et en limitant l’exploration des zones peu utiles, vous améliorez l’indexation des pages qui comptent vraiment pour votre référencement naturel. Autrement dit, vous apprenez à Google à ne pas se perdre dans les couloirs techniques de votre site pour se concentrer sur vos « pièces à vivre » SEO.

Exclusion des paramètres d’URL dynamiques et facettes de filtrage

Les paramètres d’URL (query strings) sont l’une des principales sources de gaspillage de budget de crawl. Pages de filtres, tri, pagination, tags multiples : un site e-commerce peut générer des milliers de combinaisons d’URL pour un même ensemble de produits. Laisser les robots explorer ces variantes sans contrôle revient à les enfermer dans un labyrinthe sans fin.

Une approche classique consiste à bloquer les paramètres de filtrage les plus problématiques via des patterns :

User-agent: *Disallow: /*?tri=Disallow: /*&couleur=Disallow: /*?categorie=*&filtre=*&page=*

Cette stratégie doit cependant être maniée avec prudence. Avant de bloquer une famille d’URL, posez-vous deux questions : ces pages apportent-elles une valeur SEO réelle (trafic, conversions, intentions longues traînes) ? Et existe-t-il une alternative mieux structurée (catégories principales, pages de landing dédiées) pour capter cette demande ? Dans bien des cas, il est plus judicieux de travailler les balises canoniques et la structure interne plutôt que de tout bloquer brutalement dans le robots.txt.

Blocage des répertoires système wp-admin et fichiers temporaires

Sur WordPress et de nombreux CMS, certains répertoires techniques n’ont aucun intérêt à être explorés par les robots, voire peuvent exposer des chemins sensibles côté serveur. Il est donc courant de bloquer par défaut des répertoires comme :

User-agent: *Disallow: /wp-admin/Disallow: /wp-includes/Disallow: /cgi-bin/Disallow: /tmp/Disallow: /cache/

De même, certains fichiers techniques ou temporaires peuvent être exclus pour éviter le bruit dans les rapports d’exploration : fichiers de log, scripts, exports, etc. Vous pouvez par exemple bloquer les fichiers de sauvegarde avec une règle de suffixe :

Disallow: /*.bak$Disallow: /*.old$

Attention toutefois à ne pas bloquer des chemins utilisés pour servir des ressources front importantes (images, JS, CSS) sous prétexte qu’ils se trouvent dans /wp-content/ ou un répertoire similaire. Lorsque vous avez un doute, vérifiez toujours dans l’inspecteur de votre navigateur quelles ressources sont appelées pour afficher vos pages clés.

Désindexation des pages de résultats de recherche interne

Les pages de résultats de recherche interne (/search, ?s=, etc.) constituent un cas particulier : elles génèrent souvent du contenu dupliqué, peu stable, et de qualité variable. Laisser Google explorer et indexer massivement ces pages peut diluer votre pertinence globale et créer de nombreux « soft 404 » dans vos rapports Search Console. La bonne pratique consiste donc à en limiter l’exploration via robots.txt.

Un exemple de configuration courante sur WordPress serait :

User-agent: *Disallow: /?s=Disallow: /*&s=Disallow: /search/

Gardez cependant en tête la différence fondamentale entre blocage du crawl et désindexation. Si ces pages sont déjà indexées et que vous souhaitez les faire disparaître de Google, il faudra leur ajouter une balise noindex (ou un header X-Robots-Tag) le temps que Google les recrawl, avant éventuellement de les bloquer définitivement dans le fichier robots.txt.

Gestion des ressources JavaScript et CSS pour le rendering google

Depuis plusieurs années, Google met l’accent sur le rendering complet des pages, incluant l’exécution de JavaScript et le chargement des feuilles de style CSS. Bloquer ces ressources dans votre robots.txt peut empêcher Googlebot de voir le rendu réel de vos pages, notamment sur mobile, et conduire à des évaluations erronées de l’ergonomie ou du contenu. Résultat : des signaux Core Web Vitals dégradés, une mauvaise compréhension de la structure et parfois même des pénalités algorithmiques.

La règle générale aujourd’hui est donc simple : ne bloquez pas vos fichiers JS, CSS et d’images essentiels. Si vous avez déjà des directives restrictives du type :

Disallow: /wp-content/

pensez à y adjoindre des exceptions explicites :

Allow: /wp-content/uploads/Allow: /*.css$Allow: /*.js$

Une bonne analogie : empêcher Google de lire vos CSS et JS, c’est comme lui demander de juger un magasin avec la lumière éteinte et les rayons emballés. Il peut se faire une idée approximative, mais il lui manquera des informations clés pour évaluer l’expérience réelle de vos utilisateurs.

Configuration multi-agents pour googlebot, bingbot et crawlers spécialisés

Sur certains sites, une stratégie « one size fits all » ne suffit pas. Vous pouvez avoir intérêt à adapter vos directives robots.txt en fonction des capacités et des objectifs de chaque crawler. Googlebot, par exemple, dispose d’une excellente gestion du JavaScript et d’un budget de crawl souvent généreux sur les sites établis. D’autres crawlers, en revanche, peuvent être plus limités ou plus agressifs.

Une configuration multi-agents typique peut ressembler à :

# Règles par défaut pour tous les robotsUser-agent: *Disallow: /wp-admin/Allow: /wp-admin/admin-ajax.phpDisallow: /search/Sitemap: https://www.monsite.com/sitemap.xml# Règles spécifiques pour GooglebotUser-agent: GooglebotDisallow: /panier/Disallow: /mon-compte/# Règles spécifiques pour Googlebot-ImageUser-agent: Googlebot-ImageAllow: /wp-content/uploads/# Règles pour les bots d'IA générativeUser-agent: GPTBotAllow: /User-agent: ChatGPT-UserAllow: /

Dans ce scénario, vous autorisez par exemple les crawlers d’IA à accéder librement à vos contenus publics pour maximiser votre visibilité dans les réponses génératives, tout en limitant certains répertoires aux robots classiques. L’important est de bien documenter vos choix et de surveiller l’impact de ces configurations dans vos logs serveur : qui visite quoi, à quelle fréquence, et avec quelles conséquences sur la charge serveur et le trafic SEO ?

Validation et test du fichier robots.txt avec google search console

Une fois votre fichier robots.txt en place, la tentation est grande de considérer le travail comme terminé. Pourtant, la phase de validation est tout aussi cruciale que la phase de rédaction. Sans tests rigoureux, vous risquez de passer à côté d’un blocage involontaire de Googlebot ou d’une incompatibilité de syntaxe qui rendrait vos directives inopérantes.

Utilisation de l’outil de test robots.txt dans GSC

Historiquement, Google proposait un « tester de robots.txt » dédié dans la Search Console, aujourd’hui remplacé par un rapport de diagnostic intégré. Même si l’outil interactif n’existe plus sous sa forme initiale, vous pouvez toujours vérifier la bonne prise en compte de votre fichier via la Search Console et des outils tiers. L’objectif : s’assurer que Google lit bien le contenu actuel et qu’aucune erreur de syntaxe majeure n’est détectée.

La démarche recommandée :

1. Vérifier dans la section Paramètres > Fichier robots.txt (ou équivalent) que Google a bien accédé à votre fichier, avec la date de dernier crawl ;
2. Utiliser l’outil « Inspection d’URL » pour tester des pages représentatives (pages autorisées, pages censément bloquées) et vérifier le message « Autorisé ou bloqué par robots.txt » ;
3. Comparer le contenu servit par votre serveur avec ce que Google indique avoir récupéré, afin de détecter d’éventuels problèmes de cache.

En complément, des outils externes comme Robots.txt Validator and Testing Tool ou Robots.txt Checker permettent de simuler différents user-agents et de vérifier en quelques secondes quelles URL sont effectivement bloquées ou autorisées.

Analyse des rapports de couverture et erreurs d’exploration

Au-delà du test syntaxique, la Search Console fournit des informations précieuses sur l’impact réel de votre fichier robots.txt via les rapports de Couverture de l’index et les messages d’erreur d’exploration. Vous y verrez notamment la catégorie « Indexée malgré le blocage par robots.txt » qui signale des URL découvertes via des liens externes mais dont le contenu n’a pas pu être exploré.

Ce type de cas illustre parfaitement la limite du robots.txt : une URL peut être indexée sans être crawlée. Si ces pages ne doivent vraiment pas apparaître dans les résultats de recherche, la solution n’est pas de les bloquer dans le fichier robots.txt, mais de les protéger par mot de passe ou de leur appliquer une directive noindex (sans les bloquer au crawl). Le rapport de couverture vous sert donc de garde-fou pour identifier les incohérences entre vos intentions et la réalité de l’indexation.

Surveillez également les catégories du type « Bloquée par le fichier robots.txt » pour des URL a priori stratégiques (pages de catégorie, fiches produits, contenus éditoriaux). Si vous en trouvez, c’est le signe que certaines de vos règles sont trop agressives et doivent être assouplies ou mieux ciblées.

Vérification avec bing webmaster tools et screaming frog SEO spider

Google n’est pas le seul moteur à prendre en compte votre fichier robots.txt. Pour une vision complète, il est pertinent de tester également votre configuration avec Bing Webmaster Tools, qui propose ses propres rapports d’exploration et de blocages. Bing interprète globalement les directives de la même façon que Google, mais peut se montrer plus sensible à certaines syntaxes, notamment autour de Crawl-delay.

Pour une analyse plus fine côté SEO, l’outil Screaming Frog SEO Spider est particulièrement utile. En configurant le user-agent voulu (Googlebot, Bingbot ou un agent personnalisé), vous pouvez simuler un crawl complet de votre site et visualiser :

• Les URL bloquées par le robots.txt selon chaque user-agent ;
• Les ressources (CSS, JS, images) potentiellement inaccessibles ;
• L’impact de vos directives sur la profondeur d’exploration.

En combinant ces différents outils, vous réduisez drastiquement le risque de laisser une erreur de configuration robots.txt impacter votre visibilité organique pendant des semaines sans vous en rendre compte.

Erreurs critiques à éviter dans la configuration robots.txt

Comme souvent en SEO technique, les dégâts les plus spectaculaires viennent de quelques erreurs simples mais lourdes de conséquences. Un slash mal placé, une directive trop large ou une mauvaise compréhension du rôle du robots.txt peuvent suffire à faire disparaître en quelques jours des centaines de pages stratégiques de l’index de Google. Passons en revue les pièges les plus fréquents afin que vous puissiez les éviter sur votre propre site.

Blocage accidentel de Googlebot-Image et Googlebot-Mobile

Dans un souci de « nettoyage » ou de sécurité, certains administrateurs bloquent par défaut de larges répertoires de ressources, voire des familles complètes de robots. Or, empêcher Googlebot-Image ou Googlebot-Mobile d’accéder à vos contenus peut avoir un impact direct sur votre visibilité dans Google Images et sur l’indexation mobile-first.

Par exemple, une règle globale comme :

User-agent: Googlebot-ImageDisallow: /User-agent: *Disallow: /wp-content/

empêchera Google d’accéder à vos images hébergées dans /wp-content/uploads/, même si ces images sont clés pour votre trafic (fiches produits, infographies, visuels de blog). De la même manière, bloquer un répertoire contenant vos CSS ou JS critiques nuit au rendu mobile, ce qui peut entraîner une dégradation du classement sur smartphone.

La bonne pratique : par défaut, laissez Googlebot-Image et Googlebot-Mobile accéder à toutes les ressources publiques nécessaires au rendu complet de vos pages. N’envisagez un blocage ciblé que si vous avez un cas d’usage très spécifique, et testez systématiquement l’impact via les outils d’inspection d’URL de la Search Console.

Confusion entre robots.txt et meta robots noindex

Une confusion tenace consiste à croire que le fichier robots.txt empêche l’indexation des pages. En réalité, il empêche l’exploration, pas nécessairement l’indexation. Si une URL bloquée par robots.txt est largement citée par d’autres sites, elle peut tout à fait apparaître dans les résultats de recherche, avec un simple titre d’URL et sans snippet de contenu.

À l’inverse, la balise <meta name="robots" content="noindex"> ou l’en-tête X-Robots-Tag: noindex indiquent explicitement à Google de ne pas indexer une page, même si elle est crawlable. Mais si vous combinez les deux approches (blocage robots.txt + noindex dans le code HTML), Google ne pourra pas voir la balise noindex puisque le crawl est interdit. Résultat : la page risque de rester indexée malgré vos efforts.

Règle d’or : utilisez le fichier robots.txt pour gérer le crawl, et les balises noindex pour gérer l’indexation. Ne mélangez pas les deux sur les mêmes URL.

En cas de doute, commencez toujours par appliquer le noindex tout en laissant la page accessible au crawl. Une fois que vous aurez constaté sa disparition effective de l’index (via la Search Console), vous pourrez éventuellement ajouter un blocage robots.txt si vous souhaitez également limiter le crawl pour des raisons de budget ou de confidentialité technique.

Surcharge de directives conflictuelles et ordre de priorité

À force de vouloir couvrir tous les cas, certains fichiers robots.txt deviennent de véritables catalogues de règles, parfois redondantes, souvent contradictoires. Plusieurs blocs User-agent pour un même robot, des Disallow généraux suivis d’Allow trop vagues, ou encore des patterns se chevauchant peuvent rendre le comportement des crawlers difficile à prédire.

Gardez en tête quelques principes simples :

• Un robot applique le bloc User-agent le plus spécifique qui le concerne (ex. : Googlebot prime sur *) ;
• Pour une même URL, la règle dont le chemin est le plus long (la plus spécifique) l’emporte en général ;
• Les directives sont lues de haut en bas, mais ce n’est pas strictement l’ordre qui compte, plutôt la spécificité du chemin.

Dans la pratique, mieux vaut un fichier robots.txt court, documenté et cohérent qu’une configuration tentaculaire où personne ne sait plus exactement pourquoi telle ou telle règle a été ajoutée. Lorsque vous modifiez des directives existantes, notez la date et la raison dans un commentaire (#) pour garder une trace. Et posez-vous toujours cette question : « Cette règle contribue-t-elle vraiment à mieux contrôler le crawl et l’indexation, ou ne fait-elle que complexifier mon fichier sans bénéfice SEO mesurable ? »