OneTrust Not Blocking Cookies? Six Configuration Causes

You published the banner, a visitor clicked reject, and your Network tab still shows an advertising request leaving the page. With OneTrust, that is nearly always a configuration problem rather than a product fault, and it is fixable.

First, what OneTrust actually blocks

OneTrust's own documentation says cookies can't be blocked directly. Most regulated cookies are set by scripts or tags, so the platform controls those instead. The recommended method rewrites a script's type to text/plain and adds a category class; the banner flips it back to JavaScript once the visitor consents to that category. Auto-blocking does the rewriting for you through OneTrust's loader. Both depend on what your pages actually contain, which is where the six causes below come from.

Manual blocking, per OneTrust's documentation·html
<script type="text/plain" class="optanon-category-C0004" src="..."></script>

Six configuration causes

  1. The script was never rewritten. A tag pasted into the template as plain text/javascript, with auto-blocking off or not covering it, simply runs.
  2. It sits in the wrong category. A marketing pixel categorized under strictly necessary (C0001) loads for everyone. Check the category on the script, not just on the cookie list.
  3. Someone added data-ot-ignore. OneTrust documents the attribute as a way to exempt a script from auto-blocking after it blocked something you needed. It also means that script loads regardless of category. Search your templates for it.
  4. The tag manager loader is exempted. OneTrust's example for Google Tag Manager sets data-ot-ignore on the loader. That's a legitimate fix, but it moves the job to the container: every tag inside needs its own consent condition, or it fires on load.
  5. Code runs outside OptanonWrapper. OneTrust notes that scripts placed outside that function run only on the first page load, so a later change in consent does nothing until the visitor navigates.
  6. An iframe still uses src. Embedded video and chat widgets need data-src plus a category class. Left as src, they load and set their own cookies.

What website owners should do

Open a private window, reject everything, and watch the Network tab on the homepage and one deeper page. Any third-party advertising or analytics request you see maps back to one of the six causes. Fix it, publish, and repeat the test; a template change or a new marketing tag can quietly reopen the problem next quarter. The CCPA regulations treat an opt-out as something the business must act on, so what the page does matters more than what the dashboard says.

Where Privisy fits

Privisy loads your live pages like a visitor and records what fires, which gives you a second opinion on your OneTrust setup without touching it. It complements the platform; it doesn't replace it. See how the two fit together on the OneTrust comparison page, or read about the gaps any client-side CMP leaves.

Check what fires after you click reject

Run a free scan and see which third-party requests your site sends, independent of what your consent platform reports.

Scan your site