Un script maison de génération de sitemap, écrit avant l’arrivée du générateur natif de WordPress et jamais retiré depuis, continuait de tourner en parallèle sur ce site pour couvrir un besoin spécifique : indexer également le contenu d’une recherche interne enregistrée, une fonctionnalité propre à ce projet. Ce script interrogeait directement la table wp_posts via $wpdb, sans passer par l’API WP_Query, pour des raisons de performance perçue au moment de son écriture initiale.
Le problème est apparu progressivement, à mesure que le site accumulait du contenu : le temps de génération du sitemap, initialement de quelques centaines de millisecondes, dépassait les huit secondes après trois ans de publication régulière, au point de déclencher des temps d’attente visibles pour les robots qui tentaient de le récupérer.
Le diagnostic dans les requêtes SQL
L’activation temporaire de l’extension Query Monitor a révélé la cause : la requête du script sélectionnait toutes les lignes de wp_posts dont le post_type valait post, sans jamais filtrer sur la colonne post_status. Or chaque révision d’un article enregistrée par WordPress porte exactement le même post_type que l’article original, avec un post_status à inherit et un post_parent pointant vers l’article dont elle dérive.
Sur un site publiant régulièrement et où les rédacteurs enregistraient leurs brouillons plusieurs fois avant publication, chaque article accumulait en moyenne une dizaine de révisions, multipliant d’autant le volume de lignes réellement parcourues par la requête, bien au-delà du nombre de publications visibles pour un lecteur.
Pourquoi wp_revisions_to_keep() ne suffisait pas
Le filtre wp_revisions_to_keep(), qui permet de limiter le nombre de révisions conservées par publication, avait bien été configuré à cinq sur ce site — une précaution déjà en place pour limiter la taille de la base de données. Cette limite agit uniquement sur la conservation future des révisions, pas sur celles déjà enregistrées au moment de son activation, et surtout elle ne change rien à une requête qui, par construction, ne filtre pas sur le statut des publications : réduire le nombre de révisions atténue le problème sans le résoudre à la racine.
La correction de la requête
La correction consistait à ajouter une condition explicite sur post_status, restreignant la sélection aux seules publications réellement publiées :
$resultats = $wpdb->get_results(
"SELECT ID, post_modified_gmt FROM {$wpdb->posts}
WHERE post_type = 'post'
AND post_status = 'publish'
ORDER BY post_modified_gmt DESC"
);
Ce simple ajout a ramené le temps de génération du sitemap à moins de trois cents millisecondes, en excluant du même mouvement les révisions, les brouillons automatiques et les éléments placés en corbeille, qui portaient également le post_type post sans être des contenus destinés à l’indexation.
Prévenir la récidive
- Toute requête directe en SQL sur la table
wp_postsdoit systématiquement filtrer surpost_status, à défaut de passer parWP_Queryqui applique ce filtre par défaut. - Un index composite sur les colonnes
post_typeetpost_statusaccélère ce type de requête sur les tables volumineuses, WordPress en crée d’ailleurs un par défaut à l’installation. - Documenter les scripts maison antérieurs au générateur natif reste utile pour éviter qu’ils ne survivent, oubliés, à plusieurs années de croissance du contenu.
Une requête qui fonctionne sur cent publications ne garantit rien sur dix mille. Le filtre oublié aujourd’hui devient le ralentissement mesuré demain.
En résumé
Les révisions WordPress, invisibles pour un visiteur, partagent la même table et le même type de contenu que les publications qu’elles versionnent. Toute requête directe qui ignore le filtre sur post_status les inclura silencieusement, avec un effet d’autant plus marqué que le site vieillit et accumule du contenu. Passer par WP_Query quand c’est possible, ou filtrer explicitement sinon, évite ce type de dérive progressive.
