When the Cookie Banner Changes and Nobody Tells You

Cookie banner monitoring means keeping track of which consent management platform (CMP) runs on a site, confirming it survives each deploy, and checking that marketing tags still behave correctly around consent. If the banner disappears, the site starts dropping tracking cookies without asking, which is a GDPR problem; if it changes, GA4 and the Meta Pixel can stop loading while every page still looks perfectly healthy.

No page returns a 404 and no uptime check turns red. The first sign is usually a conversions chart that stops making sense a few weeks later.

Who touches the banner, and why you are not told

Consent sits between departments. Legal owns the cookie policy and often the CMP contract. A developer owns the plugin or the script in the <head>. Marketing owns the tags that depend on it. Nobody owns the result, so changes happen for reasons that make sense to one team and never reach the others.

Typical examples: a developer installs Complianz or CookieYes on a WordPress site that already had a consent setup. Legal moves the account from Cookiebot to OneTrust and files it as a contract task. A theme or CMS update drops the snippet that loaded the CMP. Someone renames the consent categories and a tag ends up in a category no visitor ever enables. Or the banner was disabled on staging to make testing easier, and that setting ships with the release.

Each of these is a textbook silent SEO change, except the damage lands in analytics and compliance rather than rankings.

What a CMP change does to GA4 and the Meta Pixel

Most CMPs block scripts before consent, either by matching script URLs or by assigning tags to categories. A new CMP knows nothing about the exceptions the old one had configured, so a tag that used to load after "Accept" may now never load. Google Tag Manager is present, the container fires, and the GA4 tag inside it stays blocked.

With Google Consent Mode v2 the failure is harder to spot. The page sets a default with gtag('consent', 'default', {...}), and the banner is supposed to call gtag('consent', 'update', {...}) when the visitor accepts. If the new banner never sends that update, analytics_storage and ad_storage stay denied. GA4 still receives hits, but they are cookieless pings, and reports fill with modelled data instead of observed sessions. In the Network tab you can see this on the /g/collect request: the gcs parameter reads G100 when both storage types are denied and G111 when both are granted.

The opposite failure looks like good news. If the banner vanishes entirely, tags fire for everyone and GA4 sessions jump. That jump is a compliance issue, not growth.

A mismatch between categories hits paid media hardest. When the Meta Pixel sits behind a "marketing" category that the new banner hides behind a second screen, campaigns keep spending while conversions stop being attributed.

What the page should do in each state

State	GA4 / GTM	Meta Pixel	Cookies you should see
Before any choice	Blocked, or Consent Mode default denied	Not loaded	No _ga, no _fbp
After Accept	gtag.js loads, /g/collect with gcs=G111	fbevents.js loads	_ga, _ga_<ID>, _fbp
After Reject	No hits, or cookieless hits only	Not loaded	No _ga, no _fbp

Testing consent by hand

1. Open a fresh private window. A consent choice stored from a previous visit will hide the problem.
2. Load the homepage and note which CMP renders the banner. Cookiebot, Iubenda, OneTrust, CookieYes and Complianz all have recognisable markup and script URLs.
3. Open DevTools, go to Network, and filter on collect, gtag and fbevents. Check Application > Cookies as well.
4. Click Accept and confirm the requests and cookies from the table above appear. Check that the measurement ID in the request (tid=G-...) is still the client's.
5. Repeat in a new private window, clicking Reject this time.
6. Do the same on each template that matters, and do not skip the thank-you or order confirmation page, since that is where conversion tags fire.

It takes about ten minutes per site. That is fine once, and unrealistic after every release on thirty client sites.

Where Deltio fits, and where it stops

Deltio checks each site's homepage once a day, records which CMP is present, and alerts you by Slack and email when the provider appears, disappears or changes. The same daily cycle checks GA4, GTM and the Meta Pixel on the monitored pages and reports a tag that went missing or whose ID changed. A banner swap and a missing pixel therefore show up in the same place, on the same day.

It does not audit whether your consent configuration is legally adequate, and it does not inventory the cookies a site sets. It tells you what is on the page and what changed since the previous check. For the rest of a client site, see the website monitoring checklist for agencies and our guide to monitoring client websites for changes.

A reasonable place to start is the client where legal, the developer and marketing have never been on the same call. You can add that site on a 14-day trial.