WordPress Multisite SEO: Subdirectory or Subdomain?

WordPress Multisite lets one installation run several sites, and the SEO question is how those sites get their addresses and how language versions tell search engines about each other. Short answer: the choice between a path-based and a domain-based network is a WordPress setup decision, while Google compares three URL structures with different strengths and weaknesses, and nothing in the Multisite documentation says the network adds hreflang for you. If you are a publisher planning a second language, a company with regional branches or an agency choosing a network layout for a client, the order in the "Network or single site" section saves rework.

Language or country: settle the targeting first

Before touching the network settings, decide what you are targeting. Google separates a multilingual site (content in more than one language) from a multi-regional site (explicit targeting of users in different countries). A site can be both, but each answer points to different work. Two languages with identical prices and terms is a multilingual question. Separate prices, currencies, legal text and contact details per country is a multi-regional one.

The limit of geotargeting

Google's page says you can target a site, or parts of it, to users in a single country, and also says geotargeting is not an exact science. It recommends explicit methods: hreflang, country domains or explicit links. No network layout targets users on its own, and nothing here promises a ranking.

What one installation holds

The WordPress developer page on Multisite (Opens in a new tab) describes the feature as a way to create several WordPress instances within one installation. It says you can build the network around subdirectories ("path-based") or around domains or subdomains ("domain-based"). On sharing, it states that only the user table is shared between the instances and that the content of each site has its own unique tables in the database. The page also offers one use case: business sites that share some resources, such as the theme or plugins, but carry different regional content. It points elsewhere for the requirement that rewrites be enabled and for domain mapping.

Separate tables, separate pairs

Because content lives in separate tables, a post on the Turkish site and its English counterpart have no relationship in the database. The documentation does not say otherwise, and it does not describe any feature that links them. Matching translated pairs, producing hreflang links and keeping two sitemaps consistent are therefore tasks for your own process or your own tooling.

Network or single site: six questions

Practical suggestion: answer these in order.

1. Do the language sites need separate content tables, separate settings or separate teams? If yes, a network fits, since each site keeps its own tables.
2. Will all sites run the same theme and plugin set? The documentation names that kind of sharing as its use case.
3. Is your existing install more than a month old and do you want subdirectories? Then that option is closed on that install.
4. Do you need different server locations per region? Then subdomain-style addresses fit the table better.
5. Do you want the lowest maintenance on one host? Google lists that as the subdirectory advantage.
6. Who will build and audit the hreflang pairs? If nobody, settle that before building the network.

Example scenario: a trade association with country chapters

Example scenario: an association of independent bakers has chapters in Ireland, Canada and New Zealand. All three publish in English, and each has its own events calendar, membership rules and contact details. The head office wants one login and one editorial team across the chapters.

1. The head office first names the question: this is a multi-regional site, not a multilingual one, because the language is shared and the countries differ.
2. The users table is shared, which suits one editorial team; content tables are separate, which suits distinct calendars and membership pages.
3. The install is two weeks old, so subdirectories remain available. The team confirms mod_rewrite and port 443.
4. They choose a path-based network, accepting the single server location listed as a con, because separate hosting is not needed.
5. They list matching pages across chapters, such as membership rules, and add hreflang with language-and-region codes only where the page truly has a counterpart. Each page lists itself and every counterpart.
6. They place an x-default pointing to a chapter picker and add no redirect by location.
7. They record that the super admin role and security points are not covered by the page they relied on and schedule a separate review.

The scenario turns on the shared language. Where a language is shared and the countries differ, the hreflang codes carry the region, and pages with no counterpart simply get no tag.

Two network shapes, one choice

The page Before You Create A Network (Opens in a new tab) defines the two shapes. A sub-directory install creates a path-based network even though it does not use file system directories. A sub-domain install creates a domain-based network, even if you map separate domains. It also lists conditions that you should check before you commit.

What is costly to change later

The page is candid about three things. Changing your domain name after setup is more complicated, so settle it first. In a sub-directory network you cannot remove the blog slug without manual configuration. And editing a site's domain or path is possible but unusual for established sites because it changes their URLs. For SEO the last point matters most: changed URLs call for redirects, updated sitemaps and a fresh look at every language link. Google gives no guarantee about how quickly it will process such changes. These installation details can change between versions, so open the current page before you plan.

Mapping language sites onto Google's URL options

Google's page on managing multi-regional and multilingual sites (Opens in a new tab) defines a multilingual site as one offering content in more than one language and a multi-regional site as one that explicitly targets users in different countries. It then compares URL structures in a table.

Practical suggestion: read the two documents side by side with this mapping. A path-based network gives you subdirectory-style addresses. A domain-based network gives you subdomain-style addresses, or, if you map separate domains, addresses that follow the country-domain row when the domains carry country endings. The two documents never state this mapping themselves, so it is an inference you should test on a staging network.

Choosing by the problem you have

Making language pairs find each other

The page on localized versions of your page (Opens in a new tab) names three ways to tell Google about language or locale versions: tags in the page HTML, HTTP headers and an XML sitemap. It says the three methods are equivalent from Google's perspective and that you choose. HTML works if you cannot set headers or have no sitemap. Headers suit non-HTML files such as PDFs. A sitemap lets you list every variant of each URL in one place.

No built-in promise from Multisite

The Multisite page contains no statement about hreflang or about links between the sites of a network. Treat reciprocal links as work that has to be done and checked. The page on localized versions also says Google does not use hreflang or the HTML lang attribute to detect the language of a page. So hreflang helps point users to the right version; it is not how Google learns that a page is in Turkish. For a step-by-step sitemap method, see hreflang in XML sitemap, step by step.

Translation and redirect traps

Google's multi-regional page warns against translating only the boilerplate text of pages while keeping the bulk of the content in one language. It asks for a single language for content and navigation on each page and advises against side-by-side translations. It also says to avoid automatically redirecting users from one language version to another, not to redirect based on a guess of the user's language, and not to adapt content through IP analysis.

For the slug side of this work, see localized URLs and slug translation on a TR/EN site.

Duplicate content and translation discipline

Because every site in a network has its own tables, copying a post from one site to another takes a few clicks. The localized-versions page draws a useful line: localized versions of a page are considered duplicates only if the main content of the page remains untranslated. A translated page is therefore not a copy of its original, while an untouched duplicate is a risk.

Keep a pairing sheet

Practical suggestion: maintain a two-column sheet with the address on one site and its counterpart on the other. Whoever publishes a new post adds a row before publishing. When you compare the sheet against the generated hreflang output, missing counterparts show up at once. Store it where the whole team can reach it, outside the network, so it survives a change of administrator.

Turning an existing site into a network

A project can begin with a live site rather than a blank install. Two facts from the prepare-network page decide what is possible: a sub-directory install cannot be chosen when the existing install is more than a month old, and changing the domain name afterwards is more complicated. The Multisite page names migrating WordPress as the previous topic in its sequence, and the Multisite page itself gives no step-by-step migration method.

Any move that changes addresses needs redirects from the old addresses, refreshed sitemaps and a second look at the language links. Google gives no guaranteed time for the recrawl, so watch progress in Search Console rather than promising a date.

Open questions the Multisite page leaves

The page says nothing about the super admin role, about security considerations or about whether themes and plugins are activated network-wide or per site. It also gives no guidance on when not to use Multisite; the documentation has nothing on that point. Present these as open questions when you advise a client, and send the client to the network administration documentation for the first and last.

Network review checklist

• Is a network really needed, or is one site enough?
• Does the age of the existing install allow the structure you want?
• Are rewrites enabled and the port 80 or 443?
• Are domain and path structure fixed before setup?
• Is the blog slug behavior in a sub-directory network noted?
• Does every pair have return links, self-reference and full addresses?
• Is there an x-default?
• Does each page keep to one language?
• Have forced language redirects been removed?
• Were the topics the documentation leaves open handed to someone for separate review?

Pre-launch and post-launch checks

Run the check again after any theme or plugin change on the network, since a shared resource can change the output of every site at once. For the decision before the build, the international SEO market, language and URL decision guide covers the question without reference to Multisite.

A report template for clients

An architecture recommendation is easier to defend when the reasoning and its source sit side by side. This outline works for a short report.

Keep the open questions in the report instead of filling them with assumptions. A client who sees what remains unverified can plan for it, and an assumption that turns out wrong costs more than the line it would have saved.

Frequently Asked Questions

Should I pick subdirectories or subdomains for a Multisite network?

In WordPress this is a setup choice between a path-based and a domain-based network. For SEO, Google lists low maintenance as the subdirectory advantage and different server locations as the subdomain advantage. A sub-directory install is not available on an existing install that is more than a month old.

Does Multisite add hreflang automatically?

The Multisite documentation says nothing about hreflang. Plan to create the tags, headers or sitemap entries yourself and check the return links.

When does Google ignore hreflang tags?

Google says the tags are ignored if two pages do not point to each other. If page X links to page Y, page Y must link back to X, and each version must list itself too.

Should I redirect visitors by location or browser language?

Google advises avoiding automatic redirects between language versions, not guessing the user's language and not adapting content through IP analysis. Visible language links are the safer choice.

When should I avoid Multisite?

The Multisite page has nothing on that point. It names only business sites that share resources but carry different regional content as a use case. Test your own requirements.

What can a super admin do?

The Multisite page does not describe the super admin role, so the documentation says nothing here. Consult the network administration documents.

Conclusion

A Multisite network shares the user table and keeps each site's content apart. Whether it is path-based or domain-based maps, by inference, onto Google's subdirectory and subdomain options, each with its own listed strengths and weaknesses. Reciprocal hreflang links, one language per page and the absence of forced redirects are work you do and verify; the Multisite documentation does not provide them. The super admin role, security and the cases in which Multisite should not be used are not covered there, so confirm them separately.

If every language site of your network needs copy written for its readers, take a look at our content writing service.