- Le fichier robots.txt contrôle quelles pages les moteurs de recherche peuvent explorer
- Une mauvaise configuration peut bloquer l’indexation de pages importantes
- Les directives User-agent, Disallow et Allow sont les trois commandes essentielles
- Vous pouvez tester votre fichier avec Google Search Console
- Un sitemap XML doit être déclaré dans le robots.txt
- Attention à ne jamais bloquer les fichiers CSS et JavaScript
Je vais vous expliquer comment optimiser votre fichier robots.txt. C’est un fichier texte simple, placé à la racine de votre site, qui dicte aux robots des moteurs de recherche ce qu’ils peuvent ou non explorer.
Franchement, je vois trop souvent des sites qui se tirent une balle dans le pied avec ce fichier.
Qu’est-ce que le fichier robots.txt exactement
Le robots.txt est un fichier de directives. Il se trouve toujours à l’adresse votresite.com/robots.txt — jamais ailleurs. Les crawlers comme Googlebot le consultent avant d’explorer votre site.
C’est un peu comme le règlement affiché à l’entrée d’un bâtiment.
Vous voyez le principe? Les robots lisent ces instructions et décident quelles pages visiter. Mais attention — et je ne vais pas mentir sur ce point — ce fichier n’empêche pas l’indexation à 100%. Un robot peut ignorer vos directives s’il trouve un lien externe vers votre page bloquée.
La syntaxe de base à maîtriser absolument
Je vais vous donner les trois directives fondamentales. Celles que j’utilise systématiquement.
User-agent: cette ligne désigne le robot concerné. Pour cibler tous les robots, j’écris User-agent: *. Pour Googlebot uniquement, j’écris User-agent: Googlebot.
Disallow: cette commande bloque l’accès à un répertoire ou une page. Par exemple, Disallow: /admin/ empêche l’exploration du dossier admin.
Allow: cette directive autorise l’accès à une ressource spécifique dans un répertoire bloqué. Très utile pour créer des exceptions.
Voici un exemple concret que j’ai mis en place pour un client:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /panier/
Disallow: /compte/
Sitemap: https://votresite.com/sitemap.xml
Simple, non?
Les erreurs catastrophiques que je vois régulièrement
Parlons franchement des bourdes. J’ai vu un site e-commerce bloquer toutes ses fiches produits par erreur (croyez-moi, ça change tout niveau chiffre d’affaires).
Bloquer les fichiers CSS et JavaScript: cette erreur était courante il y a quelques temps. Google a besoin de ces ressources pour comprendre votre page. Ne les bloquez jamais.
Utiliser Disallow pour empêcher l’indexation: le robots.txt ne garantit pas qu’une page ne sera pas indexée. Pour ça, utilisez la balise meta noindex dans le code HTML de la page.
Oublier la casse: Disallow: /Admin/ et Disallow: /admin/ sont deux choses différentes. Le fichier est sensible à la casse.
Bloquer tout le site accidentellement: j’ai vu ça. Un développeur avait laissé User-agent: * suivi de Disallow: / en production. Résultat? Aucune page explorée pendant trois semaines.
Ça vous parle?
Comment optimiser pour améliorer le crawl budget
Le crawl budget, c’est le nombre de pages que Google explore sur votre site dans un temps donné. Pour les petits sites, ce n’est pas critique. Mais pour les gros sites — disons au-delà de 10 000 pages — ça devient stratégique.
Voici ma méthode en quatre étapes.
Bloquez les pages inutiles: paniers, comptes utilisateurs, résultats de recherche interne, pages de remerciement. Ces pages consomment du crawl budget sans apporter de valeur SEO.
Bloquez les paramètres d’URL: si vous avez des filtres qui génèrent des URLs avec des paramètres (?couleur=rouge&taille=M), bloquez-les via le robots.txt ou gérez-les dans Search Console.
Déclarez votre sitemap XML: cette ligne est essentielle. Sitemap: https://votresite.com/sitemap.xml. Elle guide les robots vers vos pages importantes.
Évitez les chaînes de redirection: ce n’est pas directement lié au robots.txt, mais les redirections multiples gaspillent du crawl budget. Je le mentionne parce que l’optimisation du crawl est globale.
Bon, passons aux exemples pratiques.
Exemples de configuration selon votre type de site
Je vais vous montrer ce que j’utilise concrètement.
Pour un site WordPress classique
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/
Allow: /wp-content/uploads/
Disallow: /trackback/
Disallow: /feed/
Disallow: /comments/
Disallow: */feed/$
Disallow: */trackback/$
Sitemap: https://votresite.com/sitemap_index.xml
Cette configuration bloque les fichiers système tout en autorisant les médias. Du coup, vos images restent accessibles.
Pour un site e-commerce
User-agent: *
Disallow: /panier/
Disallow: /mon-compte/
Disallow: /commande/
Disallow: /checkout/
Disallow: /*?orderby=
Disallow: /*?filtre=
Disallow: /*add-to-cart=
Sitemap: https://votresite.com/sitemap-produits.xml
Sitemap: https://votresite.com/sitemap-categories.xml
Vous voyez comment je bloque les actions utilisateur et les URLs de tri? C’est crucial pour éviter le contenu dupliqué.
Pour un blog ou site média
User-agent: *
Disallow: /auteur/
Disallow: /tag/
Disallow: /*?s=
Allow: /$
Sitemap: https://votresite.com/sitemap.xml
Ici, je bloque les pages auteur et tags qui créent souvent du contenu fin (thin content). Pour moi, c’est une erreur de laisser ces pages se faire crawler si elles n’apportent rien.
Les directives avancées que peu de gens connaissent
Autant dire que ces commandes sont sous-utilisées. Pourtant, elles peuvent vraiment vous aider.
Crawl-delay: cette directive ralentit la vitesse de crawl. Crawl-delay: 10 impose une pause de 10 secondes entre chaque requête. Google ne la respecte pas, mais Bing et d’autres robots oui. Je l’utilise quand un serveur est fragile.
Noindex dans le robots.txt: officiellement, Google ne supporte plus cette directive depuis des lustres. N’utilisez jamais Noindex: dans ce fichier. Utilisez plutôt la balise HTML meta robots.
Les wildcards: l’astérisque (*) remplace n’importe quelle séquence de caractères. Disallow: /*.pdf$ bloque tous les fichiers PDF. Le dollar ($) indique la fin de l’URL.
Un client m’a contacté pour exactement ce problème — il voulait bloquer tous ses PDFs téléchargeables. Cette syntaxe a résolu son souci en une ligne.
Comment tester et valider votre fichier
Ne publiez jamais un robots.txt sans le tester. Jamais.
Google Search Console propose un outil de test intégré. Allez dans Paramètres > Outil de test du fichier robots.txt. Vous collez votre code, vous testez une URL, et l’outil vous dit si elle est bloquée ou autorisée.
J’utilise aussi des validateurs en ligne comme technicalseo.com/tools/robots-txt/. Ils détectent les erreurs de syntaxe.
Autre astuce: consultez régulièrement les rapports de couverture dans Search Console. Si des pages importantes sont marquées comme « Bloquées par le fichier robots.txt », vous avez un problème.
Croyez-moi, ça change tout de vérifier régulièrement.
Faut-il bloquer les mauvais bots
Bonne question. Vous avez des robots agressifs qui scannent votre site sans apporter de valeur: scrapers, certains bots SEO, collecteurs d’emails.
Je bloque parfois des user-agents spécifiques:
User-agent: AhrefsBot
Disallow: /
User-agent: SemrushBot
Disallow: /
User-agent: MJ12bot
Disallow: /
Franchement, je trouve que ces bots consomment des ressources serveur sans bénéfice direct. Mais attention — bloquer AhrefsBot vous empêche d’apparaître dans leur index, ce qui peut limiter votre visibilité dans leur outil.
C’est un arbitrage à faire selon vos priorités.
L’importance du sitemap dans votre robots.txt
Cette ligne est non négociable pour moi: Sitemap: https://votresite.com/sitemap.xml
Pourquoi? Parce qu’elle indique explicitement aux moteurs où trouver la liste complète de vos URLs importantes. Vous pouvez déclarer plusieurs sitemaps si nécessaire:
Sitemap: https://votresite.com/sitemap-articles.xml
Sitemap: https://votresite.com/sitemap-pages.xml
Sitemap: https://votresite.com/sitemap-produits.xml
Cette méthode — que j’utilise depuis longtemps — fonctionne particulièrement bien pour les sites complexes avec différents types de contenu.
Robots.txt versus balises meta robots
Beaucoup confondent ces deux outils. Ils sont complémentaires, pas interchangeables.
| Caractéristique | Robots.txt | Meta robots |
|---|---|---|
| Fonction | Contrôle l’exploration (crawl) | Contrôle l’indexation |
| Emplacement | Racine du site (fichier unique) | Dans le HTML de chaque page |
| Garantie | Non (peut être ignoré) | Oui (respecté par Google) |
| Usage recommandé | Bloquer crawl de zones techniques | Empêcher indexation de pages |
Si vous voulez vraiment qu’une page n’apparaisse pas dans Google, utilisez la balise <meta name=”robots” content=”noindex”> dans le code HTML.
Le robots.txt seul ne suffit pas. Bref, combinez les deux intelligemment.
Surveiller l’impact de vos modifications
Chaque changement dans votre robots.txt peut avoir des conséquences. Parfois positives, parfois catastrophiques (j’ai fait cette erreur aussi).
Voici comment je procède pour mesurer l’impact:
Nombre de pages explorées: dans Search Console, section Paramètres > Statistiques sur l’exploration. Vous voyez l’évolution du nombre de pages crawlées par jour.
Pages indexées: tapez site:votresite.com dans Google. Le nombre de résultats vous donne une estimation. Comparez avant et après vos modifications.
Erreurs de crawl: toujours dans Search Console, vérifiez qu’aucune page stratégique n’est bloquée par erreur.
Je note systématiquement la date de chaque modification dans un fichier annexe. Comme ça, si je constate une baisse de trafic, je peux faire le lien.
Les cas particuliers à connaître
Certaines situations demandent une approche spécifique.
Sites multilingues: vous pouvez avoir un seul robots.txt à la racine, même si vous avez des sous-dossiers par langue (/fr/, /en/, /es/). Les directives s’appliquent à tout le domaine.
Sous-domaines: chaque sous-domaine (blog.votresite.com, shop.votresite.com) doit avoir son propre robots.txt. Ils sont considérés comme des sites distincts.
Sites en HTTPS: le protocole compte. Si vous avez migré de HTTP vers HTTPS, assurez-vous que le robots.txt est accessible sur la version HTTPS.
Environnements de staging: bloquez tout avec Disallow: / sur vos environnements de développement et de test. Vous ne voulez pas que Google indexe ces versions.
Mes recommandations finales pour un fichier optimal
Après des centaines de sites optimisés, voici ce que je vous conseille.
Gardez-le simple. Un robots.txt trop complexe devient ingérable et source d’erreurs. Bloquez uniquement ce qui doit l’être.
Documentez vos choix. Ajoutez des commentaires (lignes commençant par #) pour expliquer pourquoi vous bloquez telle section. Dans six mois, vous aurez oublié.
Testez avant de publier. Toujours. Utilisez l’outil Search Console et vérifiez vos URLs stratégiques.
Surveillez régulièrement. Le robots.txt n’est pas un fichier qu’on configure une fois pour toutes. Votre site évolue, vos besoins aussi.
Ne bloquez jamais par précaution. Si vous n’êtes pas sûr qu’une section doit être bloquée, laissez-la accessible. Il vaut mieux trop explorer que pas assez.
Déclarez votre sitemap. C’est la ligne la plus rentable du fichier.
Vérifiez l’accessibilité. Votre fichier doit renvoyer un code HTTP 200. Un robots.txt en 404 ou 500 est considéré comme autorisant tout.
Pour finir, rappelez-vous que le robots.txt est un outil parmi d’autres dans votre arsenal SEO. Il ne remplace pas une architecture propre, des balises meta bien configurées ou un contenu de qualité. Mais bien utilisé, il améliore significativement l’efficacité du crawl de votre site.
Vous avez maintenant toutes les clés pour créer un fichier robots.txt performant et éviter les pièges classiques.
