International SEO: how to run search across countries and languages

International SEO is the work of making sure that a searcher in each market you serve finds the version of your site built for them, in their language, with their currency and their delivery terms. Most of the difficulty is structural. Search engines have to be told which pages are equivalents of each other, which audience each one is for, and which version to fall back on when nothing matches. Get that wrong and the wrong country version ranks.

Shops and software companies each have their own complications, covered in the ecommerce SEO and SaaS SEO pillars.

Every localised version is another site to maintain, with its own copy, links and hreflang entries. Before choosing a URL structure, decide which markets justify that cost. In my view the answer is usually fewer than the business hopes.

• Is there demand you can measure? Search Console already shows impressions and clicks by country for your existing site, which is often the best early evidence that a market is looking for you.
• Can you serve the market? If you cannot ship there, bill in its currency, support customers in its language or meet its legal requirements, a localised page sets an expectation the business cannot meet.
• Will the page differ? A version that changes only the flag in the header gives searchers and search engines nothing new.
• Will someone own it? A market version nobody updates drifts out of date within months, with old prices and dead offers.

Language targeting versus country targeting

Search engines treat the two differently. A multilingual site offers content in more than one language, and Google Search tries to match the language of the searcher. A multi-regional site explicitly targets users in different countries, and Google tries to find the right locale page for the searcher. Some sites are both, such as a business with a US version and a Canadian version that itself comes in English and French.¹

A language version (hreflang="es") is one page for every Spanish speaker, wherever they are. A country version (hreflang="es-MX") is a page for Spanish speakers in Mexico, and it should exist because something about Mexico is different: price, currency, stock, delivery, regulation or vocabulary. Geotargeting a page to one country can improve its rankings there, at the expense of results in other locales or languages.¹ That trade is worth making when the page is local, and a poor one when it is not.

Each language version should have its own URL, not content that switches language on one URL through cookies or browser settings.¹ There are four common ways to arrange them, and Google's documentation sets out the pros and cons of each.

A ccTLD is a strong signal that a site is intended for a particular country. Google treats a number of country codes as generic, because users see them that way: .tv, .me, .io, .co and .ai are on its list, along with regional domains such as .eu and .asia.¹ A .io domain therefore says nothing about the British Indian Ocean Territory, and a .eu domain does not target Europe on its own. Searchers notice national domains too. In Nielsen Norman Group's 2011 usability studies in Australia, participants strongly preferred local sites to foreign ones, and when scanning search results they showed a strong preference for URLs ending in .au.²

Ecommerce platforms build the same trade-offs into their defaults. Shopify's help centre calls subfolders the simplest option for a store setting up international selling for the first time, and says hreflang tags are created automatically for every international domain or subfolder.³ That automation covers the tags. It does not decide which markets deserve a version, or whether the pages differ enough to be worth one.

For most organisations I would start with subdirectories on one generic domain. They are the cheapest to run, every market shares the domain's existing authority and links, and one team can manage the whole thing. ccTLDs make sense when local trust in a national domain is strong, when a market is run as a separate business, or when regulation requires a local domain. Subdomains are a reasonable middle ground when markets need different hosting or platforms. Parameters are the option to avoid. I have worked through how this choice plays out for three different businesses.

hreflang annotations tell Google that a set of URLs are alternate versions of the same page for different languages or regions, so it can show the right one to each searcher. They are recommended in three situations: when the main content is in one language and only the template is translated, when content has small regional variations in a single language, and when content is fully translated into several languages.⁴ Google may find alternate versions without them, but explicit annotations are the documented best practice.⁴ Yandex supports hreflang as well, with the same ISO 639-1 language codes and ISO 3166-1 Alpha 2 region codes, and an x-default value.⁵

It is still a minority practice. The HTTP Archive's 2024 Web Almanac, based on its June 2024 crawl, found hreflang on about 10% of desktop home pages and 9% of mobile home pages.⁶

The three implementation methods

The three methods are equivalent as far as Google is concerned, so choose whichever is most convenient.⁴ Pick one and use it consistently. Running two methods that disagree with each other is a common way to produce annotations nobody can debug. Whichever you use, alternate URLs must be fully qualified, including the protocol.⁴

Self-reference and return links

Each language version should list itself as well as every other version.⁴ The relationship also has to be confirmed in both directions: if two pages do not both point to each other, the tags are ignored. The reason is defensive. Without that rule, any site could declare itself an alternate version of yours.⁴ There is some slack for very large sets. Where a complete set of two-way links is hard to maintain, some languages can be left off some pages and the pairs that do point at each other are still processed, with the priority on linking new language versions both ways to the original, dominant one.⁴

Practitioners are less strict about self-reference than the guidelines. Patrick Stox, writing up Ahrefs' 2023 study of 374,756 domains using hreflang, called self-referencing tags more of a best practice than a requirement. Ahrefs sells the audit tool the data came from, and by its own checks 67% of those domains had at least one hreflang issue.⁷ I include self-references anyway, because they cost nothing and make a set easier to check.

Missing return links are the first item in Google's list of common hreflang mistakes.⁴ They usually come from markets that launch at different times, or from a page that exists in one market and not another. If the German site links its page to a UK equivalent, the UK page has to link back, and when a page is removed from one market every other version needs its entry removed too. In the Ahrefs study, 15.3% of domains had pages missing reciprocal tags and 16.9% had hreflang pointing at redirected or broken pages.⁷

x-default for unmatched users

The reserved value x-default names the page to show when no other language or region matches the user's browser settings. It can be used on any page but was designed for language selector pages and works best with them, and it needs no language code because it is aimed at users whose language is not otherwise covered.⁴ Typical choices are a country selector, an international English version, or a homepage that redirects by locale.

Language and region codes

The value is a language code in ISO 639-1 format, optionally followed by a region code in ISO 3166-1 Alpha 2 format, such as en-US. Only codes in those standards are supported, so a code like es-419 for Latin American Spanish is not. The value is case-insensitive.⁴ Scripts can be named with ISO 15924 codes, such as zh-Hant for Traditional Chinese and zh-Hans for Simplified Chinese.⁴

These rules are narrower than the web standard they borrow from. Language tags are defined by the IETF's BCP 47, currently RFC 5646, which also allows three-digit UN M.49 region codes such as 419 for Latin America.⁸ So es-419 is a valid value for an html lang attribute, and still an unsupported one in hreflang for Google.

• The language always comes first. A region code on its own is invalid. The standard example is "be", which is Belarusian, not Belgium. To target Belgium you would use nl-BE, fr-BE or de-BE.⁴
• The United Kingdom is GB. UK is only "exceptionally reserved" in ISO 3166-1, and the language-tag registry leaves it out as an exact synonym for GB.⁹ Google's documentation says reserved codes such as EU, UN and UK have no effect in hreflang annotations.⁴ Patrick Stox wrote in the Ahrefs study that Google does in fact accept uk.⁷ With the documentation and the standard both against it, en-GB is the only safe choice.
• A language-only code, such as de, covers German speakers everywhere. It is a sensible companion to country versions, catching German speakers in markets you have not built for, and it follows the W3C's advice to keep a language tag as short as possible.⁸

Combining hreflang with canonical tags

Canonical tags and hreflang do different jobs and need to agree. The canonical says which URL represents a set of duplicates. hreflang says which URLs are equivalent pages for different audiences. With hreflang in place, each page should have a canonical in the same language, or the best substitute language if there is no canonical in that language.¹⁰ rel="canonical" annotations carrying hreflang, lang, media or type attributes are not used for canonicalisation.¹⁰

Translation affects whether Google sees pages as duplicates at all. Different language versions are considered duplicates only when the primary content is in the same language, for example when only the header and footer are translated. For regional variants in one language, such as a UK and a US page, the documented approach is to use both canonicalisation and hreflang, to help Google choose which regional URL to show.¹¹

A surprising amount of international markup does nothing in Google, by its own account.

• Language is detected from visible content. Google uses what is on the page to determine its language, not code-level information such as lang attributes, or the URL.¹
• hreflang does not set the language either. Language detection is algorithmic, and neither hreflang nor the HTML lang attribute feeds into it.⁴
• Geo meta tags are ignored, including geo.position, distribution and geotargeting HTML attributes.¹
• Server location is a weak signal. It counts, but CDNs and hosting abroad stop it being definitive.¹

The signals Google does use are ccTLDs, hreflang in tags, headers or sitemaps, server location, and other signals such as local addresses and phone numbers, local language and currency, links from other local sites, and Business Profile data where available.¹ Language detection works best with a single language for content and navigation on each page, and no side-by-side translations.¹

None of this makes the lang attribute pointless. The W3C advises always declaring the language of a page with a lang attribute on the html element,¹² and browsers and assistive technology use it. Keep it accurate. Just do not expect it to change anything in Google.

Bing

Bing's most detailed public guidance on this is old, and it points in a different direction. A 2011 post on the Bing Webmaster Blog said document location was a key contributor to relevance and listed signals in order of priority. First was the content-language meta tag, in a language-dash-region format such as en-us, with the html or title lang attribute as alternatives, and the meta tag taking precedence when they conflicted. A content-language HTTP header could be used for a whole host. It said only ccTLDs influence document location, that .com, .net and .org do not, and that a reverse IP lookup on the server is used when other signals are less conclusive.¹³ An earlier Bing post listed the language of the body text and the locale of linking pages among its indicators.¹⁴

Treat this with care. The guidance is from 2011 and Bing has not, as far as I can find, published a replacement in the same detail, so treat it as the best available statement of Bing's approach, not a current specification. The W3C also advises against declaring a page's language with a meta element using http-equiv="Content-Language",¹² and treats the Content-Language HTTP header as metadata about a document's intended audience, not the language of its text.¹⁵ If Bing matters in your markets, an accurate lang attribute on the html element is the low-risk overlap between the two pieces of advice.

Many international sites detect the visitor's location or browser language and send them to a local version. Google advises against it: automatic redirects between language versions, based on a guess at the visitor's language, can stop users and search engines from seeing all the versions, and IP location analysis is difficult and generally not reliable.¹ Web platform guidance makes the same point from the user's side. MDN's reference for the Accept-Language header says a server should never override an explicit user language choice, and that the header is often out of the user's control, for instance when travelling.¹⁶

Crawling adds a second problem. Googlebot's default IP addresses appear to be based in the USA, and it sends requests without an Accept-Language header. A site that serves different content on the same URL by country or language, which Google calls locale-adaptive, may therefore not have all its content crawled, indexed or ranked for each locale.¹⁷ Google does also crawl from IP addresses outside the USA and asks sites to treat Googlebot like any other user from that country, but separate locale URLs annotated with hreflang remain its recommendation.¹⁷

Translation converts words. Localisation adapts the page to the market: currency, units, date formats, examples, legal terms, payment methods, imagery and, above all, the vocabulary people use when they search. Two markets that share a language can still search differently. British searchers look for trainers and American searchers for sneakers. So keyword research has to be done in each market, in its language, and a translated keyword list from the home market is a poor substitute.

There is survey evidence that buyers care, from an analyst firm that researches the language services industry. CSA Research's 2020 survey of 8,709 consumers in 29 countries found that 76% preferred to buy products with information in their own language, and 40% said they would never buy from websites in other languages.¹⁹

Half-translated pages cause their own problems. Translating only the boilerplate while keeping the bulk of the content in one language, which often happens with user-generated content, can create a bad experience when the same content appears in results several times with different boilerplate languages.¹ If a page cannot be translated, it is usually better to leave it out of that market's hreflang set than to publish a version with a translated menu and untranslated body.

Where Google stands on machine translation

Google's spam policies do not ban machine translation. Scaled content abuse is defined there as generating many pages primarily to manipulate rankings, with little or no value to users, however the content is created. Among the examples is scraping feeds, search results or other content to generate many pages, including through automated transformations like synonymising or translating, where little value is provided.²⁰

The risk is automated output published at scale with nobody checking whether it helps a reader. Machine translation followed by a fluent human review of the pages that matter, with market-specific changes made, is a normal way to localise. Running an entire catalogue or blog through a translation API into twenty languages overnight and publishing it unreviewed is the pattern the policy describes. Awkward copy on a checkout page also costs conversions, whatever a search engine thinks of it. I have set out a tiered review process for machine-translated pages.

Local currency is one of the signals Google uses to identify a page's intended audience.¹ For shops the rules are stricter, because product data has to match what shoppers see.

• Merchant Center asks for an amount and currency that match the landing page and checkout pages, with the price shown prominently in the currency of the target country.²¹
• If you show a currency that is not the local currency of the target country, you must follow the price and tax requirements of the country the currency belongs to.²¹
• When products are sold in several currencies, each currency should have a distinct URL, for example one for Canadian dollars and another for US dollars.²²
• In structured data, priceCurrency uses three-letter ISO 4217 codes, shipping destinations use ISO 3166-1 alpha-2 country codes, and the shipping rate currency must match the offer currency.²²

A common failure is converting prices in the browser after load while the HTML and structured data still carry the home currency, so crawlers, shoppers and feeds each see a different price. Render the market's price and currency in the HTML for each market URL, and generate the structured data from the same source.

Restructuring an international site is one of the riskier migrations, because every market moves at once and the hreflang graph has to be rebuilt alongside the redirects. Typical examples are consolidating ccTLDs into subfolders on one domain, splitting a market out onto its own domain, or changing the locale pattern in the URL.

Google's site move guidance applies in full: map old URLs to new ones, use server-side permanent redirects, give each new URL a self-referencing canonical, and update internal links. If the site has multilingual or multinational pages annotated with hreflang, the annotations must be updated to use the new URLs.²³ Large sites can be moved one section at a time, which makes problems easier to detect and fix.²³ For an international site, moving one market at a time is often the natural section, provided the hreflang on markets that have not moved yet is updated to point at the new URLs of those that have.

The website migrations pillar covers the full process, from redirect mapping to monitoring.

Ecommerce

Shops have the strongest case for country versions, because almost everything commercial differs by market: price, currency, tax display, delivery cost and time, returns policy, payment methods and stock. That also makes them the hardest to keep consistent: when a product is discontinued in one market, the annotations in every other market have to follow. Generate hreflang from the same catalogue data that decides availability, and the sets stay honest. The ecommerce SEO pillar covers catalogue structure, faceted navigation and product data in detail.

SaaS

Software companies often need fewer country versions than they think. The product is usually the same everywhere, so language versions do most of the work. Country versions earn their place where pricing, currency, data residency, compliance or sales contact details differ. Localise the pages closest to revenue first: the homepage, pricing, the main feature pages and sign-up. Documentation and the blog can follow if each market searches for them in its own language. The SaaS SEO pillar covers how organic search feeds trials and demos.

International results are easy to misread in aggregate, because growth in a large market hides decline in a small one. Measure each market separately, against its own baseline.

• Countries is one of the dimensions in the Search Console performance report, alongside queries, pages and devices.²⁴ Combine a country with a page filter on the market's folder or host to see how the right version performs where it should.
• Check for wrong-version traffic. If US searchers are landing on UK URLs, or the generic English page outranks the local one, hreflang is either broken or being overridden.
• Register each market folder or subdomain as its own Search Console property where useful. It keeps indexing and performance data separate for the person who owns that market.
• Report indexed pages per market against pages published per market. A market with far fewer indexed pages than it should have usually points to canonical conflicts, thin translations or crawl problems.
• Tie it to revenue or leads in each market's analytics view, in local currency. Rankings in a market that cannot convert are a cost, however good they look.

This is the order I would use. It puts decisions that are expensive to reverse before the ones that are cheap to change.