What Is WordPress Multisite?
WordPress Multisite is a built-in feature that lets you run many separate websites from a single WordPress installation, sharing one set of core files, themes, and plugins while keeping each site's content distinct. A network administrator manages the whole network centrally, while each site can have its own admins, content, and settings. Sites can be organized as subdomains or subdirectories. Multisite suits organizations running networks of related sites, but it adds complexity and is not the right tool for every situation.
- What it is
- One WordPress install serving multiple sites on a shared codebase (WordPress Developer docs)
- Enabled via
- Adding WP_ALLOW_MULTISITE and network settings in wp-config.php (WordPress Developer docs)
- URL structures
- Subdomains (site1.example.com) or subdirectories (example.com/site1)
- Roles
- Adds a Super Admin who manages the whole network above site administrators
- Shared resources
- Core, themes, and plugins are shared; content and uploads stay per-site
What Multisite is #
WordPress Multisite is a feature baked into WordPress core that turns a single installation into a network capable of hosting many distinct websites. Instead of installing WordPress separately for each site, you enable Multisite once, and from that one codebase you can create and manage numerous sites that share the same core files, themes, and plugins but keep their own content, users, and settings. A network administrator, called the Super Admin, oversees the whole network and controls which themes and plugins are available, while each individual site has its own administrators who manage that site's content. This centralization is powerful for organizations running many related sites, since updates to WordPress, themes, and plugins happen once for the entire network. For businesses considering a network of sites, understanding Multisite early shapes the whole architecture, which is why it is a common discussion point in complex /services/web-app-development projects where many branded or regional sites must coexist under unified management.
How Multisite is structured #
A Multisite network has a specific structure. At the top sits the network itself, managed by a Super Admin through a Network Admin dashboard that controls sites, users, themes, and plugins across the board. Below that are the individual sites, each with its own admin area, content, and users, though users can be shared across sites. Themes and plugins are installed once at the network level, then activated either network-wide or on a per-site basis. Crucially, the sites share one database, using separate tables for each site's content while keeping some tables common. This shared foundation is what makes central management efficient but also what makes Multisite more delicate: a problematic plugin or a database issue can affect the whole network rather than one site. Because of this shared architecture, choosing appropriate /services/managed-hosting that understands Multisite is important, since the hosting environment must handle the network's combined traffic and the interdependence of its sites reliably.
Subdomains versus subdirectories #
When you set up Multisite, you choose how the network addresses its sites: subdomains or subdirectories. Subdomains give each site an address like store.example.com or chicago.example.com, which requires configuring wildcard DNS so any subdomain resolves to the network. Subdirectories give addresses like example.com/store or example.com/chicago, which is simpler to set up but can conflict with certain permalink structures. The choice is largely permanent and affects DNS, SEO perception, and how distinct the sites feel. Subdomains suit networks where sites should feel separate, such as different brands, while subdirectories suit closely related sections under one umbrella brand. Setting up subdomains involves DNS work best handled with guidance from a /services/domains-dns-email specialist, since a wildcard record and, ideally, wildcard SSL are needed for the sites to load securely. Deciding between the two early matters, because switching structures after a network is populated is disruptive, involving URL changes across every site and the associated redirect and SEO cleanup that follows.
// Step 1: add to wp-config.php above the 'stop editing' line
define('WP_ALLOW_MULTISITE', true);
// Step 2: after running Network Setup, WordPress asks you to add, e.g.:
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false); // false = subdirectories
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);When Multisite makes sense #
Multisite shines for specific scenarios. Universities running separate departmental sites, franchises giving each location its own site with consistent branding, agencies hosting many client sites on shared infrastructure, and businesses operating regional or multilingual variants all benefit from centralized management. The advantages are real: one place to run updates, shared themes and plugins reducing duplication, and unified user management. If you maintain dozens of similar sites, Multisite can save substantial time. However, the sites should genuinely share a codebase and management for it to pay off. A network of truly independent sites with different plugin needs, separate ownership, or wildly different traffic profiles often fits better as separate installations. For a multi-location business exploring this, weighing Multisite against individual sites is part of planning a build with /services/web-app-development. The honest guidance is that Multisite is a specialized tool: excellent when your situation matches its strengths, and needless complexity when it does not, so the decision deserves careful thought before you commit.
Drawbacks and risks to weigh #
Multisite is not free of downsides. Because sites share core files and a database, a single point of failure exists: a corrupt update, a compromised plugin, or a database problem can affect every site at once. Plugin compatibility is a concern, since not all plugins are built for Multisite, and some behave unpredictably in a network. Backups and migrations are more complex, as moving one site off a network requires careful export and import work rather than a simple copy. Hosting must be capable, because all sites share the same resources, so a traffic spike on one can strain others. Security stakes are higher, since a breach can expose the whole network. These realities mean Multisite demands more disciplined maintenance, often through a robust /services/care-plans arrangement, and stronger /services/website-security practices than a single site. None of this makes Multisite bad, but it does mean the convenience of central management is balanced by concentrated risk that must be managed deliberately.
Managing users and permissions across a network #
User management in Multisite adds a layer above the usual roles. The Super Admin sits above all site administrators, with authority over the entire network: creating sites, installing themes and plugins, and managing network-wide users. Within each site, the familiar roles, Administrator, Editor, Author, Contributor, Subscriber, still apply, but a site administrator's powers are deliberately narrower than on a standalone site, since network-level actions like installing plugins are reserved for the Super Admin. A single user account can belong to multiple sites with different roles on each, which is convenient for staff who work across the network. This structure keeps control centralized while letting individual sites operate. For organizations, mapping who is a Super Admin versus a site admin is an important governance decision, since Super Admin access is essentially keys to everything. Reviewing these assignments periodically is part of sound /services/website-security practice, ensuring that the small number of people with network-wide power is intentional and current rather than accumulated by habit.
Multisite versus separate installations #
The central decision is whether to run a network or independent sites. Multisite wins when sites are similar, share management, and benefit from one-time updates, franchises, campus sites, and closely related brands. Separate installations win when sites are genuinely independent, have different plugin and hosting needs, different owners, or must be isolated so a problem with one cannot touch the others. Separate installs are simpler to back up, migrate, and secure individually, at the cost of repeating updates across each. Some organizations start with Multisite for convenience, then find that splitting a fast-growing or divergent site off into its own installation serves it better, a move that involves careful /services/website-migrations work to extract one site cleanly from the network. There is no universally right answer; it depends on how alike the sites are and how much shared management helps versus how much concentrated risk hurts. A candid assessment during planning, ideally alongside a /free-website-audit of your current setup, points to the fitting choice.
Getting Multisite set up correctly #
Enabling Multisite is a deliberate, technical process, not a casual toggle. It begins by adding a line to wp-config.php to allow Multisite, running the Network Setup screen, then adding the network-defining constants WordPress provides and updating configuration and, on some servers, rewrite rules. Subdomain networks additionally need wildcard DNS and ideally wildcard SSL so every site loads securely, work that pairs with /services/domains-dns-email expertise. Because the setup touches core configuration and DNS, mistakes can lock you out or misroute sites, so doing it on a fresh install or a tested staging copy is wise. Existing single sites can be converted, but with more care. Given the stakes and the shared architecture, many businesses have this configured by a team through /services/wordpress-development rather than attempting it unaided. Getting the foundation right, correct URL structure, working DNS, capable hosting, and appropriate admin roles, before populating the network with sites saves considerable rework, since structural changes after launch ripple across every site in the network.
Backups, updates, and maintenance in a network #
Maintaining a Multisite network differs from maintaining a single site, mainly because everything is shared. Updates to WordPress core, themes, and plugins happen once and apply across the network, which is efficient but means a problematic update can affect every site simultaneously, so testing on a staging copy of the network first is especially important. Backups must capture the whole network, its shared files and the combined database, and restoring or extracting one site requires care rather than a simple copy. Security patching is urgent, since a single vulnerability exposes all sites at once. These realities make disciplined, scheduled maintenance essential, often handled through a robust /services/care-plans arrangement built for the network's scale. Hosting matters too, because all sites draw on shared resources, so capable /services/managed-hosting keeps one busy site from starving the others. The payoff of Multisite, centralized management, is real, but it comes with concentrated responsibility: careful, consistent upkeep is what keeps the convenience from turning into a single point of widespread failure.
FAQ
Do I need Multisite to run more than one WordPress website?
No. You can run many independent WordPress installations, each on its own domain or subdomain, without Multisite. Multisite is only worthwhile when sites are similar and benefit from shared, centralized management. For a handful of unrelated sites, separate installations are usually simpler to secure, back up, and maintain than a single network.
Should I choose subdomains or subdirectories for Multisite?
Subdomains (site1.example.com) suit sites that should feel separate, like different brands, but need wildcard DNS. Subdirectories (example.com/site1) are simpler to configure and suit closely related sections under one brand. The choice is effectively permanent, so decide based on how distinct the sites should be and your DNS setup before creating sites.
Can I move one site off a Multisite network later?
Yes, but it takes careful work. Extracting a single site requires exporting its content and database tables, then importing them into a fresh standalone installation, along with media and URL adjustments. It is not a simple copy. This kind of extraction is a standard part of professional website migration work rather than a one-click operation.
Are all plugins compatible with WordPress Multisite?
No. Many plugins work in Multisite, but not all are built or tested for a network environment, and some behave unpredictably or must be activated network-wide. Before relying on a plugin in Multisite, check its documentation for network support and test it on a staging network, since a misbehaving plugin can affect every site at once.
Is Multisite less secure than separate sites?
It concentrates risk rather than being inherently insecure. Because sites share core files and a database, a breach or bad update can affect the whole network, making the stakes of any single problem higher. With disciplined updates, strong access control, backups, and capable hosting, Multisite can be run securely, but it demands more careful maintenance than isolated sites.
Who manages a WordPress Multisite network?
A Super Admin manages the whole network through a Network Admin dashboard, controlling sites, users, themes, and plugins. Each individual site also has its own administrators, but their powers are narrower, since network-level actions like installing plugins are reserved for the Super Admin. Limiting the number of Super Admins is an important governance and security decision.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?