WordPress sans usine à gaz : GA4, GTM et formulaires trackés proprement

La plupart des sites WordPress mesurent mal pour une raison simple : plusieurs plugins ajoutent chacun leur balise Google, personne ne sait lesquels envoient quoi, et aucun dataLayer ne décrit réellement les pages ou les formulaires. Le tracking fiable sur WordPress tient en trois choix : un seul point d’entrée Google (idéalement Google Tag Manager), un dataLayer qui décrit les soumissions de formulaires, et un Consent Mode v2 branché sur votre bannière. Le reste est de la configuration, et c’est là que les sites cassent.

Pour un site qui vit de ses demandes de contact, le cadrage et la mise en place se font sur la page consultant analytics lead generation B2B, qui détaille mon intervention. Ce guide explique les choix techniques, que vous pouvez appliquer seul ou confier à un prestataire.

Pourquoi WordPress mesure mal

Trois symptômes reviennent sur presque tous les audits.

Le premier est le double tag : un GTM installé à la main dans le thème, un plugin SEO ou de cache qui injecte aussi un script Google Analytics, et une balise Google Ads ajoutée par un troisième outil. Résultat : des sessions comptées deux fois, ou des conversions qui partent en double.

Le deuxième est l’absence de dataLayer. Sans variables de page, GA4 ne sait pas distinguer une page article d’une page produit, ni un visiteur connecté d’un visiteur anonyme. Les rapports par type de contenu restent vides.

Le troisième est le formulaire mal mesuré. C’est le point le plus important pour un site de génération de leads, et le plus souvent traité en dernier.

Les trois approches

Il existe trois manières de brancher Google sur WordPress. Le bon choix dépend de la compétence disponible en interne et de la place que doit occuper le tracking dans votre stratégie.

Approche	Exemples	Coût	Forces	Limites
Site Kit by Google	Plugin officiel Google	Gratuit	Ajoute la balise GA4 automatiquement, dashboard dans l’admin	Pas de configuration d’événements dans WordPress : les événements se font dans GA4 ou GTM
Plugin tout-en-un	MonsterInsights, ExactMetrics	Payant pour les fonctions avancées	GA4 sans GTM, interface simple	Formulaires et e-commerce réservés aux offres supérieures, peu flexible
GTM via GTM4WP ou insertion manuelle	GTM4WP (gratuit), code dans un plugin dédié	Temps de configuration	Dataflow maîtrisé, dataLayer sur mesure	Demande de savoir utiliser GTM

Site Kit convient à un site vitrine qui veut voir son trafic sans rien configurer. Il ne suffit pas à un site qui mesure des formulaires ou des conversions. MonsterInsights et ExactMetrics fonctionnent pour un petit site sans équipe technique, à condition de vérifier ce que l’offre comprend réellement. Pour le reste, je recommande GTM : c’est le seul choix qui donne la main sur le dataLayer et sur les événements.

Pour un comparatif détaillé des plugins, voir GTM4WP vs Site Kit vs MonsterInsights.

Le dataLayer WordPress utile

Un dataLayer WordPress minimal se pousse dans le header.php ou via un mu-plugin, avant le snippet GTM. Il doit rester petit et stable. Les variables que je demande systématiquement :

• page_type : article, page, produit, catégorie, landing, recherche ;
• content_category : la catégorie principale de l’article ;
• content_author : utile pour les blogs multi-auteurs ;
• user_logged_in : booléen, sans aucune donnée personnelle.

Le point d’attention est le mu-plugin. Un code placé dans functions.php d’un thème disparaît au changement de thème. Un mu-plugin reste actif et ne dépend d’aucun thème.

Côté pièges : ne jamais pousser l’adresse e-mail ou le nom de l’utilisateur connecté dans le dataLayer. Les variables restent des identifiants génériques.

Tracker les formulaires

C’est le point qui rapporte le plus. Un formulaire WordPress soumis ne déclenche pas de chargement de page complet dans la plupart des cas : la soumission est en AJAX, et la page ne change pas d’URL. Une conversion mesurée sur une page de remerciement n’existe donc pas toujours.

Chaque extension de formulaire expose son propre événement JavaScript. Gravity Forms, WPForms, Contact Form 7, Elementor Forms et Ninja Forms n’ont pas les mêmes noms d’événements, ni les mêmes conditions de déclenchement. Il faut lire la documentation du plugin installé avant d’écrire le listener. Exemple avec Contact Form 7, qui déclenche un événement DOM wpcf7mailsent après un envoi réussi :

<script>
document.addEventListener('wpcf7mailsent', function (event) {
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: 'generate_lead',
    form_id: event.detail.contactFormId,
    form_name: 'contact'
  });
}, false);
</script>

Trois pièges à surveiller :

1. Double déclenchement. Si le formulaire est présent deux fois sur la page (en-tête et pied, ou popup), le listener peut pousser deux generate_lead. Dédupliquez par form_id ou par identifiant de soumission.
2. Événement déclenché avant validation serveur. Certains plugins émettent un succès côté navigateur avant l’envoi réel du mail. Vérifiez dans l’onglet réseau que la soumission est bien traitée.
3. Page de remerciement vs événement. Si vous basez la conversion sur une URL de remerciement, elle doit être accessible uniquement après soumission, et non indexée. Un événement JS est souvent plus fiable, mais il ne remplace pas la vérification côté serveur pour les conversions Google Ads.

Le nom generate_lead fait partie des événements recommandés GA4. Ajoutez les paramètres form_name et, si vous avez une valeur de lead estimée, value et currency.

Consent Mode v2 sur WordPress

Le Consent Mode v2 se règle avant le chargement de GTM : la commande default doit s’exécuter avant tout tag Google. Sur WordPress, l’ordre d’exécution est le point qui casse le plus souvent.

Les CMP couramment installées sont Axeptio, Complianz, Cookiebot et Didomi. Pour leur comparaison, voir Axeptio vs Didomi vs Cookiebot. Chacune s’intègre à GTM avec sa propre logique : certaines se chargent via un tag, d’autres via un script dans l’en-tête.

Les pièges spécifiques à WordPress :

• Cache de page. Un cache qui sert une page statique avec un état de consentement figé peut envoyer des hits alors que l’utilisateur a refusé. Testez en navigation privée, sur deux pages différentes.
• Plugins de performance. WP Rocket, LiteSpeed Cache et d’autres proposent de différer ou de combiner les scripts JavaScript. Si GTM ou la CMP est différé, la commande default peut arriver après un hit GA4. Vérifiez les exclusions dans le plugin et contrôlez l’ordre dans l’onglet réseau.
• Double bannière. Un plugin RGPD gratuit et une CMP payante qui tournent en parallèle affichent deux bannières ou écrivent deux états différents.

Pour les paramètres détaillés, la documentation Google fait référence : Consent Mode, guide développeurs.

Performance et Core Web Vitals

Chaque tag ajouté a un coût de chargement. Un GTM chargé en tête de page, avec une quinzaine de balises déclenchées au chargement, dégrade le LCP et l’INP, surtout sur mobile. Le réflexe : déclencher les balises au bon moment (événement de page, délai après interaction) et supprimer les tags inutilisés.

Je mesure avant et après la mise en place avec PageSpeed Insights sur un échantillon de pages types (accueil, article, page de contact), en comparant les données de terrain CrUX lorsqu’elles existent. Une hausse du poids JavaScript après une recette de tracking doit être justifiée.

Server-side : quand le faire

Le server-side déplace la collecte vers un conteneur sGTM hébergé sur votre domaine. Il réduit le poids côté navigateur et améliore la résistance aux bloqueurs, mais il ajoute un coût d’hébergement et une maintenance.

Sur WordPress, une option existe en plugin : Stape Conversion Tracking, gratuit sur wordpress.org sous le slug gtm-server-side, sert à brancher un conteneur sGTM sans code. Addingwell propose une approche équivalente. Pour le choix entre les deux, voir Stape vs Addingwell.

Je ne recommande pas le server-side à un site vitrine sans budget média. Il devient pertinent quand les conversions Google Ads et Meta sont pilotées par la donnée et que les pertes de signal sont mesurables.

Checklist de recette

Avant de considérer le tracking livré, je vérifie :

• une seule balise GA4 et un seul GTM dans le HTML source ;
• la commande Consent Mode default avant tout tag, en refus comme en acceptation ;
• un formulaire soumis avec succès déclenche exactement un generate_lead ;
• un formulaire en erreur (champ obligatoire vide) ne déclenche rien ;
• les pages types ont le bon page_type dans le dataLayer ;
• une page servie depuis le cache n’envoie pas de hit quand le consentement est refusé ;
• DebugView GA4 reçoit les événements attendus sur un parcours complet.

Questions fréquentes

Faut-il un développeur pour installer GTM sur WordPress ?

Non pour l’installation de base : GTM4WP ou un plugin de code suffit. Un développeur est utile pour le mu-plugin du dataLayer et pour les listeners de formulaires, qui demandent quelques dizaines de lignes de code.

Site Kit suffit-il pour suivre les conversions ?

Pour un site vitrine sans formulaire, oui pour la vue d’ensemble. Dès qu’il faut mesurer une demande de contact comme conversion, il faut passer par GTM ou par un événement JavaScript configuré.

Faut-il activer le server-side tout de suite ?

Non. Commencez par un GTM propre avec Consent Mode v2 et des événements fiables. Le server-side ajoute de la valeur une fois le client-side stable.

Sources

• GTM4WP, plugin WordPress sur wordpress.org
• Site Kit by Google, plugin officiel sur wordpress.org
• Consent Mode, documentation développeurs Google