Un audit SEO trimestriel, mené par une agence spécialisée en complément du travail technique déjà réalisé sur un site multilingue, a signalé une anomalie précise : les balises hreflang présentes sur plusieurs dizaines de pages ne référençaient que deux langues, français et anglais, alors que le site proposait officiellement une troisième langue, l’espagnol, ajoutée trois mois plus tôt. Premier réflexe face à ce signalement : vérifier la configuration de WPML, en s’attendant à trouver une langue mal activée ou un contenu non traduit pour l’espagnol.
Cette première vérification n’a rien révélé d’anormal : l’espagnol était bien activé, le contenu bien traduit, et une consultation directe des réglages de génération de balises hreflang de WPML ne montrait aucune anomalie de configuration. Le problème se trouvait ailleurs, dans une couche que l’audit SEO, en analysant le HTML final servi aux visiteurs, avait justement pointée sans le savoir : le cache de page.
Comprendre où se situait l’écart
La configuration interne de WPML, consultée depuis l’administration, générait correctement les trois balises hreflang attendues pour chaque page, y compris celle pointant vers la version espagnole nouvellement ajoutée. Pourtant, un simple curl sur l’URL publique de ces mêmes pages ne renvoyait que deux balises, sans trace de l’espagnol, confirmant que le contenu réellement servi aux visiteurs (et donc aux robots d’indexation) différait de ce que WordPress générait actuellement côté serveur.
curl -s https://exemple.com/produit-phare/ | grep hreflang
Cet écart entre la configuration actuelle et le contenu réellement servi est la signature classique d’un cache de page qui n’a pas été régénéré depuis un changement de configuration antérieur au cache lui-même.
Reconstituer la chronologie du problème
- Le cache de page (géré par une extension de cache combinée à un CDN) avait mis en cache l’ensemble des pages du site environ une semaine avant l’ajout de la troisième langue.
- L’ajout de l’espagnol, effectué correctement côté WPML, a bien modifié la configuration active de génération de balises pour toute nouvelle requête non mise en cache.
- Mais les pages déjà en cache à ce moment-là n’ont jamais été régénérées automatiquement : le cache n’a aucune raison de se rafraîchir tout seul suite à un changement de configuration d’une extension, seul un changement direct de contenu ou une purge manuelle déclenche ce rafraîchissement sur la plupart des configurations standards.
- Résultat : les pages consultées depuis trois mois servaient une version HTML figée avant l’ajout de l’espagnol, avec des balises
hreflangdevenues incomplètes sans que rien ne le signale visuellement aux équipes internes.
Pourquoi ce type d’écart passe inaperçu en interne
L’équipe technique en charge du site consultait systématiquement l’administration WordPress pour vérifier la configuration, jamais le HTML brut réellement servi en façade, une pratique pourtant plus rapide à mettre en place qu’il n’y paraît. Ce réflexe de vérification côté configuration plutôt que côté résultat final explique pourquoi l’anomalie a persisté trois mois avant d’être détectée, uniquement par un audit externe qui, par méthode, analyse systématiquement le HTML brut plutôt que l’interface d’administration.
Depuis cet incident, toute modification de la configuration multilingue d’un site — ajout de langue, changement de structure d’URL — est systématiquement suivie d’une purge complète du cache, documentée dans une check-list de déploiement plutôt que laissée à la mémoire de l’équipe.
La correction, et sa vérification
La correction elle-même n’a nécessité aucune reconfiguration : une simple purge complète du cache de page et du CDN a suffi à régénérer l’ensemble des pages avec la configuration à jour, incluant la troisième langue dans les balises hreflang. La vérification a repris la même méthode que le diagnostic initial, un curl sur un échantillon de pages représentatives, confirmant cette fois la présence des trois langues attendues dans le HTML servi.
curl -s https://exemple.com/produit-phare/ | grep hreflang
# Attendu après purge : trois lignes, fr / en / es
Une vérification automatisée mise en place ensuite
Pour éviter de dépendre uniquement d’un audit externe trimestriel pour détecter ce type d’écart, un contrôle automatisé léger a été ajouté : un script exécuté chaque semaine, qui compare le nombre de balises hreflang présentes dans le HTML public d’un échantillon de pages avec le nombre de langues actuellement actives dans la configuration WPML, et alerte par e-mail en cas d’écart entre les deux.
Ce que cet incident dit du cache en contexte multilingue
Un cache de page reste indispensable pour la performance d’un site à fort trafic, mais il introduit une source de vérité supplémentaire, distincte de la configuration WordPress elle-même : ce que le cache sert peut diverger silencieusement de ce que l’administration affiche, sans qu’aucun message d’erreur ne le signale. Sur un site multilingue, où le SEO international dépend directement de la fraîcheur de balises comme hreflang, cette divergence a un coût réel, mesurable en perte de visibilité sur la langue concernée pendant toute la durée où l’écart persiste.
En résumé
Cette panne n’avait rien d’une erreur de configuration : WPML faisait exactement ce qui lui était demandé. Le vrai problème se situait dans l’absence de lien automatique entre un changement de configuration multilingue et la purge du cache qui sert le résultat de cette configuration aux visiteurs. La leçon à retenir dépasse ce cas précis : sur un site multilingue mis en cache, toute vérification technique doit porter sur le HTML réellement servi, jamais uniquement sur ce qu’affiche l’administration.
