The banner is up. The categories are configured. Users can accept or reject. By every visible measure, your OneTrust implementation is working. Then someone runs a real audit — opens the browser's network tab, rejects all non-essential consent, reloads the page, and watches tracking pixels fire anyway. That gap between "the banner appears" and "consent is actually enforced" is where most OneTrust implementations live, and it's the gap that creates compliance risk regardless of how much you spent on the platform.
This is the diagnostic guide we use when a client says their OneTrust setup isn't blocking cookies properly. The failure modes are predictable and the fixes are usually straightforward once you know where to look. Here's how to figure out what's actually leaking through.
How to confirm there's actually a problem
Before you fix anything, verify what's broken. The test is simple and doesn't require any special tools beyond a browser's developer tools.
Open the site in an incognito window. When the banner appears, click "Reject All" — not "Accept All," not the X to dismiss. Then open the developer tools (right-click, Inspect), go to the Network tab, and reload the page. Filter for third-party domains — anything that isn't your own site. Any request firing to Google Analytics, Facebook, advertising domains, or other trackers when you've denied consent is a compliance gap.
Do the same test on the Application or Storage tab to see what cookies are actually being set. A properly working consent setup shows only strictly necessary cookies after rejection. If you see cookies from advertising domains, analytics platforms, or social networks, those scripts ran despite the rejection.
Run this test on at least three page types — the homepage, a deep content page, and a page with embedded video or forms. Different pages load different scripts, and the homepage being clean doesn't mean a product page is.
Cause #1: Scripts hard-coded outside the consent layer
The most common cause, by a large margin. A tracking pixel was added directly to the site's header, footer, or theme — bypassing any consent management entirely. It fires on every page load, period, because nothing told it not to. OneTrust can't block what was never routed through it.
The fix is to find every hard-coded tag in your theme files, your custom HTML widgets, your post content, and your plugin configurations, and move them through Google Tag Manager (or wrap them in consent logic directly). Once everything is routed through a controlled layer, OneTrust can govern it. If it's hard-coded, it can't.
This is also a reason to be cautious about WordPress plugins that "easily add" analytics or marketing pixels. Many of them inject scripts directly from PHP at page load, which is exactly the pattern OneTrust can't see.
Cause #2: GTM triggers built on old or wrong consent variables
When GTM does have control of the tags, the next question is whether the triggers are checking consent correctly. The common failure: OneTrust's category names or variable structure changes (or was set up wrong initially), but the GTM triggers still reference the old shape. The tag fires because the trigger evaluates "true" when it should evaluate "false."
The fix is to standardize on a single consent signal pushed to the dataLayer by OneTrust, and build every GTM trigger on that signal. The pattern looks like: OneTrust writes a consent object to the dataLayer whenever the user makes a choice. GTM has a single "OneTrust Consent" variable that reads from that object. Every consent-gated tag uses a trigger that checks the variable. When OneTrust updates, you update the variable mapping in one place, not in dozens of triggers.
DOM-based triggers — checking whether the banner is visible, what classes are on which elements, whether a cookie is present — are brittle and should be replaced. They break the next time anything in the rendering changes.
Cause #3: OneTrust hasn't scanned for the new scripts yet
OneTrust builds its cookie database through periodic scans. If a developer or marketing team member added a new pixel, A/B testing tool, or chat widget between scans, OneTrust doesn't know about it yet. Unclassified cookies are handled based on your admin settings — and in many default configurations, unclassified cookies are allowed until manually categorized.
The fix has two parts. Short term, run a manual scan whenever new tracking technology is added to the site, and classify the results immediately. Long term, change the OneTrust setting for unclassified cookies to "Block until classified." This is the safer GDPR-compliant default. It might accidentally block a legitimate cookie until you categorize it, but that's better than leaking a tracking pixel to every visitor for a week. Catching this kind of drift is a core part of strategic maintenance — without a regular cadence, even well-built consent systems accumulate gaps.
Cause #4: Geolocation rules sending visitors the wrong banner
OneTrust can show different banners to visitors from different regions — a strict opt-in banner for EU visitors and a relaxed opt-out banner for US visitors, for instance. The system relies on geolocation to decide which template each visitor sees. If the geolocation database is outdated, if your CDN is masking the real IP, or if the rules were configured backward, EU visitors might see the US banner (or vice versa) and never get the consent flow the regulators expect.
The fix is to verify geolocation rules with real test traffic from each region (a VPN works for this), check that your CDN passes the real client IP to OneTrust rather than masking it, and confirm that the banner templates match the consent model each region requires. Get this wrong and you can be technically displaying a banner while delivering it to entirely the wrong audience.
Cause #5: Custom banners that don't integrate with the consent API
OneTrust supports fully custom banners — your own CSS, your own JavaScript, your own interaction model. The flexibility is real, and so is the failure mode: a custom banner that looks correct but doesn't properly call OneTrust's consent API when the user clicks Accept or Reject. The user thinks they've consented (or rejected). OneTrust never registers the choice. Scripts behave according to the default state, which is usually "allowed."
The fix is to confirm that your custom banner's accept and reject handlers are calling the correct OneTrust API methods, that the consent state is being written, and that the dataLayer push is happening. If you're building a custom banner, test the consent flow end-to-end, not just the visual appearance.
Cause #6: Caching serving stale consent configurations
If your site is cached aggressively (which it should be for performance), an update to your OneTrust configuration may not propagate to visitors until the cache invalidates. This is rarely the root cause of consent gaps, but it does explain "I fixed it yesterday and it's still leaking today" cases. The fix is to ensure cache invalidation triggers when OneTrust configurations change, and to test from a fresh cache after any consent-system update.
The diagnostic workflow that finds the cause
When a client reports cookies leaking through, the workflow we run is:
First, the reject-and-watch test described at the top — confirms what's actually firing. Second, identify which scripts are loading despite the rejection. Third, trace each one back to its source: is it hard-coded in the theme, injected by a plugin, fired by GTM, or loaded by OneTrust itself? Fourth, check whether the source respects OneTrust's consent signal at all. Fifth, fix the gap at the source — usually by moving the script through GTM with the proper consent trigger, or by using OneTrust's auto-blocking to suppress it at the network level.
This is mechanical work once you know what you're looking for. The hardest part is the patience to do it systematically rather than guess. The same discipline applies to website security work generally — gaps live in the parts nobody is actively checking, and the fix is structured attention rather than tools.
Where Lion Ridge fits
Audit-and-fix work on OneTrust implementations is some of the highest-leverage work we do for clients, because the gap between "we have OneTrust" and "OneTrust is actually working" can be the difference between paper compliance and real compliance. We've done enough of these audits to know where to look first and how to close gaps without breaking the marketing tagging that makes the site useful. This kind of disciplined attention is part of how we approach WordPress development generally — get the foundation right and the systems built on top stay reliable.
If your OneTrust implementation looks fine on the surface but you have a suspicion that something isn't right underneath — or you've already confirmed there's a leak and need help fixing it — tell us what you're seeing. We can usually identify the cause quickly and give you a clear path to closing the gap.
