Sites for several countries and languages: structure, targeting and rollout

Multilingual vs multi-regional

Google uses two separate terms, and they lead to different setups.

• Multilingual: “A multilingual website is any website that offers content in more than one language. For example, a Canadian business with English and French versions of its site.” For these sites, “Google Search tries to find pages that match the language of the searcher.”
• Multi-regional: “A multi-regional website is one that explicitly targets users in different countries. For example, a product manufacturer that ships to both Canada and the United States.” Here “Google Search tries to find the right locale page for the searcher.”

Many sites are both. Google's own example: “Some sites are both multi-regional and multilingual: for example, a site might have different versions for the USA and for Canada, and both French and English versions of the Canadian content.”

The practical test is simple: does the offer change, or only the language?

• Language targeting. One German version serves Germany, Austria and Switzerland with the same products, prices and terms. You need /de/, not three country versions.
• Country targeting. Prices, currency, delivery, stock, legal terms or the product range differ by country. Then each country needs its own version, even when the language is the same (/de-de/, /de-at/, /de-ch/).

Building country versions you do not need multiplies the work and creates near-duplicates. Building only language versions when the offer really differs leaves users in the wrong currency with the wrong delivery terms.

What Google officially says

Google is also honest about the limits of targeting: “Remember that geotargeting isn't an exact science, so it's important to consider users who land on the "wrong" version of your site.” And it is a trade-off, not a free gain: targeting a country “can improve your page rankings in the target country, but at the expense of results in other locales or languages.”

URL structure options

Google describes four ways to put locale versions on URLs. A fifth approach, one URL that changes with cookies or browser settings, is the one Google recommends against.

Country-code domain: example.de

A ccTLD is tied to one country. Google says ccTLDs “provide a strong signal to both users and search engines that your site is explicitly intended for a certain country.” Google's listed pros are clear geotargeting, server location being irrelevant and easy separation of sites. The cons: expensive (and sometimes unavailable), more infrastructure, strict registration rules in some countries, and a ccTLD can only target a single country. “Some countries have restrictions on who can use ccTLDs, so be sure to do your research first.”

In practice, each ccTLD is a separate site: its own links, its own Search Console property, its own technical upkeep. A new domain does not inherit the reputation your main domain has built.

Subdomain: de.example.com

Google's pros: easy to set up, allows different server locations, easy separation of sites. The con: users might not recognise the targeting from the URL alone, because, in Google's words, is "de" the language or the country? Subdomains suit markets that run on a separate platform, server or team.

Subfolder: example.com/de/

Google's pros: easy to set up and low maintenance on the same host. Cons: users might not recognise the targeting from the URL, a single server location, and separating the sites is harder. In practice this is the most common choice for a new rollout, because every market sits on one host and benefits from the same domain, links and technical stack.

URL parameters: example.com?loc=de

Google's verdict in its table is “Not recommended.” Segmenting by URL is hard, and users cannot see the targeting. Parameters are also easy to drop from internal links and easy to treat as duplicates.

One URL with cookies or browser language

Here the URL stays the same and the content changes. Google warns: “If you prefer to dynamically change content or reroute the user based on language settings, be aware that Google might not find and crawl all your variations.” The reason is how Googlebot crawls, covered below in “Automatic redirects and locale-adaptive pages”.

Whatever you choose, Google allows local words in the path: “It's fine to use localized words in the URL, or to use an Internationalized Domain Name (IDN).” Just “be sure to use UTF-8 encoding in the URL” and escape the URLs correctly in links. URL design in general is covered in the lesson “URLs”.

How to choose a structure

Google lists the options but does not pick one for you. These are the questions SEO teams usually work through:

1. Does the offer differ by country? If not, you need language versions only, and subfolders such as /de/ and /fr/ are enough.
2. Do you need a local domain? A legal entity per country, a strong local brand, or a market where local domains are expected for trust. If yes, and you can staff separate sites, use ccTLDs.
3. Does a market run on its own platform? A different shop system, server or team per country points to subdomains.
4. Otherwise, use subfolders. One host keeps links, crawling, monitoring and releases in one place.

Then fix a naming pattern and keep it everywhere: /de/ for German speakers anywhere, /de-at/ or /at/ when Austria has its own offer. Use lowercase and one separator style. Changing the structure later means a migration with a full 301 map, so it is worth deciding carefully; see the lesson “Redirects and site migrations”.

How Google works out the target country and language

“Google relies on a number of signals to determine the best target audience for a page”. The documented ones:

Regional domains are not country domains: .eu and .asia “are generally treated as generic top-level domains (much like .com or .org)”. If your site is on a generic domain and you want to reach one country, Google asks you to “explicitly set a country target using one of the methods described previously”, meaning locale-specific URLs and hreflang.

Language comes from the visible text

Language is detected from what users read, not from markup. “Google doesn't use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language.” Keep a correct lang attribute for accessibility and browsers, but do not expect it to fix a page that mixes languages.

What Google ignores

“Google ignores locational meta tags (like geo.position or distribution) or geotargeting HTML attributes.” Adding geo.region meta tags does nothing for Google Search.

Translation vs localisation

Translation changes the words. Localisation changes the page so that it works for people in that market. Google lists “the use of local language and currency” among its signals, but users notice far more than that. A localisation checklist that SEO and product teams commonly use:

• Prices and taxesLocal currency, VAT shown the way local shoppers expect, local price endings.
• Units and formatskm or miles, kg or lb, °C or °F; dates as 30/10/2026 or 10/30/2026; numbers as 1,000.50 or 1.000,50.
• Addresses and phonesLocal address format, phone numbers with the country code, local opening hours.
• Legal pagesPrivacy notice, cookie rules, terms, returns and warranty for that jurisdiction.
• Payment and deliveryPayment methods people use there, real delivery times and costs.
• Proof and examplesLocal reviews, case studies, imagery and examples that make sense in that country.

Keyword research per market

Never translate a keyword list. People in each market search with their own words, and demand differs. In the UK people search for “mobile phone” and “trainers”; in the US the same products are “cell phone” and “sneakers”. Spanish in Spain and Spanish in Mexico differ in the same way. Run research separately for every market, with that country's location and language settings in your tools, and map the results to pages. The method is in the lesson “Keyword research: sources and method”.

Localise every element that search sees, not only the body: title, meta description, headings, image alt text, structured data values (price, currency, availability), internal anchor text and, where it helps users, the URL slug.

One language per page

Google's advice: “You can help Google determine the language correctly by using a single language for content and navigation on each page, and by avoiding side-by-side translations.” A half-translated template is a known trap: “Translating only the boilerplate text of your pages while keeping the bulk of your content in a single language (as often happens on pages featuring user-generated content) can create a bad user experience if the same content appears multiple times in search results with various boilerplate languages.”

Machine translation and quality

Google's pages on international sites do not ban machine translation. What the spam policies do describe as scaled content abuse includes “Scraping feeds, search results, or other content to generate many pages (including through automated transformations like synonymizing, translating, or other obfuscation techniques), where little value is provided to users”. The problem is low-value pages at scale, whatever tool made them.

A workflow that keeps translated content useful (practice, not Google guidance):

1. Machine translation is a draft. Use it to speed up the first version, not as the final text.
2. A native speaker reviews meaning, terms and tone. Especially product claims, legal text and calls to action.
3. Keep a glossary of brand terms, product names and words you never translate.
4. Check the SEO fields: titles, descriptions, alt text and structured data are where unreviewed output shows first.
5. Release in batches. Start with the pages that matter most, review them, then expand. Do not publish thousands of unreviewed pages in one go.

Automatic redirects and locale-adaptive pages

A locale-adaptive page returns different content at the same URL depending on the visitor's perceived country or language. Google's warning: “Google might not crawl, index, or rank all your content for different locales.” The reason: “This is because the Googlebot crawler usually originates from the USA. In addition, the crawler sends HTTP requests without setting Accept-Language in the request header.” Google adds that “Googlebot crawls with IP addresses based outside the USA, in addition to the US-based IP addresses”, but it does not try every location for your site, so “make sure you explicitly tell Google about any locale or language variation that your site exposes”.

Google's recommendation is direct: “We recommend using separate locale URL configurations and annotating them with rel="alternate" hreflang annotations.”

The same logic applies to automatic redirects. If example.com/ sends every visitor from Austria to /de-at/ and every visitor from the US to /en-us/, Googlebot, mostly arriving from the US, may never see the other versions. In Google's words, “These redirections could prevent users (and search engines) from viewing all the versions of your site.” What to do instead:

• Let people switch. “Consider adding hyperlinks to other language versions of a page. That way users can click to choose a different language version of the page.”
• Suggest, do not force. A dismissible banner such as “Looks like you are in Austria. Go to the Austrian site?” keeps every URL reachable. Remember the user's choice.
• Give unmatched users a fallback. Google advises: “Consider adding a fallback page for unmatched languages, especially on language/country selectors or auto-redirecting home pages.” That is the x-default value, explained in the lesson “hreflang”.
• Treat Googlebot like a local user. “when Googlebot appears to come from a certain country, treat it like you would treat any other user from that country.”
• Keep robots rules identical. “robots meta tags and the robots.txt file must specify the same rules in each locale.”

A selector that Google can crawl is plain links, with each language named in that language:

<nav aria-label="Language and region">
  <a href="https://example.com/en-gb/" hreflang="en-GB">English (UK)</a>
  <a href="https://example.com/de-de/" hreflang="de-DE">Deutsch (Deutschland)</a>
  <a href="https://example.com/de-at/" hreflang="de-AT">Deutsch (Österreich)</a>
  <!-- links, not a JavaScript-only dropdown or a form -->
</nav>

Avoid flags for languages: a flag is a country, and Spanish or English is spoken in many of them.

Duplicates between countries in the same language

Country versions in one language are often almost identical: /en-gb/ and /en-ie/ may differ only in currency and delivery. That is allowed, as long as you say what each page is for. Google's rule for the same German content on example.de/ and example.com/de/: “pick a preferred version and use the rel="canonical" element and hreflang tags to make sure that the correct language or regional URL is served to searchers.”

Pages in different languages are a different case: “Localized versions of a page are only considered duplicates if the main content of the page remains untranslated.” So each translated version keeps a self-referencing canonical; never canonicalise all languages to English. The canonical side is covered in the lesson “Canonical tags”.

Make regional versions genuinely regional where you can: local prices, delivery terms, contact details and examples. The more each version reflects its market, the clearer the choice is for Google and users.

Launching a new market step by step

Treat every new market as a small launch with its own checks. A typical order of work:

1. Check demand. Is there search demand and a real offer for that market?
2. Decide language or country targeting and write down the locale code (for example de-AT).
3. Choose the structure and the URL pattern, using the decision tree above.
4. Research keywords for that market and map them to pages.
5. Localise the key pages first: home, top categories, top products or services, contact, legal pages.
6. Connect the versions: hreflang between equivalents, self-referencing canonicals, a crawlable selector.
7. Add local signals: currency, local address and phone where you have them, a Business Profile if you have a physical location there.
8. List the URLs in a sitemap (one per locale is easy to monitor).
9. Crawl before launch: status codes, canonicals, hreflang pairs, robots rules, mixed-language pages.
10. Launch, then set up measurement: a Search Console property for the market and a country view in analytics.
11. Build local visibility: local links, PR and partners. Google mentions “links from other local sites” among its signals.
12. Review results by market over the following weeks and fix what the data shows.

Measuring each market in Search Console

A blended total hides market problems. Set up Search Console so that each market can be read on its own.

Properties

• Subfolders: add a URL-prefix property per folder, such as https://example.com/de-at/. Google's help says: “If you need to limit your data by URL path segments (example.com/es/, example.com/en/, and so on) or by protocol (http/https), then create a URL-prefix property instead.” You then get indexing, sitemaps and performance data for that market only.
• Subdomains: a URL-prefix property per subdomain, plus the Domain property that “Includes all subdomains (m, www, and so on) and multiple protocols (http, https, ftp).”
• ccTLDs: each domain is its own site and needs its own property.

The Performance report

The Performance report has a Countries dimension next to Queries, Pages, Devices, Search appearance and Dates. Three views answer most questions:

1. Filter by page (URL contains /de-at/) and open the Countries tab: is the Austrian folder mostly seen in Austria?
2. Filter by country (Austria) and open the Pages tab: which versions do Austrian searchers see? If /de-de/ pages rank in Austria instead of /de-at/, check hreflang and how different the two versions really are.
3. Compare markets on clicks, impressions, CTR and position, and compare periods after each launch step.

In analytics, report by country and by landing-page folder, so that conversions per market match what Search Console shows. The lesson “Performance report” explains the metrics and filters in detail.

Common mistakes

• ✕Redirecting by IP or browser languageGooglebot mostly sees one version, and users cannot reach the others.
• ✕One URL for all languagesContent switched by cookie or setting; Google may never crawl the other versions.
• ✕Mixed languages on one pageTranslated menu, untranslated body, or side-by-side translations.
• ✕All languages canonicalised to EnglishTranslated pages are not duplicates; each one is its own canonical.
• ✕Translated keyword listsLocal wording and demand differ; research each market.
• ✕Unreviewed machine translation at scaleThousands of low-value pages published at once.
• ✕Country versions with no country differencesSame text, same prices, only a different folder.
• ✕Different robots rules per localeGoogle asks for the same rules in each locale.
• ✕Flags as language switchesA flag is a country, not a language.
• ✕Relying on geo meta tags or the old Search Console settingGoogle ignores the first; the second no longer exists.

FAQ

Sources

• Google Search Central — Managing multi-regional and multilingual sites
• Google Search Central — Tell Google about localized versions of your page
• Google Search Central — How Google crawls locale-adaptive pages
• Google Search Central — Spam policies for Google web search
• Google Search Console Help — The International Targeting report is deprecated
• Google Search Console Help — Add a website property
• Google Search Console Help — Performance report (Search results)

Quotes checked against the official pages on 30 October 2026.