Guide · Plan de site
Un plan de site qui dit vrai
Presque tous les sites ont un sitemap.xml. Beaucoup moins ont un plan de site exact. La différence tient à un seul champ, bien plus qu’au format qui reste trivial : la date de dernière modification. C’est celui qu’on remplit le plus vite, celui qu’on vérifie le moins, et celui qui décide de l’ordre dans lequel un moteur repasse chez vous.
Cinq choses qu’un plan déclare
Chaque ligne d’un plan de site est une affirmation sur votre site, et un moteur la traite comme telle. Les cinq points ci-dessous se vérifient sur pièces, depuis le fichier servi.
01
Un plan de site déclare, le moteur décide
Le fichier sitemap.xml liste les adresses que vous voulez voir indexées, et pour chacune la date à laquelle elle a changé pour la dernière fois. Un moteur s’en sert pour découvrir ce qui lui manque encore et pour décider où revenir en premier. Il reste maître de son parcours : il vous lit.
Le voir : Demandez /sitemap.xml et lisez-le. Chaque entrée doit être une page réelle, servie en 200, à l’adresse exacte que le site publie — même protocole, même domaine, même barre oblique finale.
Le tenir : Un plan généré par la publication elle-même. Une liste écrite à la main dérive dès la deuxième mise en ligne.
02
La date est le champ le plus souvent faux
C’est notre propre incident, du 27 août 2026 : six pages sur sept annonçaient « modifiée le 17 août » dans notre plan de site, pendant qu’IndexNow prévenait les moteurs que ces pages venaient de changer. Les deux signaux se contredisaient. La cause tenait en une ligne — les dates étaient écrites à la main. Une date à la main finit toujours par mentir.
Le voir : Prenez trois pages au hasard dans votre plan et comparez leur lastmod à la dernière modification réelle de leur texte. Si les trois portent la même date, ou la date du jour, vous lisez un horodatage de publication là où le moteur attend une date de modification.
Le tenir : Un script compare le texte visible de la page qu’on s’apprête à publier à celui de la page actuellement en ligne, et ne date d’aujourd’hui que ce qui a réellement changé. Les autres pages gardent leur date. C’est la correction que nous avons posée, et c’est celle qui tient.
03
Ce qu’un moteur fait d’une date qui ment
Une date sert à hiérarchiser des passages. Si tout un site se redate à chaque mise en ligne, toutes ses pages se ressemblent : le signal s’aplatit, et le moteur revient au rythme qu’il avait choisi de lui-même. L’ordre des visites reste alors le sien ; une date exacte est le seul levier qu’un plan vous donne dessus.
Le voir : Publiez une correction sur une seule page, puis relisez le plan. Une seule ligne doit avoir bougé.
Le tenir : Une date qui ne bouge que sur un changement de contenu. Le 7 septembre 2026, un audit de notre site a montré que le plan datait toutes les pages à chaque publication ; quatre causes distinctes ont été corrigées, et le script a ensuite rendu le plan intact, chaque page gardant sa date.
04
Ce qu’un plan contient
Une adresse mérite sa place dans le plan quand trois conditions tiennent ensemble : le chemin est ouvert à l’exploration par robots.txt, la page se déclare indexable, et son adresse canonique la désigne elle-même. Les trois vont ensemble : inscrire une adresse que le reste du site écarte revient à donner deux consignes contraires dans le même site.
Le voir : Pour chaque adresse du plan : le chemin est-il autorisé par robots.txt ? La page se déclare-t-elle indexable ? Sa canonique désigne-t-elle bien sa propre adresse ?
Le tenir : Garder au plan les seules pages que vous assumez comme indexables. Un plan est exactement cela : la liste des pages que vous voulez voir indexées.
05
Les versions de langue font partie du plan
Une page traduite est une page à part entière : elle doit être soumise comme les autres, et son appartenance au groupe doit se lire depuis le plan. Le plan de seorecords.com porte, pour chaque page, le cluster hreflang complet en xhtml:link.
Le voir : Ouvrez une entrée du plan qui correspond à une page traduite. Elle doit lister toutes les langues du groupe, et cette liste doit être la même d’une entrée à l’autre.
Le tenir : Générer le cluster au même endroit que le plan, à partir de la même source. Deux listes tenues séparément divergent.
Vérifier son plan en quatre gestes
Ces quatre gestes se font à l’œil nu, avec le fichier sous les yeux. Ils demandent seulement de le lire au lieu de le supposer juste.
- 01Demandez le fichier et vérifiez qu’il revient en 200 et en XML : une page d’erreur déguisée se trahit à son contenu.
- 02Comptez ses adresses et comparez ce nombre à celui des pages que vous voulez indexées. Un écart franc se lit tout de suite.
- 03Tirez trois adresses au hasard et suivez-les : code de réponse, canonique, consigne d’indexation.
- 04Publiez une seule correction, puis relisez le plan : une seule date doit avoir changé.
Une remarque tirée de nos deux passages : le plan est le dernier endroit où l’on cherche une erreur, parce qu’il est généré et qu’on le croit donc mécanique. Il le devient vraiment le jour où on le relit. Chez nous, il a fallu deux relectures successives pour que la date dise la vérité, ligne à ligne — et c’est aujourd’hui un contrôle qui tourne à chaque publication.
Lire votre plan tel qu’un moteur le lit
Le Vérificateur lit votre adresse et vous rend l’état de vos signaux, gratuitement, en une dizaine de secondes. Votre site reste exactement le vôtre : la lecture se fait de l’extérieur. L’Audit SEO Records va plus loin : il lit votre plan entier, page par page, et vous remet le constat daté.