Anatomie du sitemap XML natif de WordPress 5.5 : wp-sitemap.xml décortiqué

La sortie de WordPress 5.5 en août 2020 est passée un peu inaperçue sur ce point précis, éclipsée par les mises à jour automatiques des extensions et le lazy-load natif des images. Pourtant, l’ajout d’un sitemap XML natif, sans extension à installer, change discrètement une habitude vieille de plus de dix ans : celle d’installer systématiquement un plugin uniquement pour cette fonctionnalité.

Avant de décider si ce sitemap natif suffit à un projet ou s’il faut le remplacer, il faut comprendre comment il est réellement construit. Ce n’est pas un simple fichier statique généré une fois pour toutes, mais une structure dynamique, assemblée à la volée à chaque requête.

Un index qui pointe vers des sous-sitemaps

À l’adresse /wp-sitemap.xml, WordPress n’affiche pas directement la liste de toutes les URL du site. Il affiche un fichier d’index, qui renvoie vers des sous-sitemaps organisés par type d’objet : un pour les articles, un pour les pages, un pour chaque taxonomie publique, et un pour les auteurs qui ont publié du contenu.

<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://exemple.fr/wp-sitemap-posts-post-1.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://exemple.fr/wp-sitemap-taxonomies-category-1.xml</loc>
  </sitemap>
</sitemapindex>

Cette architecture en deux niveaux repose sur la classe WP_Sitemaps, qui délègue la construction de chaque type de contenu à un fournisseur dédié (WP_Sitemaps_Posts, WP_Sitemaps_Taxonomies, WP_Sitemaps_Users). Chacun sait interroger sa propre source de données et générer les URL correspondantes, sans que WordPress ait à tout centraliser dans une seule requête gigantesque.

La limite de 2 000 URL par sous-sitemap

Chaque sous-sitemap est plafonné à 2 000 URL, une valeur définie par la constante interne du cœur et modifiable via le filtre wp_sitemaps_max_urls. Au-delà de ce nombre, WordPress crée automatiquement un sous-sitemap supplémentaire (wp-sitemap-posts-post-2.xml, puis -3, ainsi de suite), sans intervention nécessaire côté développeur.

Ce découpage automatique évite les fichiers sitemap trop volumineux, que certains moteurs de recherche traitent plus lentement ou tronquent purement et simplement. C’est une différence notable par rapport à certaines anciennes extensions qui généraient un fichier unique et pouvaient dépasser des limites de taille sur de très gros sites sans que personne ne s’en aperçoive immédiatement.

add_filter( 'wp_sitemaps_max_urls', function( $max_urls ) {
    return 500;
}, 10, 1 );

Ce qui est inclus, et ce qui ne l’est pas

Le sitemap natif se limite volontairement au contenu public et indexable :

• Les articles et pages publiés, à l’exclusion des brouillons, des contenus en attente et des révisions.
• Les types de contenu personnalisés déclarés avec 'public' => true et 'show_in_rest' => true dans register_post_type().
• Les taxonomies publiques, dans les mêmes conditions.
• Les pages d’auteur, uniquement pour les comptes ayant publié au moins un contenu public.

En revanche, il n’inclut ni les dates de dernière modification affinées par type de contenu (au-delà de post_modified), ni les priorités relatives entre pages, ni les fréquences de mise à jour, des champs que l’ancienne spécification sitemaps.org autorisait mais que Google lui-même a annoncé ignorer très largement. Il ne génère pas non plus de sitemap d’images ou de vidéos dédié, contrairement à ce que proposent certaines extensions spécialisées.

Un contenu peut-il être exclu volontairement ?

Oui, via le filtre wp_sitemaps_post_types pour retirer un type de contenu entier du sitemap, ou wp_sitemaps_posts_query_args pour affiner la requête utilisée sur un type donné :

add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
    unset( $post_types['piece_jointe'] );
    return $post_types;
} );

Cette flexibilité par filtre est justement ce qui permet, dans un article suivant sur la personnalisation avancée du sitemap natif, d’aligner précisément son contenu avec la stratégie de référencement du site, sans devoir réécrire tout le mécanisme depuis zéro.

La première fois que j’ai regardé /wp-sitemap.xml sur un site fraîchement mis à jour vers WordPress 5.5, j’ai été surpris par sa sobriété. Pas de fioritures, juste les URL essentielles, bien découpées. C’est exactement ce qu’un sitemap doit être.

En résumé

Le sitemap natif de WordPress 5.5 repose sur une architecture simple mais solide : un index, des sous-sitemaps par type d’objet, un découpage automatique à 2 000 URL. Il couvre correctement les besoins d’un site de contenu classique, sans configuration, ce qui en fait une bonne base par défaut. Pour des besoins plus spécifiques, comme des sitemaps d’images ou de vidéos, ou une exclusion fine de certains contenus, les filtres natifs suffisent la plupart du temps à l’ajuster sans installer d’extension supplémentaire.