Bonnes pratiques du sitemap XML (et ce qui les casse silencieusement)

Les bonnes pratiques du sitemap XML se résument à une règle : le sitemap doit lister les URL canoniques et indexables que vous voulez faire découvrir aux moteurs de recherche, et rien d'autre. Un sitemap propre aide Google à découvrir et à réexplorer les pages importantes. Un sitemap négligé lui envoie des redirections, des 404 et des URL que vous n'avez jamais voulu voir indexées, ce qui affaiblit le signal de tout le fichier.

Les règles elles-mêmes sont simples. Le plus difficile, c'est qu'un sitemap est produit par un logiciel, et qu'une mise à jour d'extension ou un déploiement peut rendre faux un sitemap correct sans que personne ne s'en aperçoive.

À quoi sert un sitemap, et à quoi il ne sert pas

Un sitemap est une aide à la découverte. Il aide les moteurs à trouver des pages, surtout sur les grands sites, les sites récents et les pages peu liées en interne. Ce n'est pas un facteur de positionnement, et lister une URL n'oblige pas Google à l'indexer.

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://example.com/services/seo/</loc>
    <lastmod>2026-08-02</lastmod>
  </url>
</urlset>

C'est presque tout ce que Google lit. Google a indiqué qu'il ignore <priority> et <changefreq>, et qu'il n'utilise <lastmod> que lorsque la valeur est systématiquement exacte. Passer du temps à régler les valeurs de priorité n'apporte donc rien côté Google.

Les bonnes pratiques du sitemap XML à faire respecter

N'incluez que des URL qui renvoient un 200, sont canoniques d'elles-mêmes et ne portent pas de noindex. Si une page ne doit pas être indexée, elle n'a rien à faire dans le sitemap. Les URL qui redirigent et les 404 sont les pollutions les plus fréquentes ; elles apparaissent en général quand du contenu est déplacé ou supprimé alors que le générateur conserve une ancienne liste.

Utilisez des URL absolues, avec le même protocole et le même hôte que le sitemap. Un sitemap situé sur https://www.example.com/ ne doit pas lister d'URL en http://example.com/. Le fichier doit être encodé en UTF-8, et les caractères comme & dans les URL doivent être échappés en &.

Gardez un lastmod honnête. Il doit changer quand le contenu principal de la page change, pas à chaque reconstruction du site. Si une plateforme appose chaque nuit la date du jour sur toutes les URL, la valeur n'apprend rien à Google, qui finira par l'ignorer.

Respectez les limites. Un fichier sitemap peut contenir jusqu'à 50 000 URL et 50 Mo non compressé. Les sites plus grands répartissent leurs URL sur plusieurs fichiers, souvent par type de contenu, et les listent dans un index de sitemaps. Découper par type facilite aussi la localisation des problèmes, puisque vous voyez quel sitemap enfant a perdu des URL. Les fichiers peuvent être compressés en gzip, mais la limite de 50 Mo s'applique à la taille non compressée.

Rendez-le facile à trouver. Ajoutez une ligne Sitemap: https://example.com/sitemap_index.xml au robots.txt, et soumettez le sitemap dans le rapport Sitemaps de la Search Console ainsi que dans Bing Webmaster Tools. Google a supprimé en 2023 son point d'accès « ping » pour les sitemaps : la soumission et la ligne dans le robots.txt sont les voies qui restent. Notre guide comment vérifier votre robots.txt couvre le reste de ce fichier.

Qui génère le fichier

Connaître le générateur vous dit ce qui peut modifier le sitemap. Depuis WordPress 5.5, le cœur de WordPress produit un sitemap basique sur /wp-sitemap.xml. Yoast SEO et Rank Math le désactivent et servent le leur sur /sitemap_index.xml, piloté par des réglages par type de contenu, si bien que désactiver un type dans l'extension retire toutes ses URL d'un coup. Shopify génère /sitemap.xml automatiquement et ne permet pas de le modifier directement. Les sites headless et statiques le construisent en général au moment du déploiement, et un changement de configuration du build peut donc le modifier.

Comment un sitemap valide se dérègle

Problème	Déclencheur typique	Comment il se manifeste
URL indésirables listées	L'extension se met à inclure les archives de tags, les pages de fichiers joints ou des pages en noindex	Le rapport Indexation des pages se remplit d'URL exclues issues du sitemap
Vraies URL manquantes	Générateur réinitialisé lors d'un déploiement ou d'une migration, type de contenu désactivé	Le nombre d'URL découvertes baisse dans le rapport Sitemaps
lastmod sans signification	Toutes les URL redatées à chaque build	Toutes les entrées partagent la même date récente
Ancien sitemap encore référencé	Chemin du sitemap modifié, robots.txt pas mis à jour	La Search Console signale une erreur de récupération ou un fichier périmé
Fichier en cache	Un CDN ou une extension de cache sert une ancienne version	Le sitemap ne reflète pas des pages publiées il y a plusieurs jours

Aucun de ces problèmes ne produit d'erreur sur le site. Le XML reste valide, et la différence n'apparaît que si quelqu'un compare le fichier avec sa version précédente.

Pourquoi les agences passent à côté de ces changements

Sur un site que vous maîtrisez, vous finiriez peut-être par le remarquer. Sur vingt sites clients où d'autres développeurs déploient, il y a rarement une raison d'ouvrir un sitemap un mardi ordinaire. La personne qui met à jour une extension ou fusionne une release ne pense pas au sitemap, et toute casse est donc un effet de bord. Le premier signe visible est en général une indexation plus lente des nouvelles pages, ou des pages qui sortent de l'index, des semaines plus tard.

Contrôler à la main, surveiller le reste

Un contrôle manuel est simple. Ouvrez le fichier, notez le nombre d'URL par sitemap enfant, vérifiez sur un échantillon d'URL le code de statut, le canonical et le noindex, et confirmez la ligne du robots.txt. Cela fonctionne bien sur les sites auxquels vous pensez.

Pour les autres, Deltio lit chaque jour le sitemap de chaque site client, le compare au contrôle précédent et vous alerte quand des URL sont ajoutées ou retirées. Il contrôle aussi les pages vers lesquelles pointent ces URL (noindex, canonicals, changements de title) et surveille le robots.txt, car un sitemap change rarement de façon isolée. Les alertes partent sur Slack et par email, par site, avec le nom du site et les URL concernées. Le contrôle étant quotidien, un changement est signalé au cycle suivant, pas au moment où il se produit. Le format de ces notifications est présenté dans les alertes de changement SEO.

Vous pouvez ajouter un site client en essai pendant 14 jours pour voir ce que contient son sitemap aujourd'hui.