Analyseur de sitemap XML

Ce qu'un analyseur de sitemap devrait t'apprendre

Cet analyseur de sitemap XML met d'abord une chose au clair. Un sitemap ne te fera pas classer, et il ne remplace pas un bon maillage interne. C'est une carte pour la découverte, rien de plus. Du coup, un analyseur correct devrait répondre aux questions pratiques un peu ennuyeuses avant de te balancer une liste géante d'URL. Le fichier peut-il seulement être récupéré ? Est-ce un index ou un sitemap d'URL à plat ? Est-ce que les fichiers enfants se parsent ? Quelles URL es-tu en train de soumettre, et franchement, est-ce qu'elles ressemblent aux pages publiques canoniques que tu veux vraiment voir crawlées, ou est-ce que des trucs douteux se sont glissés dedans ?

Cette inspection, c'est tout l'intérêt de l'outil. Il démarre où tu lui dis de démarrer, échantillonne les fichiers enfants si la racine est un index, et garde les URL soumises bien en vue. Au passage il signale les suspects habituels : HTTPS, est-ce que le hostname reste cohérent, les lignes en double, le lastmod manquant. Puis il interroge un petit lot d'URL pour leur statut HTTP en direct. C'est quand même mieux que de plisser les yeux sur du XML brut, surtout juste après avoir poussé un lot d'articles WordPress ou bidouillé un réglage d'un plugin SEO, quand tu veux simplement t'assurer que rien n'a cassé.

Le sitemap index et les sitemaps enfants sont deux couches différentes

La plupart des plugins SEO WordPress te livrent un seul sitemap index plus tout un tas de sitemaps enfants. Vois l'index comme un annuaire, une table des matières. Les fichiers enfants contiennent les vraies lignes : articles, pages, catégories, auteurs, images. Soumets un fichier enfant par erreur et tu audites une fine tranche du site sans t'en rendre compte. Pire, un sitemap enfant peut cesser de se mettre à jour en silence pendant que l'index racine a l'air parfaitement nickel au premier coup d'oeil. Donc moi, je lirais les deux couches. C'est l'habitude la plus sûre, et ça prend dix secondes de plus.

• Le sitemap racine te dit si le point d'entrée public se charge seulement, et quel type de XML il sert.
• L'échantillon de sitemaps enfants montre quelles sections existent vraiment, et si les fichiers échantillonnés se parsent sans s'étrangler.
• L'échantillon d'URL montre les emplacements exacts que tu soumets, plus les valeurs de lastmod posées dans le XML.
• L'audit de statut tape sur un échantillon en direct, parce qu'un 404 ou un 5xx adore se cacher dans du markup qui se parse proprement.
• Le guide d'actions garde les problèmes de découverte d'un côté et les questions d'indexabilité au niveau de la page de l'autre.

Comment juger une URL soumise

Chaque URL d'un sitemap devrait vraiment être la version préférée, publique et canonique de cette page. Le bon protocole, le bon host, un code de statut sain, pas de jumeau accidentel, et ça devrait coller avec la façon dont tu y fais des liens en interne. Là où ça dérape : une vieille URL qui redirige maintenant, une section privée qui a fuité dedans, une archive en noindex que tu as oublié d'exclure, une page supprimée qui crache un 404. Le XML peut rester techniquement valide à travers tout ça. Le signal de recherche en dessous reste un beau bazar.

Le lastmod, c'est un truc à lire avec attention. Une valeur manquante ne veut pas dire que ton sitemap est cassé, malgré ce que certains outils laissent entendre. Une valeur fausse est sans doute pire que pas de valeur du tout. Voilà comment j'y pense : le lastmod est un signal de changement, et il devrait suivre les vraies mises à jour de page, mais seulement si ton générateur sait produire des dates honnêtes. Dès qu'un plugin bump le lastmod sur chaque URL pour le moindre événement insignifiant, tout le champ devient du bruit et tu ne peux plus t'y fier en plein audit. C'est peut-être juste moi, mais je préfère pas de date du tout à une date bidon.

Des vérifications de sitemap utiles sous WordPress

Tu viens de publier en masse, de déplacer du contenu des pages vers les articles, de renommer des catégories, de changer de plugin SEO, de réécrire des permalinks, ou de vider le cache du sitemap ? Va revérifier le sitemap racine. Confirme que le sitemap d'articles que tu attends est bien là, ouvre quelques lignes échantillonnées, et teste directement deux ou trois de tes nouvelles URL importantes. Si une URL n'est pas encore apparue, ne va pas accuser Search Console tout de suite. Assure-toi d'abord qu'elle est publiée, indexable, liée depuis un hub qui compte, et que tes règles de plugin l'incluent seulement.

Les sitemaps et Google Search Console

Si ton site a une pile de sitemaps enfants, soumets juste l'index. C'est le point de départ le plus propre. Search Console te remontera ensuite les problèmes de fetch et les URL découvertes au fil des jours suivants, ce qui est super, mais c'est lent. Un audit local garde quand même toute sa valeur parce qu'il attrape les bêtises tout de suite : mauvais host, un fichier enfant périmé, des lignes de 404 surprises, une sortie non HTTPS après une migration, ou un sitemap qui a cessé de se parser à la seconde où un changement de cache ou de plugin est passé en prod. Pourquoi attendre qu'un crawler te dise ce que tu peux voir en cinq secondes. Le protocole sitemaps.org et la documentation Google Search Central sont les références à garder sous la main.

Un workflow de sitemap concret

1. Lance l'analyseur sur le sitemap index que tu as soumis pour ton host canonique.
2. Survole l'échantillon des enfants et assure-toi que les sections que tu t'attendais à voir sont bien là.
3. Passe en revue les lignes d'URL. Protocole, hostname, doublons, motifs de lastmod, tout ce qui ne devrait absolument pas s'y trouver.
4. Fais un contrôle de statut sur les URL qui comptent avant de harceler un crawler pour qu'il revienne.
5. Ensuite, associe tout ça à des vérifications robots, indexabilité et canonical sur tes pages importantes. Les liens internes aussi.

Questions fréquentes

Est-ce qu'un sitemap garantit l'indexation ?

Non. Il aide à la découverte et c'est là que ça s'arrête. La page elle-même doit toujours être accessible, techniquement indexable, réellement utile et reliée au reste de ton site. Google doit aussi décider qu'elle vaut la peine d'être gardée.

Faut-il garder les URL redirigées dans un sitemap ?

En général non, à supposer que tu contrôles le sitemap. Pointe-le plutôt vers la destination canonique finale. Les redirections gardent leur utilité pour les vieux liens entrants et les migrations, mais ton sitemap est censé décrire les URL que tu veux faire trouver maintenant, pas celles qui existaient autrefois.

Un sitemap peut-il être valide tout en restant de mauvaise qualité ?

Absolument. Le XML peut se parser sans la moindre erreur tout en s'occupant de soumettre des pages maigres, des archives en double et des URL mortes. Certaines de ces pages pourraient même être bloquées par d'autres signaux entièrement. C'est exactement pour ça qu'un audit doit regarder la structure et faire des sondages sur les vraies URL, pas l'un ou l'autre.

Combien d'URL un sitemap peut-il contenir ?

La limite est de 50000 URL, ou 50 Mo non compressés, le premier des deux que tu atteins. Dépasse l'une des deux limites et il te faudra découper le truc en plusieurs sitemaps, puis tous les lister dans un sitemap index. Honnêtement, la plupart des sites n'en approchent jamais.