WordPress Multisite and SEO: The Considerations Most Guides Skip

Most WordPress multisite writeups spend nearly all their length on one decision — subdomains versus subdirectories versus mapped domains — and treat that as the entire SEO conversation. In practice, that choice matters far less than what happens after the network is built, when sitemap generation, robots.txt, and Search Console reporting all quietly behave per-site instead of per-network in ways admins don’t expect until something goes missing from the index.

Subdomain, Subdirectory, or Mapped Domain — Google Doesn’t Force the Choice

The older SEO folklore treated subdomains as functionally separate sites that had to build authority from scratch, with subdirectories always the safer bet. Google’s own John Mueller has pushed back on that repeatedly, stating Google’s systems handle subdomains and subdirectories comparably well today and don’t automatically treat a subdomain as disconnected from the rest of a domain’s authority. That doesn’t mean the choice is irrelevant — it just means it should be driven by the network’s actual administrative needs (shared branding, independent hosting requirements, franchise or multi-brand structure) rather than a defensive SEO instinct that isn’t as accurate as it used to be.

Sitemaps and robots.txt Are Generated Per Site, Not Per Network

A common assumption trips up admins early: that a single sitemap.xml at the network’s root domain covers every subsite. It doesn’t. In a standard multisite install, each site in the network generates its own sitemap.xml and its own virtual robots.txt independently. Network-activating an SEO plugin doesn’t change that — it gives every subsite the plugin’s functionality, but settings frequently don’t inherit the way admins expect, and each site’s sitemap and indexing configuration usually still needs to be checked individually rather than assumed to be correct because it was set once at the network level.

Every Site Needs Its Own Search Console Property

This becomes especially relevant with domain-mapped subsites. Google Search Console treats each verified domain or subdomain as a fully separate property, regardless of the fact that they all share one WordPress backend and one database. There’s no network-wide reporting view inside GSC itself — an admin managing a ten-site network with ten mapped domains has to verify and monitor ten separate properties, or build their own aggregated view by pulling data through the Search Console API. Guides that only mention “connect Search Console” as a single step tend to gloss over the fact that this is genuinely ten separate setup tasks, not one.

The Duplicate Content Risk Specific to Networks

Multi-brand or franchise-style multisite setups often syndicate the same taxonomy, product catalog, or article content across several sites in the network by design — that’s frequently the whole point of the architecture. Each syndicated copy needs a deliberate canonical decision:

• Self-canonical, if the content is genuinely adapted or distinct enough per site to stand on its own.
• Cross-domain canonical pointing to one authoritative copy, if it’s truly the same content republished across sites in the network.

What most guides skip entirely is that a shared media library or shared plugin-driven content pushed across a network is architecturally normal — and Google still evaluates the resulting duplication exactly the same way it would evaluate any other duplicate content situation on the open web. The network structure doesn’t earn it any special exemption.

SEO Plugin Licensing and Per-Site Configuration

One more thing most multisite guides skip: network-activating an SEO plugin is a technical step, not a licensing or configuration one. Plugins like Rank Math that offer premium features tied to a license key generally still expect that key to be validated per site within the network, not once at the network-admin level — and this trips up admins rolling out a new subsite who assume network activation alone carries every setting and entitlement along with it. The same applies to redirects: a redirect rule set up on one subsite doesn’t apply network-wide unless the plugin explicitly supports shared network rules, which most don’t by default. Budgeting time to configure each new subsite individually, rather than assuming it inherits the network’s settings, avoids a specific class of ticket that shows up constantly — “my redirects/sitemap/schema settings disappeared on the new site I just added.”

A multisite network isn’t one SEO surface with several front doors — it’s several independent SEO surfaces that happen to share a database, and every one of them needs its own sitemap, its own robots.txt review, and its own Search Console property to actually be monitored properly.

The subdomain-versus-subdirectory decision is worth making thoughtfully, but it’s a one-time architectural choice. The per-site sitemap, robots.txt, and Search Console reality is ongoing operational work that scales with every site added to the network — and it’s the part that actually determines whether the whole network gets indexed the way the admin assumes it is.