International SEO: Markets, Languages and URL Structure

International SEO comes down to three choices made in order: who each version is for (a language, a country, or both), where each version will live in the URL structure, and how you will tell Google which version is which. Google's documentation points to a separate URL for every version, annotations that link the versions to each other, and no automatic redirecting of visitors based on a presumed language. None of this guarantees rankings. It gives exporters, e-commerce teams and agencies a structure that can be maintained and that lets the right person land on the right page.

Sentences labelled "Practical suggestion" are advice beyond the documentation; the rest follows what Google's pages state. Google's limits and wording can change, so check the current pages before you commit to a build.

Start with the buyer, not the tag

Hreflang and domain choices are easy to debate and hard to reverse. The earlier question is what actually differs between the people you want to reach.

Language-driven versions

Google's documentation on multi-regional and multilingual sites (Opens in a new tab) defines a multilingual site as one that offers content in more than one language; Search tries to match the page to the searcher's language. If your catalogue, prices and delivery promise are identical everywhere and only the words change, a language version is the natural unit.

Country-driven versions

A multi-regional site explicitly targets users in different countries. The documentation lists signals that indicate an intended audience: local language, local currency, local addresses and phone numbers, links from local sites and Business Profile signals. A country version is therefore a content decision as much as a URL decision. If price, stock, shipping or legal terms differ by country, the page has to say so for that country.

Both at once

A site can be both. The documentation's own example is a site with separate versions for the USA and Canada, plus French and English content for Canada. When several regional versions share one language, the localized versions documentation advises providing a generic fallback for that language, for instance a plain English page that one of the specific pages can serve as.

Decision rule: open a language version when the words are the only difference, and a country version when a commercial or legal term differs. If you cannot write down why a market needs its own version, do not open it, because every version adds upkeep.

Choosing where each version lives

The same documentation compares four URL structures. Here is the comparison rewritten as a decision aid, keeping each pro and con the page lists.

Country-code domains

A domain such as example.de gives clear geotargeting, makes server location irrelevant and keeps sites easy to separate. The costs are real: it can be expensive, availability can be limited, it needs more infrastructure, some country-code domains carry strict requirements, and it targets a single country. The page also notes that some country-code domains, such as .tv and .me, are treated like generic top-level domains, and so are regional ones such as .eu and .asia. A domain ending is not proof of a targeting decision.

Subdomains

de.example.com is easy to set up, allows different server locations and keeps sites easy to separate. The weakness is that a visitor cannot tell from the URL whether "de" means German-speaking or Germany. The localized versions page (Opens in a new tab) adds that a subdomain name such as en-gb does not determine the audience by itself; you map the audience explicitly.

Subdirectories

example.com/de/ is easy to set up and cheap to maintain on one host. It shares the downsides of a single server location, a harder separation of sites and a URL that may not reveal the targeting. Practical suggestion: for a team that runs one platform and does not want to manage extra domains, a subdirectory is the lightest structure to start with, and it can be revisited if the business later justifies separate hosting.

URL parameters

site.com?loc=de is listed as not recommended, since URL-based segmentation is difficult and users may not recognise the targeting. The same logic extends to switching language with cookies or browser settings: the documentation says Google may not find and crawl all variations when content changes dynamically by language setting or rerouting, and it recommends a different URL per language version.

Localized words in URLs

The documentation says localized words in URLs are fine, internationalised domain names are acceptable, and URLs should be UTF-8 and properly escaped. How to carry slugs across languages is worked through in localized URLs and slug translation for a TR/EN site.

Telling Google which version is which

Google can find alternates without help, but the localized versions page recommends declaring them so Search can send each user to the most suitable version.

Pick one of three equivalent methods

The page offers link elements in the HTML head, HTTP Link headers for non-HTML files such as PDFs, and XML sitemap entries with xhtml:link. All three are equivalent to Google, and using all three gives no extra benefit while making upkeep harder, so choose one. Practical suggestion: if you can edit the template, use head elements; if you manage dozens of versions from one place, a sitemap can be easier to keep consistent.

Rules that apply to every method

• Each version lists itself and every other version.
• URLs are fully qualified, with the protocol.
• Alternates may sit on different domains.
• Annotations are ignored unless the pages link back to each other.
• Several regions sharing a language need a generic fallback for that language.
• The hreflang value is not merged with other attributes such as media in one tag.

Missing return links are, according to the page, the most frequent error. If a full set of two-way links is hard to maintain, languages can be left out, but newer variants should at least link both ways to the dominant original language.

Codes, fallback and duplicates

Values use an ISO 639-1 language code, optionally followed by an ISO 3166-1 Alpha-2 region code, for example en-GB. A region code alone is invalid, and country codes cannot stand in for languages: "be" is Belarusian, not Belgium. Script subtags such as zh-Hant are allowed. Codes outside the standards, such as es-419, are unsupported, and reserved values like EU, UN and UK have no effect. The x-default value marks the fallback for users whose language matches none of your versions and suits country selectors.

For duplicate content across regional URLs, the multi-regional page says to choose a preferred version and use rel="canonical" together with hreflang. The localized versions page adds that translated versions count as duplicates only when the main content stays untranslated. Google does not use hreflang or the lang attribute to detect page language; it relies on its own algorithms and the visible content. For a step-by-step review of the markup itself, see the hreflang audit guide.

Writing each market properly

Correct annotations over thin or half-translated pages produce a tidy structure and a poor result. The content decisions are as important as the technical ones.

One language per page

The documentation asks for a single language for content and navigation on each page and advises against side-by-side translations. It warns that translating only the boilerplate while leaving user-generated content in one language can lead to the same content appearing in search results under different boilerplate languages. It also recommends hyperlinks to the other language versions so visitors can choose, and cautions against redirecting users automatically based on a presumed language. The redirect question has its own treatment in automatic language redirects and SEO risks.

Translation, automation and effort

The multi-regional page does not discuss machine translation, so it cannot be cited for or against it. The helpful content guidance (Opens in a new tab) does not mention translation either, but its quality questions apply: it describes using generative AI to produce large amounts of text without manual oversight or curation as little to no effort, lists "are you using extensive automation to produce content on many topics" as a warning sign, and suggests explaining to readers how content was produced when they might wonder.

Practical suggestion: treat translation as content production. A fluent reader of the target language should review the output before publication, with extra attention to product names, measurement units, legal wording and the form of address. Where a market has its own questions, write the page for those questions instead of translating the source page.

Audience signals you control

Server location counts as a signal of intended audience, but the documentation calls it not definitive because CDNs and hosting choices distort it. Google also advises against using IP analysis to adapt content, calling it unreliable and noting that it can prevent Google from crawling variations. Locational meta tags such as geo.position and distribution are ignored. What remains within your reach is the visible content, currency, local contact details, and links from local sites. For the last of these, see international multilingual backlink strategy.

Content checklist per version

• Is all navigation and content on the page in one language?
• Was the text written or reviewed by a fluent reader of that language?
• Do currency, address and contact details match the target country?
• Are shipping, return and legal terms specific to the country?
• Can visitors switch to other versions through real links?
• Does switching language change the URL?
• Is someone named as owner for keeping the version current?

Reviewing a site that is already international

A site reaches this topic only after versions already exist. The questions below turn the documentation's points into an inventory; the order is a practical suggestion.

Inventory the versions

List every language and country version with its URL pattern, the person responsible and the reason it exists. Versions without a stated reason are candidates for merging. Note which versions share a language, because those need a generic fallback, and which share nearly identical content, because those raise the duplicate question the documentation answers with a preferred version and canonical plus hreflang together.

Check how users move between versions

Walk through the site as a visitor from each market. Does the page offer a visible link to the other versions? Does choosing a language change the URL? Does anything redirect you without asking? The documentation prefers links that let people choose, and cookie or setting based switching hides variations from crawlers. If the answers are uncomfortable, fix navigation before touching annotations.

Check the declarations

Confirm that one method is in use rather than several, that every version lists itself and all others, that URLs are fully qualified, and that codes follow the rules: a language code with an optional region, no region on its own, no invented codes. A short script that fetches each version and compares the sets can catch missing return links, which the documentation names as the most frequent mistake.

Check the substance

Read a sample of pages in each language as the target reader would. Is the whole page in one language? Do currency, contact details and terms match the country? If the answer is no for a version, the declaration cannot repair it. Either improve the content or retire the version according to the rule in your decision document.

What annotations cannot do

Annotations tell Search which versions exist and how they relate. The documentation presents hreflang as a signal, not as a command, and it does not promise placement. It also states that Google determines page language from visible content rather than from the lang attribute or hreflang. In short, markup describes the structure and the content has to earn the match.

A market entry roadmap with an example

Google gives no timeline, so the schedule below is a practical suggestion. Stretch or shrink it to your capacity.

Example scenario: an outdoor gear retailer entering English-speaking markets

Example scenario: A hiking and camping retailer based in Europe sells online and wants to reach the United Kingdom, Ireland and Canada. English is shared, but delivery times, taxes and returns differ, and Canada has French-speaking customers too.

The team first decides the unit of targeting. Because commercial terms differ by country, it plans country versions, plus a generic English fallback. For Canada it adds a French option and lets visitors choose the language rather than redirecting them. It picks subdirectories because one platform runs everything and extra domains are not justified. Each country page states its own delivery and return terms, and a native reader of Canadian French reviews that version.

What each phase needs to answer

Phase one is about a written answer to why each market needs its own version. Phase two starts with the page types that matter most to the business, not the whole site. Phase three picks one method for declaring versions and tests the return links. Phase four watches coverage and corrects; because the documentation names missing return links as the most frequent error, check those first when a version misbehaves.

The decision document

Keep a one-page record per version with the target audience, the reason it differs, the URL structure and why it was chosen, the method used to declare versions, the translation reviewer, the indicators to watch after launch, and the condition under which the version is merged or retired. The last item is the one teams skip. A retirement rule written in advance makes it easier to remove a version nobody can maintain, and removal should come with redirects for old addresses and updated annotations.

Choosing a first market

Market selection is not covered by Google's documents, so treat the following as practical suggestions. Look at your own data first: which countries and languages do orders and enquiries already come from? Check operational readiness, because a country version promises delivery, payment, returns and support to that country. Have a fluent reader assess how people there phrase what they search for, since a literal translation of a keyword may not match local wording. When demand is uncertain, test with one category in one language before building a full version.

Common mistakes and counter-measures

1. Labelling a version with a country code where a language code belongs: check codes against the documentation's rules.
2. Missing return links: test automatically that every version lists all versions.
3. Translating only the template: make content review a launch condition.
4. Duplicating one page across two countries with no difference: consider one version with a generic fallback.
5. Redirecting visitors by IP or browser language: offer visible links to other versions instead.

Questions teams keep asking

Is one version enough?

If the product and terms are the same everywhere and your customers already read your language, one version may serve. Another version means more upkeep, so the test is whether it lets a visitor do something they cannot do today.

Do I really need a country domain?

The documentation says a country-code domain gives the clearest targeting and lists its cost and single-country limit in the same breath. Subdirectories and subdomains are presented as valid options. Weigh a separate domain against your capacity to run a separate operation.

Where should the language choice be stored?

Switching by cookie or browser setting is the pattern the documentation warns against. Remembering a visitor's preference can still help the interface, provided every language still has its own URL and real links that crawlers can follow.

Frequently Asked Questions

Should I choose language or country first in international SEO?

Start from what differs for the visitor. If only the words differ, create a language version. If price, stock, shipping or legal terms differ by country, create a country version. Google's documentation defines multilingual and multi-regional sites separately and notes that a site can be both.

Subdirectory, subdomain or country domain: which one?

Google lists the trade-offs. A country domain gives clear targeting but costs more and targets one country. A subdomain is easy but may not show whether the label means language or country. A subdirectory is easy to maintain but has a single server location. URL parameters are not recommended. Capacity decides the choice.

Do I have to declare every version to Google?

It is not mandatory, since Google may find alternates by itself, but declaring them is recommended. Link elements, HTTP headers and sitemap entries are equivalent, and using all three adds nothing. Each version should list itself and all others, and the pages must link back to each other.

Can I use machine translation for a new market?

Google's multi-regional documentation does not address machine translation. Its helpful content guidance treats large volumes of automatically generated text without manual oversight as little effort. Practical suggestion: have a fluent reader review any translation before it goes live.

Should I redirect visitors based on their location or language?

Google advises avoiding automatic redirects based on a presumed language and recommends links to other versions. It also advises against adapting content by IP analysis, which it calls unreliable and potentially harmful to crawling.

Do two countries sharing a language need separate pages?

If price, stock or legal terms differ, separate country versions make sense, with a generic fallback for the shared language. Where content is duplicated across regional URLs, Google suggests choosing a preferred version and using rel=canonical together with hreflang.

Conclusion

International SEO is a sequence of decisions, not a tag. Decide whether a page changes because of language or because of country, choose the URL structure your team can maintain, give each version its own URL and declare the set with one method, and make sure each page is genuinely written for its language and market. Google's documents promise no ranking outcome and their details can change, so check the current pages before you build.

If a new market needs native-quality copy for each language version, Akua Adforce offers content writing; scope and terms are described on the product page.