Déterminer quelles pages doivent rester dynamiques
Le cache de pages peut servir le même HTML public à plusieurs visiteurs. Il doit laisser WordPress produire la réponse lorsqu’elle dépend d’une session, d’un rôle ou d’une sélection personnelle. Faites l’inventaire des parcours de votre site. Une page de présentation et un article public peuvent être des candidats. Un espace membre, un écran de commande, une page de profil, une prévisualisation ou un tableau de bord exigent un autre traitement. Ajoutez les pages publiques qui affichent un bloc différent après connexion ou selon une préférence enregistrée.
Notez l’adresse réellement utilisée, son propriétaire fonctionnel et la façon dont la personnalisation est décidée. Par exemple, une page peut charger un même cadre public pour tous, puis interroger une API authentifiée pour afficher le compte. Dans ce cas, classez séparément le cadre HTML et la réponse de l’API. Si le cadre intègre déjà un nom, un jeton de formulaire ou un état de session, traitez-le comme une réponse personnalisée. Les chemins traduits, les domaines secondaires et les paramètres utilisés par les extensions font aussi partie de l’inventaire.
Si la difficulté concerne simplement une ancienne version d’une page publique, suivez le guide pour trouver et vider le bon cache. Le présent parcours sert à décider quelles réponses peuvent être partagées, puis à vérifier la règle avant la mise en ligne. Si une exposition a été signalée, interrompez la diffusion du cache concerné avec le responsable et traitez le signalement par le canal prévu. La vérification proposée ici se déroule exclusivement sur une copie fictive avec les protections en place.
Identifier la couche qui décide de réutiliser une page
Demandez à l’hébergeur et au mainteneur quels services peuvent conserver du HTML. Une extension WordPress, un cache intégré à l’hébergement et un CDN peuvent agir sur le même trajet. Le navigateur ou une fonction hors ligne peut aussi conserver des réponses localement. Un cache d’objets conserve des données réutilisées par l’application, par exemple le résultat d’une requête, tandis qu’un cache de pages peut rendre une réponse HTTP entière. Documentez qui peut modifier et vérifier chaque couche.
Dans une copie WordPress.com ou un service géré, commencez par les fonctions réellement offertes par votre formule. Si vous ne disposez pas de réglage de cache HTML, préparez l’inventaire et demandez au prestataire de confirmer les exclusions et les preuves disponibles. Pour une installation autohébergée, ouvrez le panneau du cache de pages déjà actif et son écran d’exclusions. Vérifiez ensuite le cache serveur ou le CDN, même lorsque l’extension annonce des exclusions automatiques.
Conservez une copie privée des réglages en vigueur, avec la date, les règles et leur priorité. Repérez le responsable capable de revenir à une configuration de protection connue. Sur la copie, suivez les requêtes depuis le navigateur jusqu’à WordPress et relevez où la décision de servir une entrée est prise. Si une couche peut répondre avant que WordPress démarre, donnez-lui aussi la règle d’exclusion. Une consigne posée dans l’application ne peut pas corriger une copie déjà renvoyée plus tôt sur le trajet.
Limiter le cache partagé aux réponses publiques identifiées
Commencez par une courte liste de pages publiques qui renvoient le même contenu pour les visiteurs anonymes. Pour chaque couche, définissez les requêtes admissibles et les réponses que le cache a le droit de conserver. Le cadre conservateur de cette recette autorise seulement les lectures anonymes de routes explicitement prévues. Une session reconnue, une autorisation HTTP, une méthode qui peut modifier un état ou une route au comportement incertain doit suivre le chemin dynamique. Contrôlez aussi les paramètres qui changent le contenu ou déclenchent une action.
Pour un panier, un compte ou un paiement WooCommerce, relevez les pages réellement affectées dans les réglages de la boutique, puis les chemins de retour, endpoints et cookies signalés dans la documentation de la version installée. Les traductions et les pages personnalisées peuvent avoir des adresses différentes des valeurs d’exemple. Sur un site d’adhérents ou de formation, faites le même relevé pour le tableau de bord, les messages, la progression et les téléchargements protégés. Une exemption sur une seule page ne couvre pas les requêtes qui complètent son affichage.
Donnez la priorité aux exclusions sur les règles générales qui accélèrent le HTML. Vérifiez dans la documentation du moteur si le nom de la règle, son ordre et son type produisent bien ce résultat. Préservez les cookies de session et les contrôles de droits habituels. Une variation du cache fondée uniquement sur un cookie peut créer de nombreuses variantes et ne suffit pas à autoriser le stockage de réponses privées. Demandez à chaque responsable de valider l’admissibilité de la route et les raisons qui la rendent publique.
- Inventorier les adresses publiques stables et les routes personnalisées.
- Reporter les exclusions dans chaque cache de pages actif.
- Confirmer l’ordre des règles avec le responsable de la couche.
Lire les directives de cache et les décisions du service
Pour une réponse sensible, demandez à l’application une politique adaptée, par exemple Cache-Control avec private et no-store. La directive private interdit le stockage dans un cache partagé lorsqu’elle s’applique à la réponse entière. La directive no-store demande aux caches de ne pas stocker la réponse. Elle ne retire pas une copie déjà conservée. La directive no-cache impose en principe une validation avant réutilisation et permet encore le stockage sous certaines conditions. Vérifiez la politique exacte de chaque couche avec sa documentation.
L’existence d’un cookie ou d’un en-tête Set-Cookie ne constitue pas, à elle seule, une interdiction standard de mise en cache. Conservez les exclusions d’admissibilité et vérifiez aussi les directives retournées par l’origine puis par le service placé devant elle. Demandez quels en-têtes le service ajoute ou remplace. Un CDN peut avoir ses propres règles de durée et son propre indicateur. Les noms HIT, MISS et BYPASS du banc de recette servent seulement à illustrer une décision documentée par ce banc.
Dans les outils de développement, ouvrez Réseau puis sélectionnez le document ou la requête dynamique qui vous intéresse. Relevez le statut HTTP, Cache-Control et, s’ils existent, Age et l’indicateur du cache. Un MISS indique qu’une entrée n’a pas servi cette fois, avec la possibilité que la réponse soit mise en cache ensuite. L’absence d’Age peut aussi s’expliquer par le service ou la chaîne. Pour confirmer une exclusion, rapprochez la réponse de la règle ou du journal du moteur concerné.
Préparer la copie et les profils de test
Créez une copie locale isolée ou une installation de test contenant uniquement des pages et des comptes inventés. Écartez les exports de clients, les jetons, les commandes, les médias privés et les historiques. Désactivez les envois externes et les paiements de recette ou utilisez le mode prévu par le prestataire lorsque ces composants sont nécessaires. Les deux rôles utilisés ici sont éditeur et abonné. Affectez chacun à son compte de test avec les droits normaux de la copie. Le lecteur n’a pas besoin d’un compte super administrateur pour vérifier ce qu’il voit.
Préparez une page publique qui rend exactement le même repère à tous les visiteurs. Préparez aussi une page de compte de recette qui affiche un libellé fictif correspondant au rôle courant et demande une connexion au visiteur déconnecté. Les repères peuvent s’appeler « Éditeur fictif » et « Abonné fictif ». Les comptes se connectent par le parcours ordinaire. Utilisez trois profils indépendants, avec un profil anonyme et un profil pour chaque rôle. Maintenez toutes les exclusions dès le premier essai.
Remplissez une grille avec la route, le profil, le statut attendu, le repère attendu et la décision attendue du cache. Prévoyez également le résultat après rechargement. Si vous pouvez lire un journal ou l’inventaire d’un cache de recette, indiquez comment vérifier quelles routes y sont réellement admises. Cette préparation permet de vérifier une politique de prévention avec des résultats observables et sans manipuler les sessions.
- Créer un témoin public, une page personnalisée et deux comptes fictifs.
- Ouvrir trois profils distincts, dont un déconnecté.
- Définir les résultats attendus avant d’effectuer les requêtes.
Vérifier le témoin public puis les sessions autorisées
Commencez avec le profil anonyme sur la page publique. Si vous avez vidé son entrée sur la copie et que la règle autorise sa mise en cache, attendez-vous à ce que la première réponse vienne de l’origine et à ce qu’une seconde demande puisse être servie depuis le cache. Le repère public doit rester identique. Enregistrez la décision observée, même si votre hébergeur utilise d’autres mots que MISS et HIT. Gardez la même URL et la même méthode pour les deux demandes.
Connectez l’éditeur et l’abonné depuis leurs profils respectifs. Sur la page personnalisée de la copie, vérifiez pour chacun son propre résultat autorisé et la décision qui écarte le cache partagé. Rechargez dans le même profil et relevez de nouveau les en-têtes. Dans le profil déconnecté, le parcours doit continuer à demander l’identification ou à refuser l’accès, selon la règle de la page. Contrôlez les réponses dynamiques associées à la page lorsqu’elle utilise une API ou un service séparé.
Cherchez une preuve indépendante dans la couche de recette. Sur le banc local de ce guide, seule l’entrée du témoin public peut être conservée. Les réponses de compte portent private et no-store, restent hors du cache et suivent les droits WordPress. Le code de refus précis dépend de l’application. Un formulaire de connexion peut produire une redirection, tandis qu’une page de test peut répondre 401. Relevez la décision réelle sans modifier l’URL pour forcer un résultat.
- Confirmer que le témoin public peut être servi par le cache quand les conditions sont réunies.
- Valider chaque rôle et le profil anonyme selon les accès attendus.
- Contrôler les décisions répétées et, si possible, l’inventaire du cache.
Vérifier les réponses associées au parcours
Une page de compte peut se charger correctement puis demander d’autres données. Sur la copie, observez les requêtes du parcours normal. Relevez les documents, les appels asynchrones et les réponses de redirection qui portent un état de connexion ou un contenu lié à un rôle. Vérifiez l’exclusion pour chacune de ces réponses et conservez les paramètres privés hors des captures. Pour un formulaire, examinez aussi le résultat après l’envoi avec des valeurs inventées et les services externes arrêtés.
Si la navigation passe de la page publique vers un espace réservé, vérifiez ce que l’application renvoie à l’entrée, après connexion et après déconnexion. Utilisez les commandes prévues par le site. Les requêtes qui modifient un état ou répondent à un formulaire doivent conserver leur traitement d’origine et rester en dehors du cache de pages. Sur le banc de ce guide, la page fictive de compte accepte la lecture uniquement. Le test d’une méthode non prévue vérifie qu’elle est refusée et écartée du cache.
Une application hors ligne ou un service worker peut appliquer une politique dans le navigateur indépendamment du CDN. Si votre site utilise cette fonction, demandez à son mainteneur de vérifier ce qu’elle conserve après une navigation normale de recette. La liste des ressources utilisables hors ligne doit respecter les mêmes décisions de confidentialité. Les étiquettes d’un CDN ne décrivent pas le cache du navigateur. Consignez le résultat par couche pour savoir où intervenir.
Appliquer les exclusions avant toute invalidation
Sur la copie, enregistrez les exclusions dans les couches concernées et relisez leur ordre. Faites vérifier que les routes protégées passent par le chemin dynamique, puis invalidez les entrées visées selon la procédure du moteur. Une purge seule donne un effet temporaire si la règle autorise de nouveau l’enregistrement. Limitez la purge au périmètre nécessaire lorsque le service sait identifier les clés et variantes concernées. Si cette portée ne peut pas être garantie, demandez au mainteneur le moyen prévu pour retirer toutes les variantes touchées.
Si vous utilisez WP Super Cache, ouvrez Réglages → WP Super Cache → Avancé. Dans le bloc Accepted Filenames & Rejected URIs, repérez Rejected URL Strings. Ajoutez un fragment propre à la page privée, par exemple /espace-membre/ si c’est le chemin de votre page de test. Enregistrez la règle et retirez l’ancienne copie de la page du cache de l’extension. Ouvrez de nouveau cette page, puis une page publique dont l’adresse ressemble à celle de l’espace membre. Vous vérifiez ainsi à la fois l’exclusion et sa portée.
Si le cache de pages est géré directement par l’hébergeur ou par le CDN, appliquez les exclusions dans le panneau de ce service ou demandez à son support de les confirmer. Utilisez ensuite la même grille de vérification. Le résultat dépend de la couche qui répond à la requête.
Après invalidation, reprenez les mêmes profils et la même grille. Le témoin public doit continuer à fonctionner selon sa règle. Les réponses privées doivent présenter les bons en-têtes, rester exclues même après rechargement et passer les contrôles d’accès. Comparez les observations à la politique définie avant l’essai. Gardez la date, les routes et les décisions du moteur, sans identifiants de session ni corps de réponse provenant d’un utilisateur.
Si une étape diverge, arrêtez la validation et conservez la protection la plus stricte connue pour les routes en cause. La restauration d’une configuration doit préserver les exclusions qui protègent ces réponses. Une règle précédente dont la protection est incertaine doit rester écartée. Corrigez la couche identifiée, puis reprenez les témoins avant d’envisager un changement ailleurs. Le retour de recette se termine quand le comportement de protection est de nouveau établi.
- Enregistrer et vérifier la règle d’exclusion avant de retirer les copies ciblées.
- Rejouer les témoins avec les profils déjà préparés.
- En cas d’écart, conserver la protection et reprendre la vérification de la couche concernée.
Garder un relevé utile lors des prochaines mises à jour
Conservez la liste des routes, leurs règles, les couches concernées et le responsable de chaque réglage. Notez aussi les changements qui demandent de refaire la recette, par exemple un nouveau parcours de connexion, une extension d’abonnement, une traduction d’URL, un changement de CDN ou un écran de commande modifié. Une règle ancienne peut rester correcte pour l’ancienne adresse tout en laissant la nouvelle hors de son périmètre. Inscrivez la vérification des routes dans la tâche de mise à jour.
Le bilan doit permettre au propriétaire de savoir ce qui a été observé. Distinguez la règle enregistrée, l’en-tête envoyé, la décision du cache et la preuve qu’une route protégée n’entre pas dans l’inventaire du banc. Notez les limites, notamment si le prestataire ne fournit pas de journal ni d’accès aux règles. Une page publique accélérée ne suffit pas à valider les pages personnalisées. Une recette locale avec un moteur fictif permet de vérifier la logique de la politique avant de contrôler chaque couche de l’environnement cible.
Pour une boutique, le comparatif des outils de performance WordPress situe le cache de pages parmi les autres fonctions. Si une boucle de connexion reste présente hors des couches de cache, suivez le guide sur les cookies et la connexion. Dans le cas précis d’un domaine indépendant rattaché à un sous-site, utilisez le parcours TLS, connexion et retour multisite.
