Choisissez le contrôle qui correspond à l’objectif
Le crawling est la récupération automatisée d’une URL. L’indexation est la décision d’un moteur de recherche de stocker et d’afficher des informations la concernant. Le contrôle d’accès décide qui peut obtenir du contenu. Robots.txt concerne le crawling, et les crawlers conformes décident de le suivre ou non. Le protocole d’exclusion des robots de l’IETF indique qu’il ne s’agit pas d’une autorisation.
Utilisez une règle Disallow pour gérer l’accès des crawlers à un chemin public de faible valeur, comme une route de recherche interne contrôlée. Utilisez noindex pour du contenu public qui ne doit pas apparaître dans les résultats pris en charge. Utilisez de véritables contrôles d’accès pour les aperçus, les zones nécessitant une connexion, les exports ou les données sensibles. Pour les informations clients, employés, paiement ou réglementées, obtenez une revue qualifiée de sécurité et de plateforme ; robots.txt n’est jamais un contrôle compensatoire.
Robots.txt peut demander aux crawlers conformes d’éviter un chemin public défini ; il ne garantit pas la suppression des résultats.
Utilisez noindex dans le HTML ou un en-tête HTTP X-Robots-Tag, et laissez la réponse crawlable pour que l’instruction puisse être lue.
Exigez une authentification ou un contrôle applicatif/serveur approprié, puis retirez l’URL des chemins de découverte publics.
Utilisez la syntaxe et la portée de base avec précision
Publiez un robots.txt texte brut UTF-8 à /robots.txt pour chaque scheme, hôte et port qui nécessite des règles. Un fichier à https://www.example.com/robots.txt ne gouverne pas automatiquement https://example.com, un sous-domaine ou une origine HTTP. Vérifiez les origines servies par les URL canoniques, les redirections, le CDN et l’application avant de supposer qu’une règle s’applique.
Un groupe commence par User-agent puis utilise Allow ou Disallow pour des chemins. User-agent: * est le groupe général. La correspondance est sensible à la casse et débute au début du chemin. La règle la plus spécifique gagne ; un Allow d’égale spécificité devrait l’emporter sur un Disallow. Disallow: ne bloque rien, tandis que Disallow: / bloque toute l’origine. La norme définit # pour les commentaires, * pour le joker, et $ pour la fin d’un motif.
S’il n’existe pas de besoin documenté de gestion du crawl, n’ajoutez aucune exclusion ; n’introduisez pas de blocages spéculatifs.
Privilégiez un préfixe stable et étroit comme /search/ plutôt qu’un joker lâche ou une règle de nom de fichier non expliquée.
Notez l’objet de la règle, le propriétaire et la référence de changement, mais ne traitez pas les commentaires comme un substitut à une revue formelle.
Bloquez uniquement des motifs soutenus par des preuves d’URL
Avant d’écrire une règle, dressez l’inventaire des pages importantes, des chemins de crawl indésirables, des variantes de requête, de la recherche interne, des routes d’aperçu, des assets et des URL de sitemap. Pour chaque URL d’exemple, enregistrez le résultat attendu et la règle correspondante. Comparez la liste avec les URL canoniques et la navigation en direct afin qu’un blocage ne masque pas une route utile.
Conservez accessibles les ressources critiques pour le rendu dans le navigateur à moins d’un test contraire. Google met en garde contre le blocage de CSS, JavaScript, images ou autres ressources qui peut rendre une page plus difficile à analyser. Robots.txt ne résout pas la sélection de contenu dupliqué, l’autorisation ou la qualité d’une page ; utilisez la canonicalisation, les redirections, les contrôles d’accès ou le travail de contenu là où c’est approprié.
Utilisez des échantillons d’URL réels et des preuves serveur ou de crawl, pas une liste générique copiée d’un autre site.
Conservez pour chaque URL d’exemple le résultat attendu, la règle correspondante et le propriétaire responsable dans le dossier de lancement.
Alignez sitemap, noindex et décisions de confidentialité
Un sitemap indique aux moteurs quelles URL et quels fichiers vous jugez importants ; il peut aider à la découverte mais ne garantit ni le crawl ni l’indexation. Des liens internes forts restent déterminants. Vous pouvez ajouter une URL Sitemap entièrement qualifiée dans robots.txt, mais ne listez pas d’URL privées, redirigées, bloquées par robots ou volontairement noindexées. Réconciliez la sortie du sitemap avec les règles robots lors du déploiement.
Noindex n’est pas une directive de robots.txt spécifique à Google. Google la prend en charge via une balise meta dans le HTML ou un en-tête HTTP X-Robots-Tag, et doit crawler la réponse pour la voir. Si une page publique doit être retirée des résultats Google, supprimez tout bloc robots qui masque le noindex. Si le contenu est non public, n’annoncez pas son chemin dans robots.txt ; appliquez un contrôle d’accès. Les frontières liées aux données sensibles nécessitent une revue qualifiée.
Utilisez une URL complète, par exemple Sitemap: https://www.example.com/sitemap.xml ; cela n’annule pas un blocage de crawl.
Utilisez meta noindex pour le HTML ou un en-tête X-Robots-Tag: noindex lorsque c’est approprié, puis testez la réponse en production.
Restreignez d’abord l’accès lorsque le contenu est sensible, puis utilisez le processus de suppression du moteur de recherche si nécessaire.
Testez et publiez-le comme un fichier de configuration critique
Validez le texte approuvé localement, puis testez des exemples autorisés et interdits pour le groupe de crawlers visé. Après déploiement, récupérez le /robots.txt public en privé ou par requête HTTP directe pour confirmer le contenu, l’origine et le statut de la réponse. Google propose un rapport robots.txt dans Search Console pour les fichiers accessibles et une bibliothèque d’analyse open-source pour les tests locaux.
Les crawlers peuvent mettre en cache les fichiers robots, donc ne comptez pas sur une découverte ou des changements d’indexation immédiats. Les erreurs serveur ou réseau amènent les crawlers à supposer un disallow complet, tandis qu’un 4xx peut permettre l’accès. Conservez le fichier dans la configuration contrôlée par le code, exigez une revue renforcée pour les blocs sur tout le site ou les jokers, et conservez la version précédente. Les préflights SIU et la planification du rollback aident à détecter un mauvais déploiement avant qu’il ne devienne un problème d’accessibilité ou de découvrabilité plus large.
Exigez un deuxième relecteur pour les migrations d’origine, les blocages « tout le site », les jokers et les changements affectant l’authentification, le paiement ou les routes de support.
Restaurez la version antérieure lorsqu’une URL d’échantillon importante est nouvellement bloquée, qu’un asset nécessaire est inaccessible ou que le point de terminaison est indisponible.
Un seul test de crawler ne prouve pas que chaque client automatisé interprète chaque règle de la même façon.