OneTrust documentation is exhaustive, technically accurate, and almost entirely written for an audience that doesn't run a WordPress site. The walkthroughs assume a clean, centrally managed tag stack, a single point of truth for which scripts fire where, and a development team that can hard-code the consent integration into the site's source. WordPress sites don't usually work that way. They have themes that load their own scripts, page builders that inject markup at render time, plugins that fire third-party calls from inside their own code, and marketing teams who add tracking pixels through interfaces nobody is documenting. Getting OneTrust to work cleanly on a WordPress site means closing the gap between how OneTrust expects the world to work and how WordPress actually works.
This is the guide we'd hand a marketing team that's been asked to implement OneTrust on a WordPress site and is trying to figure out where to start. Not the official documentation version — the version that addresses the specific WordPress problems OneTrust's docs assume you don't have.
What OneTrust actually does (and what it doesn't)
OneTrust is a consent management platform — software that handles the cookie banner, records user consent, and signals to the rest of your tag stack which categories of trackers can fire. What it does well is the consent layer itself: presenting the banner, recording the choice, surfacing the preference center, and producing the audit trail that regulators expect. What it doesn't do automatically is enforce that consent across your site. Enforcement requires that every script which touches a cookie is wired up to read OneTrust's consent signal and behave accordingly — and on a WordPress site, those scripts are scattered across more places than most teams realize.
The most common misconception we encounter: that installing OneTrust and seeing the banner appear means the work is done. It doesn't. The banner showing up means OneTrust is loaded. Whether your analytics, advertising, chat widgets, video embeds, social pixels, and plugin-injected scripts actually wait for consent before firing is a separate question, and the default answer is usually "no" until someone audits it.
Step 1: Inventory every script and cookie
Before you touch the OneTrust admin, run a real inventory of what's actually loading on your site. OneTrust's scanner gets most of this, but the scanner is a starting point, not a complete picture. It misses scripts that only load on certain pages, conditional scripts that fire based on user behavior, and anything injected by plugins that load on specific post types or templates.
The discipline is to scan multiple page types — homepage, a deep blog post, a product page, a contact form page, anything behind a login — because different templates load different things. Cross-reference the scanner output against your plugin list, your theme's loaded scripts, and anything Google Tag Manager is firing. The output should be a single document that lists every cookie and script, what it does, what category it belongs in (strictly necessary, functional, performance, marketing), and who owns it. This document is the foundation of everything that comes after.
Step 2: Map cookies to categories, deliberately
OneTrust groups cookies into categories — typically Strictly Necessary, Functional, Performance, and Targeting/Marketing, though the exact taxonomy is configurable. Each category gets its own consent rule. Strictly necessary cookies can fire without consent because the site won't function without them. Everything else requires opt-in (in GDPR jurisdictions) or opt-out (in CCPA jurisdictions, and the rules vary by state).
The work here is judgment, not paperwork. A "performance" cookie that feeds your analytics is in a different bucket from a "targeting" cookie that feeds an ad retargeting platform. Misclassifying cookies is one of the most common compliance gaps we find in audits — a tracking pixel categorized as "functional" so it doesn't get blocked, when the regulators would categorize it as marketing and expect it to wait for consent. The honest classification is the safe one.
Step 3: Connect OneTrust to Google Tag Manager (the right way)
If you're using Google Tag Manager — and most WordPress sites with serious marketing tagging are — the integration between OneTrust and GTM is where most implementations succeed or fail. The right pattern is this: OneTrust pushes a clean, structured consent object into the dataLayer whenever consent is set or changed. GTM reads that object and uses it as the trigger condition for every tag that needs consent.
The wrong pattern, which is unfortunately common, is to build GTM triggers around DOM checks — reading whether the banner is visible, what classes are on which elements, that kind of thing. DOM-based triggers are brittle. They break when OneTrust updates its banner markup, when a CSS conflict changes the rendering, or when the page loads in an unexpected order. A dataLayer-based integration is auditable, predictable, and survives both OneTrust and GTM updates.
The other GTM-side mistake to avoid is leaving tags hard-coded in the site's source while routing everything else through GTM. Hardcoded tags don't know anything about OneTrust's consent state — they fire when the page loads, period. Funnel everything through GTM (or another controlled layer) so consent rules apply universally. The general principle applies to any integration where data needs to flow between systems on a controlled basis, which we covered in API Integrations That Improve Business Operations.
Step 4: Handle the WordPress-specific edges
A few things break the simple OneTrust setup on WordPress that don't break on hand-coded sites:
Plugins that inject scripts directly. Many WordPress plugins (forms, chat widgets, social embeds, analytics add-ons, A/B testing tools) load their own scripts directly from the plugin's PHP, not through GTM. These bypass OneTrust unless you either replace them with implementations that respect consent, route them through GTM, or use OneTrust's auto-blocking to suppress them at the script-source level.
Page builders that load assets on demand. Divi, Elementor, and similar tools sometimes inject scripts based on which modules are present on a given page. The scan you ran on the homepage may miss them. Sample multiple page types or you'll have surprises.
Theme scripts. Premium themes often include analytics integration, social sharing, or font services that load directly. These need to be either disabled (if you're using them through GTM instead) or wrapped in consent logic.
Caching. Cached pages can serve a stale version of your consent setup if cache invalidation isn't configured properly when OneTrust updates. Most managed WordPress hosts handle this well; cheap shared hosting often doesn't. Hosting is a business decision for reasons that go beyond consent, but consent management is one of them.
Step 5: Test against real network calls, not the preview mode
OneTrust's preview mode shows you the banner and the categorization. It does not tell you whether tags are actually blocked when consent is denied. The real test is opening a browser's network tab, denying all non-essential consent, reloading the page, and watching what requests fire. Anything that calls out to a third-party domain when you've denied consent is a compliance gap, regardless of what the OneTrust admin says is configured.
Do this test on every major page type and after every significant change to the site. A quarterly audit catches the drift that happens when marketing teams add new pixels, when plugins update and load scripts differently, or when OneTrust scans miss a new tracking technology.
Step 6: Make ongoing maintenance someone's actual job
OneTrust is not set-and-forget. Categories change, the OneTrust UI updates, new scripts get added to the site, regulations evolve, and the consent setup that was clean six months ago has usually accumulated gaps. The discipline is regular audits — at minimum quarterly, monthly for high-traffic sites — and a clear owner for the consent system. Without that owner, the implementation degrades quietly while everyone assumes it's still working.
This is one of the reasons we treat consent management as part of strategic website maintenance rather than a one-time setup project. The platform doesn't take care of itself.
Where Lion Ridge fits
OneTrust implementation on WordPress is exactly the kind of work boutique agencies are built for — technical enough to require real expertise, specific enough that generalists struggle with it, and ongoing enough that you want a partner who understands both halves rather than a one-time vendor. We do this work for clients whose legal or compliance teams have committed to OneTrust and need it to actually work on the WordPress side.
If you're standing up OneTrust on a WordPress site and want help getting the implementation airtight rather than approximately compliant, tell us what you're working with. We'll give you a straight read on what the project should involve and whether you need our help or just a checklist to do it yourself.
