Most major CMPs — Cookiebot, OneTrust, CookieYes, Termly, and others — offer both cookie auto-blocking and manual blocking as options. Most implementations lean entirely on auto-blocking because it requires no code changes. That convenience is also exactly why it's the most common source of a "banner not blocking" finding.
What each mechanism actually guarantees
Auto-blocking works by pattern-matching: the CMP maintains a library of known third-party script signatures (Google Analytics, common ad pixels, other widely-used tags) and intercepts requests matching those patterns before they load. No code changes are needed on your site — you assign a category in the CMP's admin panel, and matching scripts get blocked automatically. This is real, useful default coverage, and it's correct to rely on it for well-known scripts loaded in a standard way.
Manual blocking works differently: you explicitly rewrite a script tag — commonly
changing its type attribute to text/plain and adding a category-identifying class or
data attribute (the exact convention varies by CMP: OneTrust uses optanon-category-*
classes, other CMPs use their own data-attribute conventions) — so the browser never
executes it as a real script until the CMP explicitly re-enables it after consent. This is
a code-level guarantee, not a pattern-matching guess: if the rewrite is correct, the script
categorically cannot execute before consent, independent of whether the CMP "recognizes"
it.
Why auto-blocking coverage gaps are the norm, not the exception
Auto-blocking can only catch what it recognizes. Scripts that fall outside that pattern library — a hardcoded snippet added directly to a page template, a script loaded through a separate tag manager instance, one injected dynamically by a theme or app integration (common on Shopify and similar platforms), or simply a newer or less common vendor — can load through a path auto-blocking never intercepts. This isn't a CMP bug; it's the structural limit of a pattern-matching approach. See OneTrust not blocking cookies for exactly this gap worked through in detail for one specific CMP — the underlying mechanism and failure pattern are the same across every major CMP, not unique to OneTrust.
When manual blocking is worth the extra setup
For scripts you'd consider a genuine risk if they fired pre-consent — session-replay tools and ad pixels tied to current wiretapping-style litigation patterns are the clearest examples — manually blocking removes the dependency on auto-blocking correctly recognizing your specific implementation. The tradeoff is real: manual blocking requires someone to identify every relevant script and rewrite its tag, and it needs to be redone whenever a new tracking script gets added, which auto-blocking doesn't. For lower-stakes or highly standard scripts, auto-blocking alone is a reasonable, common choice. For the handful of trackers that actually matter most, treating auto-blocking as the default and manual blocking as the explicit backup for anything auto-blocking might miss is the more reliable combination — not an either/or choice.
The only way to actually know which category a given script falls into
How to check: load the site in a fresh incognito window, open DevTools Network tab, and watch what fires before any interaction with the banner. Then click Reject specifically and confirm nothing new appears. This is the same behavioral check covered in how to check if cookies fire before consent — and it's the only way to know what's actually happening, as opposed to what a CMP's category settings or auto-blocking documentation claims should be happening. A script showing as "blocked" in an admin panel and a script that's actually not firing in the Network tab are two different facts, and only one of them is the one that matters.
If you'd rather not check this by hand every time
A pre-consent scan tests the actual behavior directly — which scripts fire before consent and which respect an explicit Reject — regardless of whether your setup relies on auto-blocking, manual blocking, or both. Worth running as a first step on any CMP setup, not just after you suspect a problem.
Petrus, Founder — ConsentCheck. Built by a developer who implements this stack for a living — auto-blocking coverage gaps are close to the single most common root cause behind every "but the banner says it's blocked" conversation I've had.