Les fichiers Sitemap XML proposent depuis 2005 aux principaux moteurs de recherche une liste des différentes pages d'un site web. Mais pourquoi cette liste ne serait-elle pas mieux structurée hiérarchiquement ?...
Depuis 2005, Google et d'autres moteurs de recherche proposent aux éditeurs de sites web de mettre en place des fichiers Sitemaps au format XML afin de leur permettre de mieux indexer les sites web qu'ils doivent crawler au quotidien. Un fichier Sitemap "classique" a cette forme :
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>http://www.example.com/</loc>
<lastmod>2005-01-01</lastmod>
<changefreq>monthly</changefreq>
<priority>0.8</priority>
</url>
</urlset>
Ces fichiers XML contiennent plusieurs champs :
- L'URL des pages (loc), champ obligatoire bien sûr puisqu'il fournit aux moteurs les adresses de chaque page importante du site.
- Des champs facultatifs : la fréquence de mise à jour (changefreq), la date de dernière modification (lastmod) et la priorité d'indexation (priority). Avouons-le : l'intérêt de ces trois champs est discutable : une fréquence de mise à jour est très complexe à définir (que se passe-t-il si une page est parfois mise à jour quotidiennement puis mensuellement pendant un certain laps de temps ?), il en est de même pour la priorité d'indexation (sur quels critères la définir ?) et, pour ce qui est de la date de dernière mise à jour, on peut penser que Google se débrouille très bien pour la trouver sans l'aide du Sitemap (il en est de même de la fréquence de mise à jour d'ailleurs). D'autant plus que, parfois, il est indiqué la date du jour pour toutes les pages comme date de dernière modification. Bref, ces champs sont facultatifs et peuvent facilement être supprimés du Sitemap final sans réelle incidence sur l'indexation d'un site.
- Au fil des ans, il est devenu possible d'ajouter des indications concernant les images et les vidéos contenues dans une page à l'intérieur du Sitemap "classique".
- Puis d'autres formats de Sitemaps dédiés sont arrivés pour les vidéos, les mobiles, Google News, etc.
Bref, le format des fichiers Sitemaps évolue et connaît, année après année, des nouveautés dans sa structure et ses possibilités.
Mais, finalement, ces fichiers sont globalement linéaires, toutes les URL sont proposées au même niveau. Pourquoi n'y aurait-il pas une extension du format de Sitemap qui permettrait d'indiquer la place de la page dans l'arborescence du site ?
Exemple :
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>http://www.my-spices.com/harissa.html</loc>
<section>world</section>
<section>africa</section>
<section>marocco</section>
</url>
</urlset>
Bien sûr; les URL sont parfois déjà bien structurées à ce niveau-là (http://www.my-spices.com/world/africa/marocco/harissa.html), mais ce n'est pas non plus toujours le cas. Google peut également parfois se servir du TITLE ou du fil d'Ariane (surtout s'il utilise les "rich snippets" adéquats) mais, là encore, la méthode n'est pas fiable à 100%.
Ce ne serait pas plus compliqué de lui indiquer une hiérarchie de l'arborescence du site directement dans les Sitemaps XML, et cela lui rendrait certainement service pour mettre "les bonnes pages aux bons endroits" et avoir, ainsi, une vision claire de l'arborescence d'un site. Et, en tout cas, ce serait, selon nous, beaucoup plus utile que des champs comme la priorité d'indexation ou la fréquence de mise à jour... Enfin, c'est une idée en l'air, on verra bien ce qu'il en est à l'avenir et si Google l'attrape au vol :-)... Et vous, qu'en pensez-vous ?
 Source de l'image :DR |
Articles complémentaires :
Goossips : Sitemaps XML, WordPress et SEO
Le point de terminaison ping des sitemaps va disparaître
Bing rappelle l’importance de la balise lastmod des fichiers Sitemap XML
Goossips : URL Canonique et Sitemap XML
Google améliore l’indexation des offres d’emploi
En tant que blogueur, avec de très nombreux articles, je constate qu’il serait effectivement utile que le sitemap soit une aide à la navigation. En effet, un CMS comme WordPress n’offre pas d’outil efficace pour avoir une vue d’ensemble des articles en un clin d’oeil. Au mieux peut-on utiliser les catégories, certains plugins et autres shortcodes mais sans possibilité de rendre compte des nombreux articles existants.
A ce jour, je dois dire que les sitemaps que l’on trouve sur les blogs sont rebutants et ne donnent pas envie de les exploiter comme aide à la navigation.
Comme le dit Olivier, entre les infos que Google trouve tout seul et celles dont il ne se sert pas forcément, on peut se demander quel est l’intérêt de générer ce fichier.
Autre exemple du foutage de gueule de Google par rapport au sitemap, je me suis aperçu récemment que, bien que mon sitemap indique clairement qu’un type de page allait de 1 à 4 (site.com/page1.html, etc), Google a réussi à me signaler comme contenu dupliqué toutes les pages de ce type jusqu’à environ 10000. Je me suis demandé pourquoi il n’essayait pas d’aller jusqu’à 10000000000 ou plus dans ses tentatives (j’avais oublié de faire une 301 au-delà de 4, mais aucun lien vers la page 10000 dans mon site ou dans un autre). Il n’avait donc aucune raison de tester ces pages. Ce qui prouve bien qu’il recommande de faire un sitemap pour ne pas s’en servir.
Cela doit venir de mon côté bidouilleur php mais je ne vois pas l’intérêt de proposer en doublons des données structurées… Le sitemap fourni les URL, l’URL fournie les données structurées (le contenu quoi), si l’on commence a tout faire en double, cela ne va pas faciliter la maintenance des sites, qui sont déjà (à mon gout), largement abandonnées chez les PME qui ont d’autres chats à fouetter. Quel est l’intérêt de mettre du contenu dans un sitemap ? Le sitemap est fait pour prendre connaissance des URLs en vue de l’indexation. Le contenu de l’URL est quant à lui facteur de positionnement. Je ne crois pas que le sitemap doit devenir un critère influençant le positionnement.
En tout cas cela serait plus « juste » et surement plus utile que le « priority », sans doute un peu plus complexe à monter mais rien d’irréalisable non plus, je vote pour !
@Renaud Joly : plus compliqué pour un CMS qui aura servi à bâtir l’arborescence du site ? Pas si sûr, selon moi, le CMS a déjà toutes les données.
Quant à la navigation naturelle, c’est certes simple pour l’internaute, mais quand on doit se repérer uniquement en lisant le code HTML (comme le fait un robot), c’est beaucoup moins facile selon moi… 🙂
cdt
Une raison peut être que générer un fichier structuré va s’avérer plus compliqué qu’un fichier plat. Une autre qu’il vaut mieux se fier à la navigation ( ie les liens effectifs sur le site ) qu’au sitemap pour analyser la structure du site.
De mon côté, j’aurais même tendance à dire qu’il faudrait aussi produire des associations sémantiques qui vont au-delà de la seule hiérarchie présente sur le site.
Si j’ai des meubles de salon à vendre, je peux aussi les classer dans les meubles en bois.
Mais, sauf à avoir recours à des tonnes de canonical, on ne peut pas avoir plusieurs menus de navigation.
On pourrait ainsi convenir de différentes données-typées telle que les matériaux, époque, etc. Ces données pouvant, à l’instar des microdata, être transversales à tous les sites.
Après, faire cela dans le sitemap ou ailleurs, c’est à voir, mais la compréhension du full-text a ses limites, un peu de structuration ne ferait de mal à personne !
@Référencement Tunisie : pour la page « plan du site pour les internautes », c’est un peu la même chose que pour les URL, les TITLE, etc. : c’est intéressant mais pas fiable à 100%. Et pour les gros sites, le plan du site ne descend pas au niveau granulaire de la page…
Je pense que c’est inutile d’indiquer la hiérarchie de l’arborescence dans le fichier sitemap.xml puisqu’on a déja la page plan. Mais je suis d’accord que les balises et sont inutiles.