WordPress multisite development
When an organization runs several related sites, the expensive part is rarely building them. It is maintaining five codebases, five plugin stacks, five update schedules and five slightly divergent versions of the same design. A multisite network makes that one of each, while keeping content, editors and permissions separate.
- One codebase, one design system, one release process
- Separate content, users and permissions per site
- Bilingual networks where English and French are run as paired sites
- An architecture decision made deliberately, including when the answer is no
When a network is the right structure
Multisite is a genuine architectural choice with real costs, and it is oversold. The test is not how many sites there are; it is how much they should have in common.
It fits
Sites that should share a codebase, a design system and a release cadence: divisions or departments, regional or municipal sites, a family of brands, campaign and microsite properties, or an English and a French presence maintained as a pair. Editors stay separate; the platform does not.
It does not fit
Sites with genuinely different architectures, independent release schedules, separate hosting or data-residency requirements, or different owners with no shared authority. Forcing those into one network makes every deploy a negotiation.
Running a network properly
Network architecture
Subdomain or subdirectory structure, domain mapping, which plugins are network-activated and which are per-site, and where the boundary between shared and local sits. Decided before the build, because it is expensive to move afterwards.
Roles across the network
Super administrators, per-site editors, and the permissions in between mapped to how the organization is actually governed: who can publish where, and who can change things that affect everyone.
Bilingual pairs
English and French run as sites in one network, with the relationship between paired pages modelled explicitly so that language switching, hreflang and translation status are structural rather than manual.
Shared content where it helps
Common assets, notices, directories or taxonomies surfaced across sites where duplication would otherwise drift, without merging the sites that should stay separate.
One release process
Version control, a build pipeline and staged environments for the network as a whole, with a deploy that updates every site at once and a defined rollback.
A bilingual network we run ourselves
wplook.ca is a WordPress multisite: an English site and a French site in one network, sharing a single theme, a single custom block library and a single deployment pipeline, with the relationship between paired pages stored as content metadata and used to generate the language switcher and the hreflang alternates. It is a small network, and it is the pattern larger ones use.
Bilingual delivery is a constant in our client work as well. The mortgage and brokerage platforms are built and maintained in English and French, including a wholly French-language platform. Whether a given organization is better served by a multisite network or by a translation layer within a single site is a decision we make per project rather than by default, and we will explain the trade before it is made.
Running more sites than you can maintain?
Tell us how many sites there are, who owns each one, and what they should have in common. That last answer is what decides whether a network is the right shape.
What a network costs
Honest limitations, because they decide whether this is the right structure: a network shares a database, so one badly behaved site can affect the others; plugins are not all multisite-aware and the ones that are not have to be found before they are relied on; per-site hosting or data-residency requirements cannot be met inside one network; and a single release cadence means one site cannot ship on its own schedule.
None of these is a reason to avoid multisite. They are the reasons to decide deliberately, and to keep the option of separating a site out later by not letting the network’s shared parts grow past what genuinely should be shared.
Frequently asked questions
-
Multisite, or separate WordPress installs?
The test is how much the sites should have in common, not how many there are. If they should share a design system, a component library and a release cadence, separate installs mean maintaining that sameness by hand and watching it drift. If they have genuinely different architectures, owners or release schedules, a network turns every deploy into a negotiation. Three sites that belong together are a better case for multisite than ten that do not.
-
For English and French, do we want multisite or a translation plugin?
Both work, and they fail differently. A translation layer inside one site keeps paired content close together and is simpler to operate, which suits sites where most content exists in both languages. Paired sites in a network give each language its own editors, permissions, menus and structure, which suits organizations where the two versions are not translations of each other but different content for different audiences. We make the call per project. This site is the second kind.
-
Can a site leave the network later?
Yes, and it is worth designing for even when nobody plans to. Separating a site out means exporting its content and users and standing up its own install, which is ordinary migration work. What makes it expensive is a network whose shared parts grew past what genuinely should be shared, so we keep that boundary deliberate from the start.
-
Does multisite make the sites slower?
Not in itself. A network shares a database, so the usual cause of a slow network site is a query or a plugin behaving badly on one site and affecting the neighbours, which is a reason to govern what gets network-activated rather than a reason to avoid multisite. Caching, queries and Core Web Vitals are the same engineering problem they are on a single site.
-
Can each site have its own domain?
Yes, through domain mapping, and a network can mix subdirectory, subdomain and mapped-domain sites. What a network cannot do is put sites on separate hosting or satisfy per-site data-residency requirements, because there is one database and one file system. If that constraint applies to any site in the group, it decides the architecture.
-
Who can do what across a network?
That is a governance question before it is a technical one, and it is the part most often left until after launch. Super administrators can change things that affect every site, including plugins and themes, so that role is deliberately small. Per-site editors and administrators are mapped to how the organization is actually governed: who publishes where, and who is allowed to change something everyone sees.