If you manage websites for several locations, projects or brands, you probably repeat the same tasks: updating plugins, configuring themes and giving colleagues access. WordPress Multisite can centralise some of that work, but it also introduces shared dependencies. The decision is not simply about how many websites you have. It depends on how similar they are and how much independence each one needs.
1. What WordPress Multisite is and what websites share
WordPress Multisite is a WordPress feature that lets you run a network of websites from one installation. The sites share the same WordPress files and the same collection of installed themes and plugins. In a typical configuration, they also share a database, with separate tables for much of each site's content and shared tables for certain information, including users.
Each site can have its own pages, posts, menus and settings. Addresses can use subdirectories, subdomains or separate domains, depending on the configuration. Separate domains require appropriate DNS, hosting and HTTPS certificate configuration. Adding a site to the network does not automatically take care of those requirements.
With separate installations, each website has its own WordPress installation, plugins and database, if configured that way. You can still use centralised management tools without combining the websites into a single network. Managing several sites from one place does not necessarily mean using Multisite.
2. Themes and plugins: less repetition, more shared dependencies
What a network centralises
In Multisite, the network administrator installs and updates themes and plugins. Themes can be made available across the network or enabled for particular sites. Each site can activate an available theme and retain its own customisation settings.
A plugin can be network-activated or activated individually where the configuration and permissions allow it. Network activation does not automatically mean identical settings: some plugins store settings separately for each site, while others provide network-wide options.
- You update one copy of a theme or plugin rather than separate copies for every website.
- You can standardise available components and restrict uncontrolled plugin installation.
- You need to check Multisite compatibility, licensing terms and the behaviour of each plugin.
Where separate installations offer more freedom
Separate installations let you use different versions and combinations, subject to technical compatibility and security requirements. You can test and release an update on one website without changing the code used by the others. In Multisite, updating a shared component can affect every site that uses it, even when those sites use it differently.
3. Shared user accounts, different roles on each site
WordPress Multisite has a shared user base. The same account can be an editor on one site and an administrator on another. Having an account in the network does not automatically grant editorial or administrative access to every site.
The super administrator manages the network and has broader powers than an individual site administrator. In the standard configuration, local administrators cannot freely install themes and plugins as they could on a standalone WordPress installation. That distinction matters if each brand has its own technical team or works with a different agency.
Before choosing an approach, decide who creates accounts, who approves access and who can make changes across the network. Removing access to one site and deleting a shared account are different operations. Check the consequences and content ownership carefully before making changes.
With separate installations, accounts are separate by default. You have more flexibility to apply different access rules, but also more work when a colleague joins or leaves. Centralised user management can be convenient, provided responsibilities and permissions are clearly defined.
4. Isolation between sites has clear limits
A site within Multisite is not a technically isolated WordPress installation. Separating content and roles is not the same as separating application files, databases or hosting resources. A local administrator is restricted by permissions, but those restrictions do not provide a complete barrier against an application-level incident.
- Security: a compromised super administrator account or a vulnerability in shared code can have consequences for several websites.
- Resources: heavy traffic or demanding operations on one site can affect the rest of the network, depending on the infrastructure and configured limits.
- Updates: an incompatibility in a shared plugin may require a coordinated response rather than a change confined to one site.
- Recovery: restoring the entire database can also replace recent changes on other websites. Recovering just one site requires a process suited to the Multisite structure.
Separate installations within the same hosting account are not automatically fully isolated either. Stronger separation also involves account boundaries, processes, permissions and infrastructure. If you have specific resource or architecture requirements, you can explore cloud hosting, without assuming that choosing the service alone establishes the isolation you need.
5. When to choose a network and when to keep projects separate
A website network makes sense when projects share technical oversight, use similar components and can follow a common maintenance schedule. For example, websites for several business locations could share a theme and plugins while keeping local pages, opening hours and editorial teams separate.
Separate installations are often more suitable for brands with different functionality, autonomous teams or distinct security and publishing requirements. They are also useful when a project might be sold, transferred or moved independently. Extracting a site from Multisite is possible, but it may involve adapting its data, files and configuration.
Do not assume that Multisite always uses fewer resources or always requires less administration work. Plugin complexity, traffic and coordinated changes all matter. A centralised update can save repetitive work, but resolving a compatibility issue across several different sites can take careful planning.
When assessing WordPress hosting, check whether your intended configuration is supported and which technical requirements apply. Describe the network you actually plan to run, rather than treating Multisite support as the only question that matters.
6. A practical conclusion: decide by independence and impact
Before implementation, turn the comparison into a practical checklist:
- List the themes, plugins and integrations required by each website.
- Identify differences that need incompatible versions or configurations.
- Define local roles and decide who can administer the network.
- Test important features and the effects of shared updates in a separate environment.
- Establish backup, restoration and rollback procedures, including recovery of an individual site.
- Document how you would move a project out of the network later.
Choose WordPress Multisite when standardisation offers a genuine advantage and you can coordinate changes across the network. Choose separate installations when independence and risk separation matter more. Neither approach removes the need for testing, clear access rules and a workable recovery process.
To clarify hosting requirements, use the GazduireOnline.ro contact page and describe your projects, the components they use and the level of separation you need. Those details provide a more useful starting point than the number of websites alone.
