Votre sitemap est le seul fichier de votre site web que personne ne relit jamais.
Quelqu'un l'a configuré il y a des années, probablement un plugin, et depuis il indique discrètement aux moteurs de recherche quoi crawler. Il fonctionne, donc personne ne l'ouvre.
Nous en avons ouvert 21 — d'IKEA, Booking.com, Stripe, Shopify, Zillow, Goodreads, wikiHow et une douzaine d'autres — et nous avons vérifié chacun d'eux contre le protocole sitemap lui-même.
Huit sont revenus propres. Treize ne l'étaient pas.
L'un des treize était le nôtre.
Résultats en un coup d'oeil
Deux problèmes expliquent presque tout ce que nous avons trouvé, et les deux sont invisibles de l'extérieur : des champs qui ne font rien, et des URLs que le fichier n'est techniquement pas autorisé à couvrir.
Aucun ne cassera votre site. Les deux valent dix minutes.
Ce que nous avons vérifié, et comment
Nous avons pris le robots.txt de chaque site, suivi le premier sitemap qu'il déclarait, ouvert un vrai fichier d'URLs derrière lui, et posé trois questions.
Chaque URL se trouve-t-elle dans le propre dossier du sitemap ? Le protocole dit qu'un sitemap couvre son propre chemin et ce qui se trouve en dessous. Un fichier à /sitemaps/ qui liste des pages à /products/ est hors de ce périmètre.
Contient-il priority ou changefreq ? Les deux sont du XML valide et les deux sont ignorés par Google. Ce sont des restes de 2005.
Contient-il un lastmod lisible ? Celui-ci, Google l'utilise, quand il vous fait confiance.
Ensuite, nous avons passé plusieurs des mêmes fichiers dans notre propre XML Sitemap Generator, qui effectue exactement ces vérifications, pour nous assurer que notre lecture et l'outil étaient d'accord. Ils l'étaient.
Seuls 8 sur 21 sont revenus propres
Les huit propres : Omni Calculator, Healthline, Coursera, Vercel, Netlify, MongoDB, Semrush et Similarweb.
Les treize autres : wikiHow, Calculator.net, NerdWallet, Goodreads, GeeksforGeeks, Zillow, Booking.com, IKEA, Stripe, Shopify, HubSpot, Atlassian — et UNmiss.
Il y a un schéma dans cette répartition, et c'est le même que celui que nous avons trouvé lorsque nous avons vérifié qui publie un llms.txt : les entreprises d'outils pour développeurs sont ordonnées, et les grands sites grand public sur d'anciens systèmes de contenu ne le sont pas.
Les champs qui ne font rien
Huit des 21 sitemaps contiennent <priority>. Huit contiennent <changefreq>.
Les deux balises faisaient partie de la spécification sitemap originale de 2005. L'idée était que vous indiquiez aux moteurs de recherche quelles pages comptaient le plus et à quelle fréquence elles changeaient, et que le crawl soit planifié en conséquence.
Elle n'a pas survécu au contact avec la réalité, parce que chaque site web disait que chaque page avait une priorité 1.0 et changeait tous les jours. Google ignore totalement les deux champs. Ils restent du XML valide. Ils ne font simplement rien.
Sur un petit site, c'est du bruit inoffensif. Sur un grand, ce ne l'est pas. Le sitemap produit d'IKEA atteint 47.6 MB face à une limite stricte du protocole de 50 MB — et chaque entrée y dépense des octets dans deux champs que personne ne lit.
URLs hors de leur propre dossier
Dix des 21 listent des URLs situées hors du propre répertoire du sitemap. C'est l'erreur la plus intéressante, parce que presque personne ne sait que cette règle existe.
Un sitemap est censé couvrir uniquement son propre chemin et tout ce qui se trouve en dessous. Placez le fichier à example.com/sitemaps/products.xml et il couvre techniquement /sitemaps/ et en dessous — pas /products/, ni votre page d'accueil.
En pratique, Google est indulgent, en particulier quand vous soumettez le sitemap directement dans Search Console. Mais "généralement pardonné" est une moins bonne position que "correct", et la correction est la plus simple du SEO : déplacez le fichier à la racine de votre domaine. Un sitemap à example.com/sitemap.xml couvre tout, toujours, sans exception à retenir.
Nous avons échoué à notre propre vérification
Voici maintenant la partie inconfortable, et la raison pour laquelle nous sommes confiants que le reste est juste.
Nous avons passé unmiss.com dans notre propre XML Sitemap Generator. Il a signalé 370 URLs, 399.5 KB, HTTP 200, avec un lastmod lisible sur chaque entrée — puis a marqué ceci :
370 entrées contiennent priority ou changefreq.
"Google ignore totalement les deux champs. Ils sont valides, ils ne font simplement rien pour vous."
Chaque URL. Vous pouvez le voir dans le fichier brut, où chaque entrée est suivie d'une date, du mot weekly et du nombre 0.7 :
Personne n'a choisi cela. Cela venait d'un réglage par défaut, il y a des années, et cela a survécu parce que personne n'a rouvert le fichier — ce qui est exactement le sujet de cet article.
Copiez ceci en un après-midi
Quatre étapes. Le tout prend moins de temps que de lire à ce sujet.
1. Ouvrez votre propre sitemap. Ajoutez /sitemap.xml à votre domaine, ou trouvez l'adresse dans votre robots.txt. La plupart des gens ne l'ont jamais regardé.
2. Cherchez priority et changefreq. S'ils sont là, supprimez-les. Il n'y a aucun inconvénient et aucun risque ; ils ne faisaient rien.
3. Vérifiez où vit le fichier. S'il est dans un sous-dossier alors que vos pages sont ailleurs, déplacez-le à la racine. Ce seul déplacement élimine toute une catégorie de problème.
4. Assurez-vous que lastmod est honnête. C'est le seul champ qui compte encore, et il ne compte que s'il est vrai. Un fichier qui prétend que tout a changé aujourd'hui apprend aux moteurs de recherche à ignorer ce champ.
Ce que nous n'avons pas pu mesurer
21 sitemaps est un échantillon. Nous avons choisi des noms reconnaissables dans l'édition, le retail, le logiciel et les outils pour développeurs, et nous avons lu le premier sitemap que chacun déclarait. Un autre échantillon donnerait d'autres pourcentages.
Un fichier par site. Plusieurs de ces entreprises publient des milliers de fichiers sitemap. Nous avons évalué un vrai fichier d'URLs pour chacune, en supposant qu'ils sont générés par le même système — ce qui est probable mais non vérifié.
Le périmètre de chemin est une règle que Google pardonne généralement. Nous le signalons parce qu'il est dans la spécification et parce que notre outil le marque, pas parce que nous pouvons montrer qu'il coûte du trafic à qui que ce soit. Nous ne le pouvons pas.
Nous ne pouvons pas voir ce qu'un moteur de recherche fait avec ces fichiers. Tout ici concerne ce que les sites publient, pas ce qui est crawlé ou indexé.
Collez l'adresse d'un sitemap que vous publiez déjà et notre XML Sitemap Generator le vérifie contre le protocole sans visiter une seule URL qu'il contient. C'est la même vérification qui a trouvé le problème dans notre propre fichier, et dans dix des vingt et un ci-dessus.
- Signale les URLs hors du propre chemin du sitemap
- Repère priority et changefreq, que Google ignore
- Renvoie une copie nettoyée que vous pouvez publier aujourd'hui
Questions fréquentes
Quels sitemaps avez-vous vérifiés, et quels étaient les résultats ?
21 sitemaps lisibles le 23 août 2026. Propres : Omni Calculator, Healthline, Coursera, Vercel, Netlify, MongoDB, Semrush, Similarweb. Avec au moins un problème : wikiHow, Calculator.net, NerdWallet, Goodreads, GeeksforGeeks, Zillow, Booking.com, IKEA, Stripe, Shopify, HubSpot, Atlassian et UNmiss. Dix listaient des URLs hors du propre dossier du sitemap, huit contenaient priority et huit contenaient changefreq.
Priority ou changefreq servent-ils à quelque chose ?
Pas pour Google, qui ignore totalement les deux champs et l'a dit clairement. D'autres crawlers peuvent les lire, mais aucun grand moteur de recherche ne s'engage à agir sur l'un ou l'autre. Ce sont du XML valide qui ne fait rien, et les supprimer ne comporte aucun risque.
Pourquoi l'emplacement du fichier sitemap importe-t-il ?
Parce que le protocole dit qu'un sitemap ne couvre que son propre chemin et tout ce qui se trouve en dessous. Un fichier à /sitemaps/products.xml ne couvre techniquement pas /products/. Google est généralement indulgent, surtout pour les sitemaps soumis dans Search Console, mais le problème disparaît entièrement si vous placez le fichier à la racine du domaine.
Un sitemap avec ces problèmes est-il cassé ?
Non, et nous n'utiliserions pas ce mot. Aucun des treize sites ici n'a un sitemap qui cesse de fonctionner. Ils contiennent des champs qui gaspillent de l'espace et, dans dix cas, une organisation de chemin que la spécification n'autorise pas strictement. Ce sont des problèmes de propreté, pas des pannes — c'est précisément pourquoi ils survivent pendant des années.
Vous avez trouvé un problème dans votre propre sitemap. Quel était-il ?
Les 370 URLs du sitemap anglais d'unmiss.com contiennent priority et changefreq. Notre propre XML Sitemap Generator l'a signalé quand nous l'avons pointé vers nous-mêmes. Cela venait d'un réglage par défaut il y a des années, personne n'a rouvert le fichier, et c'est exactement le schéma d'échec dont parle cet article.
Et lastmod ?
Celui-là compte encore. Google utilise lastmod quand il fait confiance à la valeur, et la confiance se gagne par l'exactitude. Chaque sitemap de notre échantillon le contenait sur pratiquement chaque entrée, ce qui est bien — à condition que les dates soient réelles. Un fichier qui prétend que chaque page a changé aujourd'hui apprend aux moteurs de recherche à ignorer le champ.
Quelle taille un sitemap peut-il avoir ?
50,000 URLs ou 50 MB non compressés, selon la première limite atteinte, après quoi vous le divisez en plusieurs fichiers derrière un index de sitemaps. Ce plafond explique pourquoi les champs gaspillés comptent à grande échelle : le sitemap produit d'IKEA est déjà à 47.6 MB, soit 95% de la limite, tout en dépensant des octets dans deux champs que personne ne lit.
Puis-je lancer cette vérification moi-même ?
Oui, dans les deux sens. À la main : ouvrez votre robots.txt, suivez le sitemap, et cherchez priority et changefreq dans le fichier. Ou collez l'adresse dans notre XML Sitemap Generator, qui exécute les mêmes vérifications et renvoie une copie corrigée.
Corrigez le fichier que personne ne relit
La majeure partie de cette série parle d'entreprises qui ont construit quelque chose de remarquable. RTINGS mesure ce que personne ne mesure, wikiHow dessine une image pour chaque étape, Goodreads a trouvé seize noms là où tous les autres n'en ont trouvé qu'un.
Celle-ci parle de l'inverse : la chose que chaque site web possède, et que presque personne n'a regardée deux fois.
Treize des vingt et une grandes entreprises bien dotées publient un sitemap avec quelque chose qui cloche dedans. Pas parce que c'est difficile, mais parce que c'est invisible. Le fichier fonctionne, donc personne ne l'ouvre, donc les réglages par défaut de 2005 vivent éternellement.
Nous étions l'un des treize, et nous ne l'avons découvert qu'en pointant notre propre outil vers nous-mêmes.
Alors ouvrez votre sitemap. Cela prend une minute, et il y a de fortes chances que vous ne l'ayez pas lu depuis le jour où il a été créé.
Vérifié le 23 août 2026. Méthode : récupérer le robots.txt de chaque site, suivre le premier sitemap déclaré, ouvrir un vrai fichier d'URLs derrière lui, et tester le périmètre de chemin, priority, changefreq et lastmod. Les résultats ont été recoupés avec notre propre XML Sitemap Generator, qui effectue les mêmes vérifications, et les deux concordaient.
Un fichier par site est un échantillon, pas un audit de tous les sitemaps que ces entreprises publient. Le périmètre de chemin est une règle de spécification que les moteurs de recherche pardonnent couramment, et nous n'affirmons pas que l'un de ces problèmes a coûté du trafic à qui que ce soit.