La différence entre un index de sitemap et un sitemap se résume à une fonction distincte pour chacun. Un sitemap.xml classique est une liste plate de vos URL de pages réelles. Un index de sitemap est une liste de sitemaps, pas de pages. Lorsqu'un site dépasse 50 000 URL ou une taille de fichier non compressé de 50 Mo, un seul sitemap.xml n'est plus valide et vous devez répartir vos URL sur plusieurs fichiers sitemap qu'un fichier d'index référence. Ce guide couvre exactement quand ce basculement est obligatoire, la syntaxe précise, comment segmenter logiquement un grand site et comment soumettre l'index à Google pour un crawl efficace.
La plupart des pages sur ce sujet s'arrêtent à la spécification en une ligne de Google ("50 000 URL et 50 Mo par fichier") et vous laissent vous débrouiller avec le reste. Les questions pratiques auxquelles personne ne répond sont : comment diviser, à quoi ressemble réellement le fichier d'index et où placer les sitemaps hreflang et d'images. C'est le vide que cet article comble.
Sitemap Index vs Sitemap : la différence fondamentale#
Un sitemap et un sitemap index sont deux types de fichiers différents qui utilisent deux éléments racines différents. Les confondre est l'erreur la plus courante, et les moteurs de recherche rejetteront le fichier si vous les imbriquez mal.
- Un sitemap utilise l'élément racine
<urlset>et contient des entrées<url>. Chaque entrée correspond à une page réelle et indexable de votre site. - Un sitemap index utilise l'élément racine
<sitemapindex>et contient des entrées<sitemap>. Chaque entrée pointe vers l'emplacement d'un autre fichier sitemap, pas vers une page.
Considérez l'index comme une table des matières. Il ne liste pas directement vos articles ou pages produits. Il liste les fichiers sitemap plus petits, et chacun de ceux-ci liste les pages. Les moteurs de recherche récupèrent d'abord l'index, puis explorent chaque sitemap enfant qu'il référence.
Règle clé : un sitemap index ne peut pointer que vers des sitemaps. Vous ne pouvez pas mettre des URL de pages et des URL de sitemaps enfants dans le même fichier. Mélanger les deux éléments racines est invalide et échouera à la validation dans Search Console.
Pourquoi la structure à deux niveaux existe#
La raison d'être de cette structure est la limite stricte d'un seul fichier. Le protocole sitemaps.org (et Google, Bing, et les autres le suivent) plafonne tout sitemap à :
- 50 000 URL maximum par fichier.
- 50 Mo non compressé maximum par fichier.
Atteignez l'une ou l'autre limite et le fichier n'est plus conforme. Les grands sites dépassent constamment les 50 000 URL, donc le protocole vous permet de publier plusieurs fichiers sitemap et de les relier avec un seul index. Un seul sitemap index peut lui-même référencer jusqu'à 50 000 sitemaps, ce qui signifie que le plafond théorique est de 50 000 x 50 000 = 2,5 milliards d'URL. Vous manquerez de pages bien avant de manquer de capacité de sitemap.
Quand passer d'un sitemap unique à un index de sitemaps#
Le passage n'est pas un choix de style. Il est imposé par des limites, et il y a trois déclencheurs. Le premier que vous atteignez décide de la question.
| Déclencheur | La limite | Ce qui se passe si vous l'ignorez |
|---|---|---|
| Nombre d'URL | Plus de 50 000 URL dans un seul fichier | Les moteurs de recherche s'arrêtent à la limite ; les URL supplémentaires sont ignorées silencieusement |
| Taille du fichier | Plus de 50 Mo non compressé | Le fichier est rejeté comme invalide ; rien dedans n'est exploré de manière fiable |
| Organisation logique | Pas de limite stricte, mais utile au-delà de quelques milliers d'URL | Plus difficile de déboguer les problèmes d'exploration et de lire les rapports de couverture par section |
Voici l'interprétation pratique de chacun.
Le nombre d'URL est la raison la plus courante. Avec plus de 50 000 URL publiées et indexables, vous devez diviser. Il n'y a pas de paramètre à activer ni de quota à augmenter. Soit vous divisez en plusieurs sitemaps sous un index, soit les URL au-delà de 50 000 ne sont jamais soumises.
La taille du fichier concerne les sites avec des URL longues. Vous pouvez atteindre la limite de 50 Mo avant 50 000 URL si vos URL sont très longues, ou si vous incluez beaucoup d'entrées <image:image> et <xhtml:link> (hreflang) par URL. Chaque élément supplémentaire ajoute des octets, et les sites multilingues avec des annotations hreflang gonflent rapidement.
L'organisation logique est la raison sous-estimée. Même à 8 000 URL, diviser en sitemaps thématiques est judicieux. Lorsque Search Console signale des problèmes d'indexation pour un sitemap, une division par section vous indique immédiatement si le problème vient de votre blog, de vos produits ou de vos pages catégories. Un fichier géant ne vous apprend rien.
Astuce pratique : si vous approchez des 40 000 URL, construisez la structure d'index maintenant plutôt qu'après avoir dépassé les 50 000. Adapter sous pression lorsque des pages disparaissent de l'index est bien plus stressant que de la mettre en place tôt.
La syntaxe exacte de l'index de sitemap (avec exemple)#
Voici ce que les fiches techniques succinctes omettent. Un index de sitemap est un petit fichier XML. Voici un exemple complet et valide pointant vers trois 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-posts.xml</loc>
<lastmod>2026-06-25T09:00:00+00:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-06-24T14:30:00+00:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-pages.xml</loc>
<lastmod>2026-06-20T08:15:00+00:00</lastmod>
</sitemap>
</sitemapindex>
Trois détails sont importants ici.
<loc>doit être une URL absolue. Utilisez le chemin complethttps://example.com/..., pas un chemin relatif/sitemap-posts.xml. Les URL relatives sont invalides dans les sitemaps.<lastmod>est le seul autre enfant autorisé. Chaque entrée<sitemap>accepte<loc>et optionnellement<lastmod>. Il n'y a pas de<changefreq>ou<priority>au niveau de l'index (Google les ignore même dans les sitemaps classiques).<lastmod>doit être honnête. Définissez-le à la date la plus récente où une URL de ce sitemap enfant a réellement changé. Un<lastmod>qui indique toujours "aujourd'hui" habitue les robots à l'ignorer, tandis qu'une valeur précise aide un robot à décider quels sitemaps enfants récupérer en premier.
Chaque sitemap enfant est simplement un fichier <urlset> normal :
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/blog/first-post</loc>
<lastmod>2026-06-25T09:00:00+00:00</lastmod>
</url>
<url>
<loc>https://example.com/blog/second-post</loc>
<lastmod>2026-06-22T11:00:00+00:00</lastmod>
</url>
</urlset>
Vous pouvez les éditer manuellement pour un petit site, mais pour quelque chose de sérieux, vous les générez. Un générateur de sitemap XML gratuit gère le découpage, le fichier d'index et le formatage des URL absolues pour éviter une faute de frappe qui casserait silencieusement le crawl.
Comment diviser logiquement un grand site#
Vous pouvez diviser arbitrairement ("URLs 1 à 50 000 ici, 50 001 à 100 000 là"), mais c'est une occasion manquée. Diviser par section ou type de contenu fait de vos sitemaps un outil de diagnostic, pas seulement une case à cocher de conformité.
Diviser par type de contenu ou section#
Le modèle le plus propre est un sitemap par groupe logique, tous référencés par un seul index :
sitemap-posts.xmlpour les URLs de blog ou d'articlessitemap-products.xmlpour les pages produits ou de listingsitemap-categories.xmlpour les pages de taxonomie et catégoriessitemap-pages.xmlpour les pages statiques (à propos, contact, mentions légales)
Ainsi, quand Search Console indique "sitemap-products.xml : 4 200 soumises, 3 100 indexées", vous savez exactement où enquêter. Avec un fichier monolithique, vous sauriez seulement que quelque chose, quelque part, n'est pas indexé.
Garder chaque sitemap enfant bien en dessous de la limite#
Ne remplissez pas chaque fichier enfant jusqu'à 49 999 URLs. Visez quelques milliers jusqu'à environ 10 000 à 20 000 URLs chacun. Les fichiers plus petits sont plus rapides à récupérer et à re-récupérer quand une seule section change, et ils vous maintiennent en sécurité sous le plafond de 50 Mo à mesure que les URLs augmentent.
Choisir entre sitemaps séparés et combinés#
Vous avez le choix entre des sitemaps spécialisés dédiés et la combinaison de tout par URL.
| Approche | Quand l'utiliser | Compromis |
|---|---|---|
| Combiner images et hreflang dans les sitemaps d'URL principaux | La plupart des sites | Structure plus simple ; surveiller la limite de 50 Mo |
| Sitemap d'images séparé | Sites riches en images (galeries, stock, ecommerce) | Rapports plus clairs sur l'indexation des images, mais plus de fichiers à maintenir |
| Gestion hreflang/langue séparée | Grands sites multilingues | Évite de gonfler un fichier ; nécessite des annotations réciproques |
Pour la plupart des sites, moins de fichiers est préférable. Optez pour des sitemaps spécialisés séparés uniquement lorsqu'une section est assez grande pour que la combinaison pousse un fichier vers la limite de taille ou brouille vos rapports.
Où placer les sitemaps hreflang et images dans un index#
C'est l'élément que presque aucun article concurrent n'aborde, et qui pose problème sur les grands sites internationaux et riches en médias.
Hreflang dans un index de sitemap#
Les annotations hreflang se trouvent dans les entrées <url> d'un sitemap standard, via l'élément xhtml:link. Elles ne modifient pas le fichier d'index. L'index liste simplement les sitemaps enfants. Un sitemap enfant avec hreflang ressemble à ceci :
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/page</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/page"/>
<xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/page"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page"/>
</url>
</urlset>
Deux choses à retenir. D'abord, les annotations hreflang doivent être réciproques : si la page anglaise pointe vers la version espagnole, la page espagnole doit pointer vers l'anglaise. Ensuite, chaque xhtml:link ajoute des octets, donc les sitemaps avec beaucoup de hreflang atteignent la limite de 50 Mo avec bien moins de 50 000 URLs. C'est précisément le cas où il devient nécessaire de diviser en plusieurs sitemaps enfants sous un même index, même avec un nombre d'URLs modeste.
Sitemaps images dans un index#
Les entrées images se trouvent aussi dans le bloc <url> de la page, via l'espace de noms image:image, et non dans l'index. Vous pouvez soit attacher les images aux URLs de vos sitemaps principaux, soit créer un sitemap image dédié et l'ajouter comme entrée <sitemap> supplémentaire dans l'index.
Pour un site avec des milliers d'images par section, un sitemap image séparé allège vos sitemaps principaux et offre une ligne claire dans Search Console pour l'indexation des images. Pour tout le reste, attacher les images aux entrées d'URLs existantes est plus simple et fonctionne très bien.
Comment soumettre un index de sitemap à Google#
Une fois votre index créé, vous ne soumettez qu'une seule chose : le fichier d'index. Vous ne soumettez pas chaque sitemap enfant séparément. Google découvre les enfants en lisant l'index.
Étape 1 : Référencer l'index dans robots.txt#
Ajoutez une ligne Sitemap: dans votre robots.txt pointant vers l'URL absolue du fichier d'index. Cela permet à tout robot d'exploration de le découvrir, pas seulement Google.
Sitemap: https://example.com/sitemap-index.xml
Vous pouvez lister plusieurs lignes Sitemap: si nécessaire, mais avec un index correct, une seule suffit. Si vous devez également contrôler les chemins accessibles aux robots, générez un fichier propre avec un générateur robots.txt gratuit pour que les directives et la référence au sitemap soient correctement formatées.
Étape 2 : Soumettre l'index dans Google Search Console#
Dans Search Console, ouvrez le rapport Sitemaps pour votre propriété et saisissez le chemin vers votre fichier d'index (par exemple, sitemap-index.xml). Soumettez-le. Google lit l'index, puis met en file d'attente chaque sitemap enfant. Vous verrez l'index listé, et dans les jours suivants, les comptes de découverte et d'indexation par sitemap se rempliront.
Étape 3 : Vérifier que chaque sitemap enfant a été lu#
Après que Google a traité l'index, le rapport Sitemaps affiche chaque sitemap enfant référencé. Confirmez que les nombres d'URL soumises correspondent à ce que vous attendez par section. Si un sitemap enfant affiche zéro URL ou une erreur, ce fichier a un problème (une mauvaise balise <loc>, une erreur de syntaxe ou un dépassement de taille) et vous corrigez ce seul fichier plutôt que toute la structure.
Étape 4 : Surveiller et maintenir lastmod à jour#
Une fois l'index en place, une nouvelle soumission est rarement nécessaire. Google récupère l'index et les sitemaps enfants selon son propre calendrier. La chose la plus utile que vous puissiez faire est de maintenir <lastmod> à jour, à la fois dans les entrées de l'index et dans les sitemaps enfants, afin que les robots priorisent les sections qui ont réellement changé. Pendant que vous optimisez les signaux SEO techniques, il est intéressant d'associer votre sitemap à des données structurées : notre générateur de balisage schema aide vos pages clés à obtenir des résultats enrichis une fois explorées.
Erreurs courantes à éviter avec un index de sitemap#
Quelques erreurs sont responsables de la plupart des sitemaps de grands sites défectueux.
- Imbriquer un index dans un autre index. Un index de sitemap ne peut pas pointer vers un autre index de sitemap, uniquement vers des sitemaps classiques. Un seul niveau d'indexation est autorisé.
- Mélanger les entrées
<url>et<sitemap>. Un fichier est soit un<urlset>soit un<sitemapindex>, jamais les deux. - URLs relatives dans
<loc>. Toujours absolues, toujours avec le bon protocole et le bon hôte. - Lister la même URL dans plusieurs sitemaps enfants. Chaque URL doit apparaître une seule fois dans l'ensemble. Les doublons gaspillent le budget de crawl et faussent les rapports.
- Soumettre les sitemaps enfants individuellement après avoir soumis l'index. Redondant, cela encombre votre rapport Sitemaps. Soumettez uniquement l'index.
Le verdict sur sitemap index vs sitemap#
Le choix entre sitemap index et sitemap dépend de votre nombre d'URLs et de la taille du fichier, pas d'une préférence. En dessous de 50 000 URLs et 50 Mo, un seul fichier sitemap.xml suffit. Si vous dépassez l'une de ces limites, vous devez répartir vos pages entre plusieurs sitemaps enfants liés par un seul fichier <sitemapindex>, puis soumettre uniquement cet index à Google.
Bien fait, cette répartition va au-delà de la simple conformité. Découper par section transforme vos sitemaps en tableau de bord de l'exploration, maintient les fichiers hreflang et ceux riches en images sous le plafond de taille, et vous indique précisément où se situent les problèmes d'indexation. Si vous préférez ne pas écrire une seule ligne de XML, un générateur de sitemap XML gratuit construit l'index et les fichiers enfants, formate les URLs absolues et vous évite les fautes de frappe qui, silencieusement, brisent l'exploration d'un grand site.
Foire aux questions#
Quelle est la différence entre un sitemap et un index de sitemap ?
Un sitemap (<urlset>) liste les URL réelles des pages de votre site. Un index de sitemap (<sitemapindex>) liste d'autres fichiers sitemap, pas des pages. Les moteurs de recherche lisent d'abord l'index, puis explorent chaque sitemap enfant qu'il référence. Vous utilisez un index lorsque vous avez plus de fichiers sitemap qu'un seul ne peut en contenir.
Quand ai-je besoin d'un index de sitemap au lieu d'un seul sitemap.xml ? Vous devez basculer lorsqu'un seul fichier dépasse 50 000 URL ou 50 Mo non compressé, selon la première limite atteinte. Les sites multilingues avec hreflang ou les sites riches en images peuvent atteindre la limite de 50 Mo bien avant 50 000 URL. De nombreuses équipes divisent également plus tôt, autour de quelques milliers d'URL, simplement pour un reporting plus propre par section dans Search Console.
Un index de sitemap peut-il pointer vers un autre index de sitemap ?
Non. Un index de sitemap ne peut référencer que des sitemaps réguliers (fichiers <urlset>), pas d'autres fichiers d'index. Vous n'avez qu'un seul niveau d'indexation. Si vous devez organiser plusieurs sitemaps, regroupez-les logiquement sous un seul index plutôt que d'essayer d'imbriquer des index.
Combien d'URL un index de sitemap peut-il gérer au total ? Un seul index de sitemap peut référencer jusqu'à 50 000 sitemaps enfants, et chaque sitemap enfant peut contenir jusqu'à 50 000 URL. Cela donne un plafond d'environ 2,5 milliards d'URL pour un seul index, ce qui est bien plus que ce dont un site réel a besoin.
Dois-je soumettre chaque sitemap enfant à Google ou seulement l'index ? Soumettez uniquement le fichier d'index dans Google Search Console et référencez-le une fois dans robots.txt. Google lit l'index et découvre automatiquement tous les sitemaps enfants. Soumettre les sitemaps enfants individuellement est redondant et ne fait qu'encombrer votre rapport Sitemaps.
Où placer les entrées hreflang et image dans un index de sitemap ?
Elles ne vont jamais dans le fichier d'index lui-même. Les annotations hreflang (xhtml:link) et image (image:image) se trouvent dans les entrées <url> des sitemaps enfants réguliers. L'index ne liste que les emplacements des sitemaps enfants. Comme ces annotations augmentent la taille du fichier, les sitemaps enfants avec beaucoup de hreflang ou d'images atteignent la limite de 50 Mo avec moins d'URL, ce qui est souvent la raison pour laquelle vous divisez.
