Multisite is sold on sameness: activate once, apply everywhere. Consent punishes that assumption. Each subsite in a network can run different plugins, embed different services, serve a different country, and publish in a different language, while sharing one consent installation that was configured for the main site.
The right model is shared defaults with per site verification. The network gives you leverage on setup and updates. It does not give you a single compliance answer, and treating it as one is how subsidiary sites end up with banners that describe tools they do not use and miss tools they do.
What to standardize across the network
Standardize the mechanics: how consent is stored, how records are logged and retained, the blocking approach for tags, banner behavior such as equal accept and reject paths, and the update process when the consent plugin changes. Consistency here makes audits and support manageable across dozens of sites.
Also standardize the audit method. One checklist, run per site, with results stored centrally, turns network scale into an advantage: patterns appear, such as one popular plugin that breaks blocking on every subsite that uses it.
What must be checked per subsite
Plugin inventory is the biggest variable. Each active plugin that sets cookies or loads external services belongs in that subsite banner categories and descriptions. A network level cookie list copied to every site will be wrong in both directions on most of them.
Language and jurisdiction follow the audience, not the network owner. A subsite serving another country may need different banner text, a different language, and a different legal basis for its analytics. Check the actual audience data before assuming the main site settings travel.
Roles, access, and change control
Decide who can change consent settings on a subsite and who approves new plugins with tracking behavior. In many networks, site admins can install or activate tools that change the consent picture overnight, with no notification to whoever owns compliance.
A light process works: plugin activations that touch cookies get flagged, and a short consent check joins the launch checklist for new subsites. Heavy approval chains get bypassed. A flag and a checklist survive contact with real teams.
Testing a network without testing forever
Full testing of every subsite after every change does not scale, so test by class. Group subsites by their plugin and embed profile, test one representative of each class deeply, and run automated checks, banner presence, pre consent network behavior, records logging, across all of them.
When a class representative fails, fix the class, not just the site. Network thinking applied to failures is where multisite finally pays off for consent: one correction propagated everywhere the same pattern lives.
Related reading
These earlier guides go deeper on connected questions: WordPress Consent After a Theme Change: The Settings That Silently Reset Theme changes are the quiet consent killer on WordPress. Header scripts move, plugin hooks change, and the banner that worked in January is firing after the analytics by March. A post-theme consent checklist prevents it., WordPress Consent for Membership Sites: Logged-In Users Still Count Membership sites often exempt logged-in users from the banner and call it done. Account holders are still tracked, still profiled, and in most frameworks still owed the same choices as visitors. Login is not consent., and WordPress Cookie Banner Accessibility: Keyboard, Focus, and Contrast Checks A consent banner that keyboard users cannot reach or read fails twice. This guide covers the accessibility checks every WordPress banner should pass, from focus order to contrast..
Frequently asked questions
Can one consent setup cover a whole multisite network?
It can provide shared defaults for mechanics, records, and banner behavior. Each subsite still needs its own check for plugins, embeds, language, and jurisdiction, because those differ across a network.
What differs most between subsites for consent?
Plugin inventories and embedded services. Each tool that sets cookies or loads third party code must appear correctly in that sites categories. A copied network cookie list is usually wrong on most subsites.
Who should control consent settings on multisite?
Define it explicitly. Site admins who can activate tracking plugins should trigger a consent check, and one owner should hold the network baseline and the audit results.
How do you test consent across many subsites efficiently?
Group sites by plugin and embed profile, test one representative per group deeply, and run automated consent checks across all sites. Fix failures at the group level where the pattern is shared.