Un sitemap XML e-commerce est un fichier qui liste les URL de produits, de catégories et de contenus que tu veux faire trouver aux moteurs de recherche : une URL canonique par page, avec une date de dernière modification exacte. Un seul fichier sitemap contient au maximum 50 000 URL ou 50 Mo non compressés. Un grand catalogue répartit donc ses URL sur plusieurs fichiers et les référence dans un index de sitemaps, que tu soumets une seule fois dans Google Search Console.
Voilà pour la réponse courte. Le vrai travail dans une boutique, c'est de décider ce qui entre dans le fichier : variantes, pages de catégorie filtrées, produits en rupture, produits arrêtés et chaque version linguistique. Si tu te trompes, le sitemap signale à Google des milliers de pages que tu ne veux pas voir indexées, tandis que des produits que tu veux indexer restent absents. Ce guide passe en revue chaque décision, ce que Shopify, WooCommerce et Magento génèrent par défaut, et comment contrôler un sitemap par rapport au catalogue qu'il est censé décrire.
Quelles URL de la boutique mettre dans un sitemap XML
Un sitemap est la liste des URL que tu préfères voir dans les résultats de recherche. Il ne doit donc contenir que des pages qui renvoient un code 200, sont indexables et sont leur propre canonique. Ce guide traite du sitemap XML destiné aux moteurs de recherche ; une page plan du site en HTML pour les acheteurs est une page à part, facultative. Pour une boutique, cela donne :
- À inclure : les fiches produit (une URL par produit, ou par variante si chaque variante a sa propre page canonique), les pages de catégorie et de collection, les pages de marque, les guides d'achat, les articles de blog et les pages statiques que les gens recherchent, comme la livraison et les retours.
- À exclure : les URL de filtre et de tri (?color=red&sort=price), les résultats de recherche interne, les pages panier, commande et compte, les URL qui redirigent, les pages avec une balise noindex et toute URL dont la canonique pointe ailleurs.
- À vérifier : les pages de catégorie paginées. Ne les liste que si elles sont indexables et canoniques vers elles-mêmes ; beaucoup de boutiques les laissent de côté et comptent sur le maillage interne.
Google demande des URL absolues et complètes dans les sitemaps (Google Search Central) et la même URL dans les liens internes, les sitemaps et les balises canoniques, selon ses recommandations sur les URL e-commerce. Un sitemap qui liste des URL en http://, ou des URL avec une barre oblique finale que la balise canonique n'a pas, envoie un signal contradictoire pour chaque produit.
Limites de taille du sitemap pour les grands catalogues
Les limites s'appliquent par fichier, pas par site. Tous les formats sont plafonnés à 50 000 URL ou 50 Mo non compressés par sitemap, et le fichier doit être encodé en UTF-8, selon Google Search Central. La compression gzip économise de la bande passante, mais c'est la taille non compressée qui compte. Les plateformes fixent leurs propres valeurs par défaut sous ces plafonds.
Limites du sitemap et valeurs par défaut des plateformes
| URL par fichier sitemap | 50 000 | |
|---|---|---|
| Taille par fichier sitemap | 50 Mo non compressés | |
| Entrées image par URL de page | 1 000 | |
| Cœur de WordPress : URL par sitemap | 2 000 (modifiable via un filtre) | WordPress |
| Magento : URL par fichier (par défaut) | 50 000 | Adobe |
| Magento : taille de fichier (par défaut) | 10 485 760 octets | Adobe |
Découper un catalogue de 120 000 produits par type de page
Découpe d'abord par type de page, ensuite par plage. Des fichiers séparés pour les produits, les catégories, les marques et les contenus rendent les problèmes visibles : si Search Console indique que la moitié des URL d'un fichier produits ne sont pas indexées, tu sais où chercher. Une boutique fictive avec 120 000 URL produit a besoin d'au moins trois fichiers produits :
Index de sitemaps pour une boutique de 120 000 produits
Garde un découpage stable. Si un produit passe du fichier 2 au fichier 3 à chaque ajout de SKU, les rapports par fichier dans Search Console perdent leur sens. Découper selon une clé fixe, comme une plage d'ID produit ou une catégorie de premier niveau, permet de comparer chaque fichier dans le temps.
Sitemaps d'images : il ne reste que deux balises
Les images produit peuvent être listées dans l'entrée url du produit lui-même. Chaque url peut porter jusqu'à 1 000 entrées image, et seules image:image et image:loc subsistent : caption, title, geo_location et license sont obsolètes, selon la documentation de Google sur les sitemaps d'images. Des images hébergées sur un domaine de CDN ne posent pas de problème si tu valides ce domaine dans Search Console et ne le bloques pas dans le robots.txt.
Certaines plateformes écrivent encore image:title dans le fichier. Cela ne nuit pas, mais ne sert à rien non plus : la description des images reste le rôle du texte alt sur la page. Si ta plateforme ne liste que l'image principale, c'est généralement suffisant ; Google découvre les images de la galerie à partir de la fiche produit elle-même.
lastmod : la seule balise facultative que Google lit
Google ignore priority et changefreq, et n'utilise lastmod que si la valeur est exacte de façon constante et vérifiable, selon Google Search Central. La valeur doit refléter la dernière mise à jour significative de la page. Pour une fiche produit, un nouveau prix, un changement de statut de stock, un contenu réécrit ou de nouvelles images comptent. Une modification du pied de page ou un déploiement de template qui touche toutes les pages ne compte pas.
L'erreur la plus fréquente en boutique : une tâche nocturne qui réenregistre tous les produits et leur appose à tous la date du jour. Après quelques semaines, lastmod ne porte plus aucune information et Google cesse de s'y fier. Si ta plateforme alimente lastmod à partir d'un champ générique updated_at, vérifie ce qui écrit dans ce champ : une synchronisation de stock qui touche chaque ligne toutes les heures a le même effet.
Variantes, URL canoniques et paramètres
Google demande que chaque variante soit identifiable par sa propre URL, soit par un segment de chemin (/t-shirt/green), soit par un paramètre (/t-shirt?color=green). Si le paramètre est facultatif, l'URL sans paramètre est la canonique ; si chaque variante a sa propre URL, l'URL canonique du produit figure sur toutes les pages de variante, selon les recommandations de Google sur les URL e-commerce. Le sitemap liste alors la canonique, pas chaque URL de variante.
Les thèmes Shopify pointent vers une variante précise avec un paramètre ?variant= sur l'URL du produit, et le sitemap généré liste les produits : c'est donc l'URL du produit sans paramètre qu'il faut traiter comme canonique. Les boutiques qui créent une page distincte par couleur, avec son propre contenu et sa propre canonique, listent chacune de ces pages. Ce que tu ne dois jamais voir, c'est les deux à la fois : une URL parente et une douzaine d'URL de variantes dont la canonique pointe toutes vers la parente.
Produits en rupture, arrêtés et saisonniers
Le statut de stock change tous les jours, et un sitemap qui ajoute et retire des produits au même rythme crée plus de confusion qu'il n'aide. Décide au cas par cas, selon ce que renvoie la page elle-même :
Produits épuisés et arrêtés dans le sitemap
| Rupture de stock temporaire | 200, avec la disponibilité affichée | Oui | Statut de stock, date de réassort, lastmod |
|---|---|---|---|
| Une variante épuisée | 200 pour le produit | Oui (l'URL du produit) | Disponibilité de la variante sur la page |
| Saisonnier, de retour la saison prochaine | 200, indiqué comme indisponible | Oui | Date prévue si tu la connais |
| Arrêté, successeur direct | 301 vers le successeur | Non, liste le successeur | Liens internes vers la nouvelle URL |
| Arrêté, sans remplaçant | 404 ou 410 | Non | Supprimer les liens internes |
Rediriger un produit arrêté vers sa catégorie ou la page d'accueil est tentant, mais un acheteur qui cherchait un modèle précis atterrit sur une page qui ne l'a pas. Ne redirige que s'il existe un vrai successeur ; sinon, laisse la page renvoyer 404 ou 410 et retire-la du sitemap dans la même mise en production. Un produit que tu vends en précommande avant son lancement est le cas inverse : la page est en ligne et renvoie 200, elle a donc sa place dans le fichier dès sa mise en ligne.
Garder les URL de navigation à facettes hors du sitemap
Les combinaisons de filtres se multiplient vite : 20 couleurs, 10 tailles et 5 marques sur une seule catégorie donnent déjà 1 000 pages filtrées avant même le tri. Aucune n'a sa place dans le sitemap, sauf si tu as délibérément transformé un filtre en page d'atterrissage, comme /shoes/red-running-shoes, avec son propre contenu, une canonique vers elle-même et des liens internes. Ces pages vont dans le fichier des catégories ; les autres restent dehors, et notre article sur le SEO de la navigation à facettes explique comment éviter que les robots perdent leur temps dessus.
hreflang dans le sitemap pour les boutiques multilingues
Une boutique avec plusieurs langues ou versions pays peut les déclarer dans le sitemap plutôt que dans le head de la page. Chaque entrée url liste alors toutes les versions linguistiques sous forme d'éléments xhtml:link, y compris elle-même, et chaque version linguistique a sa propre entrée url avec le même ensemble de liens. Ces liens ajoutent des octets à chaque entrée : avec cinq langues, un fichier produits atteint le plafond de 50 Mo bien plus tôt. Découpe plus tôt.
La méthode du sitemap convient aux boutiques qui ont beaucoup de langues, car le head de la page reste léger et toutes les versions alternatives se trouvent dans un seul fichier que tu peux valider. Le piège, c'est l'exhaustivité : un lien retour manquant dans une langue casse la paire. Le générateur hreflang crée les balises pour un ensemble d'URL, et le guide du SEO multilingue couvre le reste de la configuration.
Ce que génèrent Shopify, WooCommerce et Magento
- Shopify génère automatiquement le fichier sitemap.xml. Il contient tous les produits avec leur image principale, les pages, les collections et les articles de blog, se met à jour quand tu en ajoutes, et avec des domaines internationaux, chaque domaine a son propre sitemap avec ses langues, selon le centre d'aide Shopify. Le fichier renvoie vers des sitemaps séparés pour les produits, les collections, les pages et les blogs, et Shopify les met à jour lui-même quand tu ajoutes un produit, une collection, une image ou un article.
- WooCommerce s'appuie sur WordPress. Depuis WordPress 5.5, le cœur publie un index de sitemaps à l'adresse wp-sitemap.xml qui couvre les types de contenu publics, produits compris, avec par défaut jusqu'à 2 000 URL par sitemap, selon WordPress. Les extensions SEO comme Yoast SEO le remplacent généralement par leur propre sitemap. Garde un seul sitemap, pas les deux, et soumets celui qui est en ligne.
- Magento (Adobe Commerce) crée les sitemaps sous Marketing > SEO & Search > Site Map et les configure sous Stores > Configuration > Catalog > XML Sitemap : fréquence et priorité par type de page, images produit (None, Base Only ou All), génération planifiée et option pour ajouter le sitemap au robots.txt, selon Adobe. La génération est planifiée : une boutique dont le cron est en panne sert donc un sitemap périmé. Notre checklist SEO Magento couvre les réglages associés.
Soumettre le sitemap et lire le rapport
Soumets l'URL de l'index dans Search Console sous Indexation, puis Sitemaps, et ajoute au robots.txt une ligne Sitemap: avec l'URL complète pour que les autres robots le trouvent aussi. Un sitemap ne couvre que les URL situées sous son propre répertoire, sauf si tu le soumets via Search Console : une raison de plus de le garder à la racine, selon Google Search Central.
Le rapport indique pour chaque fichier si Google a pu le lire et combien d'URL il a trouvées. Le rapport d'indexation des pages montre ensuite quelles URL soumises sont indexées et pourquoi les autres ne le sont pas. Lis les deux ensemble : un fichier produits avec des milliers d'URL « Explorée, actuellement non indexée » révèle généralement des fiches produit pauvres ou dupliquées, pas un problème de sitemap. Le guide de SEO technique pour les boutiques passe en revue les autres contrôles d'indexation.
Faire correspondre le sitemap au catalogue produits
Search Console te dit ce que Google a fait des URL que tu as soumises. Il ne te dit pas quels produits manquent dans le sitemap au départ, car il ne connaît pas ton catalogue. Cette comparaison demande les deux listes côte à côte.
WISEPIM ne crée ni n'héberge le sitemap de ta boutique ; c'est ta plateforme e-commerce qui s'en charge. Ses analyses Sitemap Coverage (couverture du sitemap) lisent les sitemaps que tu ajoutes dans les réglages SEO (ou les lignes Sitemap du robots.txt si tu n'en as pas défini), suivent les fichiers d'index jusqu'à leurs sitemaps enfants, y compris compressés en gzip, et rattachent chaque URL à un produit ou une catégorie de ton catalogue. Les autres URL sont classées comme pages de marque, de blog, statiques ou autres. Pour chaque URL, tu vois le type, le produit rattaché, lastmod et priority tels que le sitemap les indique, et pour chaque fichier sitemap si la dernière récupération a fonctionné.
Le contrôle inverse, Missing from Sitemap (absent du sitemap), part du catalogue : pour chaque produit présent dans une boutique connectée, il construit l'URL de boutique attendue et signale les produits dont l'URL ne figure pas dans le sitemap synchronisé, avec un filtre par plateforme et un export CSV. Aucune des deux vues n'indique si Google a indexé une page ; cette réponse reste dans Search Console. Ensemble, elles repèrent les cas qu'un robot ne signale jamais : un produit en ligne dans la boutique mais absent du fichier, et un sitemap rempli d'URL qui ne correspondent à rien de ce que tu vends.
