WordPress multisite vs separate installations

WordPress multisite vs separate installations: which model fits your sites

If your sites share little beyond a login and a hosting account, separate installations are usually the safer default; choose a multisite network only when the sites genuinely share users, content and a governance model. A team running several WordPress sites is really deciding how much it wants those sites to depend on each other, because a network makes shared users, themes, plugins and upgrades a single operational unit. The WordPress multisite handbook makes the same point: a network may not be the best solution for sites that are strongly interconnected, share data or share users. It also notes that a single site, extended with a theme-switching or capability-switching plugin, may be enough for what looks like a multi-site need.

Before you commit, list the things each site must own independently: its administrators, its plugin set, its theme, its backups and its upgrade window. Every shared item in a network is one change that touches all sites at once. For example, an illustrative network of four brand sites where one brand needs a plugin that conflicts with the others would force either a compromise for all four or a split into separate installs later. Ask your team which sites need a different editorial team, legal review or retention rule, because those differences are harder to honor inside one database than across separate installations.

Read the WordPress multisite preparation guide before you decide, and confirm three prerequisites on your own host: administrator and file system access, support for mod_rewrite and .htaccess rules, and a WordPress address on port 80 or 443. Then decide the URL structure. A subdomain network needs wildcard DNS for on-demand sites and WordPress installed at the web root, and it cannot be chosen if your WordPress address contains a path, uses localhost or is an IP address. A subdirectory network cannot be chosen for an installation older than a month because of permalink issues, and the main site's posts receive a /blog/ slug. If either rule rules out your setup, separate installations become the practical answer.

How WordPress multisite vs separate installations compare by factor

This table sets one WordPress multisite network against separate installations across users, plugins, URLs, infrastructure, updates, failure scope, backups and admin work. Read each row for the condition under which that option fits, since the handbook's own guidance is that a network suits sites that are not strongly interconnected.

Factor	Multisite network	Separate installations
Shared users	One user table across the network, so a person can hold roles on several sites. Better when the same editors or staff manage many sites and share accounts.	Each site has its own users. Better when sites have different audiences, or when the handbook's caution about sites that share users applies to you.
Shared themes and plugins	Themes and plugins are installed once and activated per site, with network-level control. Better when sites need the same tools and a consistent look.	Each install can run different versions and plugin sets. Better when sites need conflicting plugins or independent release schedules.
URL structure	Subdomain or subdirectory structure, chosen at setup. Subdirectory networks give the main site a /blog/ slug. Confirm the chosen structure fits your brand before you build.	Any domain or path layout per site, with no network constraints. Better when sites live on unrelated domains or need clean URLs on each.
Server and DNS prerequisites	Needs admin and file system access, mod_rewrite and .htaccess support, port 80 or 443, and wildcard DNS for subdomain networks. Not available on localhost, IP addresses or URLs with a path.	Standard hosting for each site. No network-specific rewrite or wildcard requirements. Better when your host or DNS setup cannot meet the multisite prerequisites.
Core update timing	One core version runs for every site, so all sites move together. Better when you want one controlled upgrade window for the whole estate.	Each site can be upgraded on its own schedule, so one site can wait for a plugin fix without holding others. Better when sites have different compatibility needs.
Failure scope	A broken plugin, theme or core update can affect every site on the network. Better when a shared test process catches issues before they reach production.	A fault is usually confined to one site. Better when a single outage must not affect other businesses or brands.
Backup and restore scope	Backups usually cover the shared database and file set in one job, but restoring one site needs care. Confirm with your host how per-site restores work.	Each site can be backed up and restored independently. Better when restores must be fast and isolated for one client or brand.
Admin workload	Fewer installs to update, but network-wide plugin and theme decisions and shared permissions need central governance. Better when one team can own the platform.	More installs to patch and monitor, each with its own plugins and settings. Better when each site has its own owner who handles updates and security.

What a shared network changes for users, themes and plugins

A multisite network means every site shares one WordPress core version, one user table and one pool of installed code, while the network administrator decides which themes and plugins each site may activate. The shared user table is the change that matters most in practice: an account created once can be given a role on several sites, so a single editor who manages three brand sites signs in with one identity. Before you commit, list which sites must keep separate editorial teams, because a user who should only reach one site still exists across the network and must be removed or restricted on each site where they hold a role. Confirm this model against the current multisite handbook's description of users and roles, since the role rules are the part teams most often misjudge.

Shared administration is the real benefit for a portfolio. You update WordPress core once, install a plugin once, and manage backups and hosting for one codebase instead of many. The cost is that a compromise or a bad update reaches every site on the network. A vulnerable plugin network-activated for one site becomes an exposure for all of them, and a core update that breaks a shared function affects every site in the same window. WordPress.org's security team does backport fixes to older versions and automatic background updates exist, but automatic plugin updates apply only in the special cases the WordPress.org API flags, so you still need a staging test and a rollback plan for the whole network. Ask whether your change window can accommodate every site at once.

Plugin and theme compatibility is the check you must run in your own environment, not assume. Some plugins were written for single-site installs and misbehave when activated network-wide, store per-site options in ways that conflict across sites, or require settings that only one site should hold. Build a list of every plugin and theme you plan to use, test each one on a copy of the network with the same subdomain or subdirectory structure, and record which can be network-activated and which must be activated per site. Also confirm that your hosting and PHP version meet the WordPress.org requirements of PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater before you test.

Subdomain or subdirectory: which URL rules decide the choice

A subdomain network gives each site its own host name, such as site-a.example.org, under one main domain. The WordPress multisite handbook sets specific conditions for this model. Each site that is created on demand needs a matching wildcard subdomain in DNS, and WordPress must run from the web root rather than from a folder. The model also cannot be selected when the WordPress address contains a path, is localhost, or is an IP address, so a test build on a development address will not convert cleanly.

Wildcard DNS record: Sites created later need a wildcard entry that resolves to the server, or each new site needs its own record added by hand.
Web root installation: WordPress must be served from the top of the domain, not from a subfolder of another application.
Address format: A WordPress address with a path segment or an IP address blocks this option.
Certificates: Wildcard or per-site certificates must cover every subdomain in use, and the handbook does not cover how your host issues them.
Brand separation: Each site reads as its own host name, which suits regional or product sites that need distinct identities.

Before design, confirm DNS and certificate handling with your host, including who issues wildcard certificates and how renewals and new site records are automated.

A subdirectory network places each site under a path on the main domain, such as example.org/team-a/. The handbook imposes a timing rule here. A subdirectory network cannot be chosen when the existing installation was set up more than a month ago, because of permalink issues. The main site's posts also receive a /blog/ slug, which changes its URL structure and should be planned with editors and search teams.

Age limit: An installation older than a month cannot be converted, so the decision must be made before the site goes live.
Blog slug: The main site's posts receive a /blog/ prefix, which affects existing links and any content that uses the bare post path.
Single host name: All sites share one domain and certificate, which simplifies DNS and certificate work.
Permalink review: Confirm the permalink structure and any redirects before the network is created, because the handbook ties the age limit to permalink problems.
Path planning: Subdirectory names become part of the public URL, so choose them with the same care as a product name.

Before design, confirm with your host that the server supports mod_rewrite and .htaccess rules, because the handbook lists them as a requirement for creating a network.

Both models depend on the same baseline. The handbook requires administrator access, file system access and a server that supports mod_rewrite and .htaccess rules. The WordPress address must also be served on port 80 or 443. These conditions apply whether the network is subdomain or subdirectory, and they are often the first point where a managed or shared host turns out to be unsuitable.

Administrator access: You need full administrative rights on the WordPress installation to create the network.
File system access: The network setup writes configuration changes to the installation, so write access to the files is required.
Rewrite support: The server must process mod_rewrite and .htaccess rules, which some hosts restrict or configure differently.
Ports: The WordPress address must be served on port 80 or 443.
Host review: Ask the host to confirm each of these in writing for the specific plan and server type.

Confirm these prerequisites against the WordPress network preparation guide and your host's current configuration before you commit to a model.

Upgrades, backups and monitoring for WordPress multisite vs separate installations

This table compares what each model asks of your team for core upgrades, plugin and theme updates, backup scope and monitoring. Read it as a checklist of operating duties: a single network concentrates them in one place, while separate installations multiply them across each site.

Operating duty	Multisite network	Separate installations
Core upgrades	One core update covers every site in the network, so one upgrade window and one test pass serve all sites. Only the latest version is officially supported, so plan to move the whole network together.	Each installation is upgraded on its own schedule. Sites can drift across versions, which multiplies testing and widens the period in which an older site is exposed.
Plugin and theme handling	Plugins and themes are shared or network-enabled, so a single incompatible update can affect every site at once. Confirm which plugins are network activated before any update.	Each site carries its own plugin and theme set. A conflict stays contained to one site, but the number of update decisions grows with every site.
Auto-update behavior	Background updates for WordPress core and for plugins and themes run per install. Plugin and theme auto-updates by default apply only in cases the WordPress.org API flags for critical vulnerabilities, so confirm your policy for every site in the network.	The same default rules apply per site. Confirm whether each site's auto-update settings match, since they are set independently and can diverge over time.
Backup and restore scope	A full network backup captures the shared database and every site's uploads in one job, but restoring a single site may require extracting its tables and files from the network. Test single-site restores before you rely on them.	Each site can be backed up and restored independently, which simplifies recovering one site. The trade-off is that you must run and verify more backup jobs.
Monitoring focus	Monitor the network as one service: a single database outage or failing cron job can stop every site. Track uptime, error logs and update status per site, not only at the network level.	Monitor each site and its host separately. Failures are more isolated, but alerting, certificate renewal and update checks must be configured for every installation.
Platform baseline	Current WordPress.org recommendations are PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. Confirm these on the shared server before you build the network, because every site depends on the same stack.	The same WordPress.org recommendations apply to each installation. Mixed sites on different PHP or database versions are possible but multiply the compatibility checks you must run.
Release timing	WordPress 7.1 was released on August 19, 2026, and 7.1.3 followed on October 6, 2026. Plan network upgrades around point releases and test them against every network plugin.	The same release calendar applies, but staggered upgrades give you more time per site and more chances to fall behind the supported version.
Skills required	Your team needs network administration, shared database and file system skills, and enough WordPress knowledge to diagnose problems that affect many sites at once.	Your team needs repeatable per-site runbooks and disciplined configuration tracking so that every installation is updated, backed up and monitored the same way.

Server and admin prerequisites before creating a network

This sequence confirms that the server, credentials and DNS can support a WordPress network before anyone changes the live installation. Each step ends with a written check that the team can hand to its host or implementation partner.

Confirm administrator and file system access
Confirm with the host or internal platform team who holds administrator rights on the WordPress installation and who can write to the file system where WordPress is installed. Creating a network requires both, and the network setup changes configuration files that a standard editor login cannot touch. Record the named accounts and the access path, such as SSH or SFTP, in the change ticket. The step is complete when at least one named person has tested write access to the configuration file on a staging copy.
Confirm mod_rewrite and .htaccess support
Ask the host to confirm that the web server supports mod_rewrite and that .htaccess rules are read for the WordPress directory. WordPress writes rewrite rules into these files when a network is created, and a server that ignores them will break permalinks across every site. If the stack is nginx or a managed platform, ask the host for the equivalent rewrite configuration and get it in writing. The step is complete when a test rewrite rule on staging takes effect.
Confirm the WordPress address uses port 80 or 443
Check the WordPress Address and Site Address settings and confirm that the address uses port 80 or 443 and does not contain a path, localhost or an IP address. The handbook lists these as conditions that block a network from being created. Your host or DNS owner should confirm the public hostname that will serve the network. The step is complete when the site address is recorded and matches the hostname that will be used for the network.
Check PHP and database versions against requirements
Compare the PHP and database versions on the staging server with the WordPress requirements page, which recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. Ask the host to confirm the exact versions in use, not the plan name. If the server is below these recommendations, the upgrade belongs to the host or the platform team and should be scheduled before the network work. The step is complete when the versions are recorded in writing and any gap has a named owner.
Confirm wildcard DNS for a subdomain network
Only if the team has chosen a subdomain network, ask the DNS owner to confirm that a wildcard record exists for the network domain so that new sites resolve without a manual DNS change each time. Also confirm that TLS certificates cover the wildcard or that the certificate process supports new subdomains. If the team has chosen a subdomain network, this check is required, and the team should confirm the certificate approach with the host. The step is complete when a test subdomain resolves and presents a valid certificate.
Take a full backup before any change
Before any network conversion, take a full backup of the files and the database, store a copy outside the server, and test that the backup restores on a separate environment. Confirm who holds the backup, how long it is retained and how a restore is triggered. The backup does not replace the staging test, but it is the rollback path if the conversion fails. The step is complete when a restore has been tested and the team has written the rollback owner into the change record.
Get a written scope if the work is outsourced
If an implementation partner or internal platform team will carry out the work, agree a written scope that lists the steps above, the environments involved, the acceptance checks and the rollback plan before work begins. Ask for the scope, deliverables and any ongoing support terms in writing, and confirm which items the client must provide, such as access and DNS records. The step is complete when the signed scope names an owner for each prerequisite and each check in this sequence.

When the WordPress handbook says multisite is the wrong choice

The WordPress multisite handbook names several conditions where a network is the wrong tool. Each card below is a warning you can check against your own sites before choosing a network, since most of them are hard blockers or design signals rather than matters of preference.

Strongly interconnected sites

The handbook says a network might not be the best solution for sites that are strongly interconnected. If your sites cross-link heavily, share editorial workflows or depend on each other's content, a network adds coordination without much benefit. Confirm how often content moves between sites and whether any site needs to act as the source for others.

Sites that share data or users

The handbook flags sites that share data or share users as a reason to reconsider. In a network, users and their roles are global, so one account can hold different roles across sites, and a compromised shared account reaches every site. Confirm whether the sites need separate editor populations, separate customer records or separate access reviews before you pool them.

A single site may be enough

The handbook notes that a single site with a theme- or capability-switching plugin may be enough. If the sites differ mainly in branding or sections, one installation with switchable themes and role-based permissions can avoid the network's extra administration. Confirm whether the differences are visual or whether they need separate plugins, data and admins.

A URL path, localhost or IP blocks subdomains

A subdomain network cannot be chosen when the WordPress address contains a path, is localhost or is an IP address. Those setups are common in staging environments and in installations built inside a subfolder. Confirm the exact site address in the admin settings and in your staging copy, because changing it later affects every site in the network.

An install older than a month blocks subdirectory

A subdirectory network cannot be chosen when the existing installation was set up more than a month ago, because of permalink issues. The main site's posts also get a /blog/ slug. Confirm the install date and the permalink structure of the current site, and decide whether the /blog/ prefix suits the main site before you commit to subdirectories.

Different core versions or hosting

A network runs one WordPress core for every site, so sites that need different core versions, different PHP settings or separate hosting cannot share it. Compliance boundaries and client-owned sites often need their own servers and update schedules. Confirm the upgrade cadence each site needs and whether any site must be isolated for regulatory or contractual reasons.

How updates and security patches reach a shared network

Automatic background updates have been part of WordPress since version 3.7, but they do not treat every component the same way. Since WordPress 5.6, newly created sites have automatic major release updates enabled by default, which matters for a network because the core update path is the one that touches every site in the install. Plugin and theme automatic updates are different: by default, WordPress applies them only in special cases determined by the WordPress.org API, which the WordPress Security Team controls to patch critical vulnerabilities. Your plugins and themes on each site will therefore usually wait for your own review and deployment, whatever the network setup. Before you choose a model, confirm on a staging copy which auto-update settings your hosting stack, must-use plugins or configuration files override, and record who approves each change.

The consequence is a trade-off in upgrade path and failure scope. A multisite network has one WordPress core, one set of network-activated plugins and one database, so a core upgrade or a faulty network-activated plugin reaches every subsite at once. That makes the network efficient to patch, but a single bad change can take many sites down together, and the change window must suit the most sensitive subsite in the network. Separate installations let you stagger core upgrades, test a plugin on one site before the rest, and isolate a compromise to one codebase and one database. The cost is that every installation needs its own core, plugin and theme patching, backup and monitoring work, which multiplies as the site count grows.

Because no service level agreement is supplied for either model, treat the update cadence as a question to settle with your own team and any hosting or support provider before committing. Ask how quickly a critical plugin fix must reach production, whether a maintenance window can cover every subsite at once, and how you would roll back a failed core upgrade across the network. The answers will show whether one shared upgrade path is an advantage for your change process or a risk you cannot accept.

Moving between a network and separate installations later

This sequence shows how to reverse the multisite decision safely, whether you are consolidating separate WordPress sites into a network or splitting a network back into standalone installations. It ends with a verified backup and a cutover plan you can roll back.

Inventory users, themes, plugins and URLs
List every site, its public URL, its administrators and editors, the themes and plugins it runs, and any content that is shared or duplicated across sites. Record the database prefix, upload paths and any custom code that references a domain or path. The inventory is done when the team can answer, for each site, which users belong to it, which code it depends on and what address search engines and links point to. Ask your agency or DeployOpen to confirm the inventory before any work is scoped.
Confirm handbook constraints for the conversion
Check the WordPress multisite handbook against your current setup before you choose a direction. A network may not suit sites that share data or users, and a subdomain network needs wildcard DNS and WordPress served from the web root. A subdirectory network cannot be created on an installation that was set up more than a month ago because of permalink issues, and the main site's posts receive a /blog/ slug. The output is a written decision record that states which conversion is possible and which constraints block it.
Build a staging copy of the current setup
Clone the production files and database to a staging environment that matches the production PHP and database versions, and confirm the web server supports mod_rewrite and .htaccess rules if a network is involved. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, so verify those versions on staging first. The step is complete when staging loads every site with the same content and login behavior as production.
Rehearse the move on staging
Run the consolidation or split on staging, following the handbook steps for your target design. Record every change to users, roles, network-activated plugins, theme assignments and the URL structure. Repeat the rehearsal until the steps are predictable. Expect the effort to grow with site count and with the amount of data that overlaps between sites, since shared users and duplicated content need manual reconciliation. The output is a runbook with each command or screen, its owner and its expected result.
Plan redirects and permalink changes
Map each old address to its new address, including post, page, category, media and feed URLs. Decide where redirects will live, such as the web server configuration or a redirect plugin, and test them on staging with a crawl or a sample of real links. Confirm the permalink structure on every site after the move, because a changed path can break links even when content moves intact. The step is done when a test crawl of the mapping returns the expected destination for every old URL.
Verify the backup before cutover
Take a full backup of files and the database for every affected site, then restore it to an isolated environment to confirm it is complete and readable. Store a copy outside the production server. Name the person responsible for the restore and the time window for rollback in writing before cutover. The backup is verified only when a restore test has loaded the sites in the isolated environment and the team has signed off on the result.
Cut over and check every site
Apply the runbook on production during the agreed window, then check each site's front end, admin login, user roles, plugin status, redirects and search indexing signals. Keep the verified backup available until the checks pass. Record the final state of each site so future changes start from a known baseline. The cutover is complete when every site passes the checklist and the rollback path has been tested or explicitly accepted.
Confirm a written scope before work starts
Ask any partner for a written scope that lists the sites in scope, the direction of the move, the deliverables, the test and rollback steps, and the responsibilities for DNS, hosting and content review. Fixed-scope engagements agree these items before work begins, and the quote should follow from that scope. Ask what is excluded, such as content cleanup or custom code changes, so the cost of switching later is clear before you commit.

What buyers ask before choosing WordPress multisite vs separate installations

Does running a multisite network cost less than separate installations?

It can reduce some recurring work, but it does not reduce cost automatically. A network shares one WordPress core, one set of plugins and themes, and one update cycle, so the team patches and tests once for many sites. The cost moves elsewhere: the network needs a larger test matrix, a single change can affect every site, and a stronger server and backup plan may be needed. Separate installations cost more to patch but isolate failures. Ask any quote to price the update, testing and backup work per model, not only the initial setup.

How long does it take to convert separate sites into a multisite network?

The duration depends on the number of sites, how much content, custom code and plugin overlap each one has, and how many sites must keep their existing URLs. No conversion duration is established here, so ask for a timeline built from a written scope. Key drivers are the URL structure you choose, whether sites share users or data, and how much plugin and theme reconciliation is needed. Confirm the approach against the WordPress multisite handbook before scoping.

What work does the team have to supply for a multisite conversion?

The team must supply administrator access and file system access, because creating a network requires both. It must also confirm the server supports mod_rewrite and .htaccess rules, and that the WordPress address uses port 80 or 443. Business owners need to decide which sites share users, themes and plugins, and which must stay isolated. Subdomain networks also need wildcard DNS and a web root setup. Gather an inventory of every site, plugin, theme and integration before work starts.

Can our own staff build and run a multisite network without outside help?

Often yes for a small, well-understood network, but only if someone on the team can handle server configuration, DNS, backups and a tested rollback. The WordPress handbook lists the prerequisites clearly, yet the harder work is the ongoing discipline: testing every plugin update against all sites and restoring a single site without affecting others. If the team lacks that capacity, a fixed-scope engagement can cover planning, implementation and documentation, while the team keeps operational ownership.

Can sites in one network keep different plugins and themes?

Yes, but the control is limited. Network administrators can manage which plugins and themes are available across the network, and individual site administrators can activate those that are allowed. Sites that need a plugin the others must not have still require that plugin to be installed at the network level, so every site shares the same code base. Teams with conflicting plugin needs usually find separate installations simpler. Confirm the exact network settings in your WordPress version before designing around them.

Can we split a multisite network into separate installations later?

A split is possible but it is a migration project, not a setting change. Each site's content, users, media, and database tables must be extracted, rebuilt as its own installation, and its URLs and permalinks kept intact. Shared users complicate the split because accounts and roles must be reassigned. Plan the split as carefully as the original conversion, and ask for a rollback plan and a tested restore for every site. Check the WordPress documentation on network setup before committing.

When does the WordPress handbook say multisite is the wrong choice?

The handbook says a network might not be the best solution for sites that are strongly interconnected, share data or share users. It also suggests that a single site with a theme or capability switching plugin may be enough. A subdirectory network cannot be chosen if the existing installation was set up more than a month ago because of permalink issues, and a subdomain network cannot be chosen when the URL contains a path, is localhost or is an IP address. Read the WordPress multisite preparation guide before deciding.

How DeployOpen scopes and delivers a WordPress network or separate installs

DeployOpen starts with the question of whether one WordPress network or several separate installations fits your sites, then plans the work around the answer. Engagements are fixed-scope, so the decision, the build, the testing and the handover are agreed in writing before any changes are made to your environment.

How we scope

Inventory which sites share users, themes, plugins and content, and which must stay isolated.
Confirm your WordPress address, domain layout, web server rewrite support and admin and file system access.
Document the written scope, deliverables and timeline before any installation or migration work starts.

How we build

Configure either a subdomain or subdirectory network, or separate installs, according to the agreed scope.
Set up the required PHP and MariaDB or MySQL versions and confirm them against the WordPress requirements.
Test user roles, plugin and theme behavior, and automatic update settings across every site in the scope.

How we hand over

Deliver runbooks covering network or install structure, update routines, backups and restore steps.
Record decisions on permalinks, domain mapping and shared accounts so future changes are traceable.
Walk your team through administration tasks and document what must be confirmed before any later change.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Plan WordPress core and plugin upgrades against the supported release line and your own change process.
Ask for the support boundary, response expectations and upgrade scope in writing before you sign.

WordPress multisite vs separate installations