Fin 2020, WordPress 5.5 introduisait un générateur de sitemap XML natif, sans plugin. Trois versions majeures plus tard, en cette fin d’année 2023, l’équipe core n’a toujours pas ajouté la moindre balise <image:image> ou <video:video> à ce sitemap. Ce constat, on le vérifie à chaque nouvel audit technique : le sitemap natif liste des URL nues, sans aucune information sur les médias qu’elles contiennent.
Ce bilan reprend, version par version, ce qui a été corrigé côté sitemap natif depuis son lancement, et ce qui manque toujours cruellement pour les sites à forte composante visuelle.
Ce que le sitemap natif fait depuis l’origine
Depuis WordPress 5.5, la classe WP_Sitemaps_Posts génère automatiquement un sitemap par type de contenu, avec pagination automatique au-delà de 2 000 URL par fichier via la constante wp_sitemaps_max_urls. C’est robuste, correctement mis à jour, et suffisant pour l’essentiel du texte. Mais la structure XML ne prévoit aucun espace de noms pour les médias, contrairement au protocole complet de sitemaps qui définit pourtant les extensions image et video depuis longtemps.
5.6 à 5.8 : des correctifs de robustesse, pas de fonctionnalité
Entre fin 2020 et l’été 2021, les correctifs apportés au module sitemaps ont surtout concerné la compatibilité PHP 8 introduite en 5.6, et la gestion des types de contenu personnalisés exclus par erreur du sitemap. Aucun ticket Trac de cette période n’a abouti à l’ajout de balises médias : le sujet a été évoqué, puis repoussé faute de consensus sur le format de stockage des métadonnées d’image nécessaires.
5.9 et 6.0 : l’arrivée de l’éditeur de site change la donne
Avec l’éditeur de site complet en janvier 2022, les images deviennent omniprésentes dans les blocs de contenu, mais le générateur de sitemap continue d’ignorer leur existence. Un correctif notable de cette période a corrigé un bug qui excluait certaines pages de type wp_template du sitemap par erreur, sans lien direct avec les médias.
6.1 à 6.3 : les correctifs viennent de l’écosystème, pas du core
Faute de solution native, l’écosystème a comblé le vide. Plusieurs extensions dédiées et des modules ajoutés à des solutions SEO généralistes exploitent le filtre wp_sitemaps_posts_entry pour injecter des données image directement dans les entrées existantes, en parsant le contenu du post à la recherche des balises <img> et de leurs attributs src et alt.
add_filter( 'wp_sitemaps_posts_entry', function( $entry, $post ) {
if ( has_post_thumbnail( $post ) ) {
$entry['images'] = array(
get_the_post_thumbnail_url( $post, 'full' ),
);
}
return $entry;
}, 10, 2 );
Ce type de filtre reste artisanal : il faut ensuite sérialiser soi-même ces données dans le bon espace de noms XML au moment du rendu, ce que le core ne prévoit pas nativement, obligeant à surcharger la classe de rendu du sitemap.
Ce qui reste fragile fin 2023
- Aucune extension native pour les balises
<video:video>, alors que le protocole sitemap les définit depuis des années. - Les images issues de galeries en blocs (bloc Galerie) ne sont détectées par aucun des correctifs communautaires les plus courants, qui se limitent à l’image mise en avant.
- Le sitemap natif ne propose toujours aucun hook de haut niveau pour enregistrer un espace de noms XML personnalisé sans réécrire une partie du rendu.
Ce que ce bilan implique pour un projet en cours
Sur un site e-commerce ou un blog fortement illustré, s’appuyer uniquement sur le sitemap natif revient à indexer le texte et laisser filer une bonne partie du potentiel Google Images. Nous recommandons systématiquement, sur ce type de projet, un plugin dédié ou un module additionnel générant un sitemap image séparé, référencé indépendamment dans robots.txt.
Un sitemap qui ne parle que de texte, sur un site qui vit d’images, c’est la moitié du travail d’indexation qui reste sur le trottoir.
Notre verdict
Trois versions majeures après son lancement, le sitemap natif de WordPress reste une fondation solide mais incomplète. Les correctifs successifs ont renforcé sa fiabilité générale sans jamais combler l’absence de support médias, un choix qui semble désormais assumé par le projet plutôt que temporaire. Pour tout site où l’image ou la vidéo pèse dans la stratégie d’acquisition, la dépendance à un module tiers n’est pas une option, c’est une nécessité qui ne devrait pas évoluer à court terme.
