Guide pour configurer un fichier robots.txt efficace en 2026

J’ai galéré pendant des mois avec un fichier robots.txt mal configuré. Mon site e-commerce perdait la moitié de son trafic organique, et je ne comprenais pas pourquoi. Le problème ? J’avais accidentellement bloqué l’exploration de toutes mes pages produits avec un Disallow: / mal placé. Résultat : Google n’explorait plus rien, mes fiches disparaissaient des résultats, et mon chiffre d’affaires en prenait un coup. Depuis, j’ai passé des heures à décortiquer ce fichier de 2 Ko. Voici ce que j’ai appris.

Qu’est-ce qu’un fichier robots.txt et pourquoi il ne fait pas ce que vous croyez

Le fichier robots.txt est un simple fichier texte placé à la racine de votre site. Il dit aux robots d’exploration (Googlebot, Bingbot, etc.) : « Voici les parties de mon site que vous pouvez visiter, et celles que je préfère que vous évitiez. »

Mais attention : ce n’est pas une barrière de sécurité. C’est un panneau « sens interdit » sur une autoroute. Un robot bien élevé (comme Googlebot) le respecte. Un robot malveillant (scraper, aspirateur de contenu) s’en fout complètement. Je l’ai appris à mes dépens quand un concurrent a copié tout mon catalogue en ignorant mes règles.

Robots.txt c’est quoi ?

Franchement, c’est un petit fichier qui pèse moins qu’une image, mais qui contrôle des millions de pages explorées par jour. Il utilise une syntaxe très simple :

• User-agent : le nom du robot ciblé (ex. Googlebot ou * pour tous).
• Disallow : les chemins à éviter.
• Allow : les chemins autorisés (pour déroger à un Disallow).
• Sitemap : l’URL de votre sitemap.

Exemple basique :

User-agent: *
Disallow: /admin/
Disallow: /tmp/
Sitemap: https://www.exemple.com/sitemap.xml

Ce code dit à tous les robots : « Ne touchez pas au dossier admin ni au dossier tmp. Et voici mon sitemap. »

Erreurs fréquentes qui coûtent cher

J’ai vu des sites entiers disparaître de Google à cause de ça. Voici les erreurs les plus courantes, et croyez-moi, elles sont faciles à commettre.

Le Disallow total par accident

Un jour, un client m’appelle paniqué : « Mon site n’apparaît plus sur Google ! » Je vérifie son robots.txt : Disallow: /. Il avait copié une ligne depuis un tutoriel sans comprendre que le slash signifie « tout le site ». Une seule erreur de slash, et 15 000 pages en moins. Le temps de corriger ? 30 secondes. Le temps de récupérer le trafic ? 3 semaines.

User-agent incomplet

Autre erreur classique :

User-agent: *
Disallow: /wp-admin/

User-agent: Googlebot
Allow: /

Ici, Googlebot reçoit deux instructions contradictoires. La règle la plus spécifique (Googlebot) prime sur la générale (*). Mais le résultat peut varier selon le robot. Bref, ne mélangez pas les torchons et les serviettes.

Oublier le sitemap

Vous avez un sitemap XML ? Indiquez-le dans le robots.txt. Google l’utilise pour découvrir des pages qu’il n’aurait pas trouvées par les liens. Sans ça, vous passez à côté d’un signal fort. J’ai ajouté la ligne Sitemap: sur un site client, et le nombre de pages indexées est passé de 1 200 à 4 500 en deux mois.

Stratégies avancées par type de site

Un robots.txt générique ne suffit plus. Il faut l’adapter à votre contenu. Voici comment je configure mes fichiers selon le type de projet.

Site e-commerce

Les filtres de catégories (tri par prix, couleur, taille) créent des milliers d’URLs inutiles. Exemple : https://www.boutique.com/chaussures?couleur=rouge&taille=42&tri=prix. Google explore ça, mais ces pages n’apportent rien. Résultat : votre budget d’exploration est gaspillé.

Solution :

User-agent: *
Disallow: /*?couleur=
Disallow: /*?taille=
Disallow: /*?tri=
Allow: /produits/
Allow: /categories/
Sitemap: https://www.boutique.com/sitemap.xml

J’ai testé ça sur un site avec 50 000 produits. L’exploration des pages utiles a augmenté de 40 % en une semaine. Les pages de filtres, elles, ne sont plus explorées. Point bonus : ajoutez une balise noindex sur ces pages filtres pour être sûr qu’elles ne soient pas indexées.

Blog WordPress

WordPress génère des tonnes de pages inutiles : archives d’auteurs, pages de tags, pages de catégories, etc. Pour un blog classique, les articles sont le coeur. Le reste ? Souvent du bruit.

Mon setup perso :

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /tag/
Disallow: /author/
Allow: /article/
Allow: /category/
Allow: /wp-content/uploads/
Sitemap: https://www.monblog.com/sitemap_index.xml

Résultat : Google explore mes articles, mes images, et les catégories principales. Les tags et les profils d’auteurs (qui doublonnent souvent le contenu) sont ignorés. Depuis que j’ai appliqué ça, mon taux d’exploration utile est passé de 35 % à 78 %.

Site médias (images et vidéos)

Les sites avec beaucoup de médias doivent faire attention. Bloquer les dossiers d’images peut nuire au référencement visuel (Google Images). Mais laisser tout libre peut surcharger le serveur.

Ma règle : autoriser l’accès aux images utiles, bloquer les dossiers techniques (thèmes, plugins). Exemple :

User-agent: *
Allow: /wp-content/uploads/
Disallow: /wp-content/themes/
Disallow: /wp-content/plugins/

Les images dans uploads sont explorées. Les fichiers CSS/JS dans themes et plugins, non. Simple et efficace.

Interaction avec les balises meta robots et X-Robots-Tag

Voilà une chose que j’ai mise des mois à comprendre : le robots.txt ne contrôle PAS l’indexation. Il contrôle l’exploration. Si vous voulez qu’une page ne soit pas dans Google, vous devez utiliser :

• Une balise noindex dans le <head> de la page : <meta name="robots" content="noindex">.
• Ou un en-tête HTTP X-Robots-Tag: noindex (pour les PDF, images, etc.).
• Ou un mot de passe (authentification HTTP).

Le problème ? Si vous bloquez l’exploration avec Disallow mais que vous oubliez le noindex, Google peut quand même indexer la page via un lien externe. J’ai vu un client dont la page « admin » était indexée, simplement parce qu’un employé l’avait bookmarkée. Le robots.txt l’empêchait d’être explorée, mais pas d’être indexée. Correction : j’ai ajouté un noindex et un mot de passe.

Priorité des directives (de la plus forte à la plus faible) :

1. Balise meta robots ou X-Robots-Tag (noindex).
2. Mot de passe HTTP.
3. Robots.txt (Disallow).
4. Lien externe vers la page (si aucune autre directive).

Comment tester son fichier robots.txt

Ne faites pas l’erreur que j’ai faite : ne le déployez pas à l’aveugle. Utilisez les outils de test.

Google Search Console

Dans GSC, allez dans « Exploration > Outil de test d’URL ». Tapez une URL sensible (ex. une page produit), et l’outil vous dira si le robots.txt l’autorise ou non. C’est gratuit, rapide, et ça m’a sauvé la mise une dizaine de fois.

Test en direct

Si vous avez accès au serveur, vous pouvez utiliser curl en ligne de commande :

curl -I https://www.votresite.com/robots.txt

Ça vous renvoie le contenu du fichier. Vérifiez qu’il répond avec un code 200 (OK) et non 404 (introuvable). Si vous obtenez un 404, le fichier n’existe pas.

Analyser les logs serveur

Pour les plus avancés : regardez les logs de votre serveur. Cherchez les requêtes venant de Googlebot. S’il tente d’accéder à des pages que vous avez bloquées, c’est que votre Disallow fonctionne. Sinon, vérifiez la syntaxe.

Gestion des robots malveillants

Les scrapers, les bots de spam, les aspirateurs… ils ignorent votre robots.txt. Mais vous pouvez quand même essayer de les ralentir.

Ma technique : bloquer les User-Agents connus pour être malveillants. Exemple :

User-agent: SemrushBot
Disallow: /

User-agent: AhrefsBot
Disallow: /

User-agent: MJ12bot
Disallow: /

Franchement, ça ne marche pas à 100 %. Les bons scrapers changent de User-Agent. Mais ça bloque les plus paresseux. Pour une protection réelle, utilisez un pare-feu applicatif (WAF) comme Cloudflare ou un module anti-spam.

Et pour les robots légitimes (Googlebot, Bingbot) ? Ne les bloquez surtout pas. J’ai vu un site bloquer Googlebot par erreur, pensant qu’il s’agissait d’un scraper. Résultat : trois mois de trafic à zéro.

Un fichier robots.txt bien configuré ne fait pas de miracle, mais il évite des catastrophes. J’ai passé trop de temps à réparer les dégâts d’un fichier mal fait. Aujourd’hui, chaque nouveau projet commence par une vérification de cette petite ligne. Et vous, quand avez-vous vérifié le vôtre pour la dernière fois ?