What is WordPress Multisite?

Table of Contents 5 sections

What is WordPress Multisite?

WordPress Multisite is a built-in feature of WordPress core that enables administrators to create and manage a network of multiple websites from a single WordPress installation. All sites in the network share the same WordPress codebase, plugin files, theme files, and database, though each site has its own set of database tables for content, users, and settings. Multisite networks can use either subdomain-based URLs (site1.example.com, site2.example.com) or subdirectory-based URLs (example.com/site1, example.com/site2) to differentiate between sites.

Multisite is commonly used by universities, corporate intranets, media networks, and hosting companies to manage large numbers of related sites efficiently. The network administrator (Super Admin) has overarching control over all sites, while individual site administrators manage their own content and settings within boundaries defined by the Super Admin. This centralised architecture simplifies maintenance, as core updates, plugin updates, and theme updates are applied once across the entire network rather than individually on each site.

Multisite Security Architecture

The shared infrastructure model of WordPress Multisite introduces a fundamentally different security architecture compared to single-site installations. Because all sites share the same database, a SQL injection vulnerability in any site or plugin could potentially expose data from every site in the network. Similarly, because all sites share the same file system, a file upload vulnerability on one site could allow an attacker to upload malicious code that affects the entire network. The blast radius of any single vulnerability is amplified across every site in the Multisite network.

The role hierarchy in Multisite adds an additional layer of complexity. The Super Admin role has unrestricted access to all sites and network-level settings, making Super Admin accounts extremely high-value targets for attackers. Individual site administrators have reduced capabilities compared to single-site administrators; they cannot install plugins or themes, modify files, or access network settings by default. This reduced capability set is a deliberate security measure that limits the damage a compromised site-level admin account can cause to the broader network.

Plugin and Theme Management in Multisite

In a Multisite network, only the Super Admin can install, update, and delete plugins and themes. Plugins can be "network activated" to make them available and active on all sites simultaneously, or they can be activated on a per-site basis by individual site administrators (if the Super Admin has made them available). This centralised control is a significant security advantage because it ensures that only vetted plugins and themes are available across the network, preventing individual site administrators from installing potentially vulnerable or malicious extensions.

However, this centralised model also means that a vulnerability in a network-activated plugin affects every site simultaneously. If a security flaw is discovered in a plugin that is active across hundreds of sites, all of those sites are immediately at risk until the plugin is updated or deactivated. Super Admins must be particularly diligent about monitoring security advisories for all installed plugins and themes, and they should establish a rapid response process for deploying security updates across the network. Regular audits of network-activated plugins ensure that unnecessary plugins are removed and that all active plugins are current.

Hardening a WordPress Multisite Network

Securing a Multisite network requires all the standard WordPress hardening measures plus additional considerations specific to the multi-tenant architecture. Super Admin accounts should be protected with strong, unique passwords and two-factor authentication, and the number of Super Admin accounts should be kept to an absolute minimum. Network-level settings should restrict the types of files that site administrators can upload, preventing them from uploading executable file types such as PHP, JavaScript, or SVG files that could contain malicious code.

Database security is particularly important in Multisite because a single database compromise exposes all sites. Using unique, complex database credentials, restricting database user permissions to only the operations WordPress requires, and implementing database-level encryption are all critical measures. If the hosting environment supports it, deploying database row-level security or separate database users for each site provides additional isolation, though this is not natively supported by WordPress and requires custom implementation. Regular database backups that are tested for restore integrity ensure rapid recovery in the event of a breach.

Isolation and Trust Boundaries

The most critical security consideration in WordPress Multisite is understanding the trust boundaries between sites. In a Multisite network, individual site administrators should be treated as semi-trusted users, not fully trusted administrators. They have the ability to create content, manage users within their site, and configure site-level settings, but they should not be able to execute arbitrary code, access the file system, or affect other sites in the network. The reduced capability set for site-level administrators enforces this boundary, but poorly coded plugins can inadvertently grant capabilities that break this isolation.

Organisations that need stronger isolation between sites should carefully evaluate whether Multisite is the right architecture. If sites in the network belong to different security domains, different customers, or different trust levels, separate single-site WordPress installations with their own databases and file systems provide significantly stronger isolation. Multisite is best suited for networks where all sites are managed by the same organisation and where a shared trust model is acceptable. For multi-tenant hosting scenarios where tenants do not fully trust each other, container-based isolation or separate installations provide a more appropriate security boundary.