Key takeaways
- Google determines a page's language from its visible content and does not use the HTML lang attribute or the URL for this.
- In hreflang, each language version must list itself and all other versions, and links must be reciprocal or Google ignores them.
- Google's hreflang supports only ISO 639-1 language codes and ISO 3166-1 Alpha 2 region codes, so a code such as es-419 cannot be used.
- Keywords must be researched in each market, because people do not search with literal translations of English terms.
- Titles, meta descriptions, URL slugs, alt text and internal anchor text all need localising for search.
This guide is for marketers and SEO specialists who already have, or are about to launch, a website in more than one language. It explains how Google handles language versions, how to implement hreflang without the usual errors, and what needs localising for search beyond the body text.
Planning the multilingual site itself, from choosing markets to testing forms, is covered in our guide to website localisation. Here we focus on visibility in search.
How does Google decide which language a page is in?
Google decides the language of a page by reading its visible content, not by checking code-level signals. Its guidance on multilingual sites states: "Google uses the visible content of your page to determine its language." It adds: "We don't use any code-level language information such as lang attributes, or the URL."
This has two practical consequences. First, a page that mixes languages sends a confused signal, so each version should be fully in one language. Second, the lang attribute is still worth adding for browsers and accessibility, but it will not fix a page whose content is half-translated.
Why does each language need its own keyword research?
Each language needs its own keyword research because people in different markets describe the same need in different words. A literal translation of your English keyword is often not what local users type.
Spanish is a clear example. A laptop shop targeting Spain would research terms around "ordenador portátil", while one targeting Mexico would research "computadora portátil" or "laptop". Search volumes, competition and intent also vary by country, so a keyword that matters in the UK may be minor elsewhere. Our article on Spanish for Spain vs Latin America shows how far vocabulary can differ within one language.
Ask native-speaking translators or local SEO specialists to research keywords before translating page titles, headings and URLs, not afterwards.
What is hreflang and how do you implement it?
Hreflang is an annotation that tells search engines which pages are language or regional versions of each other, so the right version is shown to each user. Google's documentation on localised versions of pages describes three ways to add it: HTML link elements in the page head, HTTP headers (useful for PDFs and other non-HTML files), or entries in an XML sitemap.
Whichever method you choose, the same rules apply:
- Self-reference: "Each language version must list itself as well as all other language versions."
- Reciprocal links: "If two pages don't both point to each other, the tags will be ignored."
- Valid codes: "Only language codes listed in ISO 639-1 and region codes listed in ISO 3166-1 Alpha 2 are supported." Use "de" for German, or "de-AT" for German in Austria.
- A fallback: "The reserved x-default value is used when no other language/region matches the user's browser setting."
The code rule catches many multilingual sites. Latin American Spanish is often labelled es-419 in software, but 419 is a three-digit UN M.49 region code (W3C: Language tags), not an ISO 3166-1 Alpha 2 country code. For Google's hreflang, use "es" for all Spanish speakers, or country codes such as "es-MX" and "es-AR".
Hreflang checklist before you publish
Most hreflang problems can be caught with a short checklist. Run it on every template before launch:
- Every page in a cluster lists every version, including itself.
- Every URL in the annotations returns a 200 status, not a redirect or error.
- Every URL matches the canonical URL of the page it points to.
- Language codes use ISO 639-1, and any region codes use ISO 3166-1 Alpha 2.
- An x-default points to a language selector or your main international version.
- Only one method is used per page set, to avoid conflicting annotations.
- New pages are added to all versions' annotations when they are published.
Which URL structure is best for multilingual SEO?
Any of Google's three recommended structures can rank: country-code domains, subdomains or subdirectories. Google advises against URL parameters such as ?loc=de, and it recommends a separate URL for each language version rather than switching content by cookie or browser setting.
The trade-offs between cost, maintenance and geotargeting are compared in our website localisation guide. For SEO, consistency matters more than the choice: keep the pattern the same across all languages.
What should be localised for search beyond the body text?
Search engines and users read much more than the body copy, so every visible and semi-visible element should be localised. Check each of these on every page:
- Title tags and meta descriptions, written to local keyword research and length limits;
- Headings, which should reflect how local users phrase their questions;
- URL slugs, translated where your platform supports it;
- Image alt text and file names;
- Internal link anchor text and navigation labels;
- Structured data text fields such as names and descriptions;
- Local proof, such as prices in local currency, local contact details and relevant examples.
Avoid translating only the template. Google warns that "Translating only the boilerplate text of your pages while keeping the bulk of your content in a single language" creates a poor experience for users who see the same content with different boilerplate in search.
Can machine-translated pages rank in other languages?
Machine-translated pages can be indexed, but publishing them in bulk without human review risks breaching Google's spam policies and rarely earns rankings or trust. Google's spam policies define scaled content abuse to include generating many pages from other content "including through automated transformations like synonymizing, translating, or other obfuscation techniques", where little value is provided to users.
A safer approach is to use human translation for high-value pages and, where volume demands it, machine translation followed by full post-editing by a native speaker. See machine translation post-editing explained for how that workflow works.
Common multilingual SEO mistakes
These mistakes appear again and again in multilingual site audits:
- Hreflang that points one way only, so Google ignores it.
- Invalid codes, such as "en-UK" instead of "en-GB", or "es-419".
- Automatic IP redirects that stop search engines from crawling other versions.
- Canonical tags on every language version pointing to the English page.
- Keywords translated rather than researched, so pages target terms nobody uses.
- Untranslated titles and meta descriptions on translated pages.
The same principles apply to store pages for games and apps; see our mobile app localisation guide and our guide to video game localisation.
How TranslationWorks can help with multilingual SEO
TranslationWorks is a UK-based translation agency that translates website content, titles, meta descriptions and other search metadata into 150+ languages, using native-speaking linguists. Our translation services cover full pages and templates, and our transcreation service adapts headlines and calls to action so they read naturally and reflect how people search in each market.
We are ISO 17100 certified, ISO 9001 and ISO 27001 registered and Cyber Essentials certified. Send us your page list, target keywords and languages, and we will reply with a free multilingual content quote within 24 hours.


