Docs menu

Troubleshooting

Troubleshooting CookieHug: banner not showing, scripts not blocked, GTM, Debug Mode and late-consent issues.

FAQ / Troubleshooting

Scripts are not being blocked

Check that data-cookiehug-blockingmode is set to "auto" (or not set at all)
The script may be whitelisted (common libraries like jQuery are not blocked)
For manual control, use data-cookiehug-consent attributes

Google Tag Manager is not receiving consent signals

Verify data-cookiehug-consentmode is not set to "disabled"
Check that gtag or dataLayer is available on the page
Use the browser console to verify: dataLayer should contain consent events

Consent is not persisting between page loads

Check that localStorage is available and not blocked
Verify cookies are not being cleared by browser settings
Check that the consent has not expired (30-day default)

How do I test consent without clearing cookies each time?

Use CookieHug.withdraw() in the browser console to reset consent state. This clears all consent data, resets Google Consent Mode to denied, and automatically reloads the page to ensure all previously allowed scripts are properly blocked.

How do I check consent state in the browser console?

// Full consent state
console.log(window.CookieHug.consent);

// Has the user responded?
console.log(window.CookieHug.hasResponse);

// Which regulations apply?
console.log(window.CookieHug.regulations);

Debug Mode & Diagnostics

CookieHug ships with a built-in Debug Mode that proactively checks whether your Consent Mode default command (and any TCF stub) load before your Google tags fire. It never affects the banner or consent — it is an observer that reports misconfiguration.

Enable it any of three ways:

append ?cookiehug_debug=1 to the page URL,
set localStorage.cookiehugDebug = '1' in the browser console,
or turn on Debug Mode for 24h from the CookieHug dashboard (domain detail → diagnostics).

Once active, a CookieHug debug badge appears bottom-right (green = OK, amber = warnings, red = errors). Click it for the full console report. Reports also flow into the dashboard and trigger proactive e-mail alerts and an in-panel banner.

Debug messages

CHUG_ORDER_OK — configuration is correct: the default command ran before your tags.
CHUG_GA_BEFORE_SDK / CHUG_ORDER_LATE — a Google tag fired too early. See What to do when a tag is late.
CHUG_NO_DEFAULT_CONSENT — no default command detected; tags may have run without consent.
CHUG_TCF_STUB_PRESENT — a __tcfapi TCF stub was detected; make sure it loads before your tags.

What to do when a tag is late

Debug Mode flags a tag as late (CHUG_GA_BEFORE_SDK / CHUG_ORDER_LATE) when a Google script (GA4, Google Ads, GTM) fires before CookieHug sets the default consent state. As a result the tag may run without a Consent Mode signal.

Step 1 — first verify whether the tag has adopted Google Tag Gateway (GTG). This matters: with GTG the Google tag is served from your own domain (first-party), so load timings look different and the tag may be reported as late incorrectly.

How to check whether the tag adopted GTG

Open DevTools → Network and reload the page.
Find the request that loads the Google tag (e.g. gtag/js, gtm.js, collect).
Check the request domain: if the tag loads from your own domain (e.g. metrics.yourdomain.com) instead of googletagmanager.com / google-analytics.com, the tag is likely using GTG → read Google Tag Gateway (GTG).

If the tag does NOT use GTG — fix the ordering

When the tag loads directly from Google domains, "late" is a real ordering problem. Place the CookieHug script first in <head>, before any gtag.js, gtm.js or GA4 tag, then reload with ?cookiehug_debug=1 and confirm CHUG_ORDER_OK appears.

<head>
  <!-- 1) CookieHug first -->
  <script src="https://cookiehug.com/api/script/YOUR-LICENSE-KEY.js"></script>

  <!-- 2) then Google -->
  <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXX"></script>
</head>

Google Tag Gateway (GTG)

Google Tag Gateway (GTG) is a way to serve Google tags (Google tag / GA4 / a whole GTM container) from your own domain (first-party) instead of directly from googletagmanager.com. Requests pass through a lightweight gateway on your infrastructure (CDN/server), improving measurement durability in browsers that restrict third-party scripts.

Impact on consent — read this first. GTG is frequently enabled through a one-click CDN integration (for example directly from Cloudflare). That convenience comes at a cost: the CDN injects and runs the Google tag for you, so the customer often loses control over the script load order. The gateway can execute the Google tag *before* your CMP's Consent Mode default command has run — which is exactly what produces a "late" consent signal in CookieHug's Debug Mode. GTG changes *where and when* the tag loads, but the tag still reads Consent Mode; the challenge is guaranteeing the default command runs first.

Official Google documentation: Google tag gateway for advertisers · Get started guide · One-click CDN (Cloudflare) setup.

How to verify whether a tag is enrolled in GTG

Open DevTools → Network and reload the page.
Find the request that loads the Google tag (e.g. gtag/js, gtm.js, collect).
Check the request domain: if it loads from your own domain / subdomain (e.g. metrics.yourdomain.com) instead of googletagmanager.com / google-analytics.com, the tag is enrolled in GTG.
Cross-check in Google Ads / GA4 → Google tag gateway settings, where enrolled domains are listed.

Why GTG can be misreported as late

CookieHug's Debug Mode compares the start time of Google requests with SDK initialization. With GTG the tag loads from your own domain and often earlier/faster, so the heuristic may flag it as late even though Consent Mode is working correctly. Always verify GTG enrollment before treating a warning as a real problem.

Late signal on a GTG-enrolled tag — recommended remediation

If Debug Mode reports a late signal (`CHUG_ORDER_LATE`) and you have confirmed the tag is enrolled in GTG, the load order is usually controlled by the CDN, not by you. Pick one of the following, in order of preference:

Recommended — adopt U+C (advanced Consent Mode). For GTG-enrolled tags, U+C (advanced Consent Mode) is the recommended mechanism because it is compatible with manual GTG: the tag always loads and adjusts its own behaviour from the consent signal, so it does not depend on winning a load-order race. Then, in your Google product, enable Data Transmission Controls and Global Consent Defaults according to your needs so redaction and default consent are enforced Google-side.
Or migrate everything into a GTM container and deploy GTM via GTG. Move your Google tags into a single GTM container and serve that container through the gateway. Consent is then wired once inside GTM (per-tag Consent Settings), and CookieHug's default command is respected before the container's tags evaluate.
Or set up GTG manually (instead of the one-click CDN integration) so that you control the script import order — load CookieHug's Consent Mode default command before the gateway tag.

How to work with GTG in CookieHug

Keep the CookieHug script first in <head> — even with GTG the default command must be sent before the tag initializes.
Confirm the default command is respected: open GA4 → Admin → DebugView and check analytics_storage / ad_storage on events.
In the console check window.CookieHug.consent — it should match the user's choice.
If consent is respected, treat a GTG late warning as a false positive caused by first-party timing.
If consent is not respected (the tag collects data despite denied), follow the remediation above.