WordPress Multisite Consent: One Banner Cannot Serve Every Site

A WordPress multisite network tempts one obvious consent setup: activate the plugin network wide, design one banner, push one configuration to every site. It is tidy, it is centrally managed, and it is wrong in a way that stays invisible until a subsite adds its own analytics, its own shop, its own booking tool, and the network banner is now describing a stack that exists nowhere.

Consent is per controller and per purpose. Subsites in a network often have different owners, different tools, and different audiences in different places. The banner has to describe the site the visitor is actually on, and network tooling that cannot vary by site cannot do the job.

Where the shared setup breaks

Three divergences break it. Tools diverge first: the network stack is shared, but subsite admins add plugins, embeds, and pixels, and the shared banner's categories were written for the network baseline. Purposes diverge second: a subsite shop collecting marketing consent is doing something the network's informational sites are not. Records diverge third: consent given on one subsite is not consent given on another, and a shared log that cannot say which site, which banner version, and which purposes were shown is a log that demonstrates very little.

The GPC work in Global Privacy Control on WordPress: Most Sites Claim to Honour It and Never Test It shows the per site verification habit this requires: the signal has to be tested on each site, because network activation is not evidence that a given subsite's configuration honours it. Multisite multiplies every consent question by the number of sites, and tooling that hides that multiplication is hiding the work, not doing it.

The per site model that still scales

Keep the shared parts shared: the plugin, the design system for the banner, the category vocabulary, the testing checklist. Make the operative parts per site: the tracker inventory, the purposes offered, the record store, the privacy notice, and the named owner who answers for that site's setup. A template configuration that each site clones and then edits against its own scan gives you consistency without fiction.

Network admins should also lock the dangerous middle ground: subsite admins can add tools, so the network needs a rule that adding a tracker without updating the site's consent configuration is an incomplete change, plus a periodic scan across subsites to catch the drift. The age gate analysis in Age Gates on WordPress Sites Collect the Data They Claim to Protect Against is a useful template for the per site questions: what data, whose tool, which basis, asked site by site, because the answers genuinely differ.

When one banner really is right

If the network is one organisation, one controller, and a set of sections wearing subsite clothes, a shared setup can be legitimate, provided the inventory genuinely covers every tool on every subsite and the records identify the site of consent. The test is factual, not architectural: could you show an inquiry the exact banner and purposes a named visitor saw on a named subsite on a named date. If yes, the model holds. If the honest answer involves the words probably or network wide, it does not.

Scale is a real virtue and nobody should run thirty hand built banners for fun. The line is between shared tooling with per site truth, which scales, and shared truth with per site reality, which is where networks get into trouble they cannot document their way out of.

Frequently asked questions

Can one consent banner serve a whole WordPress multisite network?

Only if the network is effectively one controller running one stack, with records that identify the site and banner version for each consent. Where subsites have different owners, tools, or purposes, each site needs its own inventory, purposes, and records, even if the plugin and banner design are shared.

What consent settings should be per site in multisite?

The tracker inventory, the purposes offered, the consent records, the privacy notice, and the named owner responsible for the setup. The plugin choice, banner design system, category vocabulary, and testing process can and should be shared across the network.

How do I stop subsites breaking network consent?

Pair a cloneable template configuration with a rule that adding a tracker is an incomplete change until the site's consent configuration is updated, and run periodic scans across subsites to catch drift. Network activation of a plugin is not evidence that each site's setup is correct; verify per site.

Does consent on one subsite cover another subsite?

No. Consent is given to a controller for stated purposes in a specific context. A visitor consenting on one subsite has not consented to another site's tools or purposes. Shared login or shared branding does not merge consent across sites.