Outils d'analyse et de suivi

Google Analytics et les outils similaires continuent de fonctionner sur un site servi par Edge Caching, sans rien configurer. Quelques extensions WordPress qui comptent les visites ou lisent les paramètres de campagne côté serveur demandent un autre réglage, parce que les pages en cache n’atteignent jamais WordPress.

Les outils qui fonctionnent tels quels

Les outils qui s’exécutent dans le navigateur du visiteur fonctionnent de la même façon, que la page vienne du cache ou de votre serveur :

• Google Analytics 4 et Google Tag Manager
• le pixel Meta (Facebook), LinkedIn Insight Tag, le pixel TikTok et les autres pixels publicitaires
• les traqueurs JavaScript de Matomo, Plausible et Fathom
• Hotjar, Microsoft Clarity et les autres outils de cartes de chaleur ou d’enregistrement de sessions

La page en cache contient le <script> de suivi comme le reste du HTML : le navigateur le charge et signale la visite. Ces outils créent et lisent leurs témoins (_ga, _fbp, …) dans le navigateur, donc le fait qu’Edge Caching ignore les témoins pour la mise en cache ne les touche pas. Edge Caching n’ajoute pas non plus d’en-tête Content-Security-Policy : rien ne bloque les scripts tiers.

Les paramètres de campagne

Les liens des infolettres et des publicités portent des paramètres de suivi comme utm_source ou gclid. Edge Caching les retire avant de consulter le cache : /tarifs/?utm_source=infolettre et /tarifs/ partagent ainsi une seule copie en cache, au lieu de reconstruire la page pour chaque lien de campagne. La liste par défaut est utm_source, utm_medium, utm_campaign, utm_content, utm_term, fbclid, gclid et msclkid.

La barre d’adresse affiche toujours le lien complet : les outils qui s’exécutent dans le navigateur, comme Google Analytics, voient donc la campagne et attribuent correctement la visite.

Attention

WordPress ne reçoit pas les paramètres retirés sur les pages servies depuis le cache, là où arrivent la plupart des liens de campagne. Les extensions qui les lisent en PHP, par exemple pour enregistrer la campagne avec une commande WooCommerce ou un formulaire de contact, ne les voient pas. Les pages qui vont toujours à WordPress, comme le panier, le paiement ou toute page d’un visiteur connecté, les reçoivent toujours.

Si vous dépendez d’une telle extension, passez-la en mode de capture JavaScript si elle en a un, ou retirez les paramètres dont elle a besoin dans Cache Rules → Query String Cleaning → Strip Specific Parameters. Les pages visitées avec ces paramètres sont alors mises en cache séparément pour chaque valeur.

Les extensions qui comptent les visites côté serveur

Une page servie depuis le cache n’exécute jamais de PHP. Les extensions qui comptent une visite au moment où WordPress construit la page manquent toutes les visites en cache, et leurs chiffres chutent nettement. C’est le cas, par exemple :

• des compteurs de vues et des widgets « articles populaires » en mode de comptage PHP
• de WP Statistics et des extensions similaires en mode de suivi côté serveur
• des extensions d’abonnement ou de mur payant qui comptent les articles lus en PHP

La plupart de ces extensions proposent un mode de comptage AJAX ou JavaScript, qui compte chaque visite, en cache ou non. Activez-le dans les réglages de l’extension.

Les bandeaux de consentement aux témoins

Les bandeaux de consentement qui décident dans le navigateur quoi afficher et quels scripts charger, comme la plupart d’entre eux (Complianz, CookieYes, Cookiebot et similaires), fonctionnent normalement.

Un bandeau qui décide côté serveur, par exemple en vérifiant un témoin de consentement en PHP avant d’afficher les scripts de suivi, ne peut pas fonctionner sur les pages en cache : chaque visiteur recevrait la version mise en cache en premier. Utilisez le mode JavaScript de l’extension, ou ajoutez son témoin de consentement dans Cache Rules → Exclude Cookies pour que les visiteurs qui ont répondu reçoivent leurs pages de WordPress.

Les robots et les requêtes bloquées

Les requêtes bloquées par le pare-feu, les Protected Pages ou le blocage géographique n’atteignent jamais vos pages : elles ne chargent donc jamais les scripts de suivi et n’apparaissent pas dans vos statistiques. La plupart des robots n’exécutent de toute façon pas de JavaScript, donc les bloquer ne change pas vos chiffres de visiteurs.

Les indicateurs Total requests, Req / sec et Traffic by Country du tableau de bord Edge Caching comptent chaque requête qui atteint la périphérie, y compris les robots, les images et les autres fichiers, en cache ou non. Ils ne correspondront pas aux chiffres de Google Analytics, qui ne compte que les pages vues par les navigateurs qui exécutent son script et acceptent ses témoins.

Vérification rapide

Pour confirmer qu’un outil de suivi s’exécute sur une page en cache :

1. Ouvrez la page dans une fenêtre de navigation privée, où vous n’êtes pas connecté à WordPress.
2. Lancez curl -sI https://exemple.com/ | grep -i x-cache. HIT signifie que la page vient du cache.
3. Regardez la vue en temps réel de l’outil, par exemple Temps réel dans Google Analytics, ou utilisez son extension de navigateur (Tag Assistant, Meta Pixel Helper). Votre visite devrait apparaître.