vendredi 25 septembre 2026

À propos

Contact

SEO & GEO

Construire une sitemap d’index séparée pour un site de plus de 50 000 pages

Un catalogue de pièces détachées dépasse les 50 000 références. Recette pour organiser plusieurs sitemaps d'index distincts sans se reposer uniquement sur la pagination native.

Par Clément Hadrot • 30 août 2021 • 4 min de lecture • Aucun commentaire
Construire une sitemap d'index séparée pour un site de plus de 50 000 pages

Un site de vente de pièces détachées pour engins agricoles gère un catalogue de 63 000 références actives, réparties en une dizaine de familles de produits. Le sitemap natif de WordPress, introduit dans le cœur depuis la version 5.5, gère déjà la pagination automatiquement, mais un problème pratique se pose vite pour ce volume : diagnostiquer un problème d’indexation devient difficile quand tout est mélangé dans une structure générique sans repère clair par famille de produits.

Voici comment ce projet a organisé ses sitemaps pour rester lisible malgré le volume, en s’appuyant sur les mécanismes natifs plutôt qu’en les remplaçant.

Ce que WordPress gère déjà nativement

Le sitemap natif de WordPress fonctionne par fournisseurs (WP_Sitemaps_Provider), un par type de contenu principal : articles, pages, et une classe distincte par taxonomie et par type de contenu personnalisé enregistré avec show_in_rest activé. Chaque fournisseur pagine automatiquement ses propres URL par blocs de 2 000, un maximum réglable via le filtre wp_sitemaps_max_urls, et bien en dessous de la limite de 50 000 URL par fichier imposée par le protocole sitemap lui-même.

Le problème réel posé par 63 000 références

Avec 63 000 produits enregistrés comme type de contenu personnalisé produit, le fournisseur de sitemap natif génère automatiquement 32 fichiers paginés (63 000 divisé par 2 000, arrondi au supérieur), tous listés dans l’index principal à /wp-sitemap.xml. Techniquement, cela fonctionne sans erreur. Le problème est organisationnel : impossible de savoir en un coup d’œil dans Search Console si les 4 000 références de la famille « filtres à huile » sont bien toutes couvertes, noyées parmi 32 fichiers numérotés sans distinction par famille.

L'essentiel à retenir : Le protocole sitemap limite chaque fichier à 50 000 URL, la pagination native de WordPress s'arrête à 2 000 ; Un index de sitemaps distinct par type de contenu facilite le diagnostic dans Search Console ; Le filtre wp_sitemaps_max_urls règle la pagination interne, pas le nombre total de fichiers

La variante retenue : un fournisseur par famille de produits

Plutôt que de reconstruire tout le système de sitemap depuis zéro, la solution a consisté à enregistrer un fournisseur de sitemap personnalisé par grande famille de produits, en étendant la classe WP_Sitemaps_Provider native :

function ma_recette_register_sitemap_providers( $sitemaps ) {
    $familles = array( 'filtres-a-huile', 'courroies', 'roulements' );

    foreach ( $familles as $famille ) {
        $provider = new Ma_Sitemap_Famille_Provider( $famille );
        $sitemaps->add_provider( 'produits-' . $famille, $provider );
    }
    return $sitemaps;
}
add_filter( 'wp_sitemaps_add_provider', function ( $provider, $name ) {
    return $provider; // les providers custom sont ajoutés via wp_sitemaps_init plus bas
}, 10, 2 );

add_action( 'init', function () {
    add_action( 'wp_sitemaps_init', function ( $sitemaps ) {
        ma_recette_register_sitemap_providers( $sitemaps );
    } );
} );

Chaque fournisseur personnalisé ne retourne que les URL de sa propre famille, avec sa propre pagination interne héritée de la classe parente. Résultat dans l’index : au lieu de 32 fichiers génériques numérotés, l’index affiche des entrées nommées explicitement produits-filtres-a-huile, produits-courroies, etc., chacune avec sa propre pagination si elle dépasse 2 000 URL.

Variante plus simple pour un besoin ponctuel

Pour un site qui n’a pas besoin d’une segmentation aussi fine, ajuster simplement le filtre wp_sitemaps_max_urls à une valeur plus élevée (jusqu’à 50 000, la limite du protocole) réduit le nombre de fichiers générés sans complexifier le code, au prix d’une lisibilité moindre en cas de diagnostic ciblé sur une sous-catégorie précise.

add_filter( 'wp_sitemaps_max_urls', function () {
    return 10000;
} );

Ce que cette organisation a permis dans Search Console

Une fois les fournisseurs personnalisés en place, le rapport de sitemaps de Search Console a pu être filtré par nom d’entrée, ce qui a permis à l’équipe technique de repérer qu’une des familles de produits, « roulements », affichait un taux d’indexation nettement inférieur aux deux autres, un signal qui serait resté noyé dans un ensemble générique de 32 fichiers numérotés sans nom explicite.

Variantes possibles selon la structure du catalogue

  • Segmentation par marque plutôt que par famille technique, pertinente si le catalogue est organisé autour de fournisseurs distincts.
  • Segmentation par disponibilité (en stock / sur commande), utile si le référencement de ces deux populations doit être suivi séparément.

Ce qu’il faut retenir

Le sitemap natif de WordPress gère très bien le volume brut d’un catalogue de plusieurs dizaines de milliers de pages sans dépassement de limite. Le vrai gain d’une segmentation personnalisée n’est pas technique mais diagnostique : elle transforme un ensemble opaque de fichiers numérotés en une structure lisible, directement exploitable pour surveiller l’indexation famille par famille dans Search Console.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi