Multi-country website: how to run one site across markets

Key takeaways

If your markets differ only in language, build a multilingual site; if products, personas, legal, compliance or privacy differ, you need a multi-regional system.
Give a market its own project only when it differs in law, design or culture, as Japan often does; European markets usually fit one project with locales.
Default to one domain with market subfolders, which Google lists as low maintenance on the same host, while country domains are expensive and need more infrastructure.
Keep each market's pricing and currency as a CMS record rendered by one template, so a layout change reaches hundreds of pricing pages at once.
Any site offering products or services to Quebec consumers needs a complete French version, legal pages included, even with no establishment in Quebec.
21Shares, in regulated finance, runs per-market rules inside one controlled system, saves $300K+ a year and launched a new region in one week.
In hreflang, every language version must list itself and all others; missing return links are the most common mistake Google lists.
Use a market selector instead of IP redirects, because most Google crawls come from the US and auto-redirects can hide your other markets.

What is a multi-region website?

A multi-region website serves buyers in several countries from a single system, with the parts that change by market handled inside that system. Before you choose domains or a CMS, work out what actually differs between your markets. That answer decides which kind of site you need. There are two common setups for multi-region websites:

On a multilingual website, only the language changes. Every market gets the same navigation, the same pages, the same user journey and the same conversion path. It's the simpler setup, and it fits companies that sell the same products everywhere with no privacy, compliance or legal differences between countries.
On a multi-regional website, much more than the words can change. Some products are sold in one market and not in another. Personas shift from region to region. Legal requirements, compliance rules and privacy terms change at the border. The site needs a structure that gives each market its own content while the shared parts stay shared.

Factor	Multilingual website	Multi-regional website
What differs	Language only	Language plus products, personas, legal, compliance and privacy
Navigation and journey	Identical in every market	Shared core, with market-specific pages and paths
When to use it	Same offer and same rules in every market	The offer or the rules change by market

Why translation alone fails a multi-regional business

The mistake we see most often is a company with multi-regional needs treating its website as a translation project. The team localizes the copy, ships a new language and expects that to carry market-specific products, pricing and legal terms. It can't, because the structure underneath assumes every market is the same. So the gaps get patched by hand, one market at a time, until the "one site" is really several sites sharing a logo.

Find out what differs first, and only then decide if you need to translate your content on conduct a more complex localisation setup.

What website owners ask us about multi-country sites

Our sales calls show where the real difficulty sits. We build and run websites for global brands that sell in many markets, and buyers raised 12 recurring questions about global sites across 40 analyzed calls. The most common, moving from separate country sites that are updated by hand and drift out of sync onto one multilingual site, came up on 7 different calls. Consolidating several company or brand sites into one after acquisitions came next at 5 calls, followed by two questions at 4 calls each: whether one partner can handle brand and website, and how regional or franchise teams can manage their own local pages.

The chart ranks every question by how often buyers raised it, so you can see that structure leads the list while the questions just below it are about running the site: acquired brands, local teams and country pricing.

Buyers ask most about structure. The next questions on the list are operating ones, such as where an acquired brand fits, who controls local pages and whether the CMS can hold market-specific pricing at scale. This guide answers both.

Should you run one site or separate country sites?

Neither option is better by default. One project with several locales suits most groups of markets, a separate project suits a market that differs in law, design or culture, and many global companies end up with a hybrid of the two. The choice depends on your markets, your organization and your industry.

Most companies pick from three setups:

One project, many markets. A single project serves every market through locales, for example with Webflow Localization. Trustly one of our longterm clients has unified its 16 locales into one project following this structure.
A separate site per market. Each market gets its own project, hosting and release cycle.
Hybrid. One main project serves 5 or 10 locales with similar needs and offers, and a separate site serves the market that works differently.

Option	When it fits	Who runs it	Typical risk
One project, many locales	Markets differ in language, pricing or product availability	One central web team, with market contributors	Markets drift apart inside one project if nobody sets guardrails
Separate site per market	A market differs in law, design, branding or culture	A market team or regional branch with its own budget	One change for every market has to be made 10 or 15 times
Hybrid	Most markets are alike and one or two are not	The central team for the main project, a market team for the separate one	Two systems to keep in step, so shared changes need planning across both

Three questions that decide it

How much does the market differ from the others? If the difference is pricing, product availability or feature availability, one project with locales handles it. If it runs deeper, into legal rules, design, branding or culture, a separate site may be justified.
How is your company structured? One central web team that market people work with points to one project. Separate branches that don't collaborate, with their own budgets, price points, features and products, often point to separate projects.
Which industry are you in, and how are you growing? In heavily regulated industries such as finance, every market brings rules that need managing and control, and that shapes how much each market can change on its own.

What markets often gets its own project?

One of our clients runs a separate project for the Japanese market. Websites in Japan look and feel different from websites in the US or across Europe, and buyers there expect to see different things and use pages differently. The Japan project had to be separate to fit those expectations, and forcing it into a European template would have meant fighting the market instead of selling to it.

The pattern holds across our work. Sites serving different European countries usually sit under one project with different locales. Japan, and any market with different business rules, privacy rules or compliance rules, is a likelier candidate for a separate project.

Choosing domains, subfolders or subdomains

For most B2B companies, one domain with a subfolder per market (example.com/de/) is the right default, because it costs the least to run and keeps every market on one host. Google's guidance on managing multi-regional and multilingual sites, last updated December 10, 2025, lists country-code domains as "Expensive" and noting they "Requires more infrastructure", while it describes subdirectories as "Low maintenance (same host)".

Google Search Central page on managing multi-regional and multilingual sites, comparing URL structures. — Google's guidance on multi-regional and multilingual sites

Structure	Google's listed pros	Google's listed cons	Best fit (our view)
Country domain (example.de)	Clear geotargeting, server location irrelevant, easy separation of sites	Expensive, more infrastructure, strict requirements in some countries, one country only	A market run as a separate project with its own rules
Subdomain (de.example.com)	Easy to set up, different server locations, easy separation of sites	Users may not know if "de" means language or country	A market that needs its own server location
Subfolder (example.com/de/)	Easy to set up, low maintenance on the same host	Single server location, harder to separate sites	Most multilingual and multi-regional sites

Google rates URL parameters such as site.com?loc=de as "Not recommended". Where the same language appears on two URLs, for example example.de/ and example.com/de/, Google says to pick a preferred version and point to it with rel="canonical".

Cost follows structure. Every separate domain brings its own hosting and everything that comes with it, and a company running two sites pays for that twice.

Hybrid sites can still be linked for search

A separate project doesn't cut a market off from the main site. Google's page on localized versions of your pages, updated September 21, 2026, states that "Alternate URLs do not need to be in the same domain." A Japan site on its own domain can still be hreflang-linked to the main site, so search engines can send each buyer to the right version.

Deciding what is global and what is local

Decide what's global and what's local by listing every difference per market first, then tagging each page type as global (same everywhere), localized (same structure, adapted for the market) or local-only (exists in one market). The list comes before the build, because it tells you which pages can share a template and which can't.

For each market, check:

Product offering. Which products and features are sold there.
Personas. Who buys, and what they need to see before they talk to sales.
Legal requirements. Language laws, terms and required disclosures.
Compliance. What you're allowed to claim and how, especially in finance.
Privacy. Consent, cookies and data terms.
Pricing. Rates, currencies and price points.

Page type	Tier	Who owns it
Home	Localized	Global marketing, with market input
Product	Localized, or local-only for products sold in one market	Global marketing; the market team for local-only products
Pricing	Localized from structured data per market	The market team, inside a central template
Legal and privacy	Local-only, per market	The legal reviewer for each market
Careers	Local-only where you hire	The market team
Blog	Global, with local posts where a market needs them	The global content team

Pricing, currency and products as structured content

Country-specific pricing belongs in structured CMS content, with one record per market and one template that renders it. Built that way, the CMS can hold hundreds of pricing pages with different rates and currencies, and a layout change ships to all of them at once. Hand-built pricing pages are how a site ends up needing the same edit 10 or 15 times. Products and features follow the same rule: store availability per market as data, and let each market page show only what's sold there.

Quebec's French-language rule

If you sell into Canada, Quebec sets a rule that changes the build. Section 52 of Quebec's Charter of the French language says catalogues, brochures, order forms and similar public documents, "regardless of the medium used", "must be drawn up in French". Another language may be offered only if the French version is available "on terms that are at least as favourable".

Websites are covered. The law firm Smart & Biggar's May 2025 analysis of the reformed Charter confirms that commercial publications include "websites and social media pages", and that a company website must comply if it offers products or services to Quebec consumers, whether or not the company has an establishment there. The French version must be complete, including terms, privacy policy and FAQs. The firm also notes that "A significant percentage of fines awarded by the Court of Quebec in recent years are for non-compliant websites."

For a multi-country site, that makes French a full locale for Quebec buyers, with its own legal pages, planned from day one.

Why localization matters in B2B

Business buyers value localization more than consumers do. In a CSA Research survey of business users, run in 2020 and published in 2022, 66% said they would pay up to 30% more for a localized product, compared with 34% of consumers. A multi-regional site that gets the language and the local details right is selling to the buyers most willing to pay for them.

Comparison: 66% of business users vs 34% of consumers would pay up to 30% more for a localized product. — Source: CSA Research, survey run 2020, published 2022

How can market teams publish without breaking the brand?

Market teams can publish on their own when the system gives them control over what's specific to their market, inside shared components they can't change. The brand, the design system and the global pages stay with the central team; the market pages belong to the market. Without those guardrails, several teams working on one site soon produce a different website experience in every market.

Self-serve microsites across time zones

Checkout.com had market teams spread across several time zones. Every change went through one central team, and the market teams weren't moving fast for no reason other than the clock. We looked at how the time zones were shaping go-to-market, then built a system where people in each market create their own microsites from shared components, without waiting for the central team to wake up.

Per-market control in a regulated industry

21Shares works in finance, where every market carries its own rules that have to be handled and controlled. We started by separating what is specific to each market from what needs central control, then built a system where a change in one market can't affect the overall brand or system. 21Shares saves $300K+ a year on this system and launched a new region in one week.

Stat card: 21Shares saves $300K+ a year and launched a new region in one week. — Source: Flow Ninja client result, 21Shares

Role	Can edit	Needs approval for
Global marketing and web lead	Design system, shared components, global pages	Releases that change every market
Market marketer	Market pages, local proof, campaigns, pricing records	New page types and changes to shared components
Legal or compliance reviewer	Disclaimers, legal and privacy pages per market	Changes outside legal content
Developer	Components, templates, integrations	Changes to locked brand components

If your market teams queue behind one central team today, talk to one of our strategists about mapping who owns which pages in each market.

When to rethink your multi-country setup

Rethink your setup when an acquisition leaves you with more than one site, when changes across markets start taking weeks, or when you're paying for sites you barely use. All three usually trace back to one cause. Markets were added one after another as separate projects, each focused on go-to-market for the new country, and nobody designed the system they would feed. That's normal for a fast-growing company. It still needs fixing.

When you acquire or merge

Acquisitions force the question. We've worked with clients who came out of an acquisition with completely different websites and branding for different markets, running as two separate sites. Being acquired creates the same problem from the other side.

Settle the brand architecture before the site structure, because the structure follows it. The usual options are a master brand, where acquired names fold into one brand and one site; an endorsed brand, where the acquired brand keeps its name under the parent; and standalone brands that keep their own sites. Buyers ask us where the parent or institutional brand sits once product brands join, and the brand architecture answers it. Under a master brand or an endorsed brand, the parent owns the home page, the navigation and the URL structure, and the acquired brand becomes products, a section or locales inside it.

Option	How the site is structured	When to choose it	What happens to the acquired domain
Master brand	One site under the parent brand; acquired products become product pages and acquired markets become locales	The acquired company sells to the same buyers and differs only in products, pricing or availability	Retired, with a 301 redirect from every page to its closest match
Endorsed brand	The acquired brand keeps its name in its own section of the parent site, on the shared design system and components	The acquired name still matters to buyers, and its offer and rules fit the parent's system	Retired, with 301 redirects into the brand's section
Standalone brand	A separate project with its own brand and site	The acquired business differs in law, design, branding or culture, or runs as a separate branch with its own budget	Kept as its own site

Acquired domains that retire should 301 redirect to their closest match on the new site so their search equity carries over.

When changes take weeks

Slow change shows up as companies grow. A company adds markets one by one without a system, and a change to one market, or a general change across all of them, ends up taking weeks when it should take days. When a new legal line or a product rename has to be made 10 or 15 times, the website becomes the bottleneck for every launch.

When you pay for duplicate sites

Two websites means two hostings and everything that comes with them. Companies paying for several sites they don't fully use often want fewer projects, and where we've combined two websites into one project with different locales, we've also seen the costs come down.

Moving separate country sites onto one system

Move separate country sites onto one system by auditing every site, deciding what's global and local, building the shared system once, and then migrating one market at a time with redirects and hreflang in place. The goal is a site where a change that applies to every market gets made once.

Stat card: Trustly unified 16 locales into one project and saved $100K. — Source: Flow Ninja client result, Trustly

Audit each country site. List every page, what it's for, and which pages rank or convert in that market.
Map what differs by market. Products, personas, legal, compliance, privacy and pricing.
Tag each page type. Global, localized or local-only.
Choose the setup. One project, separate sites or hybrid, plus the domain structure.
Build the shared system. Design system, locked components, a content model with market records, and locales.
Map every old URL to its new one. One row per page, per market.
Migrate the first market. Launch it with 301 redirects from every old URL.
Add hreflang with return links. Every version lists itself and all the others.
Monitor, then move the next market. Check rankings, leads and redirects before the next market goes live.

Trustly shows what this looks like at scale. We unified its 16 locales into one project, and Trustly saved $100K across those 16 locales. Every market now runs on the same components and templates, so a change made once reaches all 16.

Making every market findable in search and AI

Every market version needs its own indexable URL, correct hreflang and no automatic redirects, or search engines and AI tools will show buyers the wrong country's page. Google's localized versions guidance, updated September 21, 2026, sets the rules for hreflang.

Hreflang with return links and x-default

Each version lists itself and all others. Google's wording: "Each language version must list itself as well as all other language versions."
Return links. The most common mistake Google lists is "Missing return links". If page A points to page B, B must point back, or Google may ignore the annotations.
Language first. A country code can't stand alone; Google's Belgium examples are de-BE, nl-BE and fr-BE.
A generic catch-all for shared languages. When several English URLs target different countries, such as en-IE, en-CA and en-AU, Google suggests also providing a generic en URL.
x-default for everyone else. x-default is the fallback for unmatched languages, "especially on language/country selectors or auto-redirecting home pages."

Why IP-based redirects hide markets

Google's multi-regional guidance says plainly, "Don't use IP analysis to adapt your content." The reason is in the same document: "Most, but not all, Google crawls originate from the US." Redirect by IP and a crawler arriving from the US can land on the US page every time, while your other markets stay out of sight. The same guidance adds that you should "Avoid automatically redirecting" users between language versions, because those redirects can stop users and search engines from seeing every version. Let visitors pick their market with a language and country selector instead.

How B2B buyers research with AI

Buyers increasingly meet your market pages through an AI answer. Per Gartner's May 20, 2026 survey of 645 B2B buyers, 45% used GenAI in a recent purchase, mainly to gather information on vendors and products, and buyers used an average of seven information sources. An AI tool can only recommend the market page it can find and read in the buyer's language.

We see the weight of this in our own numbers: AI search went from 6.5% to 66% of our search revenue. For a multi-country site, that means each market page needs local proof, local currency and local contact details, so it answers the buyer's question for that country.

Multi-country website checklist before choosing a partner

Run this checklist before you commit to a structure or a partner, and bring the partner in before you decide. The same goal can usually be reached several ways, and a partner who has built these systems before knows which lane fits your offer, your company and your markets.

Questions to ask your build partner

What's the best approach for our markets: multilingual, multi-regional or hybrid?
How should we organize the project around our internal teams?
What technical limits will we hit?
Which option best serves our goals in each market?
Which multi-regional systems have you built, and what did each market team control?

Signs your current system is failing

Go-to-market for a new market takes too long.
A change across all markets takes weeks.
The system slows your teams down.
Markets look and behave differently because nobody set guardrails.
You pay for sites you don't fully use.

The checklist

We know what differs per market: language, products, personas, legal, compliance, privacy and pricing.
We've chosen multilingual, multi-regional or hybrid, with a written reason for any separate project.
Every page type is tagged global, localized or local-only.
We know who owns each page type in each market.
We use one domain with subfolders, or have a written reason for a separate domain.
Pricing, rates, currencies and product availability live in structured CMS content.
Legal language rules per market are listed, including Quebec French if we sell into Canada.
Market teams can publish inside locked components without waiting on a central team.
Every retired site has a URL map and a 301 plan.
Hreflang with return links and x-default is planned for every market.
Visitors choose their market with a selector, and nobody is redirected by IP.
Analytics separate traffic and leads by market.
The site can add a new market without a rebuild.

No market is off limits for a site built on the right system. Choosing that system is the work. As a Website Operating Partner for global brands, we start every multi-country project with a Website Strategy Plan that maps your markets, owners and setup before anything gets built. Talk to a strategist about yours, or run our free website scan on your current country sites first.

What does a multi-country website cost?

Our projects start from $25,000 for Webflow Development and from $50,000 for Transform, which adds strategy and design. Running the site afterward starts from $6,000 a month on a 12-month term, and we call this WebOps. On a multi-country site, scope grows with the number of markets and how much each one differs, and every separate country project adds its own hosting on top.

Can our team handle translations in-house, for example with AI and our own QA, while the partner builds the rest?

Yes. A multi-country site separates structure from words, so your team can own translation and review while the build partner owns templates, components, locales and hreflang. Quality still matters for search, because Google determines a page's language from its visible content, ignoring the lang attribute and the URL. Half-translated pages confuse buyers and crawlers alike.

If we launch in one language now, how do we build the site so we can add regions, languages and markets later?

Build for many markets on day one, even with one live. Use a locale-ready URL pattern such as example.com/en/, keep every piece of text in translatable CMS fields, store pricing and currency as data per market, and plan hreflang before launch. Adding a market then means adding content. Hard-coded text inside components is what turns a later market into a rebuild.

What should a market page show if that market has no local content yet?

Show the closest version that exists and let the buyer choose their market, and skip empty or half-built market pages. In hreflang, Google's x-default value is the fallback for languages you don't match, and when several English URLs target different countries, Google suggests a generic en version as the catch-all. Add local pages as each market earns them.

How do we host a fully working site in China, with alternatives for analytics, maps and video?

Plan China as a separate project inside a hybrid setup. A separate server with its own analytics, maps and video is exactly the kind of market-specific difference that justifies a separate build, and Google confirms alternate URLs don't need to share a domain, so a China site can still be hreflang-linked to your main site.

Does it matter that our website partner is not US-based, given time zones and English-market SEO?

No for English-market search, which depends on crawlable market URLs and correct hreflang, and most Google crawls originate from the US whoever builds the site. Time zones slow you down only when every change has to pass through one central team. One of our clients had market teams stalled by time zones until each market could publish its own microsites.

How do we measure traffic and leads by market on one multi-country website?

Use the URL structure. With one domain and a subfolder per market, every report can be filtered by path, such as /de/ or /fr-ca/, so traffic, conversions and leads separate by market without separate analytics setups. Then match leads to revenue: our analytics match your website to the deals in your CRM, so each market shows pipeline as well as visits.

Misa Vuckovic

Head of Growth at Flow Ninja and the main voice behind its WebOps model, writing on demand generation, AI in marketing, and websites in regulated industries.

More about

Misa Vuckovic