Vérification du sitemap

Un sitemap est une liste, pas un ordre

Un moteur de recherche trouve les pages en suivant des liens. Un sitemap lui évite cette peine. C’est un fichier unique où vous écrivez l’adresse de chaque page à explorer, si bien que rien ne dépend de la découverte d’un lien. Le format est petit. Un <urlset> contient des entrées <url> et chaque entrée n’a besoin que d’un <loc> avec l’adresse complète :

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/pricing</loc>
    <lastmod>2026-03-14</lastmod>
  </url>
</urlset>

Un fichier peut contenir 50 000 adresses et peser 50 Mo avant compression. Les sites plus gros répartissent la liste en plusieurs fichiers et publient un <sitemapindex>, c’est-à-dire un sitemap dont les entrées sont d’autres sitemaps. Un index ne peut pas pointer vers un autre index.

Lister une page demande seulement une visite. Que la page soit ensuite indexée ou non dépend de la page.

Comment cette vérification trouve et lit le fichier

Donnez-nous un domaine seul et notre serveur demande /robots.txt, puis cherche les lignes Sitemap:. S’il y en a plusieurs, il lit la première et liste les autres pour que vous puissiez les tester une à une. S’il n’y en a aucune, il essaie /sitemap.xml, /sitemap_index.xml et /wp-sitemap.xml, dans cet ordre et garde le premier qui contient un sitemap.

Le fichier est ensuite lu avec un analyseur XML en flux, jusqu’à 5 Mo de téléchargement. Les fichiers gzip sont d’abord décompressés. Pour un index, les cinq premiers sitemaps enfants sont récupérés et lus de la même façon et le rapport indique combien ont été laissés de côté. Enfin, cinq adresses réparties dans la liste sont demandées une fois chacune, sans suivre les redirections, pour voir ce qu’elles répondent.

Ce que signifie chaque résultat

<priority> et <changefreq> sont indiqués à titre d’information seulement. Google a dit qu’il ignore les deux.

Réparations des défauts habituels

L’analyseur s’arrête au milieu du fichier

Cherchez un & brut dans une adresse. En XML, il s’écrit & : ?a=1&b=2 devient donc ?a=1&b=2. Une ligne vide ou un avertissement PHP affiché avant <?xml casse le fichier dès son tout premier octet.

Des adresses sur le mauvais hôte ou en http://

Le générateur construit les adresses à partir de l’adresse du site dans ses réglages. Réglez-la sur la forme où les visiteurs aboutissent après les redirections, puis régénérez.

Tous les lastmod sont identiques

Le générateur inscrit l’heure de son exécution. Configurez-le pour qu’il utilise la date de la dernière modification de chaque page, ou omettez la balise. Une mauvaise date est pire que pas de date : dès que les moteurs de recherche voient qu’elle ne correspond pas aux vrais changements, ils cessent de se fier à la balise pour tout le site.

Des pages mortes ou redirigées dans l’échantillon

Régénérez le sitemap après avoir supprimé ou déplacé des pages et ne listez que des adresses qui répondent 200 et se déclarent elles-mêmes canoniques. Pour les liens à l’intérieur de vos pages, il y a le détecteur de liens morts.

Non déclaré dans robots.txt

Ajoutez une ligne avec l’adresse complète n’importe où dans le fichier : Sitemap: https://www.example.com/sitemap.xml.

Ce que cette vérification ne peut pas vous dire

Elle lit au plus 5 Mo par fichier et cinq enfants d’un index : sur un très gros site, les totaux décrivent donc la partie lue. Les doublons sont cherchés à l’intérieur de chaque fichier, pas entre les fichiers. Les extensions image, vidéo, actualités et hreflang sont comptées mais pas validées.