When GA4 appears to be installed correctly but the setup still feels unreliable, the issue is often not the tag itself. It is the order in which consent and tracking scripts load.

In this case, the website already had a cookie consent banner in place, but the technical setup underneath it was flawed. The interface suggested consent was being handled correctly, while the underlying implementation risked allowing tracking behaviour before the correct default state had been established.

Problem

The site needed to use Google Analytics 4 on WordPress without allowing analytics cookies to fire before the visitor had actively made a consent choice.

At first glance, everything looked fine. The cookie banner was visible, the scripts were present, and GA4 appeared to be connected. The issue was that this kind of setup can still fail if consent is applied too late in the page lifecycle.

That creates a serious problem. Even when the banner looks correct to the user, the tracking layer underneath it may not be. For a business relying on analytics data and wanting a more defensible consent setup, that is not a safe place to be.

Diagnosis

The root cause was script timing.

The denied consent state was not being applied early enough. Instead of establishing the default consent state before measurement logic had the chance to run, the site was setting consent too late. In practice, that meant the banner was doing its job visually, but the technical implementation was fragile.

This is exactly the kind of issue that often slips through on WordPress sites. A plugin may appear to handle consent correctly, but once you factor in script order, caching, optimisation, or deferred loading, the real behaviour can be very different from what the frontend suggests.

So the problem was not that analytics had been installed incorrectly in general. The real issue was that the load order was wrong, which made both compliance confidence and reporting reliability harder to trust.

Fix

The fix was to take direct control of the consent flow and make sure the default denied state was declared before any measurement activity could begin.

I moved the default consent configuration into the document head so it ran as early as possible. Analytics and advertising storage were denied by default on page load. Then, when a visitor actively accepted tracking, the consent state was updated and stored so the decision could persist across later page views.

That changed the setup from a passive banner-driven experience into a technically controlled consent workflow. Instead of assuming the banner was enough, the site now established the correct default first and only allowed analytics behaviour after a valid user action.

I then verified the behaviour properly rather than relying on the UI alone. That included checking that the default denied state appeared first, confirming the consent update only fired after interaction, and making sure analytics cookies were not being set before consent had been granted.

Outcome

The end result was a cleaner, more defensible GA4 implementation on WordPress.

The site now defaults to denied consent before tracking is allowed to initialise, updates that state correctly when the visitor opts in, and behaves in a way that can be tested rather than assumed. That gives the business a setup that is more predictable under optimisation layers, easier to maintain, and more trustworthy when reviewing analytics data.

This was not a cosmetic fix. It corrected the underlying behaviour of the tracking setup and removed the gap between what the user saw on the frontend and what the scripts were actually doing underneath