Applies to: WordPress Plugin + Admin Portal WP Admin: Overview tab > Script blocking Portal: app.hu-manity.co > Autoblocking

Symptom

Third-party scripts (analytics trackers, ad pixels, etc.) are firing before visitors give consent, even though you expect autoblocking to prevent this.

Common Causes and Fixes

1. One of the Two Switches Is Off

Cause: From plugin version 3.1.10 there are two switches, not one, and they do different jobs. Both are on by default for connected users, but either can be turned off — and checking only Autoblocking is the most common reason this problem is missed.

• Script blocking engine — the master switch. While this is off, Cookie Compliance never touches your scripts at all: nothing is blocked for any visitor, in any region, regardless of privacy signals.
• Autoblocking — block before consent. While this is off, scripts load immediately and the pre-consent window is unprotected; once the visitor makes a choice, their choice is enforced either way.

The engine gates the other one, so Autoblocking does nothing while the engine is off — the plugin shows this on the Autoblocking card as “No effect while the script blocking engine is off.” For the symptom above (scripts firing before consent), either switch being off will produce it, so check both.

Fix:

1. Go to WP Admin → Compliance → Cookie Consent tab.
2. Find the Script blocking engine and Autoblocking switches (classic settings screen: Cookie Consent Settings). Check Script blocking engine first — it is the top switch. If it is off, turn it on; Autoblocking cannot do anything until you do.
3. Then verify Autoblocking is toggled on. (Both are enabled by default for connected users; these steps confirm neither has been disabled.)
4. As of v3.0.2 autoblocking works regardless of which laws are selected.

Not using the WordPress plugin? On a site running the pasted snippet, the engine is the blockingEngine key inside the snippet’s huOptions block. If it reads "blockingEngine":false, nothing will be blocked — set it to true. The Admin Portal’s Site-wide autoblocking setting (Configuration → Laws) applies only to WordPress sites running plugin 3.1.11 or later, so it will not change this.

Verify: Open your site in an incognito browser. Before interacting with the banner, open the browser’s Developer Tools. Judge by what the tracker does, not by whether its file downloads: the browser may still fetch a held script file before the banner can stop it, but the script does not run. Two limits apply: a script that an already-allowed script adds later (for example a tag fired by GTM while Google Consent Mode lets GTM run) is not held, and on the Free plan blocking stops once the site passes its visit limit for the current cycle. Before consent, check that the Network tab shows no data calls from the tracker (for example, no collect or pixel requests to google-analytics.com) and that Application → Cookies shows no tracker cookies (such as _ga). Those Network and Cookies checks are the proof. In Elements a held script tag shows type="javascript/blocked", but that alone does not show that nothing ran, because a script added later by an allowed script is not held.

2. Tracker Is Not in the Known Provider List

Cause: Autoblocking works by matching scripts against a known list of tracker providers and URL patterns. If a tracker is not in the provider list, the plugin does not know to block it. You cannot add or edit providers from within WordPress; manage them in the Admin Portal.

Fix:

1. Go to app.hu-manity.co → Autoblocking and check whether the unblocked tracker appears in the provider list.
2. In the portal, add the tracker as a new provider with its script URL pattern.
3. Assign the tracker to the appropriate consent category (Basic Operations, Content Personalization, Site Optimization, or Ad Personalization).
4. Save changes in the portal. The WordPress plugin picks up updated provider data on its next scheduled config sync (about every 12 hours on a connected site), or click Pull latest settings in the Domain Info card to pick it up now.

Verify: After adding the provider and pulling the latest settings, check the Script blocking box on the Overview tab, then test on the front end.

3. Script Is Inlined or Loaded Before the Banner

Cause: Autoblocking intercepts external script tags by modifying their type attribute. However, if a script is inlined directly in your theme template, a page builder, or hardcoded in header.php, it may execute before the consent widget has a chance to intercept it. This is especially common with Google Tag Manager snippets manually placed in the <head>.

Fix:

1. Move the inline script to a WordPress-enqueued script so the plugin can intercept it.
2. Alternatively, use the Excluded script handles feature (in Cookie Consent tab → Technical Settings) to mark scripts as Essential (Category 1) if they must run immediately. These scripts are stamped with data-hu-category="1" and are never blocked.
3. For Google Tag Manager specifically, keep your own GTM snippet, place it after the Cookie Compliance script, and turn on Google Consent Mode in Cookie Compliance. With Google Consent Mode on, GTM itself runs, so tags it fires later are not held by the banner: gate your non-Google tags inside GTM. See the Google Consent Mode article for setup instructions.

Verify: View your page source. Look for inline <script> tags containing the tracker code. If found before the hu-banner.min.js script tag, the tracker runs before the banner can block it.

4. Cached HTML Still Contains Old Script Tags

Cause: A caching plugin or CDN is serving a cached version of your pages from before autoblocking was enabled. The cached HTML contains the original unmodified script tags.

Fix:

1. Purge your entire site cache (page cache, object cache, and CDN cache if applicable).
2. Ensure Caching compatibility is enabled in Cookie Consent tab → Technical Settings.
3. See Caching Plugin Compatibility for plugin-specific instructions.

Verify: Open an incognito browser window after purging. Open Developer Tools → Elements (the live page, not View Source) and confirm blocked script tags show type="javascript/blocked" and the class hu-blocked (indicating the consent widget is managing them).

5. Uncategorized Trackers Are Firing Without Consent

Cause: Trackers that are detected but not assigned to a consent category will run immediately. The plugin only blocks trackers assigned to consent categories 2, 3 or 4 (Content Personalization, Site Optimization or Ad Personalization).

Fix:

1. Go to app.hu-manity.co → Autoblocking and look for any tracker that has no consent category.
2. Assign each uncategorized tracker to the appropriate consent category.
3. Click Pull latest settings in the Domain Info card to pull updated categorizations.

Verify: No tracker on the Autoblocking page is left without a consent category, and the Script blocking box on the Overview tab shows blocking is on.

6. Free Plan Threshold Exceeded

Cause: On the Free plan, autoblocking is limited by a monthly session threshold. Once exceeded, autoblocking protection pauses until the next cycle.

Fix: Upgrade to the Professional plan for unlimited autoblocking. See Billing and Subscription Management.

Verify: Check the Script blocking box on the Overview tab. On a Free plan it reads “Off”, with “Limit reached” underneath, once the site has passed its visit limit for the cycle.

7. A Cooperative Plugin Is Already Self-Gating (v3.1.0+)

Cause: Cookie Compliance v3.1.0 registers as a WP Consent API CMP. Cooperative consumer plugins — WooCommerce, Google Site Kit, Burst Statistics, WP Statistics, Pixel Manager for WooCommerce, AddToAny, AFL UTM Tracker — now read consent directly from the visitor’s banner choice and self-gate their own analytics and tracking. If you also have a manual “trust the banner” snippet or toggle on the consumer plugin, you can see double-fires or apparent over-blocking. Conversely, if the WP Consent API integration is off, the WP Consent API reports no consent type, so plugins that rely on wp_has_consent() treat every category as allowed.

Fix:

1. Confirm the WP Consent API plugin is installed and active.
2. In the WordPress admin, go to Compliance → Cookie Consent tab → Technical Settings (classic settings screen: Cookie Consent Settings) and check the WP Consent API toggle. On v3.1.0+ it is on by default. On the classic settings screen it is greyed out when the WP Consent API plugin is not installed; on the current screen it stays clickable but has no effect until that plugin is active.
3. Remove any manual “push consent into [plugin name]” snippets you added in a previous version — they are now redundant.
4. For each affected plugin, disable its own “trust the banner” workaround so only one path is writing consent.

Verify: In the browser console, check consent_api.consent_type. It holds one value for the whole site, based on the laws you selected ('optin' if GDPR, UK PECR, LGPD or POPIA is selected, 'optout' if only CCPA, Other US State Laws or PIPEDA are selected, empty if no laws are selected or the integration is off), not on the visitor’s location. On a site with an opt-in law selected, wp_has_consent('marketing') should return false until the visitor chooses Personalized, then true. It stays false in a browser that sends Global Privacy Control, unless the visitor explicitly chooses Personalized on a site with GPC Support on. See WP Consent API Integration.

Note: The WP Consent API integration handles only the named consumer plugins above. Autoblocking still covers pasted GA4 tags, hardcoded pixels, embedded iframes, and every other third-party script that does not participate in the API.

Still Not Working?

1. Enable Debug mode in Cookie Consent tab → Technical Settings. Open the browser console and look for CC Banner: log messages showing which scripts were intercepted.
2. Check the Excluded script handles field — ensure the tracker is not accidentally listed as an exclusion.
3. Contact support with your site URL, the specific tracker that is not being blocked, and screenshots of your Overview and Cookie Consent tabs.