WordPress Multisite vs Single Site: Key Differences

Choose a single WordPress install when one site needs independent plugins, releases, access and recovery. Consider Multisite when one organization deliberately wants several sites under one WordPress codebase and can manage shared updates, network privileges and server configuration. Multisite centralizes administration; it does not provide separate hosting or a security boundary between subsites.

What is shared—and what is separate?

Area	Separate single-site installs	WordPress Multisite network
WordPress code	Each install has its own core, plugin and theme files	Sites share one core installation and plugin/theme codebase
Database and content	Usually separate databases/installations, depending on hosting	One network database; each site has its own tables, with some network-wide tables such as users
Administration	Each site has its own dashboard and update schedule	Super Admin manages the network; site users receive the capabilities granted to them
Failure and updates	Issues are often limited to the affected install	A shared code, server or network-admin issue may affect several sites
Recovery	Restore one site from its own tested backup	Network-wide backups are essential; restoring only one subsite can require extra steps

Choose separate sites when independence matters

• Brands or clients need independent administrator access, plugin choices, release schedules or hosting.
• One site needs a plugin or server configuration that may not work safely across a network.
• You need straightforward per-site migration, recovery or isolation.

Consider Multisite when central control is a real requirement

• The sites belong to one organization and can share core/plugin/theme updates.
• A small trusted team can control Network Admin privileges and test shared changes.
• Sites have a meaningful common design, governance or user-management model.

Do not choose Multisite only to save hosting or plugin costs. Capacity, plugin licensing, domain setup, backups, maintenance and support differ by host and product; there is no universal cost or speed advantage. WordPress documents that network sites share the installation files but have separate site tables and media locations.

Subdirectory and subdomain networks have different requirements

A path-based site uses an address such as example.com/site. A domain-based network can use site.example.com. For on-demand subdomains, wildcard DNS is generally required; manually created sites can use other configured DNS/virtual-host arrangements. DNS must point to the server, and the server must route each address to the WordPress installation.

Rewrite rules are server-specific. Apache commonly uses .htaccess with the required rewrite support; Nginx needs corresponding server-block configuration and does not read .htaccess. Do not paste Apache rules into Nginx or assume a shared host permits every rule. Confirm the host’s supported setup before enabling a network.

WordPress’s Network Setup screen displays the configuration lines for that installation. The initial WP_ALLOW_MULTISITE flag enables setup; after creating the network, follow the exact generated wp-config.php and rewrite instructions for that server. Do not copy a sample SUBDOMAIN_INSTALL value or rewrite block from another host as a universal configuration.

Plugins, themes and permissions

Network Admin installs plugins and themes for the network. Depending on the plugin and network settings, a plugin may be network-active or available for individual site activation. A plugin’s settings may be per-site or network-wide based on how its developers implemented it. Check the plugin author’s Multisite support notes and test it before enabling it across production sites.

Network-level access is powerful. Limit Super Admin accounts, keep a staging copy, update shared code deliberately and monitor compatibility. A plugin conflict or vulnerability in shared code can have a wider impact than the same issue in one isolated installation, but the exact blast radius depends on permissions, configuration and the vulnerability.

Before creating a network or migrating sites

1. Decide whether each site should use a subdomain, subdirectory or mapped domain; check DNS, TLS, virtual-host and host-plan support.
2. Take and verify a restorable backup of all WordPress files and the database. Test the network setup on staging where practical.
3. Confirm pretty permalinks and server rewrite support. Ask the host about Apache/Nginx requirements rather than guessing.
4. Check each active plugin, theme, commerce integration, mail system, caching layer and backup tool for Multisite compatibility.
5. Plan URL mapping, redirects, SSL, email, analytics, search-console properties and per-site SEO before moving live content.
6. Use the Network Setup screen’s generated configuration and verify login, media uploads, permalinks, forms and backups on every test site.

Converting an established site can have constraints: WordPress may restrict subdirectory networks for older installations, and changing network type later involves more than editing one constant. Read the official requirements before choosing. For a move, use the separate WordPress migration guide after confirming the target architecture.

Official WordPress references

• Before you create a network
• Create a network and use its generated configuration
• Network Admin and plugin behavior
• Network administration, URL rewrites and migration notes