WordPress Multisite SEO

WordPress Multisite runs many sites from one installation — one codebase, one database, one admin superstructure — and its SEO story is really an architecture story: the network's URL mode (subdirectories vs subdomains vs mapped domains) decides how authority pools or splits across every site it will ever host, per the consolidation physics. Multisite itself is SEO-neutral plumbing; the decisions around it aren't. Here's the guide for anyone running or inheriting a network.

The architecture decision (the one that matters)

Subdirectory networks (example.com/site-a/): every network site pools into one domain's authority — the right mode when the sites are genuinely one brand's sections (departments, regions done per the structure trade-offs, campus units). Subdomain networks (site-a.example.com): the partial-separation middle, with the consolidation ambiguity the standing guide documents — chosen mostly when content must be separate-ish (user sites, distinct audiences under one brand). Domain mapping (each site its own domain): full separation — each site a zero-authority start building alone; the mode for genuinely distinct properties sharing only infrastructure. The rule underneath: choose by whether the sites should share ranking fate — and know that multisite makes the infrastructure choice once for everyone, which is precisely its governance value and its lock-in.

The multisite-specific SEO mechanics

1. Per-site SEO configuration: each network site needs its own settings pass — SEO plugin activated network-wide but configured per site (titles, indexation maps, sitemaps per site), and each site verified separately in Search Console (domain property covers subdirectory networks in one; subdomain/mapped need per-site properties).
2. The duplication watch: networks breed template-level duplication — shared boilerplate pages ("About this network" cloned across fifty sites), default content left live (the Hello-World problem at network scale), and staging/dev sites inside the network indexed (the lock rules apply per-site). The network-wide crawl catches what per-site eyes miss.
3. Cross-site linking honesty: network sites linking each other is internal-ish (subdirectories) or external-ish (mapped domains) — either way, sitewide reciprocal footer links across fifty mapped domains recreate the network-footprint pattern innocently; link cross-site where readers are served, per the ordinary relevance rules, not as network furniture.
4. Shared-fate operations: one codebase means one security posture (a network compromise is every site's incident), one performance profile (plugin bloat taxes all sites), and one update discipline — the governance concentration that is multisite's actual product.

Should you use multisite at all?

The honest decision tree: yes for many-similar-sites-one-team (campuses, franchises, regional editions — governance and consistency at scale); no for a handful of genuinely different properties (separate installs keep independent plugin stacks, hosting choices and migration freedom — multisite extraction is notoriously sticky); and never as an SEO tactic in itself — a network of thin microsites is the template-sprawl failure with shared hosting, whichever URL mode dresses it.

Frequently asked questions

Does multisite itself help or hurt rankings?

Neither — engines see the rendered sites, not the installation behind them; a subdirectory network is indistinguishable from one big site, mapped domains from separate sites. Every SEO effect flows from the architecture choice and the governance quality, which multisite concentrates but doesn't create.

Can different network sites use different SEO plugins?

Technically per-site activation allows it; operationally it's governance debt — the network's value is one stack maintained once. Standardise, per the consistency-is-the-agency-feature logic.

How do we split one site out of a network later?

The export/import path plus a proper migration (URLs usually change mode — subdirectory to own domain is a full redirect-map event). It's doable and never trivial, which is the lock-in to price at network design time — like every architecture decision in this silo, cheapest made correctly once, while the compounding work runs above it: content and authority per site (we serve networks too).