WordPress Multisite vs multiple sites: choose the right structure

A hosting site allowance is not a WordPress network

WordPress Multisite runs a network of sites within one WordPress installation. Separate WordPress sites use separate installations, even when they share a hosting account. A plan that permits several websites does not automatically create a Multisite network or describe how those websites are isolated.

Start by listing the sites, their owners and the changes they need to make independently. A group of organisational sites maintained by one team has different needs from unrelated client projects with different release dates. Compare the application structure first, then check the real plan limits and available setup choices against that decision.

Compare shared components and independent releases

A network shares WordPress core and installed plugin and theme files, while subsites have their own content and settings. Independent installations can choose different component versions and update schedules. They still need deliberate server, database and permission design; separate directories alone do not prove that a hosting account provides strong isolation.

Scroll the table horizontally if needed.

Check administrator roles and plugin compatibility

A network administrator controls installation of plugins and themes. A site administrator does not have the same installation rights. A plugin may be enabled for one subsite or activated across the network; a network-activated plugin cannot simply be deactivated by an individual site administrator. Agree on who can approve a change that affects several sites.

Ask each important plugin developer whether the plugin supports Multisite and the intended activation mode. Review store, membership, language and security extensions in particular. Check commercial licence terms for the intended number of sites rather than assuming that one network counts as one licensed website. Record exceptions before choosing a shared architecture.

Plan domains and HTTPS for every website

A network can use subdomains or subdirectories, and modern WordPress supports mapping a subsite to a separate domain. Domain mapping still requires the domain to reach the correct hosting destination and the web server to recognise it. The application setting by itself does not configure public DNS or create a TLS certificate.

Write down the canonical address of every subsite and the domains that must be covered by HTTPS. Test front-end pages and administrator login for each mapped domain. Decide whether new sites are created by an administrator or on demand; on-demand subdomain creation can have different DNS requirements from a fixed list of known sites.

Plan domain records for your hosting destination

Define how one site and the whole network can be restored

For a network, review the shared database, network configuration, subsite tables and uploads required by your backup process. Ask whether your chosen recovery method restores the entire network or can recover one subsite. Restoring a whole older database to repair one site could also replace newer changes made elsewhere in the network.

For independent installations, identify the files and database belonging to each site and test a restore without touching the others. Neither architecture removes the need for a consistent backup and a recovery rehearsal. Set recovery boundaries before an incident: who authorises the restore, which sites it affects and how changes made after the backup are handled.

Define a backup and restore scope

Consider future transfers and divergent requirements

A client website that may be sold, transferred or maintained by another agency needs a documented exit path. Extracting one site from a network is more involved than copying one directory: review its database tables, users, uploads, domains and plugin-specific data. Rehearse the transfer process with the tooling you intend to use.

Separate installations may fit projects that need different PHP compatibility decisions or independent plugin releases. A network may fit a group with common components and central governance. These are workflow choices, not a promise that one architecture is always faster or cheaper. Compare the ongoing responsibility with the needs of the sites you actually maintain.

Prepare a WordPress transfer and cutover

Choose a structure before confirming the hosting setup

The VPSLibre WordPress configuration can record a multisite preference when that option is available. Review the returned quote and your project details; selecting a preference is not evidence that a network has already been created. Confirm the delivered environment and any application work with the operator responsible for setup.

If your organisation needs independent installations, compare the stated site allowance and resource limits rather than selecting Multisite just to host several domains. Use the WordPress preparation guide to check runtime and storage requirements. Keep an architecture note with the order so the chosen hosting family supports the planned application structure.

• One team owns shared component changes, or each site needs its own release process.
• Essential plugins support the intended architecture and licensing scope.
• Every domain and subsite login has a DNS and HTTPS plan.
• Single-site recovery and a future transfer have been reviewed.

Compare WordPress site allowances and configuration