À quoi sert un sitemap et comment le construire

À quoi sert vraiment un sitemap pour votre site ?

Un sitemap, aussi appelé plan de site, est un fichier, le plus souvent au format XML, qui liste les adresses qu'un site veut voir explorées par les moteurs de recherche. Il sert à accélérer la découverte de nouvelles pages, pas à forcer leur indexation.

Un moteur de recherche découvre normalement les pages d'un site en suivant les liens, internes comme externes, au fil de son exploration (le crawl effectué par Googlebot pour Google). Le sitemap ouvre une seconde voie, plus directe : une liste d'adresses que le site propose lui-même à l'exploration. Google documente trois situations où cette seconde voie change vraiment quelque chose :

• Un site volumineux, où le maillage interne seul met du temps à faire remonter chaque page.
• Un site récent, qui n'a pas encore accumulé de liens externes pour se faire découvrir.
• Un site au contenu riche en médias ou en actualités, avec un sitemap image, un sitemap vidéo ou un sitemap actualités dédié, que les liens classiques valorisent mal.

Ces trois cas sont ceux que Google documente lui-même, dans une page mise à jour le 18 décembre 2025. En dehors d'eux, un sitemap reste une bonne pratique par défaut, mais change rarement la donne : un petit site bien maillé, avec des liens internes clairs entre ses pages, est généralement exploré sans qu'un sitemap n'y change grand-chose.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://exemple.fr/page-produit</loc>
  </url>
</urlset>

Qu'est-ce qu'un sitemap ne garantit PAS ?

Un sitemap ne garantit ni l'indexation ni le positionnement d'une page : c'est Google lui-même qui le précise dans sa documentation. Il indique des adresses à explorer, il ne force rien.

La refonte de komtop.fr, terminée le 04/08/2026, illustre concrètement cette limite. Le nouveau sitemap est propre : un fichier d'index et trois fichiers thématiques (pages, études de cas, blog), pour 60 adresses au total. Neuf jours plus tard, au 13/08/2026, seules 46 des 67 adresses suivies dans Search Console étaient indexées. Un sitemap neuf et bien structuré n'a donc rien garanti de plus qu'une file d'attente d'exploration.

Un sitemap indique à Google quelles adresses explorer ; il ne décide pas de la suite, et il ne rattrape pas non plus une page orpheline, une page sans aucun lien interne qui pointe vers elle. C'est l'algorithme d'indexation qui juge ensuite la qualité, l'unicité et la pertinence de chaque page avant de l'ajouter à l'index. Sur un site de taille modeste, un maillage interne travaillé, avec des liens clairs entre les pages, pèse en réalité davantage sur l'indexation qu'un sitemap parfaitement formé.

Quelles adresses mettre dans un sitemap, et lesquelles exclure ?

Un sitemap ne doit contenir que les adresses canoniques que le site veut voir indexées. Quatre familles de pages n'y ont donc rien à faire, et ce sont les quatre erreurs les plus courantes :

• Les pages bloquées par robots.txt ou par une balise noindex.
• Les doublons d'une même page, avec ou sans paramètre, avec ou sans slash final.
• Les pages de connexion et d'administration.
• Les résultats de recherche interne du site.

Chaque adresse doit être une URL canonique, absolue et complète (https://exemple.fr/page, jamais /page seule), encodée en UTF-8. Quand un contenu existe en plusieurs versions, une seule version canonique figure dans le sitemap : lister les deux revient à envoyer un signal contradictoire à Google sur la version à privilégier.

Lister une adresse non indexable n'est pas seulement inutile : Google explore chaque site avec un budget limité, et une adresse bloquée ou dupliquée qui occupe ce budget retarde d'autant l'exploration des pages qui comptent vraiment.

Le sitemap et les données structurées répondent à deux questions différentes, et se complètent plutôt qu'ils ne se concurrencent : le sitemap dit à Google quelles pages existent et où les trouver, les données structurées lui disent ce que chaque page contient exactement. Un site qui soigne les deux facilite le travail du moteur à chaque étape, de la découverte à la compréhension du contenu.

Comment gérer un gros catalogue avec un index de sitemaps ?

Au-delà de 50 000 adresses ou de 50 Mo non compressé, un sitemap unique atteint sa limite et doit être scindé en plusieurs fichiers. Ce sont les deux plafonds que Google indique dans sa documentation, mise à jour le 15 juillet 2026. Un fichier d'index de sitemaps permet alors de les regrouper et de les envoyer à Google en une seule fois.

Un fichier d'index de sitemaps fonctionne comme un sitemap de sitemaps : il peut lister jusqu'à 50 000 balises loc, chacune pointant vers un fichier sitemap distinct. Google a précisé ce plafond le 20 février 2026. Un site avec plusieurs catégories de contenu, produits, articles de blog, pages catégories, peut ainsi organiser un fichier par type plutôt qu'un fichier unique difficile à maintenir.

Search Console accepte jusqu'à 500 fichiers d'index de sitemaps par site (même source). Pour la grande majorité des sites, même de gros catalogues e-commerce, cette limite laisse une marge confortable : elle ne devient une contrainte réelle que pour des places de marché de plusieurs millions de références.

Découper par type de contenu facilite aussi le diagnostic : une baisse d'indexation limitée aux pages produits, par exemple, pointe directement vers le fichier concerné plutôt que vers l'ensemble du site.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://exemple.fr/sitemap-pages.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://exemple.fr/sitemap-produits.xml</loc>
  </sitemap>
</sitemapindex>

Comment déclarer un sitemap à Google et aux autres moteurs ?

Un sitemap se déclare de deux façons, qui se cumulent sans problème : une ligne Sitemap: ajoutée dans le fichier robots.txt à la racine du domaine, ou un envoi direct dans le rapport Sitemaps de Search Console.

La ligne Sitemap: dans robots.txt a un avantage : elle est lue par tous les moteurs de recherche qui respectent le protocole, pas seulement Google, et le fichier robots.txt peut en contenir un nombre illimité, sans plafond documenté. C'est la méthode la plus simple pour un site qui vient d'être mis en ligne ou qui vient de changer d'adresses.

L'envoi direct dans Search Console apporte en plus un suivi propre à Google : date de dernière lecture, nombre d'adresses découvertes, erreurs éventuelles. Les deux méthodes ne s'excluent pas : déclarer le sitemap dans robots.txt et l'envoyer dans Search Console reste la pratique la plus sûre, surtout après une migration de site où l'ancien fichier doit être remplacé partout où il était référencé.

Sitemap: https://exemple.fr/sitemap.xml

Comment vérifier que Google lit vraiment votre sitemap ?

Le rapport Sitemaps de Search Console, dans la section Indexation, affiche pour chaque fichier envoyé la date de dernière lecture par Google, le nombre d'adresses découvertes et le nombre d'adresses effectivement présentes dans l'index.

C'est précisément ce rapport qui a permis de constater, sur komtop.fr, que le sitemap envoyé le 04/08/2026 (60 adresses réparties sur un index et trois fichiers thématiques) n'avait produit que 46 adresses indexées au 13/08/2026, sur les 67 adresses suivies par Search Console. L'écart entre adresses envoyées et adresses indexées est justement ce que ce rapport rend visible : sans lui, un sitemap peut sembler fonctionner alors qu'une partie du site reste hors de l'index.

Un sitemap qui n'a jamais été lu, ou dont la date de dernière lecture ne bouge plus, est un signal à traiter en priorité. Cela peut venir d'une erreur de format XML, d'une adresse qui redirige ou qui répond en erreur à l'intérieur du fichier, ou d'un fichier resté déclaré après une migration alors que l'ancien n'existe plus.

Repérer cet écart dans son propre rapport Sitemaps est une première étape ; comprendre pourquoi certaines adresses restent hors de l'index en est une autre. C'est ce qu'un audit SEO permet de vérifier point par point, au-delà du seul sitemap.

Quelles sont les erreurs les plus fréquentes avec un sitemap ?

Trois erreurs rendent un sitemap inutile sans que personne ne s'en aperçoive tout de suite : compter sur les champs priority et changefreq que Google ignore, laisser un lastmod faux, et laisser un sitemap pointer vers des adresses supprimées après une migration.

Les champs priority et changefreq n'ont aucun effet sur le crawl : Google les ignore aujourd'hui comme il les ignorait déjà en 2023. Gary Illyes, chez Google, l'a écrit noir sur blanc le 26 juin 2023, et la documentation le confirme toujours. Le champ lastmod, lui, est réellement utilisé comme signal de planification du crawl depuis 2023, mais seulement quand il reflète une vraie modification (même source).

Sur une prise de position publique du 16/07/2026, sur Bluesky, Gary Illyes est allé plus loin face à un professionnel dont le CMS générait des dates fausses à chaque mise en production :

probably better off without the lastmods. at least you save a few bytes.

En clair : mieux vaut retirer complètement le champ que garder des dates fausses, plutôt que d'économiser quelques octets sur un champ dans lequel Google n'a plus confiance. La confiance de Google dans lastmod se joue à l'échelle du site entier, pas page par page : un champ qui ment sur quelques adresses abîme la confiance sur l'ensemble du fichier.

Le troisième cas s'est produit sur komtop.fr lors de sa refonte du 04/08/2026 : quatre sitemaps de l'ancien site sont tombés en 404, dont celui qui était encore déclaré dans robots.txt et enregistré dans Search Console. Un plan de redirection, qui prévoit les redirections 301 vers les nouvelles adresses et la régénération du sitemap avant la bascule, évite ce genre d'oubli.

Comment trouver le sitemap d'un site existant ?

La méthode la plus fiable pour trouver le sitemap d'un site est de consulter son fichier robots.txt, accessible en ajoutant /robots.txt à la racine du domaine : il contient en général une ligne Sitemap: qui indique l'adresse exacte du fichier.

1. 1.Consulter le fichier robots.txt du site (exemple.fr/robots.txt) et chercher une ligne qui commence par Sitemap:.
2. 2.À défaut, tester directement l'adresse exemple.fr/sitemap.xml, qui reste l'emplacement le plus courant même sans déclaration explicite.
3. 3.Si l'on a accès à la propriété Search Console du site, consulter son rapport Sitemaps, qui liste tous les fichiers déclarés.

L'emplacement exact et le nom du fichier varient ensuite selon le système utilisé pour construire le site : chaque CMS a ses propres conventions. Un sitemap WordPress, par exemple, est le plus souvent généré automatiquement par l'extension SEO installée, quand d'autres systèmes demandent une configuration manuelle.

Faute d'accès à l'un de ces trois points d'entrée, robots.txt, /sitemap.xml, ou Search Console, il n'existe pas de méthode fiable pour retrouver un sitemap qui ne serait déclaré nulle part. Des trois, robots.txt reste le plus rapide à vérifier : il suffit d'ouvrir l'adresse dans un navigateur, sans outil ni accès particulier.