Single global site vs. country sites
One global site works when pricing, legal terms and fulfillment don't change by market. Country sites earn their cost only once those genuinely differ.
A single global site serving one language works best when your product, pricing, and legal terms do not change by country; separate country sites make sense once currency, regulations, or fulfillment genuinely differ. Most businesses start with one global site and add country-specific pages only where a real operational difference requires it.
This is one of the structural decisions multilingual SEO rests on, and it is worth making before you pick a URL structure or a translation tool — the kind of structural call our technical SEO service helps clients make. Get it wrong and you either maintain sites you didn't need, or force every market into one site that fits none of them well.
On this page
What's the actual difference between these two approaches?
A single global site serves every market from one set of pages, usually in one language, with no per-country pricing, legal text, or product availability. A multi-country setup gives each market — or each cluster of similar markets — its own site or section, with content, prices and sometimes legal terms that vary.
Google is explicit that this is a business decision it does not weigh in on: it treats language targeting and country targeting as two separate, valid patterns, and supports both with the same technical tools, mainly distinct URLs per version and hreflang tags [1]. There is no ranking preference baked in for having "more" sites or fewer. The decision should be driven by what your business actually needs to say differently to each market, not by an assumption that more localization is automatically better for search.
It helps to separate two questions that get bundled together in practice: "how many languages do we need" and "how many sites do we need." They are not the same question. A business can translate one global site into six languages and still run it as a single site with a single set of prices and policies. Adding languages is a content decision; adding sites is a structural and operational one, and conflating the two is where teams overestimate how much separate infrastructure they actually need.
When does a single global site work well?
When nothing meaningfully differs between your markets except, at most, the language they read in. A software company selling one product at one global price in US dollars, with the same terms of service everywhere, fits a single global site cleanly — translate the pages into the languages your buyers read, and you are largely done.
The advantage is maintenance. One site means one set of prices to update, one legal page to keep current, one content calendar. Adding a language to that setup is a translation project; adding a country to a multi-site setup is a new site with its own ongoing upkeep. For a small team, that difference in ongoing effort is often the deciding factor by itself, independent of any SEO consideration.
A single global site can still target several countries in the same language. English-speaking readers in the US, UK, Canada and Australia can all be served by regional variants of one English version — the pattern is called multi-regional targeting, and Google's guidance covers it as its own case even without any translation involved [1].
This is also the setup most B2B software companies land on by default, and for good reason. A buyer evaluating project management software in Berlin and one in Toronto are usually looking at the same feature set, the same pricing tiers in one primary currency, and the same terms of service — the only thing that plausibly needs to change is the language of the marketing copy, and sometimes not even that if the buyer's team works in English regardless of location.
When do you actually need separate country sites?
When something real changes: price in local currency, available stock or shipping, a legal disclosure required by local regulation, or a materially different product line for that market. Any one of these is a legitimate reason. "We want to feel more local" without one of them behind it usually is not, because a translated page inside a well-built global site already accomplishes most of what that feeling is chasing.
| Single global site | Separate country sites | |
|---|---|---|
| Best when | Product, price and terms are the same everywhere | Currency, legal terms or stock genuinely differ |
| Maintenance | One set of pages to keep current | Every country's content, prices and legal pages, separately |
| Speed to add a market | Translate existing pages | Build and maintain an entirely new site or section |
| SEO requirement | Hreflang for language variants | Hreflang for language and country variants, both directions |
| Typical fit | Software, services, single-currency products | Ecommerce with local stock, regulated industries, franchises |
Ecommerce is the category that most often needs the country-site model, because stock, shipping cost and sometimes even product selection legitimately vary by country in a way that a single global product catalog cannot represent honestly. International ecommerce is the sharpest version of this decision, since getting it wrong there costs actual failed orders, not just an awkward reading experience.
Regulated industries are the other common trigger. Financial services, healthcare-adjacent products and anything requiring a locally worded legal disclosure often have no choice: the disclosure has to exist, it has to be correct for that jurisdiction, and a single global terms page cannot honestly carry six different countries' regulatory requirements at once. In that situation, the country site is not a marketing nicety — it is closer to a compliance requirement that happens to also need SEO treatment.
What does the country-site approach actually cost?
More than most teams budget for upfront, because the cost is not the initial build — it is the compounding maintenance. Every country site needs its prices kept current with exchange rates or local pricing decisions, its legal pages updated when regulations change, and its content refreshed on the same cadence as everywhere else. A company with five country sites is doing five times the maintenance work of a single global site, not the two or three times a rough estimate might suggest, because small tasks — a price update, a policy change, a new product listing — all have to be repeated in full for each one.
This is why the honest advice is almost always to launch fewer, fully maintained country sites rather than many thin ones. A country site with stale prices or an outdated legal notice is worse for trust than no country site at all, because it looks like abandonment rather than absence.
Budget for this before launch, not after. A realistic plan names who updates each country site's prices when exchange rates move, who reviews legal pages when regulations change, and how often content gets refreshed in each version — the same names and the same calendar you would set up for the global site, multiplied by however many country sites you commit to running.
Is there a middle path between the two?
Yes, and it is the most common real-world setup. Most growing companies run a single global site translated into several languages, then peel off dedicated country sites only for the specific markets where currency, regulation or logistics genuinely require it — often just one or two markets out of a dozen the company serves.
Start with one global site, translated where needed
Cover every market you can with translation alone before building anything more complex.
List what actually differs per market
Currency, legal requirements, available stock, local competitors. Markets where nothing on this list applies stay on the global site.
Build a country site only where the list is non-trivial
One real difference — a required legal disclosure, for example — can be enough to justify a dedicated version.
Keep hreflang consistent across the mixed setup
A hybrid of global pages and country-specific ones still needs every version linking to every other version correctly; hreflang does not care which approach produced the page.
How does this decision change hreflang and URL structure?
It does not change the mechanics, only the scale. Whether you run one global site with language folders or several country sites, every version still needs its own crawlable URL and hreflang tags pointing to every other version, including itself [2]. A hybrid setup with some global language pages and some dedicated country sites just means more distinct URLs to keep in that web of tags, which is where sitemap-based hreflang starts to earn its keep over tags repeated in every page's head.
The choice between subfolders, subdomains and country-code domains is a related but separate question, worth deciding once you know how many distinct versions you actually need — ccTLD vs. subfolder vs. subdomain walks through that trade-off directly. And whichever URL pattern you choose, avoid using it as an excuse to auto-redirect visitors by IP or browser language, which can hide your other versions from crawlers entirely, according to Google's own guidance on the subject [3].
How do you actually decide?
Write down, per market, whether currency, legal terms, stock or product line differ from your home market. Markets with a "no" across the board stay on the global site, translated if the language differs. Markets with at least one real "yes" are candidates for a dedicated site, prioritized by how much revenue or strategic importance that market represents.
Revisit the list on a schedule rather than only at launch. A market that started with a "no" across the board can pick up a real difference a year later — a new local regulation, a decision to hold local stock, a competitor forcing a local pricing match — and the honest response is to build the country site then, not to have guessed wrong at launch. Treating this as a one-time decision rather than a periodic check is a common reason teams end up retrofitting a country site under time pressure instead of planning for one.
If translation tooling is the next decision once you know how many versions you need, Weglot vs. WPML covers the two most common ways to implement it on a WordPress-based global site.
Questions people also ask
Can I start with one global site and split into country sites later?
Yes, and it is a common path. Start with one site and add country-specific pages or sections only for the markets where you can show a genuine difference actually matters — pricing, stock, or legal terms. Splitting later costs a migration; splitting too early costs maintenance you didn't need yet.
Does having separate country sites help rankings in that country?
Not by itself. A country-code domain or a country-specific subfolder is a signal, not a ranking boost on its own. What helps rankings is genuinely relevant content, working hreflang, and normal on-page and off-page SEO — the same things that help rankings anywhere.
Is a single global site bad for SEO?
No, as long as the audience genuinely is global and undifferentiated. A single English site serving readers in ten English-speaking countries with the same offer is a perfectly normal setup, and Google's own guidance treats it as a standard case, not a compromise.
How many country sites should a growing company launch at once?
Fewer than feels ambitious. A market with a fully maintained site beats three markets with a half-finished one, both for readers and for the resourcing reality of keeping content, prices and legal pages current in every version you launch.
What's the biggest mistake companies make in this decision?
Building country sites for markets where nothing actually differs — same product, same price in one currency, same legal terms — which produces maintenance cost with no corresponding benefit. The decision should follow a real operational difference, not a sense that going global requires separate sites.
Sources
- Managing multi-regional and multilingual sites — Google Search Central (checked 23 September 2026)
- Tell Google about localized versions of your page — Google Search Central (checked 23 September 2026)
- How Google crawls locale-adaptive pages — Google Search Central (checked 23 September 2026)
Deciding between one site and several for your next market?
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Jeremy ZavaCo-founder
Leads growth and client partnerships.
Works on: CRO, SEO
Reviewed before publishing by Ibrahem Helal, Co-founder.
- Multilingual SEO: a complete guide for 2026How multilingual SEO works: URL structure, hreflang, translation, keyword research and redirects, with what each decision costs and how to check it is working.
- ccTLD vs Subfolder vs Subdomain for SEOThree ways to structure a site across countries, what each one costs to run, and how Google actually treats them — with a decision process, not just a table.
- Weglot vs WPML: which is better for SEO?Weglot is a translation proxy that works with any site; WPML is a WordPress plugin storing each language as native content. How they compare on cost and SEO.
- How to Implement Hreflang Tags CorrectlyHreflang tells search engines which language or country version of a page to show; how to add it, in the head or a sitemap, with a worked example.