Un éditeur de site immobilier m’a demandé un jour pourquoi ses fiches de biens déjà vendus continuaient à apparaître dans le sitemap XML, alors qu’elles n’étaient plus censées être mises en avant. Le type de contenu personnalisé restait public par nécessité technique (l’historique devait rester consultable via une URL directe), mais son inclusion systématique dans le sitemap gonflait inutilement le nombre d’URL soumises à l’exploration, sans aucun bénéfice de référencement.
La bonne réponse, dans ce cas comme dans beaucoup d’autres, ne passait pas par une extension supplémentaire ni par la désactivation totale du sitemap natif, mais par une requête légèrement affinée sur le fournisseur de sitemap concerné. C’est tout l’objet des filtres wp_sitemaps_* introduits avec le sitemap natif de WordPress 5.5.
Exclure un type de contenu entier
Le filtre le plus direct est wp_sitemaps_post_types, qui reçoit le tableau des types de contenu inclus par défaut et permet d’en retirer un ou plusieurs :
add_filter( 'wp_sitemaps_post_types', function( $post_types ) {
unset( $post_types['piece_attachee'] );
return $post_types;
} );Cette approche convient quand un type de contenu entier n’a aucune valeur pour le référencement, par exemple des pièces jointes exposées comme type public pour des raisons purement techniques d’affichage.
Affiner la requête sans exclure tout un type
Le cas de la fiche immobilière vendue est différent : le type de contenu bien doit rester globalement dans le sitemap, seules certaines entrées doivent en sortir selon leur statut de vente. Le filtre wp_sitemaps_posts_query_args permet d’ajuster les arguments de la requête WP_Query sous-jacente, exactement comme on le ferait pour n’importe quelle requête personnalisée :
add_filter( 'wp_sitemaps_posts_query_args', function( $args, $post_type ) {
if ( 'bien' === $post_type ) {
$args['meta_query'] = array(
array(
'key' => 'statut_bien',
'value' => 'vendu',
'compare' => '!=',
),
);
}
return $args;
}, 10, 2 );Cette solution garde tout l’avantage du sitemap natif : découpage automatique, mise à jour dynamique à chaque publication, sans qu’aucune tâche planifiée ne doive régénérer un fichier statique.
Ajouter une source personnalisée avec un fournisseur
Pour des besoins plus atypiques, par exemple exposer une liste de pages générées dynamiquement qui ne correspondent à aucun type de contenu WordPress (des vues d’agrégation, des pages de résultats de recherche sauvegardées), WordPress permet d’enregistrer un fournisseur de sitemap personnalisé via wp_sitemaps_add_provider, en étendant la classe abstraite WP_Sitemaps_Provider.
Cette voie demande davantage de code, mais reste dans l’esprit du système natif : les URL personnalisées apparaissent dans le même index, avec le même découpage automatique par lots de 2 000, sans qu’un système parallèle ne doive être maintenu.
Autres réglages fréquemment demandés
| Besoin | Filtre à utiliser |
|---|---|
| Modifier le nombre d’URL par sous-sitemap | wp_sitemaps_max_urls |
| Retirer une taxonomie entière du sitemap | wp_sitemaps_taxonomies |
| Exclure les pages d’auteur | wp_sitemaps_add_provider (en désenregistrant le fournisseur users) |
| Changer l’espace de noms XML utilisé | wp_sitemaps_init (avec précaution, la spécification est normée) |
Vérifier ses modifications
Après chaque changement, la vérification passe par l’affichage direct de /wp-sitemap.xml puis du sous-sitemap concerné. Sur un site à fort volume, il vaut la peine de comparer le nombre d’URL renvoyées avant et après le filtre, avec wp wp-cli ou un simple comptage dans une requête SQL de contrôle, pour s’assurer que l’exclusion ou l’ajout produit bien l’effet attendu et rien de plus.
- Sauvegarder la fonction ajoutée dans un plugin maison ou dans le
functions.phpdu thème enfant. - Vider tout cache de page existant, le sitemap natif n’étant généralement pas mis en cache par défaut mais certaines configurations de cache serveur peuvent intercepter la requête.
- Comparer le nombre d’entrées du sous-sitemap concerné avant et après la modification.
Sur un site avec plusieurs milliers de contenus, je préfère toujours affiner la requête du fournisseur plutôt que d’exclure un type entier. On garde ainsi la maîtrise fine, sans tout retirer d’un bloc par prudence excessive.
En résumé
Les filtres wp_sitemaps_* couvrent la quasi-totalité des besoins de personnalisation courants : exclusion de type de contenu, affinage de requête, ajout de source personnalisée. Cette flexibilité native évite bien des cas de figure où l’on aurait, il y a encore quelques années, dû installer une extension complète pour un ajustement finalement assez ciblé. Elle demande en contrepartie une compréhension correcte des hooks disponibles, et une vérification systématique après chaque modification.
