robots.txt et sitemaps

Autoriser n'est pas exclure

robots.txt retire l'autorisation de télécharger une URL, et rien d'autre. Google le dit sans détour : ce n'est pas un moyen de tenir une page hors de la recherche. Les deux idées sont sans cesse confondues, et cette confusion produit une panne précise et bien visible.

Une URL bloquée vers laquelle d'autres sites pointent peut tout de même être indexée. Google sait que l'adresse existe parce que quelqu'un l'a liée ; il ne peut simplement pas voir ce qu'elle contient. Il peut donc l'afficher sans la moindre description — le pire des deux mondes, puisque la page est publique dans les résultats alors que vous ne maîtrisez pas son apparence.

Lire et écrire le fichier

Le fichier se trouve à la racine d'un hôte et ne s'applique qu'à cet hôte et à ce protocole. Les règles sont regroupées par user-agent, et un robot obéit au seul groupe le plus spécifique qui le concerne — pas à tous ceux qui pourraient le concerner. À l'intérieur d'un groupe, Google tranche par la règle la plus spécifique, pas par l'ordre.

User-agent: *
Disallow: /admin/
Disallow: /*.pdf$
Allow: /admin/public/

User-agent: Googlebot
Disallow: /drafts/

Sitemap: https://example.com/sitemap.xml

Deux détails de cet exemple concentrent l'essentiel des malentendus. La ligne Allow est plus spécifique que le Disallow au-dessus, donc /admin/public/ reste téléchargeable. Et dès qu'un groupe Googlebot existe, Googlebot n'obéit qu'à ce groupe — le groupe joker ne le concerne plus, si bien qu'ici /admin/ lui est accessible. Ce n'est presque jamais l'intention de l'auteur.

• Bloquer un chemin ne retire pas les URL déjà indexées ; cela arrête seulement les téléchargements à venir.
• La directive Sitemap est indépendante de tout groupe user-agent et peut figurer n'importe où dans le fichier.
• Une 5xx sur le robots.txt lui-même peut amener un robot à laisser tout l'hôte de côté : servez-le depuis quelque chose de fiable.

Là où une règle robots fait des dégâts très loin d'elle

Les erreurs de robots.txt les plus coûteuses ne sont pas les pages que vous vouliez bloquer. Ce sont les ressources dont une page a besoin pour s'afficher. Les moteurs rendent les pages avant de les indexer, et le rendu télécharge scripts, feuilles de style et réponses d'API.

Bloquez un chemin de scripts ou une route d'API et le robot télécharge toujours parfaitement le HTML. Il rend ensuite une page presque vide et indexe une page presque vide. Aucun rapport ne dira que la page était bloquée, parce qu'elle ne l'était pas — seul l'était ce dont elle avait besoin.

Un sitemap est une suggestion, pas une file d'attente

Les sitemaps aident à la découverte précisément là où le maillage est le plus faible : grands sites, sites tout neufs à faible netlinking, sites riches en médias sans texte d'ancre naturel. Google affirme sans détour que lister une URL ne garantit ni l'exploration ni l'indexation.

Google indique lui-même qu'un site modeste et bien maillé peut n'en avoir aucun besoin, le robot trouvant tout en suivant les liens. Cela mérite d'être pris au sérieux avant de bâtir une infrastructure de sitemaps pour un problème que le maillage interne réglerait mieux.

Quelles balises sont lues, ignorées ou suspectées

C'est ici que l'essentiel de l'effort consacré aux sitemaps se perd. Deux des quatre balises courantes ne font rien du tout, et une troisième peut jouer contre vous.

C'est la condition posée sur lastmod qui fait mal. Si votre build tamponne chaque URL avec l'horodatage du déploiement, chaque valeur est à la fois fausse et facile à réfuter : la page n'a pas changé, et le moteur peut le constater. Dès qu'il cesse de faire confiance au champ, il cesse de l'utiliser, ce qui vous laisse plus mal loti que si vous n'envoyiez aucun lastmod. Ne l'émettez que pour de vraies modifications du contenu principal, et omettez-le plutôt que de l'inventer.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/guides/indexing/</loc>
    <lastmod>2026-06-14</lastmod>
  </url>
</urlset>

Choisir le bon instrument

Presque toute question de ce domaine se règle dès qu'on sépare trois tâches qui se ressemblent sans être les mêmes.