Un site de contenu éditorial constatait depuis plusieurs mois une érosion lente mais continue de ses positions, sans qu’aucune modification de contenu ne l’explique. Le trafic organique baissait par paliers, article après article, sans schéma évident. Le diagnostic a fini par révéler une cause inattendue : un plugin de cache page entière, trop agressif dans sa durée de rétention, qui servait aux robots une version vieille de plusieurs mois du site.
Ce retour d’expérience détaille comment ce problème a été identifié, puis corrigé, sans entrer dans la question plus large du choix d’un CDN, qui relève d’une architecture différente.
Le contexte du diagnostic
Le plugin de cache était configuré avec une durée de conservation de 30 jours et, surtout, sans mécanisme de purge automatique lors de la modification d’un article. Chaque mise à jour de contenu — correction, ajout de section, mise à jour d’une donnée chiffrée — n’était donc répercutée dans la version mise en cache qu’après expiration naturelle du délai, voire jamais si la page recevait un trafic suffisant pour être régulièrement régénérée par un visiteur avant l’expiration.
Ce que révélait la comparaison des versions
Le test décisif a consisté à comparer, via l’outil d’inspection d’URL, le code HTML tel que Google l’avait explorée avec le code HTML réel de la page à l’instant présent. L’écart était net : des paragraphes ajoutés récemment n’apparaissaient pas dans la version explorée, alors qu’ils étaient bien visibles pour un visiteur humain non passé par le cache.
Cette différence s’expliquait par un comportement précis du plugin : les robots, identifiés par leur user-agent, recevaient systématiquement la version en cache la plus ancienne disponible, tandis qu’un mécanisme de contournement du cache pour les utilisateurs connectés faussait les tests manuels effectués par l’équipe, qui voyait toujours la version à jour sans s’en rendre compte.
La correction appliquée
- Réduction de la durée de cache de 30 à 7 jours pour les contenus éditoriaux
- Ajout d’une purge ciblée de l’URL concernée déclenchée au hook
save_post, à chaque publication ou modification d’article - Suppression du traitement différencié par user-agent qui isolait les robots de la version réelle
add_action( 'save_post', function( $post_id ) {
if ( wp_is_post_revision( $post_id ) ) {
return;
}
$url = get_permalink( $post_id );
// fonction de purge fournie par le plugin de cache
purger_cache_url( $url );
} );Le délai de récupération observé
Après la correction, les positions n’ont pas rebondi immédiatement : il a fallu attendre le passage effectif des robots sur chaque URL corrigée pour que la version à jour soit reprise en compte. Sur ce site, la majorité des pages stratégiques ont retrouvé une version fraîche en une dizaine de jours, avec un rétablissement progressif des positions sur les six semaines suivantes.
Ce que ce cas nous a appris : un audit de positions qui baissent doit toujours inclure une comparaison entre ce que le robot voit réellement et ce que l’équipe voit dans son navigateur, avant de chercher une cause purement éditoriale.
Ce qu’il faut vérifier sur un site avec cache agressif
Tout site utilisant un cache page entière avec une longue durée de rétention gagne à vérifier régulièrement que la version servie aux robots correspond à la version réelle, en particulier après un changement de configuration du plugin de cache ou une migration d’hébergement. Ce contrôle simple, via l’outil d’inspection d’URL, aurait permis de détecter ce problème bien avant qu’il n’affecte durablement le trafic organique du site.
En résumé
Un plugin de cache mal réglé peut créer un décalage silencieux et durable entre le contenu réel d’un site et ce qu’en perçoivent les robots d’indexation, sans qu’aucune erreur explicite ne signale le problème. Ce cas rappelle qu’un audit de baisse de positions doit systématiquement passer par une vérification de ce que voit réellement le robot, avant de chercher une explication purement liée au contenu.
