WordPress Multisite hosting: what to check before combining sites
Decide whether your business sites belong in one WordPress network, then check plugin compatibility, hosting support, recovery and the path out.
In this guide
Consider WordPress Multisite when related sites can share one maintenance team, plugin policy and recovery plan. Keep separate WordPress installations when each business needs independent control over software changes or a straightforward handover to its own operator. Having several sites is not, by itself, a reason to combine them.
This guide is for someone maintaining several business sites and considering one shared WordPress installation. You need a list of the sites, their essential features and whoever controls their current hosting. You will finish with a choice between keeping separate installations and investigating a Multisite network, plus the hosting questions needed to confirm that choice. No terminal knowledge is required.
What one network actually shares
WordPress Multisite runs several sites within one WordPress installation. An individual site inside the network is often called a subsite. The sites share WordPress core files and installed plugins and themes; individual sites have their own content tables in the shared database and separate media-upload directories. WordPress describes this structure in its network guide.
That differs from a hosting account containing several independent WordPress installations. Separate installations let you maintain different copies of WordPress and plugins. They may still share hosting resources, so separate installations alone do not establish complete server isolation.
A network gives you a common place to manage software. The practical tradeoff is that a problem in shared code, or a change to that code, can affect multiple sites. You need someone responsible for checking the affected sites after an update.
Multisite also does not automatically make several sites one shared content system. If your real goal is to give departments different pages or audiences different access within one business website, first check whether a single site can do that. WordPress’s preparation guide specifically asks whether a network is needed.
Decide who needs independent control
The following are decision examples, not requirements imposed by WordPress.
| Your situation | Starting choice | Reason to check |
|---|---|---|
| Branches of one business use similar features and a central maintenance team | Investigate Multisite | The same team can approve software changes and coordinate recovery across the sites. |
| Unrelated clients choose their own plugins and maintenance providers | Keep separate installations | Each client needs control that would otherwise depend on the network operator. |
| One business has sites with very different applications or update schedules | Start with separate installations | Shared software creates coordination work even under common ownership. |
| A site is likely to be sold or handed to another operator | Favor a separate installation | Extracting one subsite is an additional project to plan before combining it. |
In a network, the Super Admin, also called the network administrator, controls the network. A site administrator manages an individual site but cannot install plugins or themes. WordPress documents these different roles and capabilities.
Site administrators can activate certain installed plugins if the network operator permits it; they cannot turn off plugins activated for the entire network. Agree who can approve a new plugin, who handles an urgent failure and who can cover for the network administrator. Giving every site owner network-wide access is not a substitute for independent site control.
Check the plugins before checking hosting prices
A plugin supplies a feature such as forms or bookings; a theme supplies the site’s presentation. List the essential ones for every site, including their versions and any custom modifications. For existing sites, ask the maintainer for this inventory if you do not have access to it.
WordPress’s Multisite administration documentation warns that not every plugin works in a network. Check each essential plugin’s official documentation or ask its developer whether your version supports Multisite, whether it must be activated for the whole network, and whether its settings and data behave separately for each site. Confirm license coverage for the intended sites as a separate purchasing question.
Then identify who will test the required business functions on a separate copy before any existing sites are combined. A form submitting on one subsite, for example, does not establish that every site’s form reaches the correct recipient. If an essential plugin is unsupported or its required behavior is unclear, keep the current arrangement while you resolve that issue.
Ask your current host about the exact network
You do not need to move if your current plan supports the proposed network and its operating needs. An allowance for multiple websites is not sufficient evidence of Multisite support.
Write down the addresses you want. A subdirectory uses a path such as example.com/branch/; a subdomain uses branch.example.com. A mapped domain lets a subsite use its own address, such as another-business.example. These are address examples, not configuration instructions. Ask the host who handles the domain routing and HTTPS certificates for your chosen arrangement.
Check these points in the current plan documentation, then send the unresolved ones to support:
- Is WordPress Multisite permitted on this exact plan, with this address arrangement and number of subsites? Are there extra charges or separate subsite limits?
- Which limits apply across the network, including storage, database size and processing resources? Give the host the sites’ actual activity and essential plugins; a site count alone does not establish capacity.
- Does staging, a separate copy for checking changes, support this network’s domains and plugins? What would copying changes back overwrite?
- Who maintains WordPress, plugins and themes, and which network problems will support investigate?
- What backup and restore options cover the entire network and an individual subsite?
For an example of why the details matter, Kinsta’s Multisite documentation limits plan eligibility and distinguishes staging support by network configuration. Its subdirectory networks are compatible with staging; subdomain and mapped-domain networks require a closer configuration check. A general “staging included” feature does not answer that question for every network.
If the host confirms that your current plan fits, keep it as a candidate. If it identifies a specific restriction, use that restriction when requesting another plan or provider quote. Compare the full recurring bill, including required licenses and maintenance; one WordPress installation does not establish a saving.
Resolve recovery and exit before combining sites
A backup of the network and a restore of one subsite are different capabilities. Ask the host to describe both procedures, their charges and who performs them. Confirm backup frequency, how long copies are retained and how you obtain a usable copy outside the account.
Use a concrete recovery question: If one site’s update fails, can you recover it without replacing newer content or transactions on the other sites? If the available recovery rewinds the entire network, decide whether all affected businesses can accept that. If they cannot, require a supported recovery method with an agreed test before proceeding.
For example, WP Engine’s backup documentation says its restore interface does not offer selection of individual database tables and that restoration overwrites content to match the backup. This is a provider-specific limitation to investigate, not proof that no Multisite recovery tool can restore one subsite.
Also ask how one site would leave: who would supply its content, media, plugin data, themes and settings, and who would rebuild and check it as an independent site? Include domain access and any licenses that must continue under the new operator.
Do not equate a content export with that completed handover. WordPress’s Tools Export documentation describes a content-data file. WP Engine’s Multisite guide also explains that its Copy Environment tool cannot separate a subsite into another environment, and that the native content export route does not transfer themes or plugins. Establish the missing work and its owner before relying on an exit plan.
Record the decision
Write a short note naming the sites, the network administrator and backup person, essential plugin checks, the proposed host and plan, and the recovery and exit arrangements. Mark unanswered items as unconfirmed.
Keep separate installations if independent software control, ownership handover or recovery requirements remain incompatible with one network. Keeping suitable existing hosting is a valid outcome.
Proceed to a separate test and implementation plan for Multisite when common administration fits, essential plugins support the intended use, and the host confirms the network and recovery requirements. Your next step is that scoped plan with the maintainer, using the confirmed hosting answers. This decision does not require buying a new plan or converting a live site today.
Sources and useful links
- WordPress: Create a Network explains shared installation files and separate site data; the structural introduction supports the decision here.
- WordPress: Before You Create a Network helps distinguish a genuine network need from a single-site requirement and outlines hosting considerations.
- WordPress: Roles and Capabilities and Multisite Network Administration explain network authority, plugin activation and compatibility limits.
- Kinsta: Multisite Network is a concrete example of plan eligibility and configuration-dependent staging support.
- WP Engine: Backup and Restore identifies what its restore process replaces; Multisite for WordPress documents its subsite-copy limitation.
- WordPress: Tools Export describes the contents of the native export file, useful when defining the work needed for a handover.