Une seule visite suffit, dans certains cas, à figer une redirection conditionnelle pour tous les visiteurs suivants — c’est le constat fait sur un site multirégional qui redirigeait ses visiteurs vers une version localisée de sa page d’accueil selon leur pays de connexion, via une règle PHP exécutée avant tout affichage.
Symptôme : une redirection qui ignore la condition
Le symptôme se manifeste ainsi : un visiteur situé en Belgique arrive sur la page d’accueil et se retrouve redirigé vers la version française du site, alors que la règle de redirection est censée le diriger vers la version belge dédiée. Un test depuis un VPN confirme que la redirection fonctionne correctement pour certains pays, mais reste figée sur une seule destination pour l’ensemble des visiteurs suivants, indépendamment de leur origine réelle.
La règle de redirection elle-même, une fois relue, ne contient aucune erreur logique :
add_action( 'template_redirect', function() {
if ( is_front_page() ) {
$pays = detecter_pays_visiteur();
wp_redirect( url_pour_pays( $pays ) );
exit;
}
});Diagnostic : WP Super Cache sert une page HTML déjà générée
Le diagnostic révèle que WP Super Cache, configuré en mode « mise en cache simple » (fichiers HTML statiques servis directement par Apache via des règles .htaccess, sans repasser par PHP), interceptait la requête avant même que la logique de redirection conditionnelle n’ait la moindre chance de s’exécuter. La première visite après la purge du cache déclenchait bien la redirection PHP, mais WP Super Cache mettait en cache la page de destination elle-même comme si elle était la page d’accueil — et servait ensuite cette version figée à tous les visiteurs suivants, redirection ou non.
Ce comportement s’explique par le fonctionnement même du mode de cache statique : une fois qu’Apache sert un fichier HTML directement depuis le disque via une règle de réécriture, WordPress et son cycle de hooks (template_redirect compris) ne sont tout simplement plus sollicités pour les requêtes suivantes sur cette URL.
Correctif : exclure la page d’accueil du cache statique
Le correctif le plus robuste ne consiste pas à désactiver WP Super Cache dans son ensemble, ce qui pénaliserait les performances de tout le reste du site, mais à exclure précisément les URL concernées par une logique conditionnelle du mode de mise en cache statique, via le fichier de configuration avancée du plugin :
// wp-content/plugins/wp-super-cache/wp-cache-config.php
$cache_rejected_uri[] = '^/$';Cette exclusion force WP Super Cache à repasser par PHP pour la page d’accueil à chaque requête, ce qui réactive la logique conditionnelle, au prix d’un temps de réponse légèrement supérieur uniquement sur cette page précise — un compromis largement acceptable au regard du volume de trafic concerné par la redirection.
Une alternative : le cache par variante plutôt que l’exclusion totale
Sur un site à plus fort trafic, exclure totalement une page du cache peut devenir coûteux. Une alternative consiste à mettre en cache une variante par valeur de condition, en intégrant le pays détecté dans la clé de cache elle-même — une fonctionnalité que certains plugins de cache plus avancés proposent nativement, contrairement à WP Super Cache en configuration standard :
- Vérifier si l’extension de cache en place supporte le cache par variante (souvent via un en-tête
Vary). - À défaut, réserver l’exclusion du cache aux seules pages réellement concernées par une logique conditionnelle.
- Documenter chaque exclusion dans la configuration, pour qu’elle survive aux mises à jour du plugin.
Un cache de page statique ne connaît que ce qu’il a vu une première fois : toute logique conditionnelle qui s’exécute après la génération de la page doit être traitée comme incompatible avec ce mode de cache, sauf exclusion explicite.
Prévention : tester le cache avec plusieurs conditions avant mise en production
Avant d’activer un cache de page statique sur un site qui contient la moindre logique conditionnelle — redirection par pays, contenu par rôle, tarif par segment de visiteur — un test systématique s’impose : visiter la page dans deux conditions différentes, purger le cache entre les deux visites, puis revisiter sans purge pour vérifier que la seconde condition n’a pas été écrasée par la première.
En résumé
Une redirection conditionnelle qui semble fonctionner en développement peut se figer en production dès qu’un cache de page statique intercepte la requête avant l’exécution de la logique PHP. La solution ne réside pas dans la désactivation du cache, mais dans l’exclusion précise des URL concernées, ou dans un cache par variante lorsque l’extension le permet — au prix d’un test systématique avant toute mise en production d’une logique conditionnelle sur un site déjà mis en cache.
