An agency wants to host fifteen client microsites on one WordPress install. The developer enables multisite on Friday afternoon. Monday the first client asks for their own domain, an incompatible shop plugin and a restore "only for my site". Three problems multisite can solve — but only if decisions are made before launch, not after.
Multisite is not "several WordPress in one". It is one database, one codebase, shared tables — with consequences for SSL, performance and liability.
Architecture: subdomains, subfolders or mapped domains
| Mode | Example | Advantages | Constraints |
|---|---|---|---|
| Subdomains | client1.agency.fr | Clear branding | Wildcard DNS + SSL |
| Subfolders | agency.fr/client1 | Fast setup | Less clean URLs |
| Mapped domains | client1.com | Client SEO | Mapping plugin, certificates |
The choice is hard to reverse without heavy migration. Decide based on client contract: does your brand or theirs dominate the URL?
Enabling multisite without a domain strategy is building a block without a lift — it works until the third floor.
Hosting: what the plan must allow
Before install, verify:
- Multisite allowed (some shared plans forbid it).
- Wildcard SSL or multi-certificate handling (Let's Encrypt SAN).
- PHP limits: memory, max execution time — network failure hits all sites.
- Reliable cron: network tasks + child sites.
- Staging: test network activation without touching prod.
VPS or "network" managed WordPress often fits better than basic shared.
Plugins, themes and roles: what changes
- Network activation vs per-site: some plugins support only one mode.
- Themes: child theme per site is possible; heavy builder on all sites multiplies load.
- Super admin roles: who can create sites, install plugins, see all client data?
- Upload quotas: stop one child site from filling shared disk.
Document a plugin allowlist before opening the network to editors or clients.
Backups and restore: the silent trap
One wp_blogs database + shared tables means:
- full backup = entire network;
- single-site restore = manual procedure or specialised tool;
- client export = neighbour table leak risk if poorly filtered.
Test partial restore before launch. Many multisite projects discover this limit on incident day.
The summit: multisite centralises power — and failure
Multisite shines for editorial networks, franchises, intranets or microsites under one brand. It becomes a burden when agencies use it as a billing shortcut without accepting network responsibility.
Decide and move forward without blind spots
- Pick URL model (subdomain vs mapped domain) with clients.
- Validate host compatibility and wildcard SSL.
- Test critical plugins on network staging.
- Define roles and extension allowlist.
- Document backup/restore per site and globally.
Browse our directory for multisite-compatible plans and Updating WordPress for network update strategy.
Frequently asked questions
Is multisite suitable for separate client sites?
Yes for franchise or homogeneous internal sites. No if isolation, billing or divergent plugins are required.
Subdomains or subfolders to start?
Subdomains = wildcard DNS + SSL. Subfolders = simpler start, less clean URLs.
Do all plugins work on multisite?
No. Test network activation and option storage in staging.
How do you back up multisite?
Shared database and wp-content: per-site restore is harder — test before prod.
Multisite rewards teams that set rules before the first child site — not those who enable network mode to "save time" on a Friday.