Les balises du sitemap XML expliquées

Le format sitemap est décrit par le protocole sitemaps.org, adopté conjointement par Google, Bing et Yahoo! en 2006 et inchangé depuis. Il tient en une poignée de balises, mais toutes n'ont pas le même poids : certaines sont obligatoires, d'autres facultatives, et deux d'entre elles sont aujourd'hui purement décoratives. Voici ce que chacune fait réellement.

Sur cette page :

La structure minimale d'un sitemap

Un sitemap valide est un fichier XML encodé en UTF-8, dont l'élément racine est <urlset> et qui porte obligatoirement l'espace de noms du protocole. Voici le fichier le plus court qui soit accepté par tous les moteurs :

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.mon-site.fr/</loc>
  </url>
  <url>
    <loc>https://www.mon-site.fr/contact.html</loc>
  </url>
</urlset>

L'attribut xmlns n'est pas décoratif : sans lui, le fichier est rejeté même s'il est parfaitement formé. Chaque page occupe un bloc <url>, et chaque bloc contient exactement une balise <loc>. Tout le reste est facultatif.

<loc> : l'adresse de la page

C'est la seule balise obligatoire, et la seule qui compte vraiment. Elle doit contenir une adresse absolue, commençant par http:// ou https://, appartenant au même domaine que le fichier sitemap lui-même, et pointant vers la version canonique de la page.

Quatre règles à respecter :

<lastmod> : la date de dernière modification

Facultative, mais c'est la seule balise optionnelle qui serve encore à quelque chose. Google a confirmé s'appuyer sur <lastmod> pour prioriser ses passages — à condition qu'elle soit honnête. Un sitemap dont toutes les pages affichent la date du jour à chaque génération est vite considéré comme non fiable, et la balise est alors purement et simplement ignorée pour l'ensemble du site.

Le format attendu est celui de la norme W3C Datetime, un sous-ensemble strict de l'ISO 8601. Les deux écritures suivantes sont acceptées :

<lastmod>2026-08-21</lastmod>
<lastmod>2026-08-21T14:30:00+02:00</lastmod>

Les formats français (21/08/2026) ou américains (08-21-2026) sont invalides. Renseignez cette balise uniquement si votre système sait vraiment quand chaque page a changé pour la dernière fois ; sinon, mieux vaut l'omettre.

<changefreq> et <priority> : les balises ignorées

Ces deux balises font partie du protocole d'origine et se retrouvent encore dans la quasi-totalité des sitemaps générés automatiquement. La réalité est plus simple qu'il n'y paraît : Google les ignore complètement. Ce n'est pas une rumeur de forum : c'est écrit noir sur blanc dans la documentation officielle de Google Search Central. Bing tient un discours équivalent.

<changefreq>weekly</changefreq>   <!-- ignorée -->
<priority>0.8</priority>          <!-- ignorée -->

La raison est facile à comprendre : ces valeurs sont déclaratives et invérifiables. Tout le monde ayant fini par déclarer ses pages en daily et en priority 1.0, l'information a perdu tout pouvoir discriminant. Les valeurs admises pour changefreq restent always, hourly, daily, weekly, monthly, yearly et never ; priority accepte une valeur entre 0.0 et 1.0, avec 0.5 par défaut.

Faut-il les retirer ? Ce n'est pas nécessaire : leur présence n'est pas pénalisante. Mais ne perdez pas de temps à les affiner, et ne comptez pas dessus pour faire remonter une page.

L'index de sitemaps

Quand un site dépasse les limites d'un fichier unique, ou quand on souhaite simplement séparer les rubriques, on utilise un index de sitemaps : un fichier qui ne liste pas des pages, mais d'autres fichiers sitemap. Sa racine est <sitemapindex> et chaque entrée est un bloc <sitemap> :

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.mon-site.fr/sitemap-articles.xml</loc>
    <lastmod>2026-08-21</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.mon-site.fr/sitemap-produits.xml</loc>
    <lastmod>2026-08-19</lastmod>
  </sitemap>
</sitemapindex>

Google détaille cette organisation dans sa page sur la gestion des sitemaps volumineux. C'est alors l'index que vous déclarez dans votre robots.txt et dans les outils pour webmasters : les moteurs suivent seuls les fichiers qu'il référence. Attention, un index ne peut pas en contenir un autre : le protocole n'autorise qu'un seul niveau d'imbrication. Découper ainsi présente un avantage pratique appréciable : la Search Console vous indique le taux d'indexation fichier par fichier, ce qui permet de repérer immédiatement quelle rubrique du site pose problème.

Les limites du protocole

ContrainteValeur
URL par fichier sitemap50 000 maximum
Poids du fichier décompressé50 Mo maximum
Sitemaps par index50 000 maximum
Niveaux d'index imbriqués1 seul
EncodageUTF-8 obligatoire
Compression acceptéegzip (.xml.gz)

La compression gzip est acceptée par tous les moteurs et divise typiquement le poids par dix sur un gros fichier. Attention : c'est bien la taille décompressée qui est plafonnée à 50 Mo. Notez enfin qu'un sitemap ne peut déclarer que des adresses situées au même niveau ou en dessous de son propre emplacement : un fichier placé dans /blog/sitemap.xml ne peut pas lister des pages de /boutique/. C'est la raison pour laquelle on place presque toujours le sitemap à la racine du site.

Sitemaps images, vidéos, actualités et hreflang

Le protocole admet des extensions, déclarées par un espace de noms supplémentaire sur l'élément <urlset>. La plus courante concerne les images :

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://www.mon-site.fr/galerie.html</loc>
    <image:image>
      <image:loc>https://www.mon-site.fr/img/photo.jpg</image:loc>
    </image:image>
  </url>
</urlset>

Elle n'a d'intérêt que si vos images sont chargées en JavaScript ou hébergées sur un autre domaine ; sinon, les robots les découvrent très bien seuls dans le HTML. Il existe sur le même principe des extensions pour les vidéos, pour Google Actualités (réservée aux éditeurs agréés, et limitée aux articles de moins de deux jours), et une extension xhtml:link qui permet de déclarer les équivalences entre les versions linguistiques d'une même page. Cette dernière est utile pour les sites multilingues, mais elle alourdit considérablement le fichier : les balises hreflang dans le <head> des pages font le même travail plus simplement.

Les cinq erreurs les plus fréquentes

  1. L'esperluette non échappée. De très loin la première cause de sitemap invalide. Dans une balise <loc>, une adresse contenant ?page=1&tri=date doit s'écrire ?page=1&amp;tri=date. Un seul caractère oublié rend l'intégralité du fichier illisible. Les cinq caractères à échapper sont &, <, >, " et '.
  2. L'espace de noms manquant. Un <urlset> sans son attribut xmlns est refusé sans autre explication qu'un laconique « format non pris en charge ».
  3. Des pages mortes dans le fichier. Un sitemap généré une fois puis jamais mis à jour finit par pointer vers des pages supprimées. C'est du budget d'exploration gaspillé, et la Search Console le signale.
  4. Des adresses non canoniques. Lister http://mon-site.fr/page alors que le site répond en https://www.mon-site.fr/page ajoute une redirection à chaque visite du robot et dilue les signaux.
  5. Un sitemap déclaré mais absent. Cas particulièrement sournois quand une règle de réécriture renvoie la page d'accueil pour toute adresse inexistante : le fichier semble exister dans le navigateur, mais le serveur envoie du HTML au lieu du XML.

Ces cinq points sont exactement ceux que contrôle notre outil de vérification, sur votre fichier réel.

Vérifier mon sitemap

Pour aller plus loin

Les références officielles, si vous voulez remonter à la source :

Et sur notre site :