Custom WordPress
website development
in Philadelphia

WordPress can run many sites from a single installation. The feature is called multisite, and it is tempting whenever an organisation has more than one website. One set of updates, one login, one place to manage plugins. Sometimes it is exactly right. Sometimes it ties together sites that should have stayed apart.

Multisite shares the code and the database. Every site in the network uses the same WordPress version, draws from the same pool of installed themes and plugins, and lives in the same database, with separate tables for each site. Users exist once and can be given roles on several sites.

It suits families of similar sites. A university with dozens of department sites, a franchise with a page for every location, a publisher with several regional editions, a company with a site per country. They share a design system, a set of plugins and a support team.

It suits sites with different owners much less well. If one site needs a plugin that conflicts with another, the whole network feels it. If one site grows large and busy, it shares resources with the rest. A security problem in one place can reach all of them.

Updates cut both ways. Updating core or a plugin once for every site saves time. It also means one incompatible update can break every site at the same moment. Testing on a staging copy of the whole network becomes essential.

Plugins need scrutiny. Not every plugin is written with multisite in mind. Some store settings globally when they should store them per site, some create tables that grow without limit, and some licence terms count each site separately. Checking before activation avoids painful surprises.

Domains are flexible. Sites in a network can live on subdirectories, subdomains or completely separate domains. Mapping separate domains now works in core, but certificates, redirects and analytics must still be configured for each.

Roles need thought. A network administrator controls everything. Site administrators control only their own site. Deciding who can install plugins, who can add users and who can create new sites prevents the network from growing chaotically.

Leaving multisite later is possible but tedious. Extracting one site into its own installation means exporting content, users and media, then rebuilding settings. If there is a real chance a site will need independence, starting it separately is often wiser.

Backups and performance need network level planning. A single database for many sites becomes large quickly, and restoring one site from a network backup requires care.

Before choosing multisite, write down what the sites share and what they do not. If the shared list is long and the differences are small, the network will probably serve well. If the list of differences keeps growing, separate installs are the safer path.