Le robots.txt dit ce qu'il ne faut pas lire. Le sitemap XML dit l'inverse : voici mes adresses, et voici quand chacune a changé.
C'est le seul fichier du web où un site déclare lui-même la fraîcheur de ses pages, dans un format lisible par une machine. Sur le papier, c'est exactement ce dont un moteur génératif a besoin : il cite des pages, et une citation périmée est une citation fausse.
Le 20 septembre 2026, j'ai mesuré deux choses. Ce que trente hôtes français servent réellement à l'adresse de leur sitemap. Et ce que les éditeurs des robots d'IA en disent dans leur documentation.
La deuxième mesure tient en un chiffre. OpenAI, Anthropic et Perplexity écrivent le mot « sitemap » zéro fois.
Ce que la SERP « sitemap » raconte
Relevé du 20 septembre 2026 sur Google France, langue française.
Le champ pèse 4 570 recherches mensuelles : « sitemap » 2 400, « sitemap xml » 1 000, « sitemap wordpress » 480, « plan de site » 210, « sitemap google » 170, « sitemap seo » 90, « créer un sitemap » 50, « générateur sitemap » 50, « sitemap index » 40, « sitemap lastmod » 30, « fichier sitemap » 20, « sitemap changefreq » 20, « soumettre sitemap » 10.
C'est un champ plus petit que ceux des trois derniers articles, mais d'une autre nature : la concurrence publicitaire sur « sitemap » est à l'indice 6 pour un CPC de 2,45 €, et « sitemap index » monte à 5,80 €. On n'achète pas ces clics pour vendre un dépannage, on les achète pour vendre un outil.
Les neuf résultats organiques : la documentation Google (deux pages, en 1re et 8e position), sitemaps.org, Wikipédia, xml-sitemaps.com, wegrowth.io, abondance.com, webrankinfo.com, imagescreations.fr.
Aucun des neuf ne traite du versant génératif. Les dates disent pourquoi : Google date le résultat sitemaps.org du 21 mars 2008, et la page de la spécification elle-même porte la mention « Last Updated: Monday, November 21, 2016 ». Abondance est de 2023, wegrowth de 2024. Le sujet est considéré comme clos depuis longtemps.
L'Aperçu IA cite quatre sources et se termine par : « Souhaitez-vous savoir comment soumettre votre sitemap à Google ou trouver l'adresse du sitemap de votre CMS ? »
C'est la quatrième fois consécutive qu'un Aperçu IA sur une requête technique se termine en demandant à qui il s'adresse. « Erreur 503 » le 17, « erreur 403 » le 18, « captcha » le 19, « sitemap » le 20. Le corpus français ne lui permet pas de trancher.
Et il y a mieux. L'Aperçu explique que le sitemap est « souvent accessible à l'adresse ://votre-site.com ».
Cette adresse n'existe pas. Il manque le protocole devant et le nom du fichier derrière. L'Aperçu IA qui explique où trouver un sitemap donne une adresse qui ne mène nulle part. Gardez-la en tête : la suite de cet article mesure exactement ce que vaut le conseil qu'il essayait de donner.
Le protocole
Trente hôtes français, la même liste que les 17, 18 et 19 septembre. C'est le quatrième réemploi, et il est délibéré : les trois relevés précédents ont établi quels hôtes murent leurs robots. Reprendre la liste permet de croiser, au lieu de recommencer.
Pour chaque hôte, deux chemins vers le sitemap, parce que ce sont les deux seuls qui existent :
1. la declaration -> ligne « Sitemap: » du robots.txt
2. la convention -> /sitemap.xml a la racine de l'hote
Sur chaque fichier obtenu je relève le code HTTP final, le type MIME, la taille, la racine XML (urlset ou sitemapindex), le nombre d'entrées, le nombre de balises lastmod, et la plage de dates couverte.
Deux précautions de méthode, héritées des relevés précédents. Tous les fichiers passent par iconv -f UTF-8 -t UTF-8 -c puis tr -d '\000' avant comptage, et tous les grep sont en -a : sans cela, un fichier classé binaire renvoie des zéros silencieux. Et les fichiers .gz sont décompressés avant analyse, sans quoi qonto.com serait compté à zéro entrée.
Les comptages de documentation ont été faits deux fois, une fois en grep, une fois en Python sur le texte détagué. Les deux séries sont identiques.
L'adresse conventionnelle est morte 21 fois sur 30
Premier résultat, et c'est celui qui condamne le conseil de l'Aperçu IA.
J'ai demandé /sitemap.xml à chacun des trente hôtes, sur l'hôte qui répond (l'apex, ou le www quand l'apex ne résout pas).
XML valide 9 ameli, doctolib, francetvinfo, impots.gouv,
maif, payfit, service-public, swile, urssaf
refus 403 11 lesechos, fnac, darty, laredoute, decathlon,
qonto, creditmutuel, seloger, leboncoin,
blablacar, ouest-france
introuvable 404 10 lemonde, lefigaro, liberation, cdiscount,
sephora, boursorama, axa, francetravail,
ovhcloud, abondance
Neuf hôtes sur trente servent un sitemap exploitable à l'adresse que tout le monde croit universelle. Vingt et un ne servent rien.
Et ce ne sont pas des sites sans sitemap : la plupart en publient un, ailleurs, et le déclarent dans leur robots.txt. L'adresse conventionnelle n'est pas une convention. C'est une habitude de CMS.
Détail qui rejoint l'article d'hier sur le code 200 : parmi les dix 404, plusieurs sont des pages HTML complètes. ovhcloud.com renvoie 967 480 octets de 404, lemonde.fr 225 931, cdiscount.com 158 529. Et boursorama.com renvoie un 404 en text/xml de 181 octets, c'est-à-dire un document qui annonce le bon type MIME pour ne rien contenir.
Le fichier qui dit où est le fichier
Deuxième chemin : la ligne Sitemap: du robots.txt. Elle fonctionne mieux, mais elle a ses propres pannes, et elles ne sont pas toutes du même genre.
Sur les trente robots.txt demandés à l'apex, onze ne donnent aucune directive Sitemap. Ce chiffre brut ne veut rien dire tant qu'on ne l'ouvre pas :
robots.txt refuse en 403 5 fnac, darty, laredoute,
decathlon, blablacar
apex muet, directive sur www 2 ouest-france, urssaf
robots.txt servi, sans ligne 4 cdiscount, impots.gouv,
seloger, service-public
Seuls quatre hôtes servent un robots.txt lisible sans y déclarer de sitemap. Les cinq premiers ne refusent pas de déclarer : ils refusent le fichier lui-même. laredoute.fr répond 403 à /robots.txt avec 652 815 octets de page de défi. Six cent trente-sept kilo-octets à la place d'un fichier texte qui en fait typiquement deux.
Deux cas méritent d'être isolés, parce qu'ils sont à eux seuls une contradiction complète.
ouest-france.fr déclare https://www.ouest-france.fr/sitemap.xml dans son propre robots.txt. Cette adresse répond 403. Le site publie l'adresse d'un fichier qu'il refuse ensuite de livrer.
leboncoin.fr fait pareil : il déclare https://www.leboncoin.fr/auto-main.xml, qui répond 403.
Le troisième cas est plus doux mais plus parlant. francetravail.fr déclare son sitemap à l'adresse https://www.pole-emploi.fr/informations/sitemap.xml. Elle répond 301 vers www.francetravail.fr, et le fichier final est bon : 4 848 URL, toutes avec lastmod. Le sitemap fonctionne, mais le doigt qui le désigne porte encore l'ancien nom de l'établissement. C'est exactement l'usage de la 301 que l'article du 3 septembre décrivait : un rattrapage d'adresse périmée, laissé en place, et c'est très bien ainsi.
lastmod, et ses trois façons d'échouer
Voilà le cœur du sujet. Des cinq champs du protocole, lastmod est le seul qui porte une information qu'un moteur ne peut pas deviner autrement. Google a d'ailleurs officiellement cessé de tenir compte de changefreq et priority.
J'ai calculé, pour chaque sitemap obtenu, le nombre de jours distincts rapporté au nombre d'URL. Un sitemap qui décrit honnêtement un site vivant étale ses dates. Un sitemap qui recopie l'heure de sa propre génération les écrase toutes sur une seule valeur.
sitemap URL lastmod jours j/URL% plage
abondance.com 21 21 15 71,4 2015-04-17 -> 2026-09-18
lesechos.fr 48 48 25 52,1 2019-08-06 -> 2026-09-20
impots.gouv.fr 2309 2308 711 30,8 2015-10-01 -> 2026-09-19
maif.fr 1628 1628 357 21,9 2020-11-10 -> 2026-09-17
francetravail.fr 4848 4848 928 19,1 2019-11-20 -> 2026-09-20
lefigaro.fr 7698 7698 1006 13,1 2007-10-15 -> 2026-09-20
qonto.com 12 12 1 8,3 2026-09-20 -> 2026-09-20
sephora.fr 14 14 1 7,1 2026-09-20 -> 2026-09-20
ameli.fr 5680 5680 329 5,8 2017-05-16 -> 2026-09-18
boursorama.com 40 40 1 2,5 2026-09-20 -> 2026-09-20
swile.co 58 58 1 1,7 2026-09-17 -> 2026-09-17
payfit.com 4276 4276 70 1,6 2025-11-12 -> 2026-09-18
ovhcloud.com 2297 2297 4 0,2 2026-09-13 -> 2026-09-16
liberation.fr 592 592 1 0,2 2024-06-25 -> 2024-06-25
axa.fr 1640 0 0 0,0 aucun lastmod
creditmutuel.fr 1541 0 0 0,0 aucun lastmod
Une précaution de lecture, sans laquelle ce tableau ment. lemonde.fr et francetvinfo.fr n'y figurent pas : leurs sitemaps déclarés sont des sitemaps d'actualité, qui ne couvrent par construction que les dernières quarante-huit heures. Un ratio bas y est normal. Les comparer aux autres serait une faute. Je les écarte.
Le reste se lit en trois familles.
Les dates réelles. impots.gouv.fr publie 711 jours distincts sur 2 308 URL, de 2015 à aujourd'hui. maif.fr en publie 357, francetravail.fr 928, lefigaro.fr 1 006 avec un plus ancien article daté du 15 octobre 2007. Ces fichiers décrivent un site.
L'horodatage de fabrication. sephora.fr publie quatorze entrées portant toutes, à la seconde près, 2026-09-20T04:03:36+00:00. boursorama.com publie quarante entrées portant toutes 2026-09-20. qonto.com étale ses douze entrées entre 07:05 et 07:15 ce matin. Ces valeurs ne décrivent pas quatorze, quarante ou douze modifications : elles décrivent une génération.
J'ai vérifié l'hypothèse en redemandant les trois fichiers deux heures plus tard. Les valeurs n'avaient pas bougé d'une seconde. Ce ne sont donc pas des dates calculées à la volée à chaque requête (ce serait le pire cas), mais bien l'heure d'un build programmé, recopiée sur chaque ligne. ovhcloud.com relève du même mécanisme en plus lent : quatre dates distinctes pour 2 297 URL, toutes dans une fenêtre de quatre jours.
Le gel. liberation.fr déclare en premier, dans son robots.txt, un sitemap de 592 URL dont les 592 lastmod valent exactement 2024-06-25T00:00:00.000Z. Quinze mois sans bouger, sur un fichier de résultats d'élections toujours annoncé en tête de liste.
Et l'absence pure. axa.fr publie 1 640 URL sans un seul lastmod. creditmutuel.fr en publie 1 541, également sans aucune date. Pour ces deux assureurs-banquiers, le sitemap est une liste d'adresses et rien d'autre.
Le fichier du Crédit Mutuel porte d'ailleurs, en deuxième ligne, une signature qu'on ne s'attend pas à trouver chez une banque :
<!--Generated by Screaming Frog SEO Spider 21.3-->
Screaming Frog est un crawler de bureau. Ce sitemap n'est pas produit par le site : il a été produit par quelqu'un qui a lancé un logiciel sur son poste, exporté le résultat, et déposé le fichier. Il est donc figé à la seconde où cette personne a cliqué, et il le restera jusqu'au prochain clic. C'est la version humaine du gel de Libération.
Le protocole dit « un hôte ». service-public en déclare trois
La spécification de 2008 est explicite, et je la cite mot pour mot :
all URLs listed in the Sitemap must use the same protocol and reside on the same host as the Sitemap. For instance, if the Sitemap is located at http://www.example.com/sitemap.xml, it can't include URLs from http://subdomain.example.com.
Le sitemap de service-public.fr est un index de quatorze fichiers. Dépliés, ils contiennent 67 818 URL. Réparties ainsi :
lannuaire.service-public.fr 61 521 90,7 %
www.service-public.fr 6 143 9,1 %
www.service-public.gouv.fr 154 0,2 %
Trois hôtes dans un fichier qui, selon sa propre norme, n'a le droit d'en décrire qu'un. Et 91 % du volume concerne un sous-domaine annuaire qui n'est pas celui où le fichier est déposé.
Ce n'est pas un détail de conformité. C'est le même mécanisme que celui décrit dans l'article sur les sous-domaines : l'hôte est l'unité d'autorisation, et il est aussi l'unité de déclaration. Un sitemap qui déborde de son hôte parie sur la tolérance du moteur.
Le sitemap prédit-il la citation ?
Question suivante, et c'est la seule qui compte vraiment pour un éditeur : un moteur génératif cite-t-il ce que le sitemap déclare ?
J'ai posé la même question à deux moteurs, recherche web activée, le 20 septembre 2026 : comment déclarer un changement de situation à l'Assurance Maladie. C'est un cas favorable : ameli.fr publie 5 680 URL avec lastmod, et la réponse tient forcément sur ce site.
ChatGPT (gpt-5.4) a produit dix adresses dans un bloc « URLs des sources officielles ». Je les ai toutes testées, code HTTP et appartenance au sitemap :
7 / 10 presentes dans le sitemap, toutes en 200
2 / 10 vivantes en 200 mais ABSENTES du sitemap
1 / 10 404, absente du sitemap
Les trois écarts sont instructifs, et ils ne disent pas la même chose.
Le 404 est une troncature. Le modèle a écrit /un-changement-de-situation/declarer-une-nouvelle-adresse-postale en sautant le segment declarer-un-changement-de-coordonnees. L'adresse complète existe, répond 200, et figure bien dans le sitemap. Le fichier avait donc raison ; le modèle a raccourci quand même. Un sitemap n'empêche pas un modèle de composer une chaîne d'URL fausse. C'était déjà la conclusion du 3 septembre, elle tient ici sur un site qui fait tout correctement.
Les deux pages vivantes non déclarées sont /content/tuto-ameli-changement-dadresse et un formulaire PDF, /fileadmin/user_upload/formulaires/S1104.pdf. Le PDF cité alors qu'il n'est déclaré nulle part confirme ce que mesurait l'article du 30 août : être dans le sitemap n'est pas une condition pour être cité.
Point de contrôle important, et honnête : les six URL réellement utilisées par ChatGPT comme ancrages, celles qui portent une annotation dans le corps de la réponse par opposition à la liste recopiée en fin de message, sont toutes les six présentes dans le sitemap et toutes les six en 200. Le fichier n'a pas démérité. C'est la liste décorative, en fin de réponse, qui dérape.
Les six portent par ailleurs toutes le paramètre ?utm_source=openai, exactement comme les onze citations mesurées le 13 septembre. Le comportement n'a pas bougé en une semaine.
Perplexity (sonar), sur la même question, donne seize citations. Trois relèvent du domaine ameli.fr, et une seule vient de www.ameli.fr, celle qui est dans le sitemap. Les deux autres viennent de didacticiel.ameli.fr et de forum-assures.ameli.fr, deux sous-domaines, donc deux hôtes que le sitemap de www n'a pas le droit de couvrir.
J'ai demandé leur sitemap à ces deux hôtes. forum-assures.ameli.fr en a un, modeste, neuf adresses. didacticiel.ameli.fr répond 200 à /sitemap.xml, et sert ceci :
<html><head><title>Request Rejected</title></head><body>
The requested URL was rejected. Please consult with your
administrator.<br><br>Your support ID is: 181031218275633...
Un code 200, un type HTML, et un refus de pare-feu à la place du fichier. C'est très exactement le 200 creux mesuré hier sur les murs anti-robots, appliqué cette fois au sitemap. Un outil qui vérifie « le sitemap répond-il ? » par le code HTTP valide ce fichier.
Dernier écart, et il boucle sur la section précédente : les trois pages de service-public citées par Perplexity le sont sous l'hôte www.service-public.gouv.fr. Dans le sitemap, elles sont déclarées sous www.service-public.fr. Les pages sont les bonnes, les identifiants sont les bons, l'hôte diffère.
Ce que les éditeurs de robots d'IA en disent
Rien. Et le mot est à prendre au sens strict.
J'ai compté les occurrences dans le texte détagué de sept documentations, avec des mots témoins pour distinguer un silence éditorial d'un échec de récupération :
document sitemap lastmod crawl robots.txt mots
sitemaps.org (protocole) 218 18 15 12 3090
Google - creer un sitemap 157 4 16 15 3030
Google - a propos des sitemaps 36 0 20 5 1712
Google - crawlers 0 0 65 7 1349
OpenAI - bots 0 0 11 11 2117
Anthropic - crawler 0 0 20 5 3305
Perplexity - crawlers 0 0 7 3 852
Les trois dernières lignes sont le résultat de l'article. Les documentations d'OpenAI, d'Anthropic et de Perplexity mentionnent robots.txt onze, cinq et trois fois. Elles mentionnent « sitemap » zéro fois. Les témoins écartent l'explication paresseuse : ces pages sont substantielles, elles parlent d'exploration, elles parlent du fichier d'autorisation. Elles ne parlent pas du fichier de déclaration.
La quatrième ligne mérite un mot, parce qu'elle empêche une conclusion trop nette. La page Google qui présente ses propres robots ne mentionne pas non plus le sitemap : 65 « crawl », zéro « sitemap ». Le silence n'est donc pas une signature des moteurs génératifs : c'est une affaire de découpage de documentation. Chez Google, le sitemap a ses pages à lui, et elles sont copieuses. Chez les trois autres, ces pages n'existent pas du tout.
Deux lectures restent ouvertes, et je ne tranche pas. Soit ces robots lisent les sitemaps sans le documenter. Soit ils ne les lisent pas. Ce que le relevé établit, c'est qu'aucun des trois ne s'engage sur ce fichier, là où les trois s'engagent explicitement sur robots.txt.
Auto-audit
La règle de ce blog est de passer le site dans son propre relevé.
Le sitemap d'agencegeoparis.com déclare 60 URL, 60 lastmod, 44 jours distincts, soit un ratio de 73,3 %, le meilleur du corpus. Les dates s'étalent du 9 juillet au 19 septembre 2026 et correspondent aux publications réelles. Toutes les adresses sont sur un seul hôte, conformément au protocole, et le fichier est déclaré dans le robots.txt.
Un premier défaut saute aux yeux dès qu'on applique à ce fichier la règle énoncée plus haut : il émet changefreq et priority sur chacune de ses 60 URL, c'est-à-dire les deux champs dont Google a annoncé qu'il ne les lit plus. Ce n'est pas nuisible, c'est du remplissage. Le générateur les produit depuis le premier jour et personne ne les a retirés.
Le second défaut est plus sérieux. Les adresses déclarées sont en www.agencegeoparis.com, et l'apex agencegeoparis.com ne résout pas : aucun enregistrement DNS. Quelqu'un qui tape le nom de marque sans www n'arrive nulle part. Le sitemap est cohérent avec ce choix, mais le choix lui-même est à corriger, et il rejoint le chantier ouvert par l'article sur les sous-domaines. C'est en file d'attente, hors blog.
Ce que cet article n'établit pas
Quatre réserves.
Le relevé part d'une seule adresse de sortie en France, avec un agent navigateur. Les 403 mesurés sur robots.txt et sur les sitemaps peuvent tomber différemment pour un robot arrivant depuis les plages d'adresses déclarées par son éditeur.
Le ratio jours/URL mesure la résolution d'un sitemap, pas sa véracité. Un fichier peut étaler 711 dates distinctes et se tromper sur chacune. Je n'ai pas de moyen d'établir qu'une page a réellement changé le jour annoncé ; j'établis seulement qu'un fichier à une seule date distincte ne peut pas décrire des centaines de pages.
Le zéro des trois documentations est un silence, pas une preuve de comportement. Il faudrait des logs serveur pour savoir ce que GPTBot demande réellement. C'est la méthode de l'article du 1er août, et c'est la suite naturelle de celui-ci.
Enfin, deux moteurs et une question ne font pas une loi. Les onze adresses testées chez ameli.fr sont un échantillon, pas une statistique.
Ce qu'il faut retenir
Le sitemap n'est pas un levier de citation. Deux des pages citées chez ameli.fr sont vivantes et absentes du fichier, dont un PDF. Une page ne devient pas citable parce qu'elle est déclarée.
Mais c'est le seul endroit où vous dites à une machine quand votre page a changé, et c'est une information que les moteurs génératifs n'ont nulle part ailleurs. Encore faut-il la dire.
Trois vérifications, dans cet ordre, et elles prennent dix minutes.
Demandez votre /sitemap.xml et lisez le corps, pas le code. Vingt et un hôtes sur trente ne servent rien à cette adresse, et l'un des sitemaps de ce relevé répond 200 avec une page « Request Rejected ». Un code HTTP n'est pas un bon de livraison.
Comptez vos dates distinctes. Divisez le nombre de jours distincts par le nombre d'URL. Si le résultat est proche de zéro parce que toutes vos lignes portent la même seconde, votre lastmod n'est pas une date de modification : c'est l'heure de votre dernier déploiement, et elle ne renseigne personne.
Vérifiez que votre sitemap ne déborde pas de son hôte. Le protocole l'interdit depuis 2008, et 91 % du volume de service-public.fr est dans ce cas.
Chez Orbite, nous mesurons ce que vos fichiers de déclaration livrent réellement aux robots des moteurs génératifs : le sitemap, sa fraîcheur ligne à ligne, et l'écart entre ce que vous déclarez et ce qui est cité. Si vous voulez savoir ce que le vôtre raconte : parlons de votre visibilité générative. Les termes employés ici sont définis dans le glossaire GEO.
Pour la suite de ce cluster : ce que votre robots.txt autorise vraiment, le fichier llms.txt est-il utile, IndexNow face aux moteurs génératifs, la page 404 face aux moteurs et les dates de contenu vues par les moteurs.