Autoblocking Not Working — Troubleshooting

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 a “No effect while the script blocking engine is off” note under it. 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. Look at the setting cards on that tab. 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 engine switch is not in the Admin Portal. The portal’s Configuration → Laws → Site-wide autoblocking setting updates the WordPress plugin’s Autoblocking switch, but does not change the blocking key on a snippet install.

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 never runs. 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), 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. The provider list lives in the Admin Portal (Autoblocking page) — you cannot add or edit providers from within WordPress.

Fix:

1. In the WordPress admin, open the Overview tab and check that the Script blocking box reads On (or Default allow, if your selected laws allow scripts to run until a visitor opts out).
2. Open app.hu-manity.co → Autoblocking and check whether the unblocked tracker’s provider is in the list.
3. In the portal, add the tracker as a new provider with its script URL pattern.
4. Assign the tracker to the appropriate consent category (Basic Operations, Content Personalization, Site Optimization, or Ad Personalization).
5. Save changes in the portal. The WordPress plugin picks up updated provider data on the next config sync (within 12 hours, or click Pull latest settings in the plugin's Domain Info card).

Verify: After adding the provider, click Pull latest settings in the Domain Info card, 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 but make sure it loads after the Cookie Compliance script, and turn on Google Consent Mode in Cookie Compliance so GTM receives the visitor’s choice. Cookie Compliance does not load GTM for you. With Google Consent Mode on, GTM is allowed to run, so gate non-Google tags inside GTM with consent triggers; the Cookie Compliance banner does not hold tags that GTM fires. 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 and confirm held script tags show type="javascript/blocked" and the class hu-blocked, with an external script’s address moved to a data-src attribute (indicating the consent widget is managing them). The widget makes this change in the live page, so it does not show in View Source.

5. Tracker Is Not Assigned to a Blocked Category

Cause: Trackers that are not assigned to a consent category will run immediately. The plugin only blocks trackers that are categorized into consent levels 2, 3, or 4.

Fix:

1. In the Admin Portal, open Autoblocking and find the provider of the tracker that fires without consent. Note which category it is in.
2. If it is missing, or sits in a category that is not blocked, add it or move it.
3. Assign the tracker to the appropriate consent category.
4. Click Pull latest settings in the WordPress admin (Domain Info card) to pull updated categorizations.

Verify: The provider now appears under the category you assigned in Autoblocking, and the tracker no longer fires before consent on a front-end test.

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, those plugins fall back to whatever default they have for “no CMP detected” — typically deny.

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 and check the WP Consent API toggle. On v3.1.0+ it is on by default. In the classic settings screen it is greyed out when the WP Consent API plugin is not active; in the current screen (connected sites) 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, consent_api.consent_type should return 'optin' (EU/UK/EEA) or 'optout' (US state laws); wp_has_consent('marketing') should match the visitor’s choice. 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 tab and Autoblocking page.