Début juillet 2026, sept pages stratégiques de notre propre site figuraient dans le sitemap XML, dont notre page agence SEO à Paris et notre page expert SEO. Six jours plus tard, Search Console les classait toujours en « URL inconnue de Google ». Le fichier était valide, accessible, et Google le lisait. Il n’avait rien déclenché.
Cette expérience contredit ce que le top 10 de la requête répète en chœur : le plan de site présenté comme sésame de l’indexation. Nous reprenons le sujet depuis la base : le rôle exact du fichier, l’anatomie d’une version propre, les index de sitemaps, l’usage honnête de lastmod, puis les erreurs que nous relevons en audit.
À quoi sert un sitemap XML ?
Un sitemap XML est un fichier qui déclare aux moteurs de recherche les URLs que vous jugez importantes. Il accélère la découverte, surtout sur un site récent ou volumineux, mais il ne garantit ni le crawl ni l’indexation. Google l’écrit dans sa documentation, et nous l’avons vérifié sur notre propre site en juillet 2026.
La documentation Google Search Central pose la limite sans détour : un sitemap aide les moteurs à découvrir vos URLs, « but it doesn’t guarantee that all the items in your sitemap will be crawled and indexed ». Le fichier est une déclaration d’intention, pas un ordre d’indexation.
Google précise aussi qui en a besoin. Un site de plus de 500 pages, un site récent avec peu de liens entrants, un site riche en vidéos ou présent dans Google News tirent profit du fichier. À l’inverse, un site d’environ 500 pages ou moins, correctement maillé en interne, peut s’en passer sans dommage selon la même documentation.
Cette hiérarchie renseigne sur la mécanique réelle : Googlebot découvre le web d’abord en suivant des liens. Le plan de site comble les trous du maillage, il ne le remplace pas. Pour le déclarer, deux canaux se complètent : la directive Sitemap: dans le robots.txt, lisible par tous les moteurs, et la soumission dans le rapport Sitemaps de Search Console, qui ouvre en plus le suivi de couverture.
Anatomie d’un sitemap propre
Le protocole, défini sur sitemaps.org, tient en peu de règles. Un fichier minimal ressemble à ceci :
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://www.exemple.fr/page-strategique/</loc>
<lastmod>2026-07-10</lastmod>
</url>
</urlset>- loc est la seule balise obligatoire : une URL absolue et pleinement qualifiée par entrée. Google tente de crawler l’URL exactement telle qu’elle est listée, sans corriger ni deviner.
- Encodage UTF-8 imposé, par le protocole comme par la documentation Google.
- 50 000 URLs et 50 Mo non compressés maximum par fichier. Au-delà, on découpe le fichier.
- changefreq et priority sont ignorés par Google : sa documentation l’affirme mot pour mot. Les renseigner ne pénalise pas, mais n’apporte rien.
- L’emplacement compte : selon le protocole, un fichier placé dans un répertoire ne peut référencer que les URLs de ce répertoire ou plus profondes. Placez-le à la racine, le débat est clos.
- Ne déclarez que des URLs canoniques, indexables et en 200. Ce point relève de l’hygiène plutôt que du protocole : nous y revenons dans les erreurs d’audit.
Ce qu’il fait et ne fait pas : le cas de nos 7 pages
L’idée reçue s’affiche jusque dans les extraits que Google met en avant sur la requête : le plan de site aiderait à faire indexer vos pages « même si votre maillage interne n’est pas parfait ». Notre propre site a montré l’inverse en conditions réelles, sur des pages commerciales que nous suivions jour par jour.
Le déroulé, tel que nous l’avons vécu en juillet 2026 :
- Sept pages stratégiques, présentes dans le sitemap XML mais quasi dépourvues de liens internes, restent six jours en « URL inconnue de Google » dans Search Console. Le fichier était bien lu : la date de dernière lecture du rapport Sitemaps le confirmait.
- Nous ajoutons des liens internes vers ces pages depuis des pages déjà crawlées et positionnées, et nous soumettons dans la foulée l’URL finale du bon fichier dans Search Console.
- Sous 48 heures, les pages passent en explorées puis indexées.
Honnêteté de méthode : les deux actions étaient simultanées, nous ne pouvons pas isoler la part exacte de chacune. Le point établi reste entier : pendant six jours, la seule présence dans le fichier n’a pas suffi à faire découvrir des pages sans liens. Notre conclusion tient en une phrase : le sitemap déclare, le maillage fait découvrir.
C’est la raison pour laquelle nos audits techniques croisent le contenu du fichier avec le graphe de liens internes : une URL déclarée mais orpheline est un signal faible, quel que soit le CMS. Le sujet dépasse le fichier lui-même et rejoint les fondamentaux du SEO technique : crawlabilité, indexabilité, architecture.
Fichier d’index et sous-sitemaps
Dès qu’un site dépasse les limites du protocole, ou dès qu’on veut segmenter le suivi par type de contenu, on passe à un fichier d’index qui référence plusieurs fichiers segmentés. Le protocole autorise jusqu’à 50 000 entrées par index ; Search Console accepte jusqu’à 500 fichiers d’index par propriété. Contrainte posée par Google : les fichiers référencés doivent être hébergés sur le même site que l’index.
La segmentation a une vertu de diagnostic. Dans Search Console, chaque segment affiche son propre ratio entre URLs découvertes et URLs indexées. Un segment « articles » presque entièrement indexé à côté d’un segment « produits » indexé à moitié localise le problème en une lecture, sans crawler quoi que ce soit.
Un piège rencontré sur notre propre installation : l’adresse /sitemap.xml répondait en 301 vers /sitemap_index.xml, et c’était l’URL en redirection qui avait été soumise. Tant que la soumission pointait vers la redirection, le rapport restait brouillé et la découverte s’en trouvait affaiblie. Depuis, notre règle est de soumettre l’URL finale, celle qui répond en 200, et de vérifier ce code de réponse à chaque audit.
lastmod : l’utiliser honnêtement
La position officielle de Google tient en une condition : « Google uses the lastmod value if it’s consistently and verifiably accurate ». Autrement dit, un lastmod mensonger n’est pas pénalisé, il est ignoré. Si votre CMS tamponne la date du jour sur toutes les URLs à chaque régénération du fichier, la valeur devient invérifiable et perd tout effet. Vous éteignez vous-même le seul attribut optionnel que Google exploite encore.
Le levier a pris de la valeur depuis que Google a annoncé, en juin 2023, le retrait de son endpoint de ping : il n’existe plus de mécanisme pour signaler chaque mise à jour. Restent la relecture régulière du fichier, guidée par lastmod, et la demande d’indexation manuelle dans Search Console. Sur un site volumineux, un lastmod fiable aide Googlebot à concentrer ses passages sur ce qui a changé : un enjeu direct de budget de crawl.
Notre pratique d’agence : lastmod reflète la dernière modification significative du contenu, pas la régénération technique du fichier ni le changement d’un widget de footer. Une virgule corrigée ne justifie pas une nouvelle date.
Les erreurs que nous relevons en audit
En audit, les mêmes défauts reviennent d’un site à l’autre, tous CMS confondus :
- Un fichier gelé par un cache. Sur notre propre site, en juin 2026, le fichier généré par le plugin SEO était resté figé à 68 URLs alors que le site en comptait 111 : le cache du plugin ne se régénérait plus. Quarante-trois pages n’étaient déclarées nulle part, sans aucun message d’erreur visible.
- Des URLs en redirection ou en erreur. Chaque entrée en 301 ou en 404 dépense du crawl pour rien et dégrade la fiabilité perçue du fichier.
- Des pages noindex ou non canoniques déclarées. Le fichier dit « indexe-moi », la balise dit le contraire : un signal contradictoire que Google tranche seul, rarement dans le sens espéré.
- Le fichier absent du robots.txt. La directive
Sitemap:dans le robots.txt reste le moyen le plus simple de déclarer le fichier à tous les moteurs, pas seulement à Google. - Des URLs de préproduction ou à paramètres. Un environnement de staging qui fuit dans le fichier de production expose des doublons complets du site.
- La déclaration exhaustive par défaut. Tout lister, y compris pages de filtres et archives vides, dilue la lecture que Google fait de vos priorités. Ce fichier est une liste de pages qui méritent l’index, pas un export de base de données.
Le contrôle croisé entre fichier, crawl réel et couverture Search Console fait partie de notre audit SEO standard : chaque écart entre les trois raconte un problème différent.
Questions fréquentes
Faut-il déclarer toutes les pages du site dans le sitemap ?
Non. Déclarez les URLs canoniques, indexables et répondant en 200 que vous voulez voir en résultats de recherche. Pages de filtres, archives pauvres, doublons et pages utilitaires n’y ont pas leur place : leur présence dilue la lecture que Google fait de vos priorités.
À quelle fréquence mettre à jour le fichier ?
À chaque publication, modification ou suppression de page. Sur la plupart des CMS, le fichier est généré dynamiquement et se met à jour seul. Vérifiez tout de même qu’aucun cache ne le fige, en comparant son nombre d’URLs au nombre réel de pages publiées.
Comment vérifier que Google lit mon sitemap ?
Ouvrez le rapport Sitemaps de Search Console : il affiche la date de dernière lecture et le nombre d’URLs découvertes par fichier. Pour une page précise, l’outil d’inspection d’URL indique si elle a été repérée via le sitemap, via des liens, ou pas du tout.
Un sitemap HTML sert-il encore en SEO ?
Peu. La page « plan du site » destinée aux visiteurs peut aider la navigation d’un très gros site, mais elle ne remplace ni le fichier XML ni un maillage interne construit. Si vos pages ont besoin d’un sitemap HTML pour être trouvées, le problème est le maillage.
Existe-t-il des sitemaps pour les images, vidéos et actualités ?
Oui. Google accepte des extensions dédiées aux images, aux vidéos et à Google News, avec des balises propres à chaque média. Elles se justifient quand ces contenus portent un enjeu de trafic autonome : un média vidéo ou un site d’actualité, plus rarement un site B2B classique.
Article rédigé par Yonel Sasson, Getknown, agence SEO et GEO.