Un blog qui publie régulièrement finit par accumuler des dizaines, parfois des centaines de pages. Sans mécanisme centralisé pour les relier, une partie de ces contenus devient invisible, autant pour les lecteurs que pour les robots d’exploration. Le plan du site, qu’il soit au format XML ou HTML, joue ce rôle de cartographie interne. Sa mise en place soulève des questions techniques précises, souvent mal comprises.
Sitemap XML et plan de site HTML : deux logiques distinctes pour un blog
La confusion entre sitemap XML et plan de site HTML persiste dans la plupart des guides. Les deux fichiers portent le même nom, mais ne s’adressent pas aux mêmes destinataires et ne remplissent pas la même fonction.
Le sitemap XML est un fichier de contrôle qualité, pas un inventaire brut. Selon la documentation de Google Search Central, il devrait contenir uniquement des URL canoniques, accessibles, indexables et répondant normalement. Les redirections, les erreurs 404, les pages marquées noindex et les doublons n’y ont pas leur place.
Sur un blog WordPress, la plupart des extensions génèrent ce fichier automatiquement, mais sans filtrage : les pages d’archives, les tags peu utilisés et les brouillons publiés par erreur s’y glissent souvent.
Le plan de site HTML, lui, est une page visible destinée aux visiteurs. Il liste les rubriques et les articles selon une arborescence lisible. Pour un blog organisé en catégories thématiques, cette page offre un point d’entrée alternatif au menu principal. Consulter le plan du site de AllBlogger Tips donne un aperçu concret de ce que produit cette approche sur un blog actif.
Traiter ces deux formats comme interchangeables conduit à des erreurs : un sitemap XML surchargé de pages inutiles dilue le budget de crawl, tandis qu’un plan HTML mal structuré n’apporte rien à la navigation.
Budget de crawl et indexation : ce que le sitemap ne résout pas seul
Une idée répandue veut qu’il suffise de soumettre un sitemap à Google pour que toutes les pages soient indexées. La réalité documentée par Google est plus nuancée : un sitemap ne garantit ni l’exploration ni l’indexation. Il signale aux robots les URL que l’éditeur juge importantes, sans obligation de traitement.
Pour un blog de taille modeste (quelques dizaines d’articles), le sitemap a surtout une fonction de signal. Les robots découvrent la majorité des pages via les liens internes. En revanche, sur un blog qui dépasse plusieurs centaines de publications, le sitemap devient un outil de priorisation. La balise lastmod, par exemple, peut orienter les robots vers les articles récemment mis à jour.
La balise lastmod : fiable seulement si elle est honnête
La documentation Google précise que lastmod n’est utile que si elle reflète une modification substantielle du contenu principal, des données structurées ou des liens. Modifier un détail cosmétique (une virgule, un espace) pour rafraîchir la date revient à envoyer un faux signal. Les robots finissent par ignorer cette balise sur les sites qui en abusent.
Sur WordPress, certaines extensions mettent à jour lastmod à chaque sauvegarde, même sans changement réel. Vérifier ce comportement dans les réglages du plugin évite de décrédibiliser le sitemap entier.
Liens internes et arborescence : le complément que le sitemap ne remplace pas
Le sitemap XML facilite la découverte des pages, mais c’est le maillage interne qui détermine leur poids relatif. Un article orphelin (sans lien entrant depuis d’autres pages du blog) a peu de chances d’être exploré en priorité, même s’il figure dans le sitemap.
Trois mécanismes complémentaires méritent une attention particulière :
- Les liens contextuels entre articles permettent aux robots de comprendre les relations thématiques entre les contenus, et aux lecteurs de prolonger leur lecture
- La navigation par catégories et sous-catégories structure l’arborescence du blog de façon hiérarchique, ce qui aide les moteurs à identifier les pages piliers
- Le plan de site HTML offre un filet de sécurité : si un article n’est relié à aucune catégorie active, il reste accessible depuis cette page centralisée
Un blog dont la structure interne repose uniquement sur le sitemap XML, sans maillage éditorial, ressemble à une bibliothèque dont les livres seraient catalogués mais jamais rangés sur les étagères.
Soumettre un sitemap en 2024 : ce qui a changé côté Google
Le mécanisme de notification automatique de sitemap (le « ping ») a été déprécié par Google le 26 juin 2023. Les requêtes envoyées à l’ancien endpoint renvoient désormais une erreur 404. Pour les blogueurs qui utilisaient des outils de soumission automatique, ce changement implique de revoir leur méthode.
Deux canaux restent opérationnels :
- La déclaration du sitemap dans le fichier robots.txt, via la directive Sitemap: suivie de l’URL complète du fichier XML
- L’envoi manuel ou programmé via Google Search Console, qui permet aussi de vérifier le nombre d’URL soumises, découvertes et indexées
La Search Console reste le seul outil qui fournit un retour sur l’état réel de l’indexation. Un sitemap soumis sans suivi n’offre aucune visibilité sur les pages ignorées ou en erreur.
Fréquence de mise à jour du sitemap
Sur un blog qui publie plusieurs articles par semaine, le sitemap doit se régénérer automatiquement à chaque publication. La plupart des CMS modernes gèrent ce processus nativement. Sur un blog moins actif, une régénération hebdomadaire suffit. L’objectif est que le sitemap reflète fidèlement l’état réel du blog à tout moment, sans URL fantômes ni pages supprimées.
Le plan du site, qu’il soit XML ou HTML, n’est pas un outil miracle. Il fonctionne comme un complément au maillage interne, à la qualité du contenu et à une arborescence réfléchie. Les blogs qui en tirent le meilleur parti sont ceux qui l’intègrent dans une routine de maintenance globale, en vérifiant régulièrement la cohérence entre le sitemap, les pages réellement en ligne et les données remontées par la Search Console.
