International SEO is the work that makes search engines show the right version of your site to each searcher: German to German speakers, prices in Swiss francs to people in Switzerland, English to everyone else. It comes down to four decisions: who you target (languages or countries), where each version lives (the URL structure), how you tell search engines which version is which (hreflang, canonicals and the lang attribute), and whether each version is genuinely made for its market. This guide is for site owners and marketers adding a second language or country, and for teams whose existing versions show up in the wrong places. By the end you will have a strategy, the technical signals in place and a way to check them.
Quick answer
- Decide languages or countries first. Translating for German speakers everywhere is one version (
de); selling in Germany, Austria and Switzerland with different prices is three (de-DE,de-AT,de-CH). - Give every version its own URL. Subfolders (
example.com/de/) suit most sites; ccTLDs (example.de) suit companies with separate national operations. Never serve different languages on one URL by cookie or IP. - Link the versions with hreflang. Every version lists every version, itself included, with valid codes (
en-GB, noten-UK) and onex-default. - Keep one canonical per version, pointing at itself. Never canonicalise the German page to the English one.
- Do not redirect visitors automatically by IP or browser language. Show a suggestion banner and a visible language switcher instead.
- Localise, do not just translate: keywords, currency, units, addresses, legal pages and examples per market.
- Check one page per template in each language with the free hreflang checker, and build the tags with the hreflang generator.
What is international SEO?
International SEO is search engine optimisation for a site that serves more than one language or country. Ordinary SEO asks "can this page rank?"; international SEO adds "and when it ranks, does the right version appear for each searcher?". A Croatian shop that adds English and German pages needs Google to show the German page in Vienna and the Croatian one in Zagreb, with the right currency and shipping terms, and it needs each version to be worth ranking in its own market.
"Multilingual SEO" and "international SEO" are often used interchangeably. Strictly, multilingual SEO is about languages (one site in English, German and Croatian), while international SEO also covers countries (the same English content for the UK and the US, with different prices). Most projects involve both, and the technique is the same: separate URLs, hreflang and localised content.
What it is not: a way to rank in a country where your pages are not relevant. hreflang and structure help Google pick between versions of a page that already deserves to rank. If the German page has thin, machine-translated text and no German links, the signals only make Google show a weak page to the right people.
International SEO strategy: languages, countries or both?
Write down, before any URL or tag exists, which markets you serve and what actually differs between them. The answer decides how many versions you need.
| Situation | Versions | hreflang values |
|---|---|---|
| Same offer everywhere, content translated | One per language | en, de, hr |
| Same language, different prices, stock, legal terms or spelling | One per country | en-GB, en-US, en-IE |
| Several countries share a language, one country differs | Language versions plus the exception | de for most German speakers, de-CH for Switzerland |
| A global English site plus local sites | Local versions plus a default | de-DE, fr-FR, x-default for the English site |
Two rules keep the list short. Create a country version only when something a visitor cares about really differs: price, currency, availability, delivery, law or vocabulary. And create a version only when you can maintain it: an out-of-date Austrian page with last year's prices is worse than none.
Then do keyword research per market, in the market's language. People in different countries search with different words for the same thing ("mobile phone" and "cell phone", "Handy" in German), and a translated keyword list misses them. Search volumes, competitors and even the search engine can differ: Google dominates most of Europe and the Americas, but not every market.
Choosing a URL structure
Each version needs its own URL that anyone, including Googlebot, can open directly. Google's documentation on managing multi-regional and multilingual sites compares the options:
| Structure | Example | Strengths | Costs |
|---|---|---|---|
| Subfolder | example.com/de/ | One domain, shared authority, one CMS and certificate | Country signal comes only from hreflang and content |
| Subdomain | de.example.com | Can run on separate servers | Behaves much like a separate site; more to maintain |
| Country-code domain (ccTLD) | example.de | Strongest country signal; clear to visitors | A domain, registration and site per country; each builds authority from zero |
| URL parameter | example.com/?lang=de | None worth having | Google recommends against it |
For most sites that are translating content, subfolders are the answer: one site to maintain and every link helping every version. ccTLDs make sense for companies with national teams, separate stock or separate legal entities. International sites: subfolder vs subdomain vs ccTLD puts the three side by side with the costs, and explains which signals Google really uses for country targeting.
Whatever you choose, avoid two patterns that hide versions from search engines: one URL whose language changes by cookie or browser setting, and automatic redirects by IP address. Google says it does not vary the location its crawler comes from to discover versions, and Googlebot mostly crawls from US addresses, so a site that redirects by IP may show Googlebot only the US version.
How Google decides which version to show
Google uses different signals for language and for country, and it helps to keep them apart.
Language is detected from the visible text. Google's documentation says plainly that it does not use code-level information such as the lang attribute or the URL to determine a page's language. So a German page must actually be in German, including its title, headings and main text; boilerplate-only translation (translated menus around untranslated content) confuses both visitors and search.
Country comes from, in Google's own list: the ccTLD, hreflang annotations, the server location, and other signals such as local addresses and phone numbers, the local language and currency, and links from other sites in that country. Search Console's old country-targeting setting is gone, so for subfolders and subdomains hreflang and on-page signals do the work.
The choice between versions is where hreflang comes in. When several versions of a page could answer a search, hreflang tells Google which one to show for which language and region. It does not make a page rank higher; it swaps in the right version of a page that already ranks.
hreflang: linking the versions together
hreflang is an annotation that lists every language or country version of a page, so Google can show each searcher the right one. Most sites add it as <link rel="alternate" hreflang="de" href="…"> tags in the head of every version; an HTTP Link header or the XML sitemap carries the same information. The complete reference, with the syntax, valid codes, a full working example and a step-by-step implementation, is in our guide to hreflang tags and how to implement them.
Four rules from Google's localized versions documentation decide whether a set counts. Each version lists every version, itself included, and every link must be returned. Codes are an ISO 639-1 language with an optional ISO 3166-1 alpha-2 region (de, de-AT, en-GB). URLs are absolute and answer 200 without a redirect. And each set lives in one place, not in the head and the sitemap at once.
When a set breaks, it breaks silently: the pages look fine and Google ignores the annotations. The sections below cover the parts that go wrong most often.
x-default: the fallback
x-default names the page for searchers whose language or region matches none of your versions, usually the international English page or a language picker. It is optional but recommended, used once per set and listed on every version like the others. x-default explained covers which page it should point at and the redirect mistake that makes the whole set useless.
Return links and other hreflang errors
Most hreflang problems are one of four errors: a version that does not link back, a page that leaves itself out of its own set, an invalid code such as en-UK or en_GB, and an alternate that redirects or answers 404. They happen because different people edit different language versions, and nothing on the page shows the break. Hreflang return links explains how each error happens, how to see the whole matrix from outside the way Google does, and how to generate the tags from one list so they stop drifting.
Tags, headers or sitemap
For a site of a few hundred pages with a multilingual plugin, tags in the head are simplest. For large sites, headless setups or platforms where you cannot edit the head, the XML sitemap is easier to keep consistent; HTTP headers are for PDFs and other files without HTML. hreflang in sitemaps vs in HTML has a working sample of each and explains how to migrate without a period where the two disagree.
Language and region codes
The codes themselves trip up many sites: en-UK instead of en-GB, es-LA meant as Latin America (LA is Laos, so it targets Spanish speakers in Laos), jp instead of ja, underscores instead of hyphens. The rule is always a two-letter ISO 639-1 language, optionally followed by a two-letter ISO 3166-1 country or a four-letter script (zh-Hant), and never a country on its own.
Our hreflang language and region codes reference lists valid codes for Spanish, English, Chinese and other common languages next to their invalid look-alikes, explains how to target Latin America without es-419, and helps you decide between language-only and language-country codes. The hreflang generator names each code as you type (de-AT becomes "German (Austria)") and flags the common mistakes.
hreflang and canonical tags
Canonical tags and hreflang do different jobs: a canonical chooses between copies of the same content, hreflang links translations and regional variants. The rule that keeps them from fighting is simple: every version's canonical points at itself, and its hreflang set lists those same canonical URLs. Pointing all canonicals at the English page tells Google the other versions are duplicates, and their hreflang is then ignored.
The guide to using hreflang and canonical tags together works through the cases that trip sites up: tracking parameters, paginated categories, pages that exist in one language only, separate ccTLDs, and how to check each version's canonical against its hreflang set.
Same-language regional versions (en-GB and en-US with almost identical text) are a special case: Google may treat them as duplicates and pick one canonical, but with a correct hreflang set it still shows the local URL to local searchers. Different prices, currencies and spellings make each version more clearly its own.
Localising content, not just translating it
Signals get the right version in front of the right person; the content decides whether that person stays. For each market:
- Keywords from that market's research, used in the title, H1 and meta description of the localised page, not a translation of the English ones.
- Currency, units, date formats and phone numbers in local form: 1.299,00 € in Germany, £1,099.00 in the UK, sizes in centimetres or inches.
- Local trust signals: a local address or delivery terms, local payment methods, reviews from that market, legal pages that follow local law.
- Translated metadata and media: titles, descriptions, image alt text, Open Graph tags and structured data per version. Schema for multilingual sites shows how each version describes its own page while the brand stays one entity.
- The right
langattribute on each page's<html>element. Google does not use it to detect the language, but screen readers, browsers and other tools do; language attributes covers the values.
Machine translation is a tool, not a finished version. Google's spam policies list automated transformations, translation included, as scaled content abuse when they produce many pages that give users little value. Machine translation reviewed and corrected by a fluent speaker is a different thing from a thousand untouched pages.
Platform notes
WordPress
WPML, Polylang, TranslatePress and Weglot all print hreflang for the translations they manage, so the usual job is fixing their output rather than writing tags: untranslated pages listed as alternates, alternate URLs that now redirect, a theme that hardcodes lang="en-US". Multilingual WordPress: WPML, Polylang and hreflang covers the URL settings each plugin offers and the failures the checker finds most often.
Shopify
Shopify Markets gives each market its own domain or subfolder and adds hreflang for them automatically. Check that every market you publish is one you really serve, since each one adds versions to every page's set; the hreflang tags guide covers the setting that turns the automatic tags off and when not to use it.
Other platforms and custom sites
Webflow Localization and many headless CMS setups can print hreflang for the locales they manage; custom sites should generate all sets from one table of URLs, either in the page template or in the sitemap generator. The hreflang generator turns such a table into tags, a sitemap or HTTP headers.
How to check your international setup
Hreflang is generated by templates, so the same mistake repeats on every page of a type. Check one home page, one category, one product or article and one contact page in each language, and you have covered most of the site.
The checker reads every hreflang tag on the page, validates the codes, checks for a self-reference and at most one x-default, then fetches up to 50 alternates and reads their own tags to confirm each links back. The table shows each version's HTTP status, its html lang value and whether the return link exists. It reads hreflang in the HTML; sets declared only in a sitemap are not checked yet. The same findings appear in the SEO module of every getReport report:
To build a complete, consistent set from a table of your versions, with every code checked, use the generator. It runs in your browser and does not visit the URLs, so run the checker once the pages are live.
After launch, watch search performance per country in Search Console's performance report, filtered by country and page. A version that gets impressions in the wrong country, or none in its own, points back to one of the signals above.
Common mistakes
- Automatic redirects by IP or browser language. Googlebot, crawling mostly from the US, may never see the other versions, and travellers get the wrong one. Suggest, do not force.
- Canonicals that point across languages. The German page's canonical pointing at the English one removes the German page from the index.
- Half-finished sets. A new language added to three templates out of five, so the other pages have no return links.
- Invalid codes.
en-UK,en_GB,ukon its own. Google ignores them silently. - Country versions without a difference. Six identical English sites for six countries dilute authority and give Google six near-duplicates to choose from.
- Untranslated metadata. A German page with an English title and meta description looks untranslated in results.
- One URL for all languages. Language switched by cookie or JavaScript on the same URL means search engines index one language only.
Questions people ask
What is international SEO?
International SEO is optimising a site that serves several languages or countries so that search engines show each searcher the right version. It covers choosing target markets, giving each version its own URL, linking the versions with hreflang, keeping canonicals per version, and localising the content itself. Done well, a German speaker in Austria finds the Austrian page with euro prices, not the English one.
What is the difference between international SEO and multilingual SEO?
Multilingual SEO is about languages: the same site in English, German and Croatian. International SEO is broader and also covers countries, such as separate UK and US versions in the same language with different prices. The techniques overlap almost completely, with separate URLs, hreflang and localised content, so most projects are both at once. The difference only matters when you decide how many versions to build.
Which URL structure is best for international SEO?
Subfolders, such as example.com/de/, suit most sites: one domain, shared authority and one site to maintain. Country-code domains such as example.de send the strongest country signal and suit companies with national teams, stock or legal entities. Subdomains sit in between. Avoid URL parameters and serving different languages on one URL. Whatever you choose, every version needs its own crawlable address.
Should I redirect visitors to their country version automatically?
No. Google advises against redirecting by IP address or browser language: its crawler mostly comes from US addresses and may never see your other versions, and travellers or expats get the wrong page. Let everyone open any URL directly, show a banner suggesting the likely version, and keep a visible language switcher on every page. hreflang then sends searchers to the right version in the first place.
Is translated content duplicate content?
No. Google does not treat a page and its translation as duplicates, because they are in different languages. Same-language regional versions, such as en-GB and en-US with nearly identical text, can be folded together, but with correct hreflang Google still shows each searcher the local URL. Keep a self-referencing canonical on every version and make regional versions differ where your offer really differs.
Can I use machine translation for a multilingual site?
Yes, as a starting point. Google's spam policies treat automated translation as a problem only when it produces many pages of little value to readers. Have a fluent speaker review and correct at least the pages that matter, including titles, meta descriptions and calls to action, and research keywords in each language instead of translating the English ones. Unreviewed translations also convert poorly.
Do I need hreflang if each language is on its own domain?
Usually yes. A country-code domain tells Google the country, but not that example.de and example.at are German versions of the same product page. Without hreflang, Google may rank the German site in Austria. Link the versions across domains the same way as within one domain: every page lists all versions, itself included, with full URLs and return links on every domain.