Robots.txt : syntaxe, erreurs courantes et cas avancés

Un fichier de 30 lignes qui bloque accidentellement 12 000 pages produits pendant 48 heures. C'est arrivé à un e-commerce mode de 18 000 URLs lors d'une refonte technique — un Disallow: /catalog/ poussé en production au lieu de staging. Le trafic organique a chuté de 34% en deux jours, et il a fallu trois semaines pour retrouver le niveau d'avant. Le robots.txt est probablement le fichier le plus sous-estimé et le plus dangereux de votre stack SEO.

La syntaxe robots.txt, au-delà des bases

Le protocole robots.txt repose sur le Robots Exclusion Protocol, standardisé dans la RFC 9309 publiée en septembre 2022. Cette RFC a clarifié des zones grises que Google, Bing et d'autres interprétaient chacun à leur manière depuis des années.

Les directives fondamentales

Un robots.txt valide se compose de groupes de règles, chacun ciblant un ou plusieurs user-agents :

# Groupe 1 : règles pour Googlebot
User-agent: Googlebot
Disallow: /admin/
Disallow: /checkout/
Allow: /admin/public-api/
Crawl-delay: 1

# Groupe 2 : règles pour tous les autres bots
User-agent: *
Disallow: /internal/
Disallow: /tmp/

# Sitemap
Sitemap: https://www.shop-vetements.fr/sitemap-index.xml

Points techniques à retenir :

L'ordre des règles dans un groupe n'a pas d'importance pour Google. Googlebot applique la règle la plus spécifique (longest match), pas la première rencontrée. C'est un point de divergence majeur : certains crawlers comme ceux basés sur le comportement classique appliquent la première règle qui matche.
Crawl-delay est ignoré par Googlebot. Google le dit explicitement dans sa documentation. Bing, Yandex et d'autres le respectent. Si vous voulez contrôler la fréquence de crawl de Googlebot, passez par les paramètres de Search Console.
La directive Sitemap est indépendante de tout User-agent. Elle peut apparaître n'importe où dans le fichier.
Le fichier doit être à la racine du domaine : https://www.shop-vetements.fr/robots.txt. Un robots.txt dans un sous-répertoire (/blog/robots.txt) n'a aucune valeur.

Les wildcards : puissance et pièges

Google et Bing supportent deux caractères spéciaux non prévus dans la RFC historique mais documentés et largement adoptés :

* : correspond à zéro ou plusieurs caractères.
$ : ancre de fin d'URL.

User-agent: Googlebot

# Bloquer toutes les URLs avec un paramètre de tri
Disallow: /*?sort=

# Bloquer les fichiers .json sauf le manifest
Disallow: /*.json$
Allow: /manifest.json$

# Bloquer les pages de pagination au-delà de la page 5
# ⚠️ Impossible nativement — les wildcards ne gèrent pas la logique numérique
# Il faut lister explicitement ou utiliser un pattern commun
Disallow: /category/*/page/

# Bloquer les URLs de recherche interne avec facettes
Disallow: /search?*facet=
Disallow: /search?*color=
Disallow: /search?*size=

L'erreur classique avec les wildcards : un Disallow: /*? qui bloque toutes les URLs contenant un query string. Ça inclut les pages paginées, les paramètres UTM (peu importe pour le crawl si vos canonicals sont propres), mais aussi des URLs légitimes qui n'existent que sous forme paramétrée.

Le matching "longest path" de Googlebot

Ce mécanisme est souvent mal compris. Quand plusieurs règles s'appliquent à une même URL, Googlebot choisit celle dont le path est le plus long (le plus spécifique) :

User-agent: Googlebot
Disallow: /products/
Allow: /products/featured/

Pour l'URL /products/featured/summer-sale, Googlebot applique Allow: /products/featured/ car cette règle est plus longue (21 caractères) que Disallow: /products/ (10 caractères). En cas d'égalité de longueur, Allow l'emporte — c'est un choix d'implémentation de Google, documenté sur Google Search Central.

Erreurs courantes qui coûtent du trafic

Le Disallow qui bloque les ressources CSS/JS

C'est un classique, surtout sur des sites legacy ou des CMS sur-configurés. Bloquer /wp-includes/ ou /assets/ empêche Googlebot de rendre correctement vos pages. Si Google ne peut pas charger vos CSS et JS, il voit une page brute, souvent cassée — et votre contenu rendu côté serveur peut devenir invisible.

# ❌ Pattern dangereux trouvé sur des WordPress mal configurés
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

# ✅ Version corrigée
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
# Ne PAS bloquer wp-includes, themes ou plugins — 
# Googlebot a besoin de ces ressources pour le rendering

Pour vérifier ce que Googlebot voit réellement, utilisez l'outil d'inspection d'URL dans Search Console. Comparez le screenshot rendu avec votre page. Si le layout est cassé, vérifiez les ressources bloquées dans l'onglet dédié.

Le robots.txt qui retourne un 5xx

Si votre serveur retourne un code 5xx pour /robots.txt, Google traite ça comme un "full disallow" temporaire — il arrête de crawler tout le site jusqu'à ce que le fichier redevienne accessible. Documenté dans la RFC 9309, section 2.3.1.3.

Concrètement, si votre application génère dynamiquement le robots.txt (via un middleware Next.js, un controller Django, etc.) et que ce endpoint crash, votre site entier disparaît du crawl. La solution : servez le robots.txt comme un fichier statique ou ajoutez un fallback robuste.

Exemple avec un middleware Next.js qui pourrait crasher vs. une approche statique sécurisée :

// ❌ Risqué : robots.txt généré dynamiquement sans error handling
// app/robots.ts (Next.js App Router)
export default function robots() {
  // Si cette fonction throw, le endpoint retourne 500
  // → Google arrête de crawler tout le site
  const config = getConfigFromDatabase(); // peut crasher
  return {
    rules: config.robotsRules,
    sitemap: `${config.baseUrl}/sitemap.xml`,
  };
}

// ✅ Sécurisé : fallback en cas d'erreur
// app/robots.ts
import type { MetadataRoute } from 'next';

export default function robots(): MetadataRoute.Robots {
  try {
    const env = process.env.NEXT_PUBLIC_ENV;
    const baseUrl = process.env.NEXT_PUBLIC_BASE_URL || 'https://www.shop-vetements.fr';
    
    if (env === 'staging' || env === 'preview') {
      return {
        rules: { userAgent: '*', disallow: '/' },
      };
    }

    return {
      rules: [
        {
          userAgent: 'Googlebot',
          allow: '/',
          disallow: ['/checkout/', '/account/', '/api/', '/internal/'],
        },
        {
          userAgent: '*',
          allow: '/',
          disallow: ['/checkout/', '/account/', '/api/'],
        },
      ],
      sitemap: `${baseUrl}/sitemap-index.xml`,
    };
  } catch {
    // Fallback : autoriser tout plutôt que crasher
    return {
      rules: { userAgent: '*', allow: '/' },
    };
  }
}

Confondre Disallow et noindex

Un Disallow empêche le crawl, pas l'indexation. Si Google découvre une URL via un lien externe ou un sitemap, il peut l'indexer sans jamais la crawler — en affichant un snippet vide dans les résultats. Pour désindexer, il faut une directive noindex dans la meta robots ou l'en-tête HTTP X-Robots-Tag.

Le piège classique : vous bloquez /staging/ dans le robots.txt ET vous avez un noindex sur ces pages. Sauf que Googlebot ne crawle pas ces pages (à cause du Disallow), donc il ne voit jamais le noindex. Les pages peuvent apparaître dans l'index, sans contenu affiché. C'est le pire des deux mondes.

Règle simple : si une page ne doit pas être indexée, utilisez noindex. Si elle ne doit pas être crawlée (pour économiser du crawl budget), utilisez Disallow. Les deux objectifs sont distincts.

Cas d'usage avancés pour les gros sites

Gestion des facettes sur un e-commerce de 45 000 pages

Prenons un site e-commerce de mobilier avec cette structure :

3 000 pages produits
150 pages catégories
~42 000 URLs de facettes (combinaisons couleur/matière/prix/dimensions)

Les facettes sont le cauchemar du crawl budget. Googlebot peut passer 80% de son temps à crawler des combinaisons de filtres à faible valeur ajoutée pendant que vos nouvelles pages produits attendent trois semaines avant d'être découvertes.

User-agent: Googlebot

# Autoriser les pages catégories et produits
Allow: /meuble/
Allow: /meuble/*/

# Bloquer les facettes multi-filtres (2+ paramètres)
Disallow: /meuble/*?*&*

# Bloquer les paramètres de tri et d'affichage
Disallow: /*?sort=
Disallow: /*?view=
Disallow: /*?per_page=

# Autoriser explicitement les facettes à valeur SEO
# (couleur seule sur les catégories principales)
Allow: /meuble/canape/?couleur=
Allow: /meuble/table/?couleur=
Allow: /meuble/chaise/?couleur=

# Bloquer les facettes à faible volume de recherche
Disallow: /*?hauteur=
Disallow: /*?poids=
Disallow: /*?garantie=

Sitemap: https://www.mobilier-example.fr/sitemap-index.xml

Cette approche est complémentaire au canonical : les facettes autorisées au crawl doivent avoir un canonical self-referencing, les facettes bloquées sont de toute façon invisibles pour Googlebot. Le robots.txt gère le crawl budget, le canonical gère la déduplication.

Bloquer les bots d'IA sans bloquer les moteurs de recherche

Depuis 2023, une préoccupation croissante : les crawlers de modèles de langage (GPTBot, ClaudeBot, etc.) qui consomment de la bande passante sans retour de trafic. Bloquer ces bots est légitime, mais il faut être chirurgical.

# Moteurs de recherche : accès normal
User-agent: Googlebot
Allow: /
Disallow: /account/
Disallow: /checkout/

User-agent: Bingbot
Allow: /
Disallow: /account/
Disallow: /checkout/

# Bots d'IA : blocage total
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

# Fallback pour les bots non identifiés
User-agent: *
Allow: /
Disallow: /account/
Disallow: /checkout/

Sitemap: https://www.votre-media.fr/sitemap-index.xml

Attention : Google-Extended est le user-agent spécifique pour l'entraînement des modèles d'IA de Google. Le bloquer n'affecte pas le crawl de Googlebot pour la recherche classique. C'est un levier intéressant si vous voulez maîtriser votre visibilité dans les AI Overviews sans couper l'indexation classique.

Le sujet du robots.txt et des LLMs évolue rapidement — surveillez les user-agents déclarés par chaque provider.

Environnements de staging et preview

Un cas qui revient systématiquement dans les audits : les environnements de staging accessibles publiquement, indexés par Google, qui créent du contenu dupliqué avec la production.

Le robots.txt seul ne suffit pas. La stratégie de défense en profondeur :

Robots.txt strict sur staging :

User-agent: *
Disallow: /

Meta robots noindex sur toutes les pages (au cas où le robots.txt est contourné).
HTTP Basic Auth ou IP whitelisting (la vraie protection).
En-tête X-Robots-Tag: noindex au niveau serveur pour couvrir les assets et APIs.

La config Nginx pour un environnement staging blindé :

server {
    listen 443 ssl;
    server_name staging.shop-vetements.fr;

    # Basic auth sur tout le site
    auth_basic "Staging Environment";
    auth_basic_user_file /etc/nginx/.htpasswd;

    # X-Robots-Tag en fallback
    add_header X-Robots-Tag "noindex, nofollow" always;

    # Robots.txt statique qui bloque tout
    location = /robots.txt {
        auth_basic off;  # Accessible sans auth pour que les bots voient le Disallow
        return 200 "User-agent: *\nDisallow: /\n";
        add_header Content-Type text/plain;
    }

    location / {
        proxy_pass http://staging-upstream;
    }
}

Le auth_basic off sur /robots.txt est important : si le robots.txt est derrière une auth, il retourne un 401, et certains bots traitent ça comme un "tout est autorisé".

Vérifier et debugger votre robots.txt

Outils de validation

Google Search Console propose un outil de test du robots.txt (Search Console > Paramètres > robots.txt). Il montre le fichier actuellement en cache chez Google et permet de tester si une URL spécifique est bloquée ou autorisée. Limites : il ne teste que pour Googlebot et ses variantes.

Screaming Frog : dans la config du crawl, activez "Respect robots.txt" et vérifiez l'onglet "Blocked by Robots.txt" après le crawl. Utile pour voir l'impact réel de vos règles sur l'ensemble de votre site. Vous pouvez aussi switcher le user-agent pour tester le comportement pour Bingbot ou d'autres.

CLI avec curl — le test le plus rapide :

# Vérifier que le robots.txt est accessible et retourne un 200
curl -sI https://www.shop-vetements.fr/robots.txt | head -5

# Voir le contenu complet
curl -s https://www.shop-vetements.fr/robots.txt

# Vérifier le robots.txt sur tous vos sous-domaines
for sub in www api cdn staging; do
  echo "=== $sub.shop-vetements.fr ==="
  curl -s -o /dev/null -w "%{http_code}" https://$sub.shop-vetements.fr/robots.txt
  echo ""
done

# Tester avec un user-agent spécifique
curl -s -A "Googlebot" https://www.shop-vetements.fr/robots.txt

Surveiller les changements en continu

Le robots.txt est souvent modifié par des déploiements automatisés, des plugins CMS mis à jour, ou des équipes DevOps qui ajoutent des règles sans prévenir le SEO. Un changement involontaire peut passer inaperçu pendant des jours.

Voici un script simple de monitoring qu'on peut placer en cron ou dans une CI :

#!/bin/bash
ROBOTS_URL="https://www.shop-vetements.fr/robots.txt"
CHECKSUM_FILE="/tmp/robots_checksum"

CURRENT=$(curl -s "$ROBOTS_URL" | sha256sum | awk '{print $1}')

if [ -f "$CHECKSUM_FILE" ]; then
  PREVIOUS=$(cat "$CHECKSUM_FILE")
  if [ "$CURRENT" != "$PREVIOUS" ]; then
    echo "⚠ robots.txt a changé !"
    echo "$ROBOTS_URL"
    # Envoyer une alerte Slack/email ici
    curl -X POST -H 'Content-type: application/json' \
      --data '{"text":"🚨 robots.txt modifié sur production !"}' \
      "$SLACK_WEBHOOK_URL"
  fi
fi

echo "$CURRENT" > "$CHECKSUM_FILE"

C'est exactement le type de régression qu'un outil de monitoring SEO comme Seogard détecte automatiquement — un changement dans le robots.txt déclenche une alerte avant que l'impact sur le crawl ne soit visible dans vos analytics.

Scénario réel : migration SPA vers SSR et robots.txt

Un média en ligne de 15 000 articles migre d'une SPA React (client-side rendering) vers Next.js en SSR. Avant la migration, leur robots.txt bloquait les bundles JS pour des raisons historiques (un dev avait voulu "cacher le code source"). Le rendering côté client dépendait entièrement de ces JS.

L'état avant migration :

# ❌ robots.txt historique — bloquait les bundles critiques
User-agent: *
Disallow: /api/
Disallow: /_next/static/
Disallow: /draft/

Le Disallow: /_next/static/ bloquait tous les assets statiques générés par Next.js (JS, CSS, images optimisées). En mode SPA, Google ne pouvait pas exécuter le JS → les pages étaient crawlées mais rendues vides → 60% du contenu n'apparaissait pas dans l'index.

Après migration vers SSR, le HTML est servi directement par le serveur. Le JS n'est plus nécessaire pour le contenu initial, mais il reste indispensable pour l'hydratation et les interactions. Le nouveau robots.txt :

User-agent: Googlebot
Allow: /
Disallow: /api/internal/
Disallow: /draft/
Disallow: /preview/
Disallow: /account/

User-agent: *
Allow: /
Disallow: /api/
Disallow: /draft/
Disallow: /preview/
Disallow: /account/

Sitemap: https://www.media-example.fr/sitemap-index.xml

Résultat observé sur 8 semaines :

Le crawl rate dans Search Console a augmenté de 2,3x (Google explorait enfin les pages correctement rendues au lieu de ré-essayer les pages vides).
Le nombre de pages indexées est passé de 6 200 à 14 100.
Le trafic organique a progressé de 78% entre la semaine 3 et la semaine 8 post-migration.

La leçon : le robots.txt doit évoluer avec votre architecture technique. Une règle pertinente en 2021 pour une SPA peut devenir destructrice après une migration SSR. Chaque changement d'architecture de rendering doit s'accompagner d'une revue du robots.txt.

Interactions entre robots.txt et les autres directives

Le robots.txt ne vit pas en isolation. Il interagit avec les meta robots, le X-Robots-Tag, les canonicals, et les sitemaps de manière parfois contre-intuitive.

Ordre de priorité des signaux

Google traite les signaux dans cet ordre :

Robots.txt : si une URL est bloquée, Googlebot ne la crawle pas → il ne voit jamais les meta robots ni le canonical.
HTTP headers (X-Robots-Tag) : traités à la réception de la réponse HTTP, avant le parsing du HTML.
Meta robots : traités lors du parsing HTML.
Canonical : traité en dernier, comme un signal (pas une directive) de préférence.

La conséquence : si vous bloquez une URL dans le robots.txt, toute directive noindex, canonical, ou autre présente sur cette page est invisible pour Google. C'est pourquoi bloquer + noindex est contradictoire — le noindex ne sera jamais lu.

Robots.txt et sitemap : la contradiction courante

Un piège fréquent : inclure dans le sitemap des URLs bloquées par le robots.txt. Google signale cette incohérence dans Search Console (rapport de couverture), mais beaucoup d'équipes ignorent ces avertissements.

Si une URL est dans le sitemap, c'est un signal qu'elle est importante. Si elle est bloquée dans le robots.txt, c'est un signal qu'elle ne doit pas être crawlée. Google voit la contradiction et perd confiance dans la qualité de vos signaux.

La bonne pratique : auditez régulièrement la cohérence entre votre sitemap et votre robots.txt. Screaming Frog permet de croiser les deux — crawlez le site en respectant le robots.txt, puis comparez avec la liste d'URLs du sitemap. Toute URL présente dans le sitemap mais bloquée par le robots.txt est un bug à corriger.

Interaction avec les meta tags SEO

Vos balises title, meta description, et balises Open Graph ne servent à rien si la page est bloquée au crawl. Avant de debugger un problème d'affichage dans les SERPs, vérifiez toujours en premier si la page est accessible à Googlebot via le robots.txt.

Taille et performance du robots.txt

La RFC 9309 spécifie que les crawlers doivent supporter des fichiers robots.txt d'au moins 500 kibibytes (512 000 octets). Google respecte cette limite — au-delà, le contenu excédentaire est traité comme un Allow. Documenté par Google dans ses explications sur l'architecture de crawl.

En pratique, si votre robots.txt dépasse 100 Ko, c'est probablement un signe que vous essayez de résoudre un problème d'architecture par des règles de crawl. Mieux vaut corriger la source (structure d'URLs, gestion des paramètres, canonical) que d'empiler des milliers de lignes de Disallow.

Pour vérifier la taille de votre fichier :

curl -s https://www.shop-vetements.fr/robots.txt | wc -c
# Résultat en octets — visez sous 10 000 pour un site standard

Le robots.txt est le premier fichier que Googlebot demande sur votre domaine à chaque session de crawl. Un fichier lourd ou un endpoint lent ralentit le début de chaque session. Servez-le en statique, avec un TTL de cache raisonnable (quelques heures), et assurez-vous qu'il ne dépend d'aucune base de données ou service externe pour être généré.

Le robots.txt est un contrat entre vous et les crawlers. Un contrat mal rédigé, contradictoire avec vos autres signaux, ou modifié sans surveillance, peut annuler des mois d'effort SEO en quelques heures. Auditez-le à chaque déploiement, testez-le avec les outils de Search Console et Screaming Frog, et mettez en place un monitoring qui vous alerte instantanément en cas de changement non prévu — c'est exactement ce type de régression silencieuse que Seogard est conçu pour intercepter.