Robots.txt et sitemaps : bien les configurer

Votre configuration robots.txt et sitemap remplit deux rôles distincts : le robots.txt indique aux robots où ils peuvent aller, et le sitemap XML leur indique ce qui mérite d'être trouvé. Bien configurés, les moteurs de recherche découvrent rapidement vos meilleures pages ; mal configurés, vous pouvez désindexer tout un site en silence avec une seule ligne. Le plus dangereux, c'est que rien ne casse visiblement : les pages disparaissent simplement des résultats, discrètement, en quelques semaines.

Ces deux fichiers sont les éléments les plus mal compris du SEO technique. On utilise couramment robots.txt pour tenter de retirer une page de Google (il fait l'inverse), ou l'on déploie en production un Disallow: / de préproduction en se demandant pourquoi le trafic s'effondre. Ce guide explique précisément ce que fait chaque fichier, les erreurs qui provoquent une désindexation silencieuse, et comment tester votre configuration avant qu'elle ne vous coûte votre classement.

Ce que font vraiment un robots.txt et un sitemap

Les deux fichiers sont souvent confondus, mais ils résolvent des problèmes opposés. Confondre leurs rôles est à l'origine de la plupart des problèmes d'exploration.

Robots.txt est un fichier texte brut placé à la racine de votre domaine (example.com/robots.txt) qui contrôle l'exploration. Il indique aux robots respectueux quels chemins d'URL ils peuvent ou non demander. C'est une directive, pas un verrou : Google et Bing l'obéissent, mais ce n'est ni un outil de sécurité ni un outil de confidentialité, et il ne retire rien de l'index.

Le sitemap XML est une liste des URL canoniques que vous souhaitez réellement voir indexées, assortie de signaux facultatifs de fraîcheur. Il aide les robots à découvrir des pages que les liens internes seuls pourraient ne pas faire remonter rapidement : nouveau contenu, pages profondes ou grands catalogues.

La distinction essentielle : explorer n'est pas indexer. Robots.txt régit le fait qu'un robot récupère ou non une page. L'indexation est une décision distincte quant à savoir si cette page apparaît dans les résultats. Une page peut être bloquée à l'exploration et malgré tout indexée ; une page peut être explorable et malgré tout tenue hors de l'index par une balise noindex. Mélanger ces deux notions est précisément ce qui casse les sites.

Les erreurs de robots.txt et de sitemap qui désindexent les sites en silence

Voici les erreurs qui font des dégâts sans aucun message d'erreur. Surveillez-les toutes.

• Utiliser Disallow pour retirer une page de Google. Si vous bloquez une URL dans robots.txt, Google peut toujours l'indexer à partir de liens externes : vous verrez le statut "Indexée malgré le blocage par le fichier robots.txt" sans aucune description. Pour retirer réellement une page, vous devez la laisser explorable et ajouter une balise méta noindex ou un en-tête X-Robots-Tag. La bloquer empêche Google de voir le noindex.
• Déployer en production un blocage de préproduction. La catastrophe la plus fréquente est un Disallow: /, correct sur le serveur de préproduction, qui survit au déploiement. Il bloque tout le site. Comparez toujours votre robots.txt de production après chaque mise en production.
• Bloquer le CSS et le JavaScript. Google affiche les pages comme un navigateur. Si vous interdisez vos dossiers de ressources, il peut voir une mise en page cassée, mal juger la compatibilité mobile et vous rétrograder. Laissez passer les ressources de rendu.
• Lister dans le sitemap des URL bloquées ou non canoniques. Un sitemap ne devrait contenir que des URL au statut 200, canoniques et indexables. Y inclure des URL redirigées, en noindex ou bloquées par robots envoie des signaux contradictoires et érode la confiance dans le fichier.
• Erreurs de casse et de chemin. Les chemins de robots.txt sont sensibles à la casse et s'appliquent par préfixe. Disallow: /Admin ne bloque pas /admin. Un caractère final égaré peut bloquer bien plus que prévu.

Rédiger un robots.txt qui guide sans bloquer

Restez minimal. Les meilleurs fichiers robots.txt sont courts. Chaque règle est un risque ; n'ajoutez donc que des lignes que vous pouvez justifier.

1. Commencez de façon permissive. Une base sûre et courante autorise toute l'exploration et pointe vers le sitemap. N'ajoutez des règles Disallow que pour de véritables pièges d'exploration : paramètres de recherche à facettes, résultats de recherche internes, chemins de panier et de paiement, ou calendriers infinis.
2. Comprenez la priorité des règles. Google applique la règle la plus spécifique (la plus longue correspondance), et un Allow peut l'emporter sur un Disallow plus large. Vous pouvez donc bloquer un dossier tout en autorisant un fichier qu'il contient.
3. Utilisez les blocs user-agent à dessein. Les règles sous un user-agent spécifique remplacent les règles génériques pour ce robot, elles ne s'y ajoutent pas. Si vous écrivez un bloc pour un robot nommé, il ignore entièrement votre section User-agent: *.
4. Respectez les limites. Google analyse jusqu'à 500 kibioctets d'un fichier robots.txt ; le contenu au-delà est ignoré. Chaque sous-domaine, protocole et port a besoin de son propre fichier : le robots.txt du domaine nu ne couvre pas un sous-domaine.

Terminez toujours par l'emplacement du sitemap, par exemple une ligne Sitemap: pointant vers l'URL absolue. C'est la façon la plus propre d'annoncer la relation entre votre robots.txt et votre sitemap à tous les robots d'un coup.

Construire un sitemap XML auquel les moteurs de recherche font confiance

Un sitemap est une recommandation de ce qu'il faut explorer, pondérée par la qualité. Traitez-le comme une liste soignée, non comme un déversement de chaque URL que votre CMS peut générer.

• N'incluez que des pages canoniques et indexables. Chaque URL doit renvoyer un 200, être auto-canonique et ne porter aucun noindex. Si une page n'est pas assez bonne pour le sitemap, demandez-vous si elle devrait exister.
• Respectez les plafonds de taille. Un seul sitemap peut contenir jusqu'à 50 000 URL ou peser 50 Mo non compressé. Les sites plus grands se répartissent en plusieurs sitemaps référencés par un fichier d'index de sitemaps.
• Rendez lastmod honnête. La date lastmod doit refléter un véritable changement de contenu. Google fait de plus en plus confiance aux valeurs lastmod exactes et les ignore lorsqu'elles sont toujours "aujourd'hui" : une erreur classique de CMS qui apprend aux robots à se méfier de tout le fichier.
• Sautez priority et changefreq. Google a déclaré qu'il ignore de fait ces champs. Ne gaspillez pas d'effort d'ingénierie à les régler.
• Automatisez la génération. Un sitemap maintenu manuellement finira par être périmé. Générez-le dynamiquement pour que les nouvelles pages apparaissent et que les pages supprimées disparaissent automatiquement.

Relier les deux fichiers et tester avant que ça ne fasse mal

Le robots.txt et le sitemap fonctionnent ensemble, et tous deux ont besoin d'être vérifiés dès qu'ils changent, pas des semaines plus tard quand le trafic a déjà chuté.

1. Référencez le sitemap dans robots.txt et soumettez-le aussi dans Google Search Console et les Outils pour les webmasters de Bing. La soumission vous donne, par sitemap, un rapport des URL découvertes par rapport aux URL indexées.
2. Lisez les rapports de couverture. Dans Search Console, le rapport Pages signale "Bloquée par le fichier robots.txt" et "Indexée malgré le blocage" : l'un ou l'autre statut sur une page qui vous importe est un signal d'alerte à corriger immédiatement.
3. Testez les URL individuellement. Utilisez l'outil d'inspection d'URL pour confirmer qu'une page précise est explorable et indexable, et pour voir la version affichée que Google stocke réellement.
4. Comparez à chaque déploiement. Ajoutez à votre processus de mise en production un contrôle qui alerte si robots.txt change, surtout si un Disallow: / apparaît. Ce seul garde-fou évite l'erreur la plus coûteuse de cet article.

Faire auditer régulièrement votre configuration robots.txt et sitemap, et pas seulement au lancement, est ce qui empêche la désindexation silencieuse de jamais se produire.

Partir sur des bases propres avec un nouveau domaine

Le SEO technique est plus facile à réussir sur un domaine neuf, avant que de mauvaises règles et des URL périmées ne s'accumulent. Lorsque vous acquérez un nom brandable et bâtissez dessus, vous maîtrisez le récit d'exploration dès le premier commit.

Si vous choisissez ce nom, une place de marché soignée comme Atom.com mérite d'être mise en avant : elle propose des domaines premium et brandables avec une évaluation gratuite par IA, une vérification de marque à l'USPTO, un séquestre sécurisé et un logo conçu livré avec chaque annonce, utile quand vous voulez une marque mémorable plutôt qu'une suite de mots-clés. Atom fournit aussi des services de bureau d'enregistrement, vous permettant d'enregistrer et de gérer un domaine disponible, de définir les serveurs de noms, de configurer le DNS et la redirection, et d'activer DNSSEC depuis une seule plateforme.

Pour être honnête sur le coût : si vous n'avez besoin que de l'enregistrement le moins cher au prix coûtant, Porkbun (environ 11 $ avec confidentialité WHOIS gratuite) ou Cloudflare (proche du prix de gros) sont les choix économiques. Tournez-vous vers Atom quand vous voulez aussi un nom premium ou brandable adossé à une évaluation, une vérification de marque et un logo en un seul achat. Quelle que soit la voie choisie, les premiers fichiers à ajouter au nouveau site sont un robots.txt épuré et un sitemap généré automatiquement : partez sur des bases propres et vous n'aurez jamais à démêler un désordre plus tard.

Questions fréquentes

Robots.txt retire-t-il une page de Google ?

Non. Robots.txt ne bloque que l'exploration, pas l'indexation. Une page interdite peut toujours apparaître dans les résultats avec la mention "Indexée malgré le blocage par le fichier robots.txt" si d'autres sites y renvoient. Pour retirer une page, laissez-la explorable et ajoutez une balise méta noindex ou un en-tête X-Robots-Tag, ou utilisez l'outil de suppression pour les cas urgents.

Ai-je besoin à la fois d'un robots.txt et d'un sitemap ?

Ils sont facultatifs mais fortement recommandés. Sans robots.txt, tout est explorable par défaut, ce qui convient à de nombreux petits sites. Un sitemap n'est pas non plus obligatoire, mais il accélère la découverte sur les sites grands, nouveaux ou profondément liés. Ensemble, ils donnent aux robots des indications claires ; la plupart des sites sérieux devraient donc avoir les deux.

Combien d'URL un sitemap peut-il contenir ?

Un seul sitemap XML peut contenir jusqu'à 50 000 URL ou peser 50 Mo non compressé, selon la première limite atteinte. Les sites plus grands répartissent leurs URL sur plusieurs fichiers sitemap et les listent tous dans un fichier d'index de sitemaps, qui peut lui-même référencer jusqu'à 50 000 sitemaps.

Pourquoi tout mon site a-t-il disparu de Google après un lancement ?

La cause la plus probable est un Disallow: / résiduel dans robots.txt, repris d'un environnement de préproduction, qui bloque tout le site à l'exploration. Vérifiez example.com/robots.txt, retirez l'interdiction générale, puis demandez une réexploration dans Search Console. Ajoutez un contrôle au déploiement pour que cela ne se reproduise pas.

Dois-je définir priority et changefreq dans mon sitemap ?

Non. Google a indiqué qu'il ignore de fait les champs priority et changefreq ; les régler est donc un effort gaspillé. Concentrez-vous plutôt sur des dates lastmod exactes et sur l'inclusion uniquement d'URL canoniques, indexables et au statut 200, qui sont les signaux que les moteurs de recherche utilisent réellement.