Autoblocking Overview

Autoblocking is Cookie Compliance’s consent-first safeguard. It pauses non-essential scripts and iframes until a visitor makes a choice, then only allows what aligns with that choice to run. This prevents pre-consent leakage and keeps analytics and ads from running ahead of the visitor’s recorded choice. Think of it as a gate that opens only for what a user has actually agreed to—nothing more.

How it works, conceptually

When a page loads, Cookie Compliance looks for third-party Providers (analytics, ads, media embeds, widgets). Until there’s valid consent, those Providers are held: they don’t run, so they set no non-essential cookies. (The browser may still download a held script file, which contacts the provider’s server, 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. After a choice is recorded, the system “releases” only the Providers that match the accepted Purpose Categories. Withdrawals or changes are saved immediately and held Providers stay held, but Providers already running on the page keep running until the next page load (turn on Reloading to reload the page as soon as the choice is saved). This applies to traditional sites and modern SPAs alike, so late-loaded components don’t sneak past consent.

Two controls, not one

From plugin version 3.1.10 onward, autoblocking is governed by two separate switches, not one. Both live in WordPress admin → Compliance → Settings tab, in the first settings section on the page. Checking only one of them is the most common reason autoblocking appears not to be working.

• Script blocking engine — the master switch. Turn this off and Cookie Compliance never touches your scripts: nothing is blocked for any visitor, in any region, regardless of privacy signals. Leave it on unless you handle script blocking yourself.
• Autoblocking — block before consent. Holds third-party scripts until the visitor makes a choice. With this off, scripts load immediately; once the visitor chooses, their choice is enforced either way.

The engine gates the posture, 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. If third-party scripts are firing before consent, check the engine first: with Autoblocking off you still lose only the pre-consent window, but with the engine off nothing is enforced at any point.

Both switches live in the WordPress plugin. The Script blocking engine switch is only there. Autoblocking can also be set in the Admin Portal at app.hu-manity.co, under Configuration → Laws → Site-wide autoblocking; saving it there updates the plugin’s Autoblocking setting, with plugin 3.1.11 or later. On a site that uses the pasted snippet instead of the plugin, both are keys in the snippet itself (blockingEngine and blocking) — see Where to put the Cookie Compliance snippet.

Purpose Categories & Access Levels (the core model)

Cookie Compliance uses a small, consistent set of Purpose Categories to describe why a Provider runs. Typical categories include:

• Basic Operations (Category 1) — essential functions required for the site to work (not subject to autoblocking).
• Content Personalization (Category 2) — recommendations, embedded media behavior, UX tailoring.
• Site Optimization (Category 3) — analytics, performance measurement, A/B testing.
• Ad Personalization (Category 4) — advertising, audience building, cross-site tracking.

The provider list below is the Admin Portal. Adding and editing providers is done there. The WordPress plugin can show which trackers it detected, and it cannot add or edit providers.

1. Open app.hu-manity.co → Autoblocking.
2. Open a Purpose Category to see its providers.
3. Use Add Provider or the row menu to add or edit one, then click Publish Now.

These categories power everything: the banner text, what’s allowed to run, and what’s recorded in your consent logs. They’re also what make consent portable across pages and sessions—if a visitor accepts “Site Optimization,” any matching Provider can run, while others remain blocked.

On top of categories, the banner offers Access Levels that provide quick, understandable defaults:

• Private — the highest-privacy experience. Only Basic Operations run. Everything else stays blocked unless the visitor later opts in.
• Balanced — a pragmatic middle ground. Basic Operations, Content Personalization, and Site Optimization may run. Ad Personalization stays off unless the visitor chooses Personalized or turns that purpose on in Preferences.
• Personalized — the most feature-rich experience. Content Personalization and Ad Personalization are enabled together with Site Optimization, giving visitors full personalization and marketing features.

Access Levels are simply presets over the Purpose Categories, expressed in plain language so visitors understand the tradeoffs. Whether someone taps “Private,” “Balanced,” or “Personalized,” autoblocking enforces that choice by mapping it to the underlying purposes and only unblocking Providers that fit.

Signals and scope (just what you need)

The banner is the source of truth for user choices; Autoblocking enforces those choices at runtime. Where enabled, consent modes—Google Consent Mode, Meta (Facebook) Consent Mode, and Microsoft Consent Mode—read the standardized consent signals so their tags degrade gracefully before consent and upgrade after consent. These modes complement, not replace, autoblocking. If Global Privacy Control (GPC) is honored in your setup, autoblocking also treats it as a do-not-sell/share preference for the relevant purposes.

What to expect (practical boundaries)

Most common Providers are recognized out of the box, backed by a built-in database of 282 patterns covering 181 providers across the 4 Purpose Categories above. Self-hosted or uncommon loaders may need a precise URL pattern so they’re identified correctly. Inline or obfuscated tags can obscure detection; transparent integration yields the most reliable results. Basic Operations are never blocked; everything else follows the consent model you expose in the banner. The goal is consistency: the wording visitors see, the purposes you configure, what actually runs, and what gets logged all line up.

Key Terminology

• Provider — a third-party service such as analytics, ads, media, or widgets.
• URL pattern — the match rule used to recognize a Provider’s script/iframe/endpoint.
• Purpose Category — the why behind a Provider (e.g., Site Optimization); governs unblocking.
• Access Level — a preset that toggles multiple purposes at once (Private, Balanced, Personalized).
• Consent signals / Consent Modes — standardized flags read by some platforms to adapt behavior.

That’s the big picture. Autoblocking guards the door; Purpose Categories define the rules; Access Levels make the decision simple for visitors—so what runs always reflects what was actually agreed to.