Est-ce que chaque site web a besoin d'un fichier robots.txt ?

Ce n'est pas strictement obligatoire, mais c'est une bonne pratique. Sans fichier robots.txt, les moteurs de recherche explorent l'intégralité de votre site par défaut. Un fichier robots.txt vous permet de contrôler quelles pages sont explorées, ce qui est utile pour exclure les pages d'administration, les résultats de recherche internes et les contenus dupliqués.

robots.txt peut-il empêcher une page d'apparaître dans les résultats de recherche ?

Non. robots.txt empêche l'exploration, pas l'indexation. Si une page est bloquée dans robots.txt mais liée depuis une autre page indexée, Google peut toujours la référencer dans les résultats sans afficher de description. Utilisez la balise meta noindex ou l'en-tête X-Robots-Tag pour empêcher une page d'apparaître dans les résultats de recherche.

Que se passe-t-il si je bloque accidentellement Googlebot dans robots.txt ?

Google cessera d'explorer les URLs bloquées. Si ces pages étaient précédemment indexées, elles pourraient finir par être supprimées des résultats au fil du temps. Vérifiez l'outil d'inspection des URLs dans Google Search Console pour voir quelles pages sont explorées.

Où doit se trouver robots.txt ?

robots.txt doit se trouver à la racine de votre domaine : https://votre-domaine.com/robots.txt. Il ne s'applique qu'aux URLs de ce domaine exact. Un robots.txt sur example.com ne contrôle pas l'exploration de subdomain.example.com.

Comment tester mon fichier robots.txt ?

Utilisez l'outil de test robots.txt de Google Search Console (Paramètres > Exploration > Testeur robots.txt). Vous pouvez saisir n'importe quelle URL et voir si le robots.txt actuel autorise ou bloque l'exploration par Googlebot.

Générateur robots.txt : Créez le bon fichier pour votre site en 2 minutes

robots.txt est l'un de ces fichiers que l'on crée une fois puis que l'on oublie. Pour les petits sites de contenu, c'est généralement acceptable. Pour les sites avec des panneaux d'administration, des chemins de staging exposés, des pages de résultats de recherche interne, ou des contenus dupliqués, un robots.txt mal configuré (ou absent) peut causer silencieusement des problèmes SEO pendant des mois.

Ce guide explique ce que robots.txt fait réellement, ce qu'il ne fait pas (source de confusion fréquente) et comment rédiger un fichier correct pour les types de sites courants. Vous pouvez utiliser le générateur robots.txt pour créer le vôtre sans mémoriser la syntaxe.

Ce que robots.txt fait réellement

robots.txt est un fichier texte brut que vous placez à la racine de votre domaine et qui indique aux robots d'exploration quelles URLs ils doivent ou ne doivent pas explorer. Le mot clé est "explorer" — pas "indexer."

Le fichier se trouve à https://votre-domaine.com/robots.txt. Quand Googlebot, Bingbot ou tout autre robot visite votre site, la première chose qu'il fait est de récupérer ce fichier. En fonction de ce qu'il trouve, il décide quelles URLs suivre.

Un robots.txt minimal ressemble à ceci :

User-agent: *
Allow: /

Cela indique à tous les robots qu'ils peuvent tout explorer. Fonctionnellement identique à ne pas avoir de robots.txt du tout.

Un fichier restrictif pourrait ressembler à :

User-agent: *
Disallow: /admin/
Disallow: /internal/
Disallow: /api/

Chaque directive est une ligne Disallow ou Allow, appliquée à un ou plusieurs groupes User-agent.

La distinction entre exploration et indexation (c'est important)

Beaucoup de développeurs supposent que bloquer une URL dans robots.txt la supprime des résultats de recherche Google. Ce n'est pas le cas, et cela cause de vrais problèmes.

Voici ce qui se passe réellement quand vous bloquez une URL :

Googlebot cesse de l'explorer — il ne suivra pas les liens de cette page, ne lira pas son contenu
Mais si d'autres pages indexées renvoient vers cette URL bloquée, Google peut toujours découvrir que l'URL existe
Google peut toujours afficher cette URL dans les résultats de recherche avec une description générique comme "Aucune information disponible pour cette page"

Donc si vous avez une page que vous voulez complètement exclure des résultats de recherche, Disallow seul ne suffit pas. Vous avez besoin d'une directive noindex — mais voilà le problème : si la page est bloquée à l'exploration, Googlebot ne peut pas lire la balise noindex pour la respecter.

Cela crée une situation frustrante : pour utiliser noindex, vous devez laisser la page être explorée.

La règle de base :

Utilisez robots.txt Disallow pour empêcher les robots de gaspiller le budget d'exploration sur des pages sans importance pour le SEO (chemins de staging, APIs internes, pages filtrées dupliquées)
Utilisez la balise meta noindex pour empêcher des pages spécifiques d'apparaître dans les résultats de recherche
Pour les pages vraiment sensibles (panneaux d'administration, contenu privé), utilisez une authentification réelle — pas robots.txt

User-Agent : cibler des robots spécifiques

Le champ User-agent vous permet de cibler tous les robots ou des robots spécifiques.

User-agent: *

L'astérisque signifie "tout robot non spécifié autrement." La plupart des fichiers robots.txt utilisent ceci pour les règles générales.

Vous pouvez également cibler des robots nommés :

User-agent: Googlebot
Disallow: /no-google/

User-agent: Bingbot
Disallow: /no-bing/

User-agent: *
Disallow: /admin/

Les règles sont appliquées par groupe user-agent. Googlebot suit le bloc Googlebot. S'il n'y a pas de bloc correspondant, il retombe sur le bloc *.

Quelques robots que vous pourriez vouloir gérer spécifiquement :

Googlebot — le principal robot d'exploration web de Google
Googlebot-Image — le robot d'images spécifique de Google
Bingbot — Microsoft Bing
GPTBot — le robot d'entraînement d'OpenAI (une préoccupation plus récente pour les sites de contenu)
anthropic-ai — le robot d'entraînement d'Anthropic
AhrefsBot, SemrushBot, MJ12bot — outils SEO et d'analyse

Pour bloquer spécifiquement les robots d'entraînement IA :

User-agent: GPTBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: *
Allow: /

Cela devient de plus en plus courant. Si cela compte vraiment pour votre site est une question distincte, mais la syntaxe est correcte.

Modèles Disallow courants

Voici des modèles corrects pour des situations courantes :

Bloquer un répertoire entier

User-agent: *
Disallow: /admin/

Le slash final compte. /admin/ bloque /admin/settings, /admin/users, etc. Sans le slash, /admin bloquerait aussi une page littéralement nommée /administrator ou /admin-login — probablement pas ce que vous voulez.

Bloquer un fichier spécifique

User-agent: *
Disallow: /private-page.html

Bloquer les paramètres de requête URL (pages de filtres)

Les sites e-commerce ont souvent les mêmes produits accessibles via de nombreuses combinaisons de filtres : /products?color=red&size=L&sort=price. Cela crée du contenu dupliqué. Bloquez-les :

User-agent: *
Disallow: /*?

Cela bloque toute URL avec une chaîne de requête. Attention — si vos pages importantes utilisent des chaînes de requête (certaines SPAs le font), cela les bloquera aussi. Une approche plus ciblée :

User-agent: *
Disallow: /products/*?

Cela bloque les URLs avec chaîne de requête uniquement sous /products/.

Autoriser un chemin spécifique dans un répertoire bloqué

Parfois vous voulez bloquer la plupart d'un répertoire mais autoriser un chemin :

User-agent: *
Disallow: /account/
Allow: /account/signup

L'ordre au sein d'un bloc user-agent compte. La plupart des robots appliquent la règle correspondante la plus spécifique.

La directive Sitemap

Vous pouvez (et devriez) inclure l'URL de votre sitemap dans robots.txt :

User-agent: *
Disallow: /admin/

Sitemap: https://votre-domaine.com/sitemap.xml

La directive Sitemap va à la fin, en dehors de tout bloc user-agent. Ce n'est pas une simple formalité — Google l'utilise activement pour trouver et prioriser l'exploration de vos pages importantes.

Si vous avez plusieurs sitemaps (courant pour les grands sites avec des sitemaps d'images ou de vidéos) :

Sitemap: https://votre-domaine.com/sitemap.xml
Sitemap: https://votre-domaine.com/sitemap-images.xml

Vous devriez aussi soumettre votre sitemap directement dans Google Search Console, mais l'inclure dans robots.txt garantit que tout robot qui lit le fichier le découvre automatiquement.

Crawl-Delay : à utiliser avec précaution

Certains robots supportent une directive Crawl-delay :

User-agent: *
Crawl-delay: 10

Cela indique aux robots d'attendre 10 secondes entre les requêtes. Initialement utilisé pour empêcher les robots de surcharger les petits serveurs.

Le problème : Googlebot l'ignore. Google a dit explicitement ne pas supporter Crawl-delay. Si vous avez besoin de réduire le taux d'exploration de Googlebot, faites-le dans Google Search Console sous les paramètres de débit d'exploration.

D'autres robots comme Bingbot supportent Crawl-delay, donc ce n'est pas complètement inutile — mais pour Google spécifiquement, c'est sans effet. Ne vous y fiez pas pour la limitation de débit.

Les erreurs courantes qui nuisent au SEO

Bloquer les fichiers CSS et JavaScript

C'était un conseil courant — "bloquez les robots pour qu'ils ne crawlent pas les scripts et feuilles de style pour économiser de la bande passante." C'est une mauvaise pratique. Google a besoin de rendre vos pages pour les évaluer correctement, et le rendu nécessite CSS et JavaScript. Si vous bloquez ces fichiers :

# Ne faites pas cela
User-agent: *
Disallow: /wp-content/
Disallow: /assets/
Disallow: /*.css$
Disallow: /*.js$

Google ne peut pas voir à quoi ressemblent réellement vos pages, ce qui peut nuire aux classements. Laissez les robots accéder à vos ressources statiques.

Oublier les environnements de staging et de développement

Si votre environnement de staging est accessible à staging.votre-domaine.com ou votre-domaine.com/staging/, assurez-vous qu'il est soit :

Derrière une authentification (préféré)
Bloqué dans robots.txt

Le contenu de staging indexé par Google crée des problèmes de contenu dupliqué. C'est une négligence courante sur les sites qui évoluent rapidement.

Utiliser robots.txt pour protéger du contenu sensible

Cela vaut la peine d'être répété. robots.txt n'est pas un contrôle d'accès. Le fichier est lisible publiquement — n'importe qui peut visiter votre-domaine.com/robots.txt et voir exactement quels chemins vous avez essayé de cacher. Si ces chemins sont intéressants, les gens les visiteront directement. Utilisez une authentification côté serveur pour tout ce qui est vraiment sensible.

Bloquer accidentellement votre sitemap

# Cela bloque accidentellement le sitemap
User-agent: *
Disallow: /
Allow: /public/

Sitemap: https://votre-domaine.com/sitemap.xml

Dans cet exemple, /sitemap.xml est bloqué par Disallow: / parce qu'il ne correspond pas à l'exception Allow: /public/. La directive sitemap dans le fichier ne débloque pas automatiquement l'URL du sitemap. Vous devrez ajouter Allow: /sitemap.xml explicitement.

Mauvais emplacement

robots.txt doit se trouver à la racine du domaine. votre-domaine.com/robots.txt fonctionne. votre-domaine.com/blog/robots.txt ne fait rien — les robots ne chercheront pas là.

De plus, un robots.txt à votre-domaine.com n'affecte pas subdomain.votre-domaine.com. Chaque sous-domaine a besoin de son propre robots.txt si vous voulez contrôler l'exploration là-bas.

Exemples robots.txt pour des types de sites courants

Site de contenu ou marketing standard

User-agent: *
Allow: /

Sitemap: https://votre-domaine.com/sitemap.xml

S'il n'y a rien à cacher et pas de problème de contenu dupliqué, restez simple.

Site WordPress

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

Sitemap: https://votre-domaine.com/sitemap.xml

Allow: /wp-admin/admin-ajax.php est important — certains thèmes et plugins utilisent cet endpoint pour des fonctionnalités frontend auxquelles Googlebot a besoin d'accéder pour un rendu correct.

Site e-commerce avec pages de filtres

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /search?
Disallow: /products/*?sort=
Disallow: /products/*?page=

Sitemap: https://votre-domaine.com/sitemap.xml

Les pages panier et paiement ne devraient jamais être indexées. Les pages de compte sont du contenu spécifique à l'utilisateur. Les combinaisons d'URLs filtre/tri créent du contenu dupliqué.

Next.js ou SPA avec routes API

User-agent: *
Disallow: /api/
Disallow: /_next/
Allow: /_next/static/
Allow: /_next/image

Sitemap: https://votre-domaine.com/sitemap.xml

Bloquez les routes API. Bloquez les chemins internes Next.js sauf les ressources statiques et l'endpoint d'optimisation d'images dont les renderers ont besoin.

Tester votre robots.txt

Ne supposez pas que votre fichier est correct — vérifiez-le.

Google Search Console dispose d'un testeur robots.txt (Paramètres > robots.txt). Vous saisissez un chemin URL et il vous indique si Googlebot est autorisé ou bloqué en fonction de votre fichier actuel. Il vous montre aussi ce que Google a récupéré comme fichier pour la dernière fois.

L'outil d'inspection des URLs dans Search Console vous permet de vérifier des URLs individuelles et de voir si Google peut y accéder et les rendre.

Les outils tiers comme les vérificateurs robots.txt dans diverses suites SEO peuvent valider la syntaxe et tester plusieurs user-agents. Le générateur de méta SEO et le générateur d'images OG sont des compagnons utiles quand vous travaillez sur la configuration SEO globale de votre site.

Après avoir apporté des modifications à robots.txt, vous pouvez demander à Google de le récupérer à nouveau via l'outil d'inspection des URLs — bien que les modifications se propagent généralement en quelques jours de toute façon.

Générer votre robots.txt

Écrire robots.txt manuellement n'est pas compliqué, mais il est facile de se tromper légèrement dans la syntaxe — un slash manquant, une directive au mauvais endroit, un bloc user-agent qui ne couvre pas ce que vous pensiez.

Le générateur robots.txt vous permet de sélectionner les robots à configurer, les chemins à bloquer, d'ajouter l'URL de votre sitemap, et d'obtenir une sortie propre et valide. C'est plus rapide que de chercher la syntaxe, et cela réduit le risque d'une faute de frappe qui vous coûterait une couverture d'exploration sur des pages importantes.

Une fois généré, placez le fichier à la racine de votre serveur web et vérifiez qu'il est accessible à votre-domaine.com/robots.txt. Pour la plupart des frameworks :

Next.js : Ajoutez public/robots.txt ou utilisez la route robots.ts dans l'App Router
Gatsby : Placez dans static/robots.txt
Hugo : Placez dans static/robots.txt
Sites HTML simples : Placez dans le répertoire racine servi par votre serveur web

Pour les utilisateurs de Next.js App Router, vous pouvez aussi le générer programmatiquement :

// app/robots.ts
import { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: '*',
      allow: '/',
      disallow: ['/admin/', '/api/'],
    },
    sitemap: 'https://votre-domaine.com/sitemap.xml',
  }
}

Cette approche est préférable pour les sites où les règles peuvent dépendre de variables d'environnement (par exemple, bloquer tous les robots en staging).

robots.txt est simple, mais les idées reçues à son sujet — surtout la distinction entre exploration et indexation — causent de vrais problèmes SEO, parfois difficiles à déboguer. Configurez le fichier correctement une fois, testez-le dans Search Console, et vous pourrez ensuite réellement l'oublier.