Goal: make sure non-essential services stay paused before consent and only start when the visitor’s choice (via Access Levels and Purpose Categories) allows them.

Quick checks (one screen)

• Fresh session: Start with a clean browser session and visit a page that normally loads analytics/ads/media.
• Before consent: You shouldn’t see non-essential cookies, pixels, or third-party iframes. (A held script file may still appear as a download in the Network tab; it does not run.) Two limits: a script that an already-allowed script adds later is not held (for example a tag that Google Tag Manager fires while Google Consent Mode lets GTM run, so gate those inside GTM), and on the Free plan blocking stops once the site passes its visit limit for the current cycle.
• Balanced selected: Content Personalization and Site Optimization should start; Ad Personalization stays off.
• Personalized selected: Personalization and advertising services start.
• Update consent: Use the Update consent icon to change your choice, then reload—services you enabled should stop again.

Cookie Compliance script placement (must be first)

For autoblocking to work reliably, the Cookie Compliance inline configuration script and the loader script must appear at the very top of <head>—before Tag Manager, analytics, pixels, or any other third-party code.

Where it should be

• In the page <head>, and effectively the first script (before Tag Manager, analytics, pixels, or other loaders).

How to confirm (simple)

1. Open the page, right-click → View Page Source (or use DevTools → Elements).
2. Look at the very top of <head> and find the Cookie Compliance snippet (you’ll typically see our <!-- Cookie Compliance --> comment and a loader script served from //cdn.hu-manity.co/hu-banner.min.js).
3. Ensure no other scripts (GTM, analytics, ad pixels, optimizers) appear above these.

If it’s not first

• Move it above other scripts (most issues vanish once it’s first) and retest in a clean browser session (logged out, site data cleared).
• On builders/CMS: use the theme/header injection that runs earliest.

URL Patterns & Providers (one place to check)

Providers are the services you use (analytics, ads, media). URL Patterns are how the banner recognizes them on your pages.

What to look for

• The services you actually use appear in the Autoblocking list.
• Each has clear URL Patterns (script, iframe, or endpoint) that match how it loads on your site.
• Nothing too broad (catching your own assets), nothing too narrow (missing a vendor’s CDN path).

When something slips through

• Add/adjust a pattern for the real host/path you see in Network (e.g., the loader JS and its event endpoint).
• Include iframe sources for embeds (e.g., video players) if they’re not already covered.

You don’t need code—just make sure the names and patterns reflect what’s truly on your pages.

Geolocation (all regional defaults in one place)

Geolocation sets regional defaults before the visitor makes a choice. You pick one mode at a time:

• Managed geolocation: sensible baselines using your org and visitor location.
• Manual geolocation: you choose settings per region (e.g., EU, UK, US, CA, BR, Other regions).

What Geolocation can toggle per region

• Banner Display (show/hide by default)
• Update consent (show/hide the reopen control)
• Autoblocking functionality (On/Off for that region)
• Privacy Policy Link (show/hide)
• Do Not Sell Link (US contexts)

Accuracy note
IP lookups can be wrong (VPNs/privacy relays, mobile carrier gateways, corporate proxies, CDNs, or stale IP data). Treat defaults in stricter regions (e.g., EU) accordingly; the visitor’s selection still decides what actually runs.

Consent Modes (keep signals aligned)

If you enable Google Consent Mode, Meta (Facebook) Consent Mode, or Microsoft Consent Mode, those tags read the same consent state your banner maintains:

• No decision / Private / Balanced: advertising/personalization signals are constrained.
• Personalized: full behavior only when mapped purposes are accepted.

Consent Modes complement autoblocking—they don’t replace it.

Autoblocking & caching (why changes may not show right away)

• Site/CDN caches: Pages or scripts can be cached by your CDN/host. After changing settings, purge caches, and test again in a clean browser session.
• Browser caching: The banner’s assets and vendor scripts may be cached locally—clear cache or use a private window.
• Session state: Consent is stored per visitor; a prior choice will carry until changed or cleared.
• Single-Page Apps (SPAs): Components that load later are still checked, but if you test mid-session, navigate/refresh to see the new state apply consistently.

If you’re testing a fix, always start clean browser session, then reload after changing state (accept/reject/revoke) to confirm it sticks

WordPress caching (positioning & blocking)

If your site runs a caching/optimization plugin (e.g., WP Super Cache, W3 Total Cache, WP Rocket, WP Fastest Cache), it can reorder or rewrite scripts in ways that break autoblocking. When you see the banner load too late, or vendors fire before consent, check these features first (turn off one at a time, then retest):

• Defer / delay JavaScript execution
• JavaScript aggregation/combination
• JavaScript minification
• JavaScript compression (and similar “optimize JS” toggles)

Names vary by plugin, but the option descriptions usually mention deferring, combining/aggregating, minifying, or delaying scripts. After changing settings, purge caches and do a hard reload (or test in a clean browser session).

Cookie Compliance → Caching compatibility:
On a connected site the plugin prints the Cookie Compliance script early in <head> (at the start of WordPress’s head output) and tells supported optimizers (WP Rocket, Autoptimize, LiteSpeed Cache and others) not to defer or combine it, whether or not Caching compatibility is on. Turn on Caching compatibility in the WordPress plugin settings so the plugin also clears your caching plugin’s cache whenever your banner settings change. If your optimizer still touches it, add an exclusion rule for the Cookie Compliance script in your caching plugin, keep our script at the top of <head>, purge caches, and test again in a clean browser session.

Logged-in users (important for testing)

For accurate checks, view your site logged out—as an anonymous visitor. With Cookie Compliance for WordPress (plugin 3.1.9 or later), scripts are not blocked for users who can manage the banner: by default, users with the manage_options capability (a site can change this with the cn_manage_cookie_notice_cap filter). Other logged-in users get blocking as usual. So, when validating autoblocking, test logged out (or as a user who cannot manage the banner), in a clean browser session.