TL;DR
- Most multisite governance documents are written after the incident, not before. Networks above ten sites accumulate decisions faster than tribal knowledge can hold them. The same plugin request gets two different answers six months apart. The inconsistency is not malicious, it is structural. WordPress permissions exist. Policies do not, until somebody writes them down.
- An AI multisite governance policy reads three inputs — the current network inventory (sites, plugins per site, themes per site, super-admin and site-admin counts), the site-admin role permissions, and any known incidents from the last 12 months in plain English. The chat returns the first draft of a one-page policy. Six sections, calibrated to your inventory.
- The plugin allowlist sits in three tiers. Tier one is mandatory and network-activated by the super admin (security, backups, accessibility, analytics). Tier two is approved and per-site activatable (forms, SEO, image optimization, page builders). Tier three is request-only — everything else, with documented denials so the network admin reuses prior decisions instead of re-litigating from scratch.
- Three traps. Treating the AI draft as the final policy (the network admin’s incident history calibrates the tier boundaries, not the chat). Drafting governance for fewer than ten sites (below that threshold the maintenance cost exceeds the value). Treating policy as a security tool rather than a coordination tool (it documents what the team agreed to before the compromise — detection and response live in different artifacts).
- The policy lives in the network admin’s wiki or shared docs folder, linked from a wp-admin Network Settings dashboard widget. The site admin reading their dashboard sees the policy link before they file the next plugin request. Putting the link there does most of the work.
Most multisite governance documents are written after the incident, not before.
A site admin activates a plugin that crashes the homepage on three sister sites. The IT lead writes a memo banning that plugin. Six months later a different site admin requests a similar plugin and the memo cannot be found. The cycle resets.
That is the pattern in networks above ten sites. Tribal knowledge stops scaling. Nobody has time to write the bylaws on a Tuesday afternoon.
This piece is about how an AI chat reads three things. Your network inventory. Your site-admin role permissions. A one-paragraph summary of the last 12 months of incidents.
The chat returns the first draft of a one-page policy the network admin edits instead of starting from scratch.
Why does multisite governance fail without a policy document?
Networks above ten sites accumulate decisions faster than memory can hold them.
A site admin asks the network admin for a forms plugin. The network admin says yes based on what was approved last quarter, half-remembered. Six months later a different site admin asks for the same plugin under a different name and gets a different answer. The decisions diverge without anybody intending to be inconsistent.
The WordPress advanced-administration handbook is plain about permissions. Site admins cannot install new themes or plugins and cannot edit user profiles on their site. Only the Network Admin has the ability to perform those tasks.
Permissions are not the same thing as policy. The permissions structure tells you who can install a plugin. The policy tells you which plugins count as approved before the request lands. Most networks have the first and lack the second.
The cost of the gap is not catastrophic on any single decision. It compounds. Sites drift in plugin stack, theme version, and configuration. Compliance reviews surface inconsistencies the team did not know existed.
New site admins learn the system by asking, then the answer changes when the next site admin joins.
What does an AI-drafted governance document actually contain?
A short artifact, six sections.
Network inventory snapshot. Plugin allowlist with rationale per plugin. Theme approval workflow.
Per-site storage cap. Super-admin escalation path. Explicit "out of scope" section.
The chat reads three inputs.
The current network inventory. Forty sites or whatever the actual count is, with the plugins each runs and the themes each uses. Exported from wp-admin Network or WP-CLI.
The site-admin role permissions, exported the same way.
A one-paragraph plain-English summary of the last 12 months of incidents. Which plugin caused which problem. Which theme switch broke which site. Which compliance request landed last quarter.
The output is a draft. Not the final document the committee argues over for six weeks. The network admin reads the draft, edits the lines that do not match their specific history, and ships the result to whoever signs off.
The chat handles the boilerplate. The network admin handles the calibration.
How do you turn the network inventory into a policy?
The work splits into five steps. None of them needs a meeting.
Step 1 — export the current network inventory. Use wp-admin Network plus the Sites and Plugins list. Run a WP-CLI snapshot if your environment supports it. Capture the count of sites, the plugins active per site, the themes used per site, and the count of super-admin versus site-admin accounts. Twenty minutes for a 40-site network.
Step 2 — write the incident summary. One paragraph, plain English. Which plugin caused which problem in the last 12 months. Which theme switch broke which site.
Which compliance request landed (or which is pending). If the year was quiet, write that the year was quiet. The chat needs the calibration data either way.
Step 3 — feed the chat with one specific prompt. Paste the inventory, the site-admin permissions, and the incident summary. Add a short multisite security primer in three lines — DISALLOW_FILE_MODS, super-admin minimization, registration-domain restriction. Ask for the six-section policy outline tuned to your inventory.
Step 4 — apply the network admin’s lens. Read the draft. Mark the lines that hold under your specific incident history. Mark the lines that need rewording.
Mark the lines that look reasonable on paper and would generate friction on your specific team. The chat does not know your team’s politics. You do.
Step 5 — circulate the draft for one round of comments. Network admin plus two site admins is enough — not the entire team. Ship version 1.0 of the policy to the wiki within two hours of starting Step 1. Version 1.1 follows whatever the comments surface.
The cadence is the point. A draft that ships is more useful than a perfect document still in committee.
What does the plugin allowlist look like in practice?
Three tiers, each with a clear default action.
Tier one — mandatory and network-activated. Security plugin. Backup plugin. Accessibility checker.
Analytics. The super admin activates these network-wide. The site admin cannot deactivate them. They show as "Network Active" in the per-site Plugins page.
Tier one is non-negotiable across the network.
Tier two — approved and per-site activatable. Forms. SEO plugin. Image optimization.
Page builder of the team’s choice. The site admin activates or deactivates these without filing a request. The list is short, named, and reviewed quarterly.
Tier three — request-only. Everything else. The site admin opens a ticket. The network admin reviews.
The answer is either "approved, activate it" or "denied, with a one-line reason" recorded against the plugin name. The denial log is what saves time over the next year. The same plugin requested twice gets the same answer without a fresh evaluation.
The three-tier structure is the load-bearing decision in the document. Two tiers under-specifies and pushes too much to ad-hoc requests. Four tiers over-specifies and creates exception cases nobody remembers. Three is the working number.
What can go wrong with this approach?
Three traps catch teams who already have multisite running but no written policy.
Trap 1 — treating the AI draft as the final policy. The chat reads the inventory and writes a defensible draft. The network admin’s incident history is what calibrates the tier boundaries. The chat does not know that your team had a six-week argument about page builders in 2025 — you do. The draft is the starting point, not the answer.
Trap 2 — drafting governance for fewer than ten sites. Below that threshold, the policy maintenance cost exceeds the value. An informal email thread between three people does the same job for a five-site network. The threshold where a written policy starts to pay back its drafting cost lands around 10-to-15 sites, or the moment a regulated-industry compliance request arrives. Smaller networks should defer the document.
Trap 3 — treating the policy as a security tool rather than a coordination tool. The document does not stop a compromised super-admin account. The document does not patch a plugin CVE. The document records what the team agreed to before any of those events.
Detection lives in monitoring and audit logs. Response lives in incident runbooks. Policy lives in the artifact you read at the next plugin request.
The three artifacts are different. The policy carries the coordination weight, and the others carry the security weight.
Why is the policy a coordination control rather than a security control?
The policy is not a security control. The policy is a coordination control.
A coordination control answers questions the team already faces. What plugins count as approved. Who can switch themes. Where the network admin draws the line on storage caps.
Those answers exist in every multisite network whether they are written down or not. Writing them down lets the next site admin read them without filing a ticket.
A defensible WordPress multisite network treats the policy document as the artifact that travels with the network admin role. New network admin reads version 1.0 on day one. Version 1.1 ships when something in the network changed enough to invalidate a prior decision. The AI wp-config hardening checklist covers the DISALLOW_FILE_MODS and SSL-enforcement settings the policy points back to.
Other questions worth answering
How often should the written rules be revised once the first version ships?
Quarterly or after any major event. Per Melapress’s March 2026 analysis, centralized rule enforcement across all subsites is the baseline. Many teams settle on roughly two cycles a year.
A major incident, a regulated compliance request, or a fresh network admin handover all trigger immediate revision. Calendar timing falls away in those cases.
When a super-admin leaves the team, what should change in the agreed rules?
The off-boarding moment triggers two updates. First, decrement the super-admin count and confirm no orphaned sessions remain in any subsite. Per WP Folder Shield’s October 2025 analysis, super-admin minimization is the baseline. Second, capture any tribal knowledge that leaves with them and fold it into the written rules.
What signals tell you a subsite has drifted from the agreed standards?
Three tells. Plugin lists diverge from the tier-one mandatory set. Theme versions fall behind the network’s standard release. Storage caps creep past the documented per-site limit.
WordPress’s canonical advanced-administration handbook on multisite notes that only the super admin can fix any of these once they appear.
Should the written rules carve out a staging environment for testing changes?
Yes, with one constraint. The staging tier should mirror the production tier-two list and never run tier-three experiments. WordPress’s advanced-administration handbook on multisite notes that theme edits propagate across every site using that theme. Staging that shares themes with production stops being safe testing.
Where should the policy live before the next plugin request?
In the network admin’s wiki or shared docs folder, linked from the wp-admin Network Settings page via a small custom dashboard widget. The site admin reading their dashboard sees the policy link before they file the next plugin request. That single placement choice does most of the work the document was supposed to do.
The next post in this series covers the AI plugin selection workflow that pairs with this policy. The policy says what counts as approved. The selection workflow says how to evaluate candidates before they reach the allowlist. The two posts compound.
Together they replace the ad-hoc evaluation that consumes the network admin’s afternoons.
If you want a calm second opinion on your first multisite policy draft before you ship it to the wiki, you can contact me here. I read your network inventory, your incident summary, and the chat’s draft, and tell you which tier boundary to revisit first. There is no pitch, no upsell, and the conversation is free.