Autoblocking Checklist

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.
Balanced selected: Only Site Optimization should start; Content/Ad Personalization stay off.
Personalized selected: Personalization and advertising services start.
Revoke: Use the Revoke Consent option and 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)

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

Cookie Compliance - Autoblocking script position

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:

Automatic Geolocation: sensible baselines using your org and visitor location.
Manual Geolocation: you choose settings per zone (e.g., EU, UK, US, CA, BR, Other regions).

What Geolocation can toggle per zone

Banner Display (show/hide by default)
Revoke Consent option (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:

In the WordPress plugin settings, enable Caching compatibility. This adds compatibility adjustments so the Cookie Compliance script remains in the correct, first position and isn’t deferred/combined by common caching tools. 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. Cookie Compliance does not block scripts for logged-in users. If someone is signed in to an account on your site, they’ve already agreed to your site’s terms and experience, which we treat as outside the scope of cookie consent enforcement. So, when validating autoblocking, always test after logging out, in a clean browser session.