Multilingual SEO: URL structure, hreflang and translation that search engines can follow

A multilingual site is, in Google's words, any website that offers content in more than one language. The first decision is where each language lives, and Google's answer starts with one rule: use a different URL for each language version of a page, not one URL whose language changes with cookies or browser settings.

The reason is how Google crawls. Its page on locale-adaptive sites says Googlebot's default IP addresses appear to be in the USA and that it sends requests without an Accept-Language header, so a page that adapts to each visitor may only ever show Google one version. Google recommends separate locale URLs annotated with hreflang, and lists four ways to build them:

• Country domains (example.de): a clear country signal and easy separation, but expensive, more infrastructure, and each domain targets a single country. It is a choice about markets more than languages.
• Subdomains (de.example.com): easy to set up and to host in different places, though visitors may not know whether de means a language or a country.
• Subdirectories (example.com/de/): easy to set up and low maintenance on one host, but harder to separate later.
• URL parameters (?loc=de): Google marks these as not recommended.

For most sites adding languages to an existing domain, subdirectories are the simplest choice: one host, one codebase, and each language's performance readable by filtering on its folder. Choose country domains when you run a separate business in each country, not because you translate.

hreflang tells Google which URLs are versions of the same page in other languages or for other regions, which, in Google's words, helps it point users to the most appropriate version by language or region. You can declare it in HTML link elements, in HTTP headers or in your sitemap. The rules most implementations break:

• Every version lists itself and all the others. If two pages do not both point to each other, Google ignores the tags.
• Codes follow ISO. A language code from ISO 639-1, optionally followed by a region from ISO 3166-1 Alpha 2: de, de-AT, pt-BR. A region on its own is not valid.
• URLs are fully qualified, including https://, and alternates may sit on other domains.
• x-default is used when no other language or region matches the visitor's browser setting. Google says it was designed for language selector pages and works best with them.
• Same language, different regions count too. Google's own example is English content for the US, GB and Ireland, and it says it is usually best to mark such pages explicitly.

Two limits matter. Google does not use hreflang or the HTML lang attribute to detect a page's language, so annotations cannot rescue a page written in the wrong one. And the International Targeting report that used to list hreflang errors is deprecated, although Google says it will continue to support and use hreflang. The guide to checking hreflang in Search Console shows how to verify tags today.

From the words on it. Google says it uses the visible content of a page to determine its language, and does not use code-level information such as lang attributes, or the URL. So the page itself has to be unambiguous:

• One language per page, for content and navigation. Google advises against side-by-side translations.
• Translate more than the frame. Google warns that translating only the boilerplate while keeping the bulk of the content in one language makes a poor experience, a common result with user comments and reviews.
• Translate what searchers see before they click: titles, meta descriptions and the text in your structured data.

Keep the lang attribute correct anyway. Google does not read it for language, but browsers, screen readers and translation tools do.

Sending a visitor in Germany straight to your German pages feels like good service, and plenty of sites do it. This section explains why Google advises against it and what to do instead. In short: suggest the switch, never force it.

Google's guidance is to avoid automatically redirecting users from one language version of a site to another, because such redirects could prevent users and search engines from viewing all your versions. A crawler arriving from a US address with no language header would be sent to the same version every time, and visitors are not always who their location suggests: an English speaker living in Munich, or a colleague checking the French page.

• Link every page to its other language versions. Google suggests showing links on all pages so users can choose their region or language.
• If you can guess a visitor's language, show a banner offering the switch and let them decide.
• Point x-default at the page for visitors whose language you do not cover, such as a language picker.

Good enough that a native speaker would not stop to notice it. Search engines have said where the floor is:

• Translate the main content, not just the template. Google says localised versions of a page are only considered duplicates if the main content remains untranslated, so translated menus around an English article make a duplicate in a new frame.
• Make localised pages different where it matters. Bing's webmaster blog says localisation creates duplicate content when regional or language pages are nearly identical, and recommends meaningful changes such as terminology, examples, regulations or product details.
• Know where the spam line is. Google's spam policies do not ban machine translation. They list translating among the automated transformations used to turn scraped content into many pages where little value is provided. Translating your own useful pages is not that; translating other sites' pages to fill a new language is.

Machine translation, including AI models, makes a reasonable first draft. Have a fluent speaker review each template and a sample of every batch, and check that numbers, units, currencies, dates and product names survived the trip.

A programmatic set multiplies with every language: 2,000 pages in five languages are 10,000 URLs to crawl, index and keep current. Translate it the way you built it, with the template and the data handled separately; the guide to programmatic SEO covers the method itself.

• Translate the template once, by a person: headings, fixed sentences, conditional text and the rules that choose between them. Plurals and grammatical gender often need separate sentence variants, not swapped words.
• Localise the data: units, currencies, date formats, decimal separators, and values that differ by country, such as tax rules or availability.
• Check demand per language before you build. Searchers in another market may use a different pattern, or none. Search Console's Performance report breaks impressions down by country, so you can see where a set's searchers already are.
• Generate hreflang from the row ID, so every language version of a row lists all the others; for large sets, listing alternates in the sitemap keeps them in one place.
• Publish a language when its pages pass the original's checks, not when the translation job finishes.

Say you run a currency-conversion site with 1,500 pair pages and want Spanish and Portuguese versions. A template translated word for word produces convertir 1 dólares whenever the amount is one, and a decimal point where Brazilian readers expect a comma. A translator who fixes the template's plurals and number formats once corrects all 3,000 new pages at the same time.

AutoPSEO's content engine writes articles in your site's languages. You choose them from 27 in the settings; each article is translated and every translation is checked before it is published. The article and its translations are then delivered to your own site through a signed webhook, and your site stores and renders every language. The translation documentation lists the checks.