Standing up OneTrust on a single WordPress site is a defined project with a known scope. Standing it up across a WordPress Multisite network of fifty, a hundred, or more child sites is a different category of problem, and the lessons from single-site implementations don't transfer cleanly. The platform expects a one-to-one relationship between site and consent configuration; multisite networks are inherently many-to-one and many-to-many. The work is to bridge that gap in a way that's consistent across the network, doesn't require reconfiguring every site individually, and stays maintainable as new sites get added.
We've done consent management implementations on multisite networks at real scale, and the patterns are different enough from single-site work that it's worth a dedicated discussion. If you're running a multisite network and trying to figure out how OneTrust (or any enterprise consent platform) actually fits, here's what changes and what to plan for.
Why multisite changes the problem
A WordPress Multisite installation is a single WordPress install serving many distinct sites — each with its own domain or subdomain, its own admin, often its own theme and plugin configuration, but all sharing the same underlying database and codebase. The architecture is excellent for managing many related sites without duplicating infrastructure — we built the Greater Toronto Hockey League platform this way to handle 65 member team sites on a single installation, and the FanReach partnership uses the same model.
What multisite is excellent for is also what makes consent management complicated. The same install serves visitors from many different audiences, each child site may have different tracking requirements, and configuration changes can either propagate to every site (network-wide) or stay scoped to a single site (per-site) depending on how they're applied. OneTrust's defaults assume single-site behavior. Getting it to behave correctly across a multisite network requires deliberate architectural choices, not just configuration choices — the same dynamic we've written about in why enterprise websites require different architecture.
The four architectural patterns
There are four ways to structure a consent management implementation across a multisite network. Each has tradeoffs, and the right choice depends on how similar the child sites are and who controls configuration changes.
Pattern 1: One OneTrust account, one configuration, propagated to all sites. The simplest pattern. A single OneTrust property serves every child site with the same banner, the same categories, and the same rules. Network-level changes apply everywhere automatically. The downside is rigidity — every site gets the same treatment regardless of whether it makes sense for that specific audience.
Pattern 2: One OneTrust account, multiple configurations, mapped by domain. A single OneTrust property serves all sites, but different banners, categories, or rules apply to different child sites based on the domain or URL. This is OneTrust's intended pattern for multi-property organizations. It gives you per-site flexibility while keeping central control. The cost is configuration complexity — you have to maintain the mapping deliberately, and adding a new site means updating the OneTrust configuration as well as creating the site itself.
Pattern 3: Separate OneTrust accounts per child site. Each child site has its own OneTrust property, configured independently. Maximum flexibility, maximum cost. The configuration burden multiplies linearly with site count, and updates that should apply everywhere have to be made everywhere. Almost never the right answer for a true multisite network, though sometimes the right answer for organizations whose "multisite" is really a collection of distinct businesses sharing infrastructure.
Pattern 4: Hybrid — shared base configuration with per-site overrides. A single OneTrust property with a base set of categories and rules that apply network-wide, plus the ability for individual sites to override specific elements (banner copy, additional categories, specific script blocking) when their situation requires it. This is what most mature multisite consent implementations end up looking like. The base layer keeps things consistent and maintainable; the override layer accommodates the real differences between sites.
What gets harder at scale
Beyond the architectural decision, several aspects of consent management get specifically harder at multisite scale.
Cookie inventory across many sites. Different child sites often have different plugins, different embedded content, and different marketing pixels. The cookie inventory for the network isn't the union of all cookies on all sites — it's the per-site reality, because the same cookie might be present on twenty sites and missing from thirty others. The scan has to be comprehensive across the network, and the classification work scales with the variation between sites.
Tag manager structure. If each child site has its own Google Tag Manager container, you're configuring the OneTrust-GTM bridge once per site. If sites share a container, you have to handle the per-site rules within the container's logic. Neither is wrong; both require deliberate design.
Per-site customization. Multisite networks often exist precisely because different sites need their own branding, their own messaging, their own audience-specific configuration. The consent banner is part of that — the language, the styling, sometimes the specific opt-in choices. Building enough flexibility into the network configuration that each child site can have its own banner, while still maintaining central control of the underlying compliance logic, is real architectural work.
Onboarding new sites. New child sites get added regularly in healthy multisite networks. The consent configuration has to be part of the onboarding process — not something that gets added later when someone notices the new site doesn't have a banner. Documented procedures and templated configurations matter at scale in ways they don't for single sites.
Network-wide audits. Auditing a single site for cookie leaks is a quarterly task. Auditing fifty sites is fifty quarterly tasks unless you build sampling and automated monitoring into the process. The scaling problem isn't the audit itself; it's the discipline of doing it consistently.
The plugin architecture choices that matter
At multisite scale, the WordPress-side plugin choices significantly affect how consent management behaves. A few patterns we've found work well:
Network-activated consent plugin. If you're using a WordPress plugin to load the consent management script (rather than putting it in the theme or GTM), network-activate it so every child site gets the same script loading behavior. Per-site activation creates drift.
Centralized tracking pixel management. Avoid letting child site admins add tracking pixels through ad-hoc means (theme code, custom HTML blocks, plugin configurations). Standardize on Google Tag Manager or another centralized layer so every script is governed by the consent system rather than firing independently.
Documented per-site override paths. When a child site needs a different banner, a different category, or different rules, the path to make that change should be documented, sanctioned, and traceable — not a one-off custom job that nobody else knows about. Otherwise the network configuration drifts toward chaos.
Single source of truth for the cookie inventory. One canonical document that lists every cookie used anywhere in the network, which child sites use it, what category it belongs to, and who owns it. Maintaining this document is the ongoing work that prevents the inventory from becoming guesswork.
Performance at scale
The OneTrust script payload is heavier than the smaller consent platforms — a real consideration when you're loading it on every page of fifty sites. Network-level caching, CDN distribution, and careful script loading (async or deferred where the implementation allows) matter more on multisite than on a single site, because the cumulative impact compounds across the network. Managed hosting that handles multisite specifically — with proper caching and the operational attention multisite needs — is genuinely important here.
When OneTrust isn't the right answer for multisite
It's worth being honest about this: not every multisite network needs OneTrust. If your network is a hundred local-business sites in a single jurisdiction with the same straightforward tracking needs, a lighter consent platform may actually be a better fit. OneTrust's enterprise capability shines when you have genuine multi-jurisdiction complexity, formal compliance requirements that demand its audit trails, or integration with broader privacy infrastructure. If your multisite is large but consistent and the requirements are uniform, the simpler platforms can handle it at a fraction of the cost. The number of sites alone doesn't justify OneTrust; the complexity of the requirements does.
Where Lion Ridge fits
Multisite consent management is some of the most specialized work we do, and there are very few agencies set up to handle it well. Our experience comes from years of building and maintaining real multisite networks at scale, including ones where consent management has to behave consistently across dozens of distinct properties while still letting each one operate with its own identity. The architectural decisions matter, and getting them right at the start saves significant ongoing pain — a discipline we describe in our broader WordPress development guide.
If you're running a WordPress Multisite network and trying to figure out the consent management approach — or you have one in place and it's not behaving consistently across the network — tell us what you're working with. We'll give you a straight read on the architectural choices and what implementation should actually involve at your scale.
