Fichiers d'index de sitemaps : le guide complet
Quand un seul fichier ne suffit plus, l'index de sitemaps prend le relais. Structure, règles du protocole, exemple complet et pièges classiques.
Un fichier d'index de sitemaps est un sitemap de sitemaps : un document XML qui, au lieu de lister des pages, liste d'autres fichiers sitemap. Il devient obligatoire dès qu'un site dépasse 50 000 URL ou 50 Mo par fichier, et il est utile bien avant, pour organiser ses sitemaps par type de contenu, par langue ou par date.
Qu'est-ce qu'un <sitemapindex> ?
Le protocole sitemaps.org définit deux types de fichiers. Le sitemap classique a pour racine <urlset> et contient des entrées <url> pointant vers des pages. L'index a pour racine <sitemapindex> et contient des entrées <sitemap> pointant vers d'autres fichiers sitemap. Les deux partagent le même namespace et les mêmes règles de base : XML bien formé, URL absolues, caractères réservés échappés. Un robot qui lit un index récupère ensuite chaque fichier enfant et le traite comme un sitemap ordinaire.
Quand avez-vous besoin d'un index ?
Deux situations le justifient :
- Les limites du protocole. Un fichier sitemap est plafonné à 50 000 URL et 50 Mo non compressé. Au-delà, le découpage en plusieurs fichiers plus un index n'est pas une option, c'est la seule voie conforme.
- L'organisation. Même loin des limites, découper par type de contenu (sitemap-pages.xml, sitemap-blog.xml, sitemap-produits.xml), par langue ou par tranche de dates rend le diagnostic beaucoup plus fin : dans Search Console, chaque fichier enfant a ses propres statistiques, et un problème d'indexation se localise en un coup d'œil au lieu de se noyer dans un fichier unique.
Les grands CMS et générateurs de sites créent d'ailleurs un index par défaut, même pour des sites modestes — si votre sitemap.xml commence par <sitemapindex>, vous en utilisez déjà un.
Un exemple complet
Voici un index minimal et valide, avec deux sitemaps enfants :
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-pages.xml</loc>
<lastmod>2026-07-16</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-blog.xml</loc>
<lastmod>2026-07-10</lastmod>
</sitemap>
</sitemapindex>Chaque entrée <sitemap> exige un <loc> avec l'URL absolue du fichier enfant ; <lastmod> est optionnel mais recommandé, on y revient plus bas.
Les règles à respecter
- Un index peut référencer jusqu'à 50 000 sitemaps et ne doit pas dépasser 50 Mo non compressé — les mêmes plafonds qu'un sitemap ordinaire. À 50 000 URL par enfant, un seul index couvre en théorie 2,5 milliards de pages.
- Pas d'index imbriqué. Un index doit référencer des sitemaps de pages, jamais un autre index. Le protocole interdit les hiérarchies à plusieurs étages : si votre arborescence l'exige, aplatissez-la en un seul index.
- Le namespace est le même que pour un sitemap : xmlns="http://www.sitemaps.org/schemas/sitemap/0.9", copié à l'identique.
- Les sitemaps enfants doivent se trouver sur le même hôte que l'index, avec les mêmes règles www/non-www et http/https que pour les URL de pages.
- Un fichier ne peut pas mélanger les deux rôles : soit
<urlset>avec des pages, soit<sitemapindex>avec des sitemaps.
lastmod au niveau de l'index
Le <lastmod> d'une entrée d'index indique la date de dernière modification du fichier sitemap enfant, pas d'une page. Bien renseigné, il permet aux robots de ne re-télécharger que les enfants qui ont changé : sur un index de cinquante fichiers dont un seul bouge chaque jour, le gain est réel. Même exigence de sincérité que pour les pages : si tous les enfants affichent la date du jour en permanence, le signal ne vaut plus rien.
Ne soumettez que l'index
Dans Google Search Console comme dans Bing Webmaster Tools, soumettez uniquement l'URL de l'index. Les moteurs découvrent et lisent les enfants automatiquement, et Search Console affiche ensuite chaque fichier enfant avec ses propres statistiques sous l'entrée de l'index. Soumettre chaque enfant à la main n'apporte rien et encombre le rapport. Même logique dans robots.txt : une seule ligne Sitemap: pointant vers l'index suffit. La référence officielle du format se trouve sur sitemaps.org.
Comment un validateur vérifie un index
La validation se fait en deux temps. D'abord l'index lui-même : racine <sitemapindex>, namespace, URL absolues et bien formées, dates lastmod valides, absence d'index imbriqué. Ensuite les enfants : chaque fichier référencé doit exister, répondre en 200 et être lui-même un sitemap valide — un index impeccable qui pointe vers des fichiers cassés ne sert à rien. Notre validateur de sitemap procède exactement ainsi : il valide l'index, liste les enfants trouvés et vous laisse lancer la validation de chacun en un clic.
Les erreurs d'index les plus courantes
| Erreur | Conséquence | Correction |
|---|---|---|
| Index imbriqué dans un index | Interdit par le protocole ; les enfants du second niveau sont ignorés | Aplatir : un seul index, tous les sitemaps au même niveau |
| Enfant en 404 ou qui redirige | Section entière du site non explorée | Mettre l'index à jour à chaque ajout ou suppression de fichier |
| Pages listées directement dans l'index | Entrées ignorées : un index ne référence que des sitemaps | Déplacer les URL de pages vers un sitemap enfant |
| URL relatives dans <loc> | Entrées invalides | URL absolues, schéma compris |
| Enfants sur un autre hôte ou schéma | Fichiers ignorés | Aligner index et enfants sur l'hôte canonique |
| Index figé après un changement de génération | Il liste des fichiers supprimés et ignore les nouveaux | Régénérer l'index en même temps que les enfants |
En résumé
L'index de sitemaps est un format simple avec peu de règles : un niveau de profondeur maximum, 50 000 enfants au plus, des URL absolues sur le bon hôte, un lastmod honnête, et une seule soumission — celle de l'index. Le piège le plus fréquent n'est pas dans l'index lui-même mais dans ses enfants ; validez l'ensemble, de la racine jusqu'au dernier fichier, avant de le soumettre.