Applies to: WordPress Plugin + Admin Portal

WP Admin: Protection tab > Tracker Status
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. Autoblocking Is Not Enabled

Cause: Autoblocking is on by default for connected users, but may have been disabled. Verify it has not been turned off; the consent widget intercepts and delays third-party scripts only while autoblocking is active.

Fix:

  1. Go to WP Admin → Compliance → Settings tab.
  2. Look at the Compliance Behavior section. Verify that Autoblocking is toggled on. (Autoblocking is enabled by default for connected users; this step is to confirm it has not been disabled.)
  3. If it shows as disabled, enable it. As of v3.0.2 autoblocking works regardless of which laws are selected.

Verify: Open your site in an incognito browser. Before interacting with the banner, open the browser’s Developer Tools → Network tab and filter by the tracker domain (e.g., google-analytics.com). The request should not appear until after consent is given.

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 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 24 hours, or use Refresh in the Protection tab).

Verify: After adding the provider, click Refresh in the Your Trackers panel 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, ensure GTM is loaded through the consent widget’s built-in Google Consent Mode v2 integration rather than a hardcoded snippet. 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. View the page source and confirm script tags have been modified with data-hu-category attributes or type="text/plain" (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 (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 portal to open the portal Autoblocking page.
  3. Assign each uncategorized tracker to the appropriate consent category.
  4. Click Refresh in the WordPress admin 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 Basic (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: 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 → Configuration and check the WP Consent API toggle. On v3.1.0+ it is on by default; if it is greyed out, the WP Consent API plugin is not installed.
  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, wp_get_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.
Was this article helpful?
YesNo