Multi-site in Craft vs WordPress: which is less painful

Multi-site means different things to different people. To a parent brand it might mean five regional sites that share a logo and not much else. To a university it might mean forty faculty sites with shared news and separate staff lists. To a SaaS company it might mean one marketing site, one docs site and one customer portal under different subdomains. The architecture you pick has to match the shape of the job.

Both Craft and WordPress can do multi-site. They do it differently. I have built and rescued both. What follows is the version I wish I had read before I started.

How Craft handles multi-site

In Craft, multi-site is a single install. One codebase, one database, one user base, several sites. Each site has its own locale, its own URL pattern and its own content scope. Crucially, fields can be configured to propagate values across sites or to keep them separate per site. That choice is per field, not per site.

An example. A news site running English and Welsh. The article body is per-site so each language can have its own copy. The featured image is propagated so editors only upload once. The publish date is propagated. The slug is per-site so URLs make sense in each language. None of this is a workaround. It is how the system is meant to be used.

Editors see one control panel with a site selector at the top. Permissions can be scoped per site so a regional editor only sees their own content. The database has one entries table with site-specific records, which keeps queries clean and migrations sane.

How WordPress handles multi-site

WordPress Multisite is a network of separate WordPress installs sharing a codebase. You enable it in wp-config, configure subdomain or subdirectory routing and then create sites within the network. Each site gets its own set of database tables prefixed by the site ID. The user table is shared across the network.

That structure has consequences. Each site is functionally independent. Plugins activated at the network level apply everywhere. Plugins activated at the site level apply only to that site. Theme settings, options and uploads are per site. Content is not shared by default; if you want a post that appears on three sites, you either duplicate it or you reach for a content sharing plugin or a custom solution.

Roles are network-aware but not as granular as they look. The super admin role is the only one that can install plugins network-wide. Site admins have limited control compared with a single-install admin. That matters when a marketing team expects to manage their site independently and finds out they cannot install a plugin without going through IT.

Where Craft wins

For sites that share a content structure and need shared content across the network, Craft is the cleaner option. A retailer running country sites, where most products and articles are shared and a few are localised, fits Craft like a glove. A publisher running language versions of the same magazine, where editors need to see all language variants side by side, is the same pattern.

The shared user base is also useful. One editor account works across all sites with permissions scoped per site. In WordPress Multisite you can grant users access to multiple sites, but the role on each site is independent, which becomes admin overhead at scale.

Performance is generally better. One database, one set of caches, one queue. WordPress Multisite multiplies a lot of overheads by the number of sites in the network.

Where WordPress wins

For networks where each site is its own thing, WordPress Multisite is genuinely well suited. A university where each faculty wants its own design, its own plugin stack and its own admins is the canonical case. The trade-off of duplicated configuration is exactly what you want when the goal is autonomy.

The plugin ecosystem is also wider, which matters when one site in the network needs a niche integration that the others do not. In Craft a niche plugin sometimes does not exist and you build it. In WordPress it usually does.

Hosting is more familiar. Most managed WordPress hosts support Multisite directly. Craft multi-site runs on any Craft-capable host, but you are more often putting together the hosting yourself.

The plugin compatibility problem

WordPress Multisite has a real plugin compatibility issue that does not get talked about enough. A non-trivial percentage of WordPress plugins do not handle network installs correctly. They store options in the wrong table, write files to a path that other sites cannot access, or assume a single-site database structure. Most popular plugins now declare Multisite compatibility, but the long tail does not.

On a Multisite build I would budget weeks for testing the plugin stack against the network configuration. That is not a one-off cost; every plugin update could regress.

Craft does not have this class of problem because multi-site is part of the core. Plugins that handle entries handle multi-site entries by default.

Licensing and cost

Craft 5 is the long-term support release and Craft 6 has been announced, with general availability expected later in 2026. Multi-site is part of the Solo and Pro editions. There is no per-site licence multiplier. One install, one licence, however many sites you add. That is structurally cheaper than building a network of separate Craft installs.

WordPress core is free. Plugins are licensed individually and many plugins charge per site rather than per install. A WordPress Multisite network with twenty sites and three commercial plugins each licensed per site is a significant annual cost that nobody quotes upfront. Worth checking before you commit.

Honest pitfalls of both

Craft multi-site fails when each site genuinely needs to be different. If two of the sites have a completely different content model, you are now maintaining a content model that is half-relevant to half the network. The unified field layouts that make Craft elegant for shared content become a constraint for divergent content.

WordPress Multisite fails when the sites need to share content. The plugin solutions for cross-network content sync exist but are fragile and editors hate workflows that involve copying a post to several sites. If shared content is the requirement, fighting Multisite to provide it usually ends in a custom build that costs more than picking the right tool would have.

A common Multisite mistake is choosing it for what should be three separate WordPress installs. If the sites do not share users, content or admin oversight, separate installs are simpler and safer.

How I would decide

Pick Craft multi-site when content overlaps. Regional or language variants of a core site. Brand portfolios that share product data. Publications that share editorial workflow.

Pick WordPress Multisite when sites are independent but share infrastructure. University faculties. Franchise networks where each location runs its own marketing. Internal portals where IT wants one place to manage updates but each team manages their own site.

And pick separate installs when the sites have nothing in common. The shared codebase is not worth the operational coupling.

If you are weighing this up for a real project, the answer often comes down to how much content overlap exists. I have done a fair number of these and the wrong call is expensive to reverse. If you want a second opinion, look at how I work with Craft CMS or WordPress development and support, then get in touch and tell me the shape of your network.