Quelles sont les limites techniques réelles des fichiers sitemap XML ?

Pourquoi ces limites de 50 Mo et 50 000 URL existent-elles ?

Ces contraintes techniques ne sont pas arbitraires — elles répondent à des impératifs de traitement serveur chez Google. Un fichier sitemap surdimensionné ralentit le parsing, monopolise des ressources et peut même échouer en timeout lors du traitement.

La limite de 50 000 URL s'explique par la nécessité de découper le crawl en chunks gérables. Celle de 50 Mo cible les cas où les URL sont particulièrement longues ou accompagnées de nombreuses métadonnées (images, videos, alternates hreflang).

Ces limites s'appliquent-elles de manière cumulative ou alternative ?

C'est un OU exclusif, pas un ET. Dès que l'une des deux limites est atteinte — que ce soit 50 000 URL ou 50 Mo — Google cessera de traiter le reste du fichier. Sur un site e-commerce avec des URL longues et des balises image pour chaque produit, vous pouvez atteindre 50 Mo bien avant 50 000 URL.

L'inverse est vrai pour des sites avec des URL courtes et peu de métadonnées : vous plafonnez à 50 000 URL alors que le poids reste sous 20 Mo. Comprendre où se situe votre goulot d'étranglement est crucial pour structurer vos sitemaps correctement.

Que se passe-t-il concrètement si on dépasse ces seuils ?

Google tronque le fichier au moment où la limite est atteinte. Les URL situées après ce point ne seront tout simplement pas découvertes via le sitemap. Aucune erreur explicite n'apparaîtra forcément dans la Search Console — le fichier sera marqué comme traité, mais partiellement.

Résultat : des pages stratégiques peuvent rester hors crawl si elles se trouvent en fin de fichier. C'est un piège classique sur les sites qui génèrent automatiquement leurs sitemaps sans vérifier les limites.

• Limite stricte : 50 Mo OU 50 000 URL maximum par fichier
• Conséquence du dépassement : troncature silencieuse, URL non découvertes
• Solution : découper en plusieurs fichiers sitemap ou utiliser un index sitemap
• Piège fréquent : génération automatique sans contrôle de taille
• Métadonnées lourdes : images, videos, hreflang gonflent rapidement le poids

Cette déclaration est-elle cohérente avec les observations terrain ?

Absolument. Ces limites sont documentées depuis des années et correspondent exactement à ce qu'on observe en pratique. J'ai vu des dizaines de sites perdre du crawl sur des sections entières parce qu'un sitemap de 75 000 URL avait été soumis sans broncher dans la Search Console.

Le problème ? Google ne vous crie pas dessus quand vous dépassez. Le fichier est accepté, partiellement traité, et vous ne découvrez le souci que des semaines plus tard en analysant les logs serveur ou en constatant que des pages ne remontent jamais dans l'index.

Quelles nuances faut-il apporter à cette règle ?

La limite de 50 Mo peut être atteinte beaucoup plus vite qu'on ne le pense si vous enrichissez vos sitemaps avec des balises image (<image:image>), video ou des alternates hreflang multiples. Un sitemap avec 20 000 produits e-commerce, chacun ayant 4 images et 8 versions linguistiques, explose facilement les 50 Mo.

Autre nuance : la compression. Les serveurs peuvent servir les sitemaps en gzip, ce qui réduit drastiquement la bande passante utilisée. Mais attention — la limite de 50 Mo s'applique au fichier décompressé, pas au fichier compressé transmis. Ne vous faites pas avoir par un fichier .xml.gz de 8 Mo qui pèse en réalité 65 Mo une fois extrait.

Dans quels cas cette limite pose-t-elle réellement problème ?

Sur les sites de grande envergure : marketplaces, agrégateurs, médias avec archives profondes. Dès que vous dépassez 100 000 URL indexables, vous êtes obligé de fragmenter vos sitemaps. Ça devient un sujet d'architecture : comment découper intelligemment ? Par rubrique ? Par date ? Par priorité stratégique ?

Là où ça coince souvent : les CMS ou générateurs de sitemap automatiques qui crachent un fichier monolithique sans se poser de questions. Si votre outil ne gère pas nativement la pagination ou l'index sitemap, vous êtes bon pour du développement custom.

Que faut-il faire concrètement pour rester dans les clous ?

Premier réflexe : auditer vos sitemaps existants. Téléchargez chaque fichier, décompressez-le si nécessaire, et vérifiez le poids réel + le nombre d'URL. Si vous êtes proche des limites (disons 45 000 URL ou 45 Mo), fragmentez maintenant plutôt que d'attendre le dépassement.

Pour les gros sites, passez à un index sitemap (sitemap_index.xml) qui référence plusieurs fichiers sitemap. Vous pouvez ainsi découper par thématique, par langue, par profondeur de crawl — tout en restant sous les seuils individuels. C'est scalable et maintenable.

Quelles erreurs éviter absolument ?

Ne générez jamais un sitemap à la volée sans buffer ni contrôle de taille. J'ai vu des scripts PHP planter en production parce qu'ils tentaient de charger 200 000 URL en mémoire avant de réaliser que le fichier XML dépassait 150 Mo.

Autre erreur classique : oublier que les métadonnées optionnelles (images, videos, news) gonflent le poids. Si vous ajoutez 5 balises <image:image> par URL produit, vous mangez 10x plus d'octets qu'un sitemap basique. Calculez le coût moyen par entrée et extrapolez.

Comment vérifier que mon site est conforme ?

Utilisez la Search Console pour voir quels sitemaps ont été traités et combien d'URL ont été découvertes. Si le nombre d'URL découvertes est inférieur au nombre total dans le fichier, c'est un red flag immédiat.

Comparez ensuite avec vos logs serveur : Googlebot crawle-t-il effectivement les URL situées en fin de sitemap ? Si non, c'est probablement qu'elles n'ont jamais été soumises faute de traitement complet du fichier.

• Vérifier le poids décompressé de chaque fichier sitemap (limite : 50 Mo)
• Compter le nombre exact d'URL par fichier (limite : 50 000)
• Fragmenter en plusieurs sitemaps si l'une des limites est proche
• Mettre en place un index sitemap pour les sites de grande envergure
• Contrôler la cohérence dans la Search Console (URL soumises vs découvertes)
• Analyser les logs serveur pour détecter les URL jamais crawlées
• Éviter les métadonnées lourdes inutiles (images, videos) si elles ne servent pas le SEO
• Automatiser la génération avec des checks de validation intégrés