# Personnaliser le sitemap natif de WordPress avec les filtres wp_sitemaps_*

> Le sitemap natif de WordPress se personnalise entièrement par filtres, sans toucher au cœur. Exclusion de contenus, ajout de dates, réglages fins : le tour de la question.

- Auteur : Clément Hadrot
- Publié le : 2020-11-17
- Mis à jour le : 2020-11-17
- Catégorie : SEO & GEO
- URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/personnaliser-sitemap-natif-wordpress-filtres/

## L’essentiel

- wp_sitemaps_post_types pour exclure un type de contenu entier
- wp_sitemaps_posts_query_args pour affiner la requête
- wp_sitemaps_add_provider pour ajouter une source personnalisée

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

> L'essentiel à retenir : wp_sitemaps_post_types pour exclure un type de contenu entier ; wp_sitemaps_posts_query_args pour affiner la requête ; wp_sitemaps_add_provider pour ajouter une source personnalisée

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.

1. Sauvegarder la fonction ajoutée dans un plugin maison ou dans le `functions.php` du thème enfant.
2. 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.
3. 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.