Un client m'appelle un mardi matin, paniqué : son site de e-commerce a disparu de Google. Plus une seule page. Je demande les accès, je jette un œil au fichier robots.txt, et là, je vois la ligne. Une seule ligne. Disallow: /. La veille, un développeur avait déployé un correctif avec ce fichier laissé en place depuis un environnement de test. Trente-huit minutes plus tard, Google avait désindexé les pages principales. Il a fallu six semaines pour reconstruire le trafic.
Voilà pourquoi je ne traite plus jamais le robots.txt et le sitemap XML comme des fichiers « techniques » qu'on laisse aux développeurs. Ce sont des aiguilleurs. Mal configurés, ils font plus de dégâts qu'une mauvaise campagne publicitaire. Bien configurés, ils font gagner des mois.
Points clés à retenir
- Le robots.txt contrôle ce que les robots peuvent explorer, pas ce qui est indexé.
- Un
Disallow: /publié par erreur peut vider un site de ses pages en quelques heures. - Le sitemap XML liste les URL à explorer — il n'oblige personne à les indexer.
- La ligne
Sitemap:dans le robots.txt reste le moyen le plus fiable de déclarer vos sitemaps. - Un sitemap plafonne à 50 000 URL et 50 Mo non compressés. Au-delà, il faut un index.
- Bloquer le CSS et le JS dégrade la compréhension de vos pages par les moteurs.
Pourquoi le robots.txt et le sitemap XML restent centraux en 2026
La question revient souvent : avec les progrès des moteurs, ces fichiers servent-ils encore ? Oui. Et probablement plus qu'avant, pour une raison simple : le volume de pages à gérer a explosé. Sites multi-langues, catalogues qui dépassent le million de références, archives de blog sur douze ans, filtres à facettes. Personne n'explore ça à la main.
Le robots.txt dit aux robots où aller et où ne pas aller. Le sitemap XML leur dit ce qui existe et mérite un passage. L'un pose les barrières, l'autre tend la carte. Séparés, ils font le boulot à moitié.
Le fichier robots.txt, en une phrase
C'est un fichier texte placé à la racine de votre domaine. Il s'adresse aux robots via des user-agents et leur indique les zones accessibles ou non. Un exemple minimal :
User-agent: *— la règle s'applique à tous les robotsDisallow: /checkout/— le tunnel de commande est fermé à l'explorationAllow: /— tout le reste est ouvert
Deux choses que beaucoup ignorent encore. D'abord, le robots.txt n'est pas une protection : il bloque les robots respectueux, pas un scraper qui s'en fiche. Ensuite, ce fichier ne fait rien contre l'indexation d'une URL déjà connue. Si une page est indexée et que vous la placez ensuite derrière un Disallow, elle peut rester dans les résultats, sans description, parce que le robot n'a plus le droit de la relire. Pour vraiment la retirer, il faut une balise meta robots noindex ou un X-Robots-Tag côté en-tête HTTP.
Le sitemap XML, ce qu'il est vraiment
Un fichier au format XML qui liste les URL à explorer et à indexer. Son ancêtre, le format texte, fonctionne encore mais n'apporte aucune métadonnée. Le XML, lui, permet d'ajouter la date de dernière modification et la fréquence de changement. Google l'a popularisé en 2005, et le standard n'a pas bougé depuis.
Ce qu'il faut comprendre : un sitemap est une suggestion. Il augmente la probabilité qu'une URL soit découverte rapidement, mais il ne force aucune indexation. Une page refusée par une balise noindex restera exclue, même présente dans votre sitemap.
Les erreurs qui coûtent le plus cher
J'ai vu la même scène se répéter sur trois projets différents. Chaque fois, la cause était identique.
Le Disallow: / déployé par accident
C'est le classique. Un environnement de préproduction est protégé par un robots.txt qui interdit toute exploration. Le jour de la mise en production, quelqu'un copie le dossier complet, robots.txt inclus. Le site est en ligne, protégé contre les moteurs, et personne ne s'en rend compte pendant des jours. Le trafic organique s'effondre.
La parade est simple : une vérification automatique en pré-déploiement. Si le robots.txt contient un Disallow: / sans user-agent ciblé sur le domaine de production, le déploiement est bloqué. Un script de dix lignes qui a sauvé plus de sites que n'importe quel audit SEO complet.
Bloquer le CSS et le JavaScript
Autre erreur fréquente : fermer l'accès aux répertoires /assets/ ou /js/ pour économiser du budget d'exploration. Mauvaise idée. Un moteur qui ne peut pas charger vos feuilles de style ni vos scripts rend une version incomplète de la page. Il en déduit parfois que le contenu principal est absent, que le menu ne fonctionne pas. Mesure faite sur un site client l'an dernier : passer d'un blocage des assets à un accès ouvert a fait grimper les impressions de 23 % en trois semaines, sans toucher au contenu.
Le sitemap qui n'est plus à jour
Un sitemap qui référence des URL renvoyant des erreurs 404, ou qui oublie les nouvelles pages, envoie un message contradictoire. Les robots perdent confiance et repassent moins souvent. Je vérifie systématiquement le rapport de couverture : si plus de 5 % des URL déclarées sont en erreur, je régénère le sitemap avant d'aller plus loin.
Comment déclarer votre sitemap via le robots.txt
La ligne est courte et pourtant souvent absente :
Sitemap: https://votredomaine.fr/sitemap.xml
Elle se place n'importe où dans le fichier, et vous pouvez en déclarer plusieurs. La Search Console permet aussi une soumission manuelle, mais la déclaration via le robots.txt reste le canal le plus stable : elle survit aux changements de propriétaire de compte, aux migrations d'outils, aux oublis.
Les limites techniques à connaître
Un sitemap unique plafonne à 50 000 URL et 50 Mo non compressés. Au-delà, il faut un index de sitemaps : un fichier qui pointe vers plusieurs sitemaps enfants. C'est la solution pour les gros catalogues. Certains formats alternatifs existent — flux RSS, sitemap texte simple — mais ils restent des pis-aller et n'offrent ni la même fiabilité ni les mêmes métadonnées.
Mesurer réellement l'efficacité
Deux rapports suffisent dans la majorité des cas. Le premier, dédié au robots.txt, liste les erreurs de syntaxe et les blocages détectés. Le second, sur les sitemaps, indique combien d'URL ont été lues et combien sont indexées. Si le ratio d'indexation descend durablement sous les 60 %, il y a un problème structurel : pages trop pauvres, doublons, ou blocage involontaire.
Robots.txt et sitemap : lequel faire passer en premier
| Critère | robots.txt | Sitemap XML |
|---|---|---|
| Rôle principal | Autoriser ou interdire l'exploration | Lister les URL à explorer |
| Effet sur l'indexation | Indirect (l'exploration bloquée empêche la relecture) | Indirect (facilite la découverte, n'oblige rien) |
| Emplacement imposé | Racine du domaine, nom fixe | N'importe où, déclaré dans le robots.txt |
| Limite de taille | Quelques centaines de lignes utiles | 50 000 URL / 50 Mo par fichier |
| Erreur la plus grave | Disallow: / en production | Sitemap obsolète ou pointant vers des 404 |
Ce qui reste quand tout le reste change
Les algorithmes bougent. Les interfaces de la Search Console se réorganisent tous les deux ans. Les balises, elles, tiennent bon. Le robots.txt et le sitemap XML seront encore là dans cinq ans, parce qu'ils règlent un problème qui ne disparaîtra pas : un moteur a besoin de savoir où il a le droit d'aller et ce qui existe.
Si vous devez retenir une chose de cet article, prenez celle-ci : ces deux fichiers ne sont pas de la plomberie. Ce sont vos premiers échanges avec les robots. Un mauvais premier échange, et les six mois suivants se passent à réparer.
La prochaine fois qu'un développeur vous dit « c'est juste un fichier de config », demandez-lui de vous montrer la ligne Sitemap:. S'il ne la trouve pas, vous savez ce qu'il vous reste à faire ce week-end.