WordPress Multisite tempts administrators into a single decision applied everywhere: one consent plugin, one banner, one set of categories, network wide. It is an understandable instinct on a platform built for shared management. It is also where multisite consent programs go wrong, because the network is one installation but rarely one audience, one brand, or one legal situation.
A university network, a franchise system, and an agency hosting client sites on one install have almost nothing in common except the software. Their consent needs differ accordingly, and the setup has to express those differences without dissolving into per site chaos.
Shared tooling, per site configuration
The workable pattern is a shared tool with site level configuration. Network activate the consent plugin so every subsite has vetted, maintained tooling with no option to forget it entirely. Then configure categories, banner text, and policy links per site, because the trackers on the athletics subsite and the admissions subsite are not the same trackers.
Baseline templates keep this manageable. Define a network standard configuration that covers the common stack, and let site admins adjust from it with the differences documented. Sites that add new tracking tools adjust their categories to match, which is the same rule as any single site, enforced at network scale through the template rather than through hope.
Records must stay separated by site
Consent records answer the question of what a visitor agreed to on a specific property. A network level log that pools every site's consent events into one undifferentiated store creates retrieval pain and legal confusion: the consent given on one subsite does not authorize tracking on another, and your records should reflect that boundary structurally, not just in a site column nobody filters by.
Separation also protects sites from each other. If one property faces an inquiry, its records should be producible without exposing or entangling the whole network. The same logic applies to retention schedules, which may legitimately differ between a public marketing subsite and one serving a regulated audience.
Subsite admins need guardrails, not just access
Multisite's permission model means many hands can add plugins, embeds, and tag containers, each capable of outrunning the consent setup in an afternoon. A new video embed on one subsite, a marketing pixel added for a campaign, and that site's banner no longer describes its tracking. Network governance, approved tool lists and a change habit of updating categories with tools, is the actual compliance mechanism.
Periodic network wide scanning closes the loop. Crawl the subsites, inventory the trackers actually loading, and compare against each site's declared categories. Drift is guaranteed; the only choice is whether you find it on a schedule or an investigator finds it for you. Multisite makes the scan efficient, since one crawl can cover the family.
When one network really is one site
Some multisite installs are one property wearing technical clothes: language versions of a single site, or sections of one brand split for administration. There, a unified consent experience across the network can be right, and forcing separate banners on each language subsite would be worse for visitors and for consistency.
The test is the visitor's and the law's view, not the admin's. Same entity, same purposes, same audience relationship: unify. Different brands, entities, or audiences sharing an install for convenience: separate. Deciding which pattern a network is, in writing, before configuration begins, prevents the most expensive multisite mistake, which is building the wrong one thoroughly.
Related reading
These earlier guides go deeper on connected questions: WordPress Booking Plugins and Cookie Consent: What Fires Before a Visitor Agrees Booking plugins bring calendars, payment tools, and sometimes maps and chat into a WordPress page, and many load third party services before consent. How to audit a booking flow for pre consent loading and fix the worst offenders., WordPress Popups and Consent: What Your Popup Plugin Fires Before the Banner Popup plugins load trackers, set cookies, and phone home on page load, before any consent. Auditing what your WordPress popup plugin fires, and gating it behind consent., and WordPress Contact Form Plugins and Consent: What Your Forms Collect Before Submission WordPress contact forms collect more than the message: pre-submission tracking, spam APIs, entry logs. What fires before consent and how to set forms up cleanly..
Frequently asked questions
Can one consent banner cover a whole WordPress multisite network?
Only when the network is effectively one property: same entity, same audience, same purposes, such as language versions of one site. When subsites are different brands, entities, or audiences, consent must be configured and recorded per site, even though the tooling can be shared and network activated.
How should consent records be stored on multisite?
Separately per site, or in a shared store with strict per site separation that is actually used in retrieval. Consent given on one subsite does not authorize tracking on another, and an inquiry into one property should be answerable without entangling the rest of the network.
Who is responsible for consent on a subsite?
Practically, both levels: the network provides vetted tooling, baselines, and audits, while the subsite controls its own tools and content and must keep its categories honest. Governance that assigns those duties explicitly, with an approved tool list and drift scanning, is what makes the split work.
How do we stop subsites adding trackers without updating consent?
Combine an approved tools policy with scheduled network wide tracker scans that compare what actually loads on each subsite against its declared categories. Drift is inevitable on a multi admin platform; finding it on your own schedule is the control that keeps banners truthful.