What Is WordPress Multisite? Pros and Cons

Multisite Defined (One Core, Many Sites)

Multisite defined: enabling it turns one WordPress install into a network container. Key points:

• One set of core files (wp-admin, wp-includes) serves every site.

• One database holds all content — each site's rows share tables with a site-ID prefix (wp_2_posts for site 2, and so on).

• One admin hierarchy above all sites: the Network Admin (Super Admin), who creates sites, installs themes and plugins network-wide, and manages users.

• Each site behaves like a normal WordPress to its users — its own scoped dashboard, content, users, URL, and theme choice from the network-approved set.

The mental model: an apartment building — shared structure and utilities, individually furnished flats, one landlord above all.

Subdomains vs Subdirectories vs Domain Mapping

Every site in the network needs an address, and you pick the shape once, at setup. Subdomains give each site its own hostname — site1.example.com — but require wildcard DNS so new subdomains resolve automatically. Subdirectories use paths — example.com/site1/ — and need no DNS work, which makes them the simpler default for new networks; on an existing site they can collide with older page URLs.

Domain mapping gives each subsite a completely separate domain (brand.com) — a native feature since WordPress 4.5, needing only that your hosting accepts multiple domains. The choice is hard to reverse, so decide before enabling the network.

Super Admin vs Site Admin Powers

Two admin layers sit above a multisite network. The Super Admin works from the Network Admin dashboard: creating and deleting sites, installing themes and plugins for the whole network, managing registration settings, and assigning users.

A Site Admin runs one subsite: its posts, pages, media and users, plus a theme chosen from the network-approved set. One Super Admin login reaches every site in the network; a site admin sees only their own. If you enable the plugins menu in Network Settings, site admins can activate or deactivate installed plugins on their site — but cannot install new ones.

Plugins and Themes at the Network Level

Plugins and themes operate under network rules. Installation happens at the network level: the Super Admin installs; themes then appear in each site's Appearance menu, and plugins in Plugins > Add New, if enabled.

Activation has two flavours: network activation — live on EVERY site, right for security, SEO and caching essentials — versus per-site activation, where each site's admin opts in (right for optional tools). Consequences to understand: a plugin activated network-wide that conflicts with ONE site affects them ALL — the debugging multiplier. Per-site plugin settings are stored separately, so configuration work multiplies. Some plugins simply are not multisite-compatible — check compatibility before adopting.

The discipline that works: keep the network plugin set small and rock-solid (security, backups, cache), and let sites opt into the long tail individually.

When Multisite Shines (Schools, Brands, Chains)

Multisite fits organisations whose sites share governance. Universities run department sites and student blogs under one domain — the University of British Columbia's blogs network is the classic example. Hotel and retail chains give each outlet a subsite with consistent branding.

Brands run regional or campaign sites that share plugins and a single update plane. Publishers and SaaS products let users create their own sub-blogs — the model WordPress.com itself runs on. Internal company intranets and one-site-per-language multilingual setups round out the list. The common thread: many sites, one team, one set of rules.

When to Avoid It (Unrelated Client Sites)

The agency question — should client sites share one multisite? Usually NO, for the risk-list reasons: clients need isolation (one client's plugin experiment must not affect another's checkout), individual backups and restores, independent resource scaling, and clean exits. A client leaving must take their site, trivially a standalone export, painfully a multisite extraction.

The modern better answer for agencies: separate installs per client, automated — staged, updated, backed up by tooling — higher overhead than one network, dramatically lower blast radius. Multisite fits agencies only when clients are tiny, unrelated risk is accepted, and the agency wants one admin plane more than isolation. On hosting: multisite needs a plan that allows wildcard subdomains and multiple domains — WebJi®'s hosting supports multisite deployments with those features.

Heavier student bodies or franchise networks belong on VPS or cloud tiers, where the shared install has real headroom.

Setup and Conversion Basics

Enabling multisite takes five steps: back up files and database; deactivate all plugins; add define( 'WP_ALLOW_MULTISITE', true ); to wp-config.php above the stop-editing line; open Tools → Network Setup, choose subdomains or subdirectories and click Install; then paste the two generated snippets into wp-config.php and .htaccess and log in again.

Three cautions: the subdirectory option can clash with URLs on a site older than a couple of months; subdomain networks need wildcard subdomains from your hosting; and the conversion is not trivially reversible — treat enabling multisite as a one-way door and test on a staging copy first.