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 → Settings tab.
2. Look at the setting cards under the Settings heading. 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 WordPress plugin displays a read-only list of detected trackers in the Protection tab — you cannot add or edit providers from within WordPress.

Fix:

1. In the WordPress admin, go to Protection tab and review the Your Trackers panel. Note whether the unblocked tracker appears in the list.
2. If the tracker is missing, click Manage trackers in Admin Portal at the bottom of the panel (or go directly to app.hu-manity.co → Autoblocking).
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 open Your Trackers and confirm the new tracker appears. 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 Settings 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 Settings 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. Uncategorized Trackers Are Firing Without Consent

Cause: Trackers that are detected but not assigned to a consent category (shown as “Uncategorized” in the Your Trackers panel with a “Fires without consent” warning) will run immediately. The plugin only blocks trackers that are categorized into consent levels 2, 3, or 4.

Fix:

1. In the WordPress admin Protection tab, check the Your Trackers panel for any “Uncategorized” trackers.
2. Click Manage trackers in Admin Portal to open the portal Autoblocking page.
3. Assign each uncategorized tracker to the appropriate consent category.
4. Click Pull latest settings in the WordPress admin (Domain Info card) to pull updated categorizations.

Verify: The “Uncategorized” section in the Your Trackers panel should show 0 trackers. Uncategorized warnings should disappear.

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 Protection tab header for threshold warnings or usage indicators.

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 → Settings 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 Settings 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 Protection tab configuration.