Symptôme. Un client signale que la Search Console indique une soumission de sitemap différente de celle configurée dans son extension SEO. En vérifiant, deux fichiers répondent effectivement : /wp-sitemap.xml, le sitemap natif de WordPress, et /sitemap_index.xml, généré par l’extension installée quelques mois plus tôt. Les deux sont valides, les deux listent globalement les mêmes contenus, mais dans un ordre et un découpage différents, et c’est justement cette redondance qui sème le doute.
Diagnostic : pourquoi deux sitemaps coexistent
Le sitemap natif de WordPress, introduit en version 5.5, reste actif par défaut même après l’installation d’une extension SEO complète, sauf si cette dernière prend explicitement soin de le désactiver. La plupart des extensions sérieuses le font, mais certaines configurations spécifiques, ou des extensions plus anciennes mises à jour tardivement pour la compatibilité avec le sitemap natif, peuvent laisser les deux mécanismes actifs simultanément sans avertissement clair.
Le risque n’est pas une pénalité de référencement à proprement parler : Google gère très bien la présence de plusieurs sitemaps déclarés. Le vrai problème est opérationnel : on ne sait plus lequel des deux fichiers fait référence, quelles URL exactement sont soumises, et un contenu exclu manuellement dans l’un peut très bien continuer d’apparaître dans l’autre.
Le filtre officiel : wp_sitemaps_enabled

WordPress prévoit justement un filtre dédié à la désactivation complète du sitemap natif, pensé pour ce cas d’usage précis :
add_filter( 'wp_sitemaps_enabled', '__return_false' );
Une fois ce filtre actif, l’adresse /wp-sitemap.xml renvoie une page 404 standard, et WordPress cesse totalement de générer la structure de sous-sitemaps sous-jacente. C’est la méthode recommandée par la documentation officielle, largement préférable à un blocage au niveau du serveur web (via une règle de réécriture d’URL), qui masquerait le fichier sans réellement désactiver le mécanisme interne, avec un coût de traitement inutile à chaque requête.
Vérifier que son extension le fait déjà
Avant d’ajouter ce filtre soi-même, il faut vérifier que l’extension SEO installée ne le fait pas déjà, sous peine de filtre redondant mais inoffensif. La vérification la plus simple reste directe :
- Ouvrir
/wp-sitemap.xmldans un navigateur. - Si une page 404 s’affiche, l’extension désactive déjà correctement le sitemap natif : rien à faire de plus.
- Si un fichier XML valide s’affiche, comparer son contenu à celui du sitemap propre à l’extension, et ajouter le filtre
wp_sitemaps_enabledpour trancher en faveur d’un seul mécanisme actif.
Un cas particulier : garder le sitemap natif malgré tout
Sur un petit site sans besoin de fonctionnalités SEO avancées, il est tout à fait défendable de faire l’inverse : désinstaller l’extension SEO dédiée au sitemap et garder uniquement le sitemap natif, plus léger et suffisant pour un site de quelques dizaines de pages. La décision dépend surtout du besoin de personnalisation : dès qu’un site a besoin d’exclure des contenus au cas par cas, d’ajouter des images ou des vidéos au sitemap, ou de gérer des priorités par page, le sitemap natif seul montre ses limites et l’extension reprend l’avantage.
Déclarer le bon sitemap dans Search Console
Une fois le choix tranché, il reste une étape souvent oubliée : mettre à jour la déclaration du sitemap dans Google Search Console et dans le fichier robots.txt virtuel généré par WordPress (via le filtre robots_txt), pour ne référencer que le fichier réellement actif. Un ancien sitemap encore déclaré, même désactivé, continue d’être occasionnellement revisité par les robots d’exploration, ce qui génère des erreurs 404 inutiles dans les rapports.
add_filter( 'robots_txt', function( $output, $public ) {
if ( '1' === $public ) {
$output .= "Sitemap: https://exemple.fr/sitemap_index.xml\n";
}
return $output;
}, 10, 2 );
Prévention
Pour éviter ce genre de doublon à l’avenir, un point de vigilance simple à intégrer à toute checklist d’installation d’extension SEO : vérifier systématiquement l’état de /wp-sitemap.xml juste après l’activation, avant de passer à la configuration des autres réglages. Cette vérification prend moins d’une minute et évite des semaines de confusion dans les rapports d’indexation.
Un sitemap, c’est un point de vérité unique pour les robots d’exploration. Dès qu’il y en a deux qui se contredisent, même légèrement, la confiance dans les deux en pâtit.
En résumé
La coexistence de deux sitemaps actifs, natif et fourni par une extension, est un symptôme fréquent mais facile à corriger avec le filtre wp_sitemaps_enabled. Le diagnostic passe par une simple vérification de /wp-sitemap.xml, et la prévention par une vérification systématique à chaque installation d’extension SEO. Le choix final entre les deux mécanismes dépend surtout du besoin de personnalisation du site concerné.