OneTrust is one of the most common CMPs behind a "cookie banner not blocking cookies" finding — not because OneTrust doesn't work, but because its blocking mechanisms have real coverage limits that a correct-looking category configuration doesn't reveal on its own.
The core issue: OneTrust has two blocking mechanisms, and only one is automatic
OneTrust blocks scripts two ways: autoblocking (automatic pattern-matching against
known third-party scripts) and manual blocking (rewriting a script tag's type
attribute to text/plain plus an optanon-category-* class, so OneTrust only re-enables
it after the matching category is accepted). Blocking the script from executing is what
stops the cookie it would have set from ever being set in the first place — a cookie can't
exist without the script that sets it running, so "not blocking cookies" and "not blocking
the script" describe the same underlying gap. Autoblocking covers a lot out of the box, but
it can only intercept scripts it recognizes. Anything outside that recognized pattern set
needs manual blocking — and a script that was never manually rewritten, and that
autoblocking doesn't recognize, simply isn't blocked by anything, regardless of what the
category settings in the OneTrust admin panel show.
1. Check whether the firing script is actually covered by autoblocking
How to check: in a fresh incognito window, open DevTools Network tab and reload without touching the banner. Note exactly which request is firing early — the specific domain and script. Then check OneTrust's autoblocking documentation or admin panel for whether that specific script pattern is in its recognized list.
The fix: if it's a common, well-known script (GA4, major ad pixels), autoblocking should normally catch it — if it's still firing, confirm autoblocking is actually enabled for your domain in OneTrust's settings; in some setups it's a feature that needs to be explicitly turned on rather than always active by default, so it's worth checking directly rather than assuming. If it's a less common, custom, or hardcoded script, move to manual blocking instead of relying on autoblocking to eventually recognize it.
2. Check whether the script needs manual optanon-category blocking
How to check: find the script tag for the firing request in your page source. If it's
a plain <script src="..."> tag with no type="text/plain" and no optanon-category-*
class, and it isn't covered by autoblocking (check #1), nothing is blocking it — this is
the gap, not a OneTrust misconfiguration.
The fix: rewrite the tag to type="text/plain" with the appropriate class —
optanon-category-C0002 for Performance/Analytics, optanon-category-C0004 for
Targeting/Advertising are the common defaults, though your OneTrust setup may have
different category IDs configured. OneTrust's script only re-executes once the visitor
consents to that category — this is the exact mechanism, not a general "make it work"
setting.
3. Check whether the script loads through a path autoblocking can't see
How to check: scripts injected by a separate tag manager instance, a theme/app integration (common on Shopify and similar platforms), or dynamically inserted via JavaScript rather than present in the initial page source can load through paths autoblocking's pattern-matching doesn't reliably intercept, even for otherwise-recognized scripts.
The fix: for scripts loaded through GTM specifically, use GTM's own Additional Consent
Checks on the individual tag rather than relying on OneTrust's page-level autoblocking to
catch a script GTM injects dynamically — this combines OneTrust's category state (pushed
into dataLayer) with GTM's own per-tag consent gating, which is more reliable for
dynamically-loaded scripts than autoblocking alone. This same general auto-blocking vs.
manual-blocking distinction — and when to trust which — is worth understanding beyond just
OneTrust specifically; see auto-blocking vs. manual blocking in cookie
banners for the broader version of this question.
4. Confirm by testing Reject specifically, not just the pre-interaction state
How to check: reload in the same incognito session, click Reject All (not just observe the pre-interaction state), then check the Network tab again. A script that's silent before interaction but still fires after an explicit Reject has a different problem than one that's simply unblocked — usually a category mapping mismatch rather than a missing block.
The pattern behind most real-world OneTrust findings
The category settings being correct and the actual blocking behavior being correct are two different facts — OneTrust's admin panel showing a category as "blocked" describes intent, not a guarantee about every script on the page. The gap is almost always in coverage (autoblocking not recognizing a specific script) or configuration (a script that needed manual rewriting and never got it), not a OneTrust product defect. This is exactly the kind of gap that's easy for OneTrust itself to structurally never surface, since it can only tell you about scripts it's aware of — see why Google Consent Mode v2 isn't working for the parallel version of this same "looks configured, isn't behaving correctly" pattern on the Consent Mode side specifically.
If you'd rather have this checked automatically
A pre-consent scan tests actual behavior — what fires before consent and after an explicit Reject — rather than reading OneTrust's category configuration, which is exactly the gap between "configured" and "working" this article covers.
— Petrus, Founder, ConsentCheck. I implement OneTrust professionally, and coverage gaps like this — not outright misconfiguration — are the majority of what I actually find when auditing a "should be working" setup.