Google Analytics 4 in WordPress: GA4, GTM and consent mode

Updated version: Google Analytics 4 in WordPress: GA4, GTM and consent mode.

#How to add Google Analytics to WordPress in 2026

There are four ways to add Google Analytics 4 (GA4) to a WordPress site in 2026, ranging from beginner-friendly to advanced. Each method has different trade-offs for control, compliance, and performance:

If you are in the EU (including Poland), Consent Mode v2 is mandatory since March 2024. Any implementation method must integrate with a cookie consent banner (Cookiebot, Complianz, or similar) before firing analytics tags.

#Best way to add Google Analytics 4 to a WordPress site

For most professional WordPress sites in 2026, Google Tag Manager (GTM) is the recommended method. It provides the best balance of control, flexibility, and compliance:

• You can manage GA4, conversion tracking, remarketing tags, and custom events from a single GTM dashboard without touching WordPress code.
• Consent Mode v2 integrates natively with GTM, respecting user privacy choices before firing any tracking tags.
• Server-side GTM takes this further by routing analytics through your own domain, reducing ad-blocker interference and improving data accuracy.

The plugin method (Site Kit) is faster to set up but gives less control over consent handling and event configuration. Direct code injection works but becomes hard to maintain as tracking requirements grow.

Analytics is the foundation of every digital strategy. But the way to add Google Analytics to WordPress has changed dramatically over the years. We used to paste a simple _gaq.push script. Today, in the era of GA4, GDPR and Consent Mode v2, things are significantly more complex.

This guide walks you through all GA4 integration methods with WordPress, from the simplest to the most advanced, including procurement or regulatory contexts and best practices for 2026.

#How to add GA4 to WordPress with a plugin

If you do not want to work with code, use a plugin. It is the simplest method but has limitations.

#Site Kit by Google plugin for GA4

Pros:

• Official Google product
• Shows statistics directly in the WP dashboard
• Automatic integration with Search Console, PageSpeed Insights
• Easiest setup (a few clicks)

Cons:

• Limited tag control
• No advanced tracking options
• May conflict with other plugins

Installation:

1. Plugins > Add New > “Site Kit”
2. Activate and connect to Google account
3. Select services to connect (Analytics, Search Console)
4. Done

#GA4 measurement ID in Rank Math or Yoast SEO

Many SEO plugins have built-in tracking ID options. A good choice if you already use one of these plugins.

RankMath:

• RankMath > General Settings > Analytics
• Paste Measurement ID (G-XXXXXXX)

#How to add Google Tag Manager to WordPress

This is the recommended method in 2026. Instead of adding GA4 directly, add a GTM container that manages all tags.

#Benefits of using Google Tag Manager

1. Central management panel: All tags (GA4, Facebook Pixel, Hotjar, ads) in one place
2. Consent Mode v2: Simple implementation required by EU law
3. No code editing: Changes without modifying theme files
4. Debugging: Built-in preview mode
5. Versioning: Change history and rollback capability

#How to add a GTM container to WordPress

1. Create GTM container:

• Go to tagmanager.google.com
• Create account and container (Web)
• Copy container code (GTM-XXXXXXX)

2. Paste code in WordPress:

// In functions.php or mu-plugin
add_action('wp_head', 'add_gtm_head', 1);
add_action('wp_body_open', 'add_gtm_body', 1);

function add_gtm_head() {
    ?>
    <!-- Google Tag Manager -->
    <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','GTM-YOUR-ID');</script>
    <!-- End Google Tag Manager -->
    <?php
}

function add_gtm_body() {
    ?>
    <!-- Google Tag Manager (noscript) -->
    <noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-YOUR-ID"
    height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
    <!-- End Google Tag Manager (noscript) -->
    <?php
}

3. Configure GA4 tag in GTM:

• In GTM: Tags > New > GA4 Configuration
• Paste Measurement ID (G-XXXXXXX)
• Trigger: All Pages
• Publish

#How to set up Consent Mode v2 in GTM

Since March 2024, Consent Mode v2 is mandatory in Europe. Without it, Google will not process data from your site.

What it does:

• Blocks analytics and advertising cookies by default
• After user acceptance: full tracking
• After rejection: anonymous pings (modeled data)

Implementation with GTM:

1. Install cookie banner (Cookiebot, Complianz, CookieYes)
2. Configure GTM integration
3. Set tags to “Respect Consent State”
4. Add consent variables (analytics_storage, ad_storage)

#Add GA4 to WordPress without a plugin

If you want to avoid plugins and have a simple site, add the code directly.

#GA4 gtag.js snippet in functions.php

add_action('wp_head', 'add_ga4_code', 1);

function add_ga4_code() {
    ?>
    <!-- Google tag (gtag.js) -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=G-YOUR-ID"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());

      gtag('config', 'G-YOUR-ID');
    </script>
    <?php
}

#GA4 gtag.js snippet with Consent Mode defaults

add_action('wp_head', 'add_ga4_with_consent', 1);

function add_ga4_with_consent() {
    ?>
    <script>
      // Default consent state - everything blocked
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      
      gtag('consent', 'default', {
        'analytics_storage': 'denied',
        'ad_storage': 'denied',
        'ad_user_data': 'denied',
        'ad_personalization': 'denied',
        'wait_for_update': 500
      });
    </script>
    
    <!-- Google tag (gtag.js) -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=G-YOUR-ID"></script>
    <script>
      gtag('js', new Date());
      gtag('config', 'G-YOUR-ID');
    </script>
    <?php
}

#GA4 server-side tracking for WordPress

In 2026, ad blockers and ITP (Intelligent Tracking Prevention) significantly limit the effectiveness of client-side tracking. The solution is Server-Side Tracking.

#How server-side GA4 tracking works

1. A script on the page sends data to your server (not to Google)
2. Your server forwards the data to Google Analytics
3. Blockers do not see the Google connection

#Server-side GTM hosting options and costs

1. Google Tag Manager Server-Side Container:

• Requires Cloud Run (GCP) or other hosting
• Full data control

2. Stape.io (SaaS):

• Hosted sGTM
• Easier setup

#Benefits of server-side tracking

• Ad blocker resistant: approximately 95% data vs approximately 70%
• Better accuracy: fewer conversion losses
• First-Party Cookies: longer cookie lifespan
• Privacy: data passes through your server

#GA4 ecommerce tracking for WooCommerce

If you run a store, you need Enhanced E-commerce.

#WooCommerce ecommerce tracking with GTM

1. Data Layer: WooCommerce sends product, cart and purchase data
2. GA4 E-commerce tags: configure in GTM
3. Events: view_item, add_to_cart, purchase

#How to check if GA4 is working on WordPress

#Tools to test GA4 tracking

1. Google Tag Assistant: Chrome extension
2. GTM Preview Mode: preview mode
3. GA4 DebugView: real-time in GA4
4. Network tab: check that requests are being sent

#Common GA4 tracking problems and fixes

1. Double tracking:

• Symptom: 200% page views
• Cause: two GA4 tags (for example, Site Kit + GTM)
• Solution: remove one source

2. No data:

• Symptom: 0 users
• Cause: consent blocked or wrong ID
• Solution: check Consent Mode and Measurement ID

#Direct gtag.js script loading vs Google Tag Manager

In modern WordPress engineering, tracking user interactions with Google Analytics 4 requires a disciplined architectural approach. Historically, developers injected raw script snippets directly into header templates or relied on monolithic plugins that obscured tracking logic. As web performance metrics such as Interaction to Next Paint (INP) and Largest Contentful Paint (LCP) dictate search visibility, and privacy regulations across the European Union require explicit consent verification prior to reading device storage, client-side tracking requires rigorous implementation standards.

Direct gtag.js script loading versus Google Tag Manager represents the first major architectural choice for engineering teams. Direct gtag.js loading operates through a compact JavaScript library that communicates directly with Google measurement endpoints. Because gtag.js loads a minimal payload without container compilation or variable evaluation routines, it produces lower main-thread blocking time compared to a full Tag Manager container. When an enterprise platform only requires pageview tracking, standard conversion signals, and predictable outbound link monitoring, direct gtag.js loading provides an optimal performance profile.

Conversely, Google Tag Manager container deployment remains the standard for organizations managing multi-channel attribution and continuous marketing testing. Tag Manager introduces an abstraction layer where tags, triggers, and variables evaluate incoming events before forwarding them to third-party destinations. While GTM adds approximately 30 to 45 kilobytes of compressed JavaScript and demands parsing time on mobile devices, it decouples deployment velocity from software release cycles. Marketing and analytics teams can deploy conversion pixels, test trigger logic, and restructure event parameters without requesting code releases or database migrations.

Evaluating the operational trade-offs clarifies the boundary between both architectures:

For high-traffic publishing networks and headless commerce storefronts where Core Web Vitals directly influence organic rankings, direct gtag.js deployment minimizes Total Blocking Time (TBT). For enterprise e-commerce platforms with dozens of ad-network integrations, GTM provides the governance framework necessary to manage tags systematically.

#WordPress enqueue pipeline with wp_enqueue_script and wp_add_inline_script

A persistent vulnerability in WordPress implementations is the insertion of raw tracking scripts directly into template files or via generic unhooked output. Using raw output statements inside header templates breaks script dependency trees, prevents proper hook ordering, and prevents automated script attribute manipulation by performance or security plugins.

The professional standard requires leveraging the WordPress enqueue pipeline. Through wp_enqueue_script, WordPress registers the external Google tag library, while wp_add_inline_script attaches configuration routines and consent commands directly before or after the handle. WordPress 6.3 introduced formal support for script loading strategies via the $args array in wp_register_script and wp_enqueue_script, allowing developers to declare strategy => 'async' or strategy => 'defer' natively.

Consider the following implementation demonstrating production-grade enqueueing with explicit dependency management and async execution:

add_action('wp_enqueue_scripts', function (): void {
    $measurement_id = 'G-XXXXXXXXXX';

    // Register Google tag library with explicit async execution strategy
    wp_register_script(
        'google-tag-platform',
        'https://www.googletagmanager.com/gtag/js?id=' . rawurlencode($measurement_id),
        [],
        null,
        [
            'strategy'  => 'async',
            'in_footer' => false,
        ]
    );

    // Prepare initial inline configuration script
    $inline_config = sprintf(
        'window.dataLayer = window.dataLayer || [];' . "\n" .
        'function gtag(){dataLayer.push(arguments);}' . "\n" .
        'gtag("js", new Date());' . "\n" .
        'gtag("config", "%s", {' . "\n" .
        '  send_page_view: true,' . "\n" .
        '  anonymize_ip: true,' . "\n" .
        '  cookie_flags: "SameSite=None;Secure"' . "\n" .
        '});',
        esc_js($measurement_id)
    );

    // Attach configuration inline script before or after the main library
    wp_add_inline_script('google-tag-platform', $inline_config, 'after');
    wp_enqueue_script('google-tag-platform');
}, 10);

When deploying Google Tag Manager instead of direct gtag.js, script registration follows an equivalent architectural discipline. While GTM documentation historically recommended pasting raw script blocks immediately following the opening head tag and a noscript iframe following the body tag, modern WordPress themes expose the wp_body_open hook to standardize body-level injection.

add_action('wp_head', function (): void {
    $container_id = 'GTM-XXXXXXX';
    ?>
    <script>
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','<?php echo esc_js($container_id); ?>');
    </script>
    <?php
}, 1);

add_action('wp_body_open', function (): void {
    $container_id = 'GTM-XXXXXXX';
    ?>
    <noscript><iframe src="https://www.googletagmanager.com/ns.html?id=<?php echo esc_attr($container_id); ?>"
    height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
    <?php
}, 1);

Hook priority 1 guarantees that the dataLayer container initialization executes before plugins or interactive theme blocks attempt to push interaction events.

#Server-side tagging architecture with Cloudflare Zaraz and Cloud Run

Client-side tag execution faces structural vulnerabilities in 2026. Browser security standards, including Apple WebKit Intelligent Tracking Prevention (ITP) and Firefox Enhanced Tracking Protection (ETP), cap client-side cookie lifespans to seven days or twenty-four hours when referral parameters indicate tracking clicks. Concurrently, network-level ad blockers and privacy extensions intercept calls to Google tracking domains, leading to 15 to 30 percent data loss on tech-forward audiences.

Server-side tagging resolves these challenges by introducing a first-party proxy architecture. Instead of browser clients establishing connections with third-party Google infrastructure, the client dispatches analytics requests directly to a subdomain of the parent website, such as metrics.example.com. The server-side container inspects incoming payloads, strips sensitive headers, enriches the data with server-side context, and routes authorized events to Google Analytics over secure server-to-server APIs.

Engineering teams primarily choose between two production architectures for server-side GTM:

1. Google Cloud Run container clusters: Google provides open-source container images for Server-side Tag Manager (sGTM). Deployed on GCP Cloud Run behind an HTTP load balancer, these containers scale horizontally with request volume. This approach provides complete feature parity with all sGTM community templates, full control over transformation logic, and direct integration with BigQuery export pipelines. Operational costs average 40 to 120 USD monthly depending on ingress traffic and minimum instance reservations.

2. Cloudflare Zaraz and edge routing: For platforms already routed through Cloudflare, Cloudflare Zaraz or Cloudflare Workers can act as the edge collector. Zaraz executes analytics actions within Cloudflare edge worker nodes without loading external JavaScript libraries into the user browser. While configuration paradigms differ from native GTM workspaces, edge execution eliminates client-side JavaScript execution overhead, achieving zero impact on Total Blocking Time.

Architectural comparison of client-side and server-side tracking pipelines:

#Content Security Policy script hashes and nonce handling

Deploying analytics scripts in security-conscious corporate environments requires integration with a strict Content Security Policy (CSP). A robust CSP header eliminates Cross-Site Scripting (XSS) vectors by explicitly defining trusted script origins, disallowing unsafe inline evaluation without validation, and enforcing cryptographic verification on all executed code.

When Google Tag Manager or gtag.js initializes, it dynamically generates inline script elements. In a strict CSP environment, the browser blocks these elements unless configured with cryptographic hashes or dynamic nonces.

#Cryptographic sha256 hashes

For static inline scripts that do not vary across user sessions, teams can generate a SHA-256 digest of the script body and include it in the script-src directive:

Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-abcdef123456...' https://www.googletagmanager.com; connect-src 'self' https://*.google-analytics.com https://*.analytics.google.com;

While sha256 hashing works reliably for direct gtag configuration blocks that contain static code, it fails for Google Tag Manager containers that dynamically inject additional client tags, conversion pixels, or third-party tracking libraries.

#Dynamic nonces via WordPress filters

The enterprise standard for GTM in a strict CSP environment is cryptographic nonce delivery. The web server generates a unique, cryptographically secure random token (nonce) per HTTP request. This token is passed in the CSP header and injected into every authorized script tag.

In WordPress, developers can generate nonces at runtime and distribute them across script handlers:

function get_http_csp_nonce(): string {
    static $nonce = null;
    if ($nonce === null) {
        $nonce = base64_encode(random_bytes(16));
    }
    return $nonce;
}

// Attach CSP header with dynamic nonce
add_action('send_headers', function (): void {
    $nonce = get_http_csp_nonce();
    $csp = "default-src 'self'; " .
           "script-src 'self' 'nonce-{$nonce}' 'strict-dynamic' https: http:; " .
           "connect-src 'self' https://*.google-analytics.com https://*.analytics.google.com https://*.googletagmanager.com; " .
           "img-src 'self' https://*.google-analytics.com https://*.googletagmanager.com;";
    header("Content-Security-Policy: {$csp}");
});

// Inject nonce into GTM script tag
add_action('wp_head', function (): void {
    $nonce = get_http_csp_nonce();
    $gtm_id = 'GTM-XXXXXXX';
    ?>
    <script nonce="<?php echo esc_attr($nonce); ?>">
    (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','<?php echo esc_js($gtm_id); ?>');
    </script>
    <?php
}, 1);

Using strict-dynamic ensures that scripts trusted by the nonce can create new script tags without requiring individual hash approvals, resolving GTM tag loading while preserving defense-in-depth against malicious script injection.

#Consent Mode v2 implementation and default signals

Since March 2024, Google requires Consent Mode v2 for all traffic originating in the European Economic Area (EEA) to maintain audience targeting and measurement capabilities in Google Ads and GA4. Consent Mode v2 introduces two specific privacy parameters in addition to existing storage flags: ad_user_data and ad_personalization.

The technical requirement demands that default consent signals are declared before any tracking library loads or executes. If the default command fires after gtag.js initializes, tags may collect storage signals prematurely, violating GDPR ePrivacy principles.

The standard consent parameters comprise four primary signals:

1. analytics_storage: Controls access to device storage (cookies, local storage) for measurement purposes.
2. ad_storage: Controls device storage access for advertising measurement and conversion tracking.
3. ad_user_data: Controls whether user data (such as hashed email addresses) can be dispatched to Google for ad attribution.
4. ad_personalization: Controls whether collected events can feed remarketing and audience targeting algorithms.

The proper initialization sequence requires outputting the consent default state at the earliest possible execution point:

add_action('wp_head', function (): void {
    ?>
    <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}

    // Establish default consent state before tags load
    gtag('consent', 'default', {
      'analytics_storage': 'denied',
      'ad_storage': 'denied',
      'ad_user_data': 'denied',
      'ad_personalization': 'denied',
      'wait_for_update': 500
    });

    // Optional URL passthrough for cookieless attribution
    gtag('set', 'url_passthrough', true);
    gtag('set', 'ads_data_redaction', true);
    </script>
    <?php
}, 0);

When a user interacts with a certified Consent Management Platform such as Cookiebot, Complianz, or CookieYes, the CMP fires an update command:

gtag('consent', 'update', {
  'analytics_storage': 'granted',
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted'
});

Under Advanced Consent Mode, tags fire before consent is granted, sending cookieless pings that Google models mathematically. Under Basic Consent Mode, all tracking requests are strictly blocked until consent is explicitly confirmed.

#WooCommerce e-commerce dataLayer event dispatching

Tracking e-commerce transactions in WooCommerce requires dispatching structured dataLayer events formatted according to the GA4 enhanced e-commerce schema. Default WooCommerce installations do not expose dataLayer structures out of the box. Relying on screen scraping or CSS selector triggers leads to frequent data breaks during theme updates.

Developers must inject structured events into the dataLayer during key shopping milestones: view_item_list, view_item, add_to_cart, begin_checkout, and purchase.

The purchase event is critical for revenue reconciliation and conversion tracking. It must execute exactly once upon order completion. The recommended approach utilizes the woocommerce_thankyou hook, validating order state and persisting a tracking flag in order metadata to prevent duplicate transaction counts on page refreshes:

add_action('woocommerce_thankyou', function (int $order_id): void {
    if (!$order_id) {
        return;
    }

    $order = wc_get_order($order_id);
    if (!$order) {
        return;
    }

    // Guard against duplicate purchase event dispatches
    if ($order->get_meta('_ga4_purchase_tracked')) {
        return;
    }

    $items = [];
    $item_index = 0;

    foreach ($order->get_items() as $item) {
        $product = $item->get_product();
        if (!$product) {
            continue;
        }

        $items[] = [
            'item_id'        => (string) $product->get_sku() ?: (string) $product->get_id(),
            'item_name'      => $product->get_name(),
            'price'          => (float) $order->get_item_subtotal($item, false, false),
            'quantity'       => (int) $item->get_quantity(),
            'index'          => $item_index++,
            'item_category'  => wp_strip_all_tags(wc_get_product_category_list($product->get_id(), ', ')),
        ];
    }

    $payload = [
        'event'     => 'purchase',
        'ecommerce' => [
            'transaction_id' => (string) $order->get_order_number(),
            'value'          => (float) $order->get_total(),
            'tax'            => (float) $order->get_total_tax(),
            'shipping'       => (float) $order->get_shipping_total(),
            'currency'       => $order->get_currency(),
            'items'          => $items,
        ],
    ];

    // Mark order as tracked to prevent double counting
    $order->update_meta_data('_ga4_purchase_tracked', '1');
    $order->save();

    ?>
    <script>
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({ ecommerce: null }); // Clear previous ecommerce object
    window.dataLayer.push(<?php echo wp_json_encode($payload); ?>);
    </script>
    <?php
}, 20);

For AJAX-based cart operations, WooCommerce exposes jQuery events like added_to_cart and removed_from_cart. Modern themes using block-based carts or custom REST endpoints should trigger custom DOM events with the GA4 item payload to maintain data layer integrity across checkout steps.

#Core Web Vitals and performance overhead of analytics tags

Analytics scripts carry substantial client-side performance implications. A poorly configured tracking stack can degrade Core Web Vitals, causing measurable regressions in search rankings and user engagement.

Key performance hazards include:

1. Main-thread CPU contention (INP degradation): When multiple marketing tags execute synchronous DOM queries and event handlers, user input interactions face noticeable delay. If a user clicks an element while GTM evaluates complex custom JavaScript variables, Interaction to Next Paint (INP) exceeds the recommended 200-millisecond threshold.
2. Resource contention on Largest Contentful Paint (LCP): If tracking libraries load with render-blocking behavior in the document head, browser parsers pause CSS and hero image discovery, delaying LCP benchmarks.
3. Memory leaks from unbound SPA listeners: On headless or single-page WordPress architectures, failing to detach event listeners across page transitions results in memory leaks and sluggish mobile performance.

Optimization checklist for high-performance tracking:

By implementing asynchronous script strategies, strict Consent Mode defaults, first-party server-side collection, and rigorous dataLayer sanitation, WordPress sites achieve resilient, compliant measurement without compromising speed or security.

#Summary

Recommendation for 2026:

• Small sites: Site Kit or RankMath
• Business/agencies: GTM + Consent Mode v2
• E-commerce/Enterprise: sGTM Server-Side

Do not let your analytics data be incomplete. Learn more about professional WordPress development at WPPoland.