Pourquoi un article publié depuis trois semaines n’apparaît-il toujours pas dans le sitemap XML généré par Yoast SEO ? La question s’est posée sur un projet où le contenu principal de chaque fiche produit était affiché par un bloc dynamique personnalisé, avec un render_callback qui allait chercher les données en base au moment de l’affichage plutôt que de les stocker dans post_content.
Le sitemap n’a rien à voir avec ce mécanisme d’affichage : il liste les articles publiés d’un type de contenu donné, indépendamment de ce qu’ils affichent. Le vrai problème, dans ce cas précis, se situait ailleurs — dans le statut de publication réel des fiches produit, masqué par un comportement du bloc qui laissait croire que tout allait bien côté éditeur.
Le sitemap Yoast ne regarde pas le rendu du bloc
Yoast SEO construit son sitemap à partir d’une requête sur les types de contenu publics et publiés, via l’API WP_Query, filtrée par le statut publishet par les réglages de visibilité SEO (indexable ou non, définis par extension via wpseo_sitemap_exclude_post). Il ne relit jamais le HTML produit par un render_callback : à ses yeux, un article publié est un article publié, quel que soit son contenu affiché.
Le diagnostic a donc commencé par une vérification simple : les fiches manquantes étaient-elles vraiment publiées ? Une requête directe en base a montré que plusieurs dizaines de fiches produit étaient en statut draft, alors que l’éditeur, lui, affichait un contenu qui semblait complet et publié.
Le vrai coupable : un bloc qui masque l’état réel de l’article
Le bloc en question stockait son identifiant produit en attribut, mais son save() renvoyait une chaîne vide (bloc entièrement dynamique). Résultat : l’éditeur affichait toujours un contenu correct via ServerSideRender, même quand l’article racine n’avait en réalité jamais été publié — seule une prévisualisation avait été enregistrée par erreur lors d’un import CSV.
Vérifier le statut réel des articles concernés
La commande WP-CLI suivante liste rapidement les statuts d’un type de contenu personnalisé, sans avoir à ouvrir chaque fiche dans l’éditeur :
wp post list --post_type=produit --fields=ID,post_title,post_status --format=table
Sur ce projet, la commande a révélé 47 fiches en draft sur un total de 312, toutes issues du même lot d’import. Un simple changement de statut en masse a résolu la majorité du problème :
wp post list --post_type=produit --post_status=draft --field=ID | xargs -I{} wp post update {} --post_status=publish
Le cas où le contenu est bien publié mais reste absent
Une fois le statut corrigé, quelques fiches manquaient encore. Cette fois, la cause tenait aux réglages de visibilité SEO de Yoast : le champ _yoast_wpseo_meta-robots-noindex était renseigné à 1 sur ces articles précis, probablement copié par erreur depuis un modèle utilisé pour créer les fiches. Ce champ exclut explicitement l’article du sitemap, indépendamment de son statut de publication.
wp post meta get 128 _yoast_wpseo_meta-robots-noindex
// retourne "1" -> l'article est explicitement exclu du sitemap
Ce qu’il faut vérifier avant d’accuser le bloc
- Le statut de publication réel en base, pas seulement l’aperçu dans l’éditeur.
- Le champ meta
_yoast_wpseo_meta-robots-noindexsur les articles concernés. - Le filtre
wpseo_sitemap_exclude_post, s’il a été personnalisé dans le thème ou une extension maison. - Le cache du sitemap lui-même : Yoast met en cache le fichier XML généré, et une purge peut être nécessaire après correction (
wp option delete wpseo_sitemap_cache_validatorsur les versions concernées, ou simplement une re-sauvegarde des permaliens).
Ce que cet article ne couvre pas
La configuration complète du plugin Yoast SEO — réglages de titres, balisage OpenGraph, gestion des redirections — dépasse largement ce cas précis. De même, le balisage schema.org spécifique aux fiches produit, qui influence le rich snippet dans les résultats de recherche, mérite un traitement à part entière, distinct du problème d’indexation traité ici.
Pour aller plus loin
Un bloc dynamique bien conçu ne devrait jamais donner l’illusion qu’un contenu est publié quand il ne l’est pas. Sur ce projet, la solution de fond a consisté à ajouter un indicateur visuel dans l’éditeur (bordure orange) dès que ServerSideRender affiche un contenu dont l’article source n’est pas en statut publish — un garde-fou simple qui aurait évité des heures de recherche.
