Multilingual SEO

TL;DR — Multilingual SEO is optimizing a site that’s available in more than one language so the right version shows up for the right person. It’s about language, not country — that’s the first thing to get straight. You give each language its own URL, tell Google which URLs are versions of each other with hreflang, and let Google figure out the language from the actual text on the page.

Multilingual vs. multi-regional — get this straight first

These two get mixed up constantly, and the whole topic makes more sense once you separate them:

• Multilingual = your site serves more than one language. A Swiss site in German, French, and Italian is multilingual — three languages, one country.
• Multi-regional = your site targets users in more than one country. A site with separate US and UK English versions is multi-regional — one language, two regions.

Plenty of sites are both (think a global brand with English, Spanish, and French, each split by country). But the signals and the problems are different, so it helps to know which one you’re actually dealing with. This page is about the language side.

What “language targeting” actually means

When your site has the same page in several languages, you want Google to:

1. Know each language version exists.
2. Understand they’re versions of the same thing.
3. Show the German one to German searchers and the French one to French searchers.

You make that happen with a handful of signals — chiefly the hreflang attribute, which is a little tag that says “this URL is the Spanish version, that one’s the French version, here’s the relationship between them.” Google then tries to serve the matching one.

The part beginners are surprised by: Google figures out what language a page is in by reading the visible words on it — not from any setting in your code. So a page that says it’s German in the code but is full of English text will be treated as English. Write real content in the target language; that’s the signal that counts.

Where the different language versions live (URL structure)

You need a separate URL for each language. There are three common ways to do it:

• Subdirectory — example.com/es/, example.com/fr/. The usual pick for most sites: easy to set up, and all the versions share the strength of your one domain.
• Subdomain — es.example.com, fr.example.com. Works, but search engines treat it more like a separate site.
• Country-code domain (ccTLD) — example.es, example.fr. The strongest signal for targeting a country, but it’s a whole separate website to build authority for.

Avoid stuffing the language into a URL parameter like example.com?lang=es — Google specifically recommends against it.

When you actually need multilingual SEO (vs. just translating)

If you only translate the words and dump them on the same URL — or auto-redirect everyone by their location — you don’t really have multilingual SEO, and Google may never even find your other languages. You need the real thing (separate URLs + hreflang + content Google can crawl) once you’re genuinely serving multiple languages and want each one to rank. If you’ve only got one language, you can skip all of this.

Want the technical depth — how Google’s language algorithm works, the Bing differences, the common hreflang errors, and the 2025 auto-translation threat? Switch to the Advanced tab.

Multilingual SEO mistakes

Treating lang as Google’s language detector

Why it fails: Google determines language from visible page text rather than relying on the HTML attribute. Do instead: make the rendered main content consistently use the target language; retain correct metadata for accessibility and engines that use it.

Using hreflang to declare a page’s language

Why it fails: hreflang maps alternate URLs; it does not replace meaningful translated content. Do instead: publish a distinct crawlable URL with visible target-language content, then connect equivalent versions with reciprocal hreflang.

Forcing visitors through an automatic language redirect

Why it fails: crawlers and multilingual users can be trapped on the assumed version. Do instead: keep every version directly accessible and offer a visible suggestion plus crawlable language links.

Test yourself: Multilingual SEO

TL;DR — Get the mental model right and most multilingual SEO falls into place. Google does not read your <html lang> attribute or Content-Language HTTP header to detect language — it primarily uses visible text. Other engines may use different signals, so verify their current guidance. hreflang doesn’t declare a page’s language; it maps which URLs are alternates so Google can swap in the right one — and it’s a hint, not a directive. It’s also fiendishly error-prone: my study of 374,756 domains found 67% had hreflang issues. Use subdirectories for most sites, never auto-redirect Googlebot, and only translate pages with a real business case.

Multilingual ≠ multi-regional

The foundational distinction. Multilingual is about language; multi-regional is about country. A Swiss site in German, French, and Italian is multilingual but single-regional. A US/UK English site is multi-regional but single-language. They overlap all the time, but they use different signals and create different problems, so I keep them separate in my head and so should you. Google’s own framing: “A multilingual website is any website that offers content in more than one language,” versus “A multi-regional website is one that explicitly targets users in different countries.”

How Google actually detects page language (this is the big one)

Here is the single most-misunderstood thing in this whole topic, and it’s worth overstating because so many people get it wrong:

Google ignores your <html lang> attribute. Google ignores your Content-Language HTTP header. It reads the visible text.

Straight from the docs: “Google uses the visible content of your page to determine its language. We don’t use any code-level language information such as lang attributes, or the URL.” And on the hreflang page: “Google doesn’t use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language.”

On Search Off the Record (July 2024), Gary Illyes gave this a name: LDCP — Language Demotion, Country Promotion. His explanation: “if someone is searching in German and your page is in English, then you would get a demotion.” That’s a ranking mechanism, and it’s more fundamental than hreflang — if your page isn’t genuinely in the searcher’s language, LDCP demotes it regardless of what your tags say. (Illyes also signaled this kind of manual signaling is on the way out, noting Google already had systems “automatically learning” to pair alternate-language versions — auto-detection is the direction of travel.)

Why does Google distrust <html lang> so much? Because it’s wrong constantly. Gary told the Joomla story: the CMS “came with the Lang attribute set to English, and there was no way to override it… And then you looked at the page, and it was 100% German. So it was like you can’t trust that.” John Mueller has said the same — the HTML lang attribute is “something we don’t use at all” and “almost always wrong. So we tend to ignore that.”

The takeaway: language detection is a content problem, not a markup problem. Write real content in the target language. The lang attribute still matters for accessibility (screen readers) and for Bing — just not for Google’s language detection.

Bing does it the opposite way

Bing does not support hreflang. And where Google ignores your code-level language hints, Bing depends on them. Bing’s priority order:

1. <meta http-equiv="content-language" content="en-us"> — the primary signal.
2. <html lang=""> attribute — secondary.
3. On-page text content.

Bing’s format is a 2-letter ISO 639 language code, a dash, then an ISO 3166 geography code (en-us, es-mx). So a properly internationalized site running on both engines wants distinct-URL content plus hreflang (for Google/Yandex) plus the content-language meta tag (for Bing). They’re not redundant; they feed different engines.

What hreflang actually does (and doesn’t)

hreflang is a relationship map, not a language detector. It doesn’t tell Google the language of a page — Google already gets that from content. It tells Google which URLs are alternates of each other and for which language-region audience, so Google can swap in the right one per searcher. Google: “Use hreflang to tell Google about the variations of your content, so that we can understand that these pages are localized variations of the same content.”

Three things have to be right or the cluster is ignored:

• Bidirectional. “If two pages don’t both point to each other, the tags will be ignored.” English points to Italian, Italian must point back.
• Self-referencing. Each page lists itself plus all the others.
• x-default as a fallback for unmatched languages (recommended, not strictly required).

Three delivery methods: HTML <link> tags in the <head>, the HTTP Link header (useful for non-HTML files like PDFs), or an XML sitemap with the xhtml:link namespace. URLs must be fully qualified including https://.

And critically: hreflang is a hint, not a directive. Google’s own line is that “hreflang annotations are a hint to Google, not a directive.” It can and will override you when canonical tags, content signals, or indexation status disagree.

The valuable, under-covered angle: hreflang speeds indexing of new languages

Here’s a benefit almost nobody talks about. On the same SOTR episode, Gary Illyes said discovering hreflang triggers a verification crawl of the alternates: “There is a dependency crawl triggering when we discover Hreflang, like we want to verify that.” In plain terms — when Google finds hreflang on a page, it goes and crawls the alternate-language versions to verify the relationship, which speeds up indexing of your new language pages. So hreflang isn’t only about serving the right version; it’s a discovery accelerant for newly launched languages.

Why your GSC hreflang data looks thin (and that’s normal)

Another Illyes point worth internalizing: “Search Console only reports canonicals… the vast majority of the Hreflang clusters… are not canonical.” Most hreflang alternates aren’t canonical URLs, so they don’t show up individually in GSC’s coverage reporting. If your dashboards make it look like your language pages “aren’t indexed,” that’s often just GSC reporting canonicals — not a real problem. Verify with the URL Inspection tool and live SERPs rather than trusting the aggregate count.

Duplicate content: es-MX vs. es-ES

A common fear is that two Spanish variants will be flagged as duplicates. Google’s actual rule: “Localized versions of a page are only considered duplicates if the main content of the page remains untranslated.” Two genuinely-Spanish pages with real regional differences (currency, vocabulary, local references) are distinct. But two es-ES and es-MX URLs with identical text and no regional differentiation will be treated as duplicates — hreflang alone doesn’t separate them; distinct regional content does. Within a valid hreflang cluster, signals can also consolidate across the alternates, which is generally helpful.

URL structure, internal linking, and language detection

Structure. Subdirectories (/es/, /fr/) for most sites — they inherit root domain authority and are low-maintenance. Subdomains get treated more like separate sites. ccTLDs are the strongest country geotargeting signal but mean separate properties and separate link-building. URL parameters are explicitly “not recommended.”

Internal linking between versions. Link language versions to each other sensibly (the language switcher is part of this), but don’t treat every alternate as a primary nav link. Let hreflang carry the formal relationship; let the switcher serve users.

Language detection UX — and the crawlability trap. This is where sites quietly break themselves. Googlebot “sends HTTP requests without setting Accept-Language in the request header” and crawls mostly from US IPs (though it does use some non-US IPs too). If you auto-redirect users to a language version based on IP or Accept-Language, Googlebot may only ever see your English version and never discover the rest. Google’s blunt instruction: “Avoid automatically redirecting users from one language version of a site to a different language version.”

Do this instead: serve distinct URLs, annotate with hreflang, and if you want to help users, show a non-intrusive nudge banner (“This page is available in English — switch?”) that keeps them on their current URL and remembers their choice via cookie or localStorage. Use Accept-Language as a suggestion, never a redirect trigger. And don’t use flags as language identifiers — flags are countries, not languages.

Translation quality and machine translation

Machine translation itself isn’t banned. Google’s own definition: “Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users.” Jump to quote Translation is named as one example of an automated transformation covered by that policy — “including through automated transformations like synonymizing, translating, or other obfuscation techniques,” specifically “where little value is provided to users.” Jump to quote The judgment is value, not production method. Raw MT dumped at scale with no editorial oversight is the real risk; MT with human review and curation (a workflow often called MTPE) is a standard, scalable way to stay clear of it. Judge a translated page the way you’d judge any page — does it serve real search intent for that market — and don’t just translate your English keywords: do real keyword research per language, because intent and phrasing differ market to market. (More depth: machine translation and SEO.)

Schema for multilingual sites

Use the inLanguage property on your Article/Product/FAQPage schema to state the content’s language, and give each language version its own schema block in that language. Schema and hreflang do different jobs: hreflang maps alternate URLs; schema clarifies content meaning and language. They’re complementary layers.

The error rate: my 374,756-domain study

I ran a study across 374,756 domains using hreflang. The headline: over 67% had issues. The breakdown, most common first: missing x-default (56.3%), missing self-referencing tags (18%), broken/redirected references (16.9%), missing reciprocal tags (15.3%), non-canonical references (8%), wrong ISO codes (4.6%), inconsistent HTML lang vs. hreflang (3.2%), duplicate language entries (2.5%), and the same page declared for multiple languages (2.5%).

Two caveats keep this from being doom. First, the top two — x-default and self-referencing — are recommended, not strictly required, so the real-severity picture is softer than 67% suggests. Second, Google fixes a lot of this for you. Gary Illyes has said hreflang errors “didn’t cause problems” in his implementation era, and my own long-standing position (from my Enterprise SEO Chaos SMX talk) is that it may not be worth your time chasing every hreflang error because Google is probably correcting many of them automatically. But the structural errors — missing reciprocal links, broken URLs — do break the cluster and should be fixed. Triage: fix structural, monitor behavioral.

The 2025 threat: Google’s translate.goog proxy

A newer wrinkle worth knowing about (Motoko Hunt’s June 2025 Search Engine Land piece): when Google determines there’s no high-quality, local-language content available, it auto-translates content via a translate.goog proxy. The browser matters — Chrome users get routed to the publisher’s original URL (traffic preserved), but Safari/Firefox users go through translate.goog (traffic lost). Ahrefs data put this at 6.2 million AI Overview appearances with translated URLs and hundreds of millions of clicks of exposure. The strategic read: publishing native local-language content is both the defense (Google won’t proxy-translate what you already provide) and the offense (you rank for those markets yourself). Treat auto-translated SERPs as a signal of unmet demand.

Mueller’s caution: don’t translate everything

Finally, restraint. John Mueller warns against the all-languages reflex — “Let’s create all languages! Let’s make pages for all countries! What if someone in Japan wants to read it in Swahili?” — and notes “it’s easy to dig into endless pits of complexity with hreflang.” His advice, which I echo: “first… limit the number of pages you create to those that are absolutely critical & valuable.” Prioritize high-traffic, high-conversion pages in markets with demonstrated demand (use GSC to find queries already pulling impressions in a target language). Every language version you create is crawl, indexation, canonicalization, and maintenance overhead — only spend it where there’s a real return.

AI summary

A condensed take on the Advanced version:

• Multilingual ≠ multi-regional. Multilingual is about language (Swiss site in 3 languages, 1 country); multi-regional is about country (US/UK English). They overlap but use different signals.
• Google detects language from visible text — not <html lang>, not the Content-Language header, not the URL. Gary Illyes named the ranking mechanism LDCP (Language Demotion, Country Promotion): wrong-language pages get demoted.
• Bing is the opposite: it doesn’t support hreflang and uses <meta http-equiv="content-language"> as its primary signal (priority: content-language meta > html lang > content).
• hreflang is a relationship map, not a language detector, and it’s a hint, not a directive. Must be bidirectional + self-referencing; x-default recommended.
• Bonus benefit: discovering hreflang triggers a verification crawl, speeding indexing of new language pages (Illyes). Most alternates aren’t canonical, so GSC under-reports them — that’s normal.
• es-MX vs es-ES are only duplicates if the main content is untranslated; genuine regional differences separate them.
• URL structure: subdirectories for most sites; ccTLDs strongest for country targeting; avoid URL parameters. Never auto-redirect by IP/Accept-Language — Googlebot crawls without Accept-Language and mostly from US IPs, so it may miss your other languages.
• Machine translation isn’t banned. Google’s scaled-content-abuse policy names translation as one example of an “automated transformation,” but the violation is publishing many low-value pages to manipulate rankings — the judgment is value, not method. Raw MT dumped at scale with no editorial oversight is the real risk; MT with human review (MTPE) is a standard, scalable workflow.
• Error rate: my study of 374,756 domains found 67% had hreflang issues, but Google auto-corrects many — fix structural errors, monitor the rest.
• 2025 threat: Google’s translate.goog proxy can hijack traffic where native content is missing; native local content is both defense and offense.

Official documentation

Primary-source documentation from the search engines.

Google

• Managing Multi-Regional and Multilingual Sites — the foundational doc: definitions, URL structure options, locale signals, the auto-redirect warning.
• Localized Versions of your Pages — the hreflang reference: the three implementation methods, bidirectionality, self-referencing, x-default, and the duplicate-content rule.
• International SEO Overview — the entry point for language/country/region optimization.
• How Google Crawls Locale-Adaptive Pages — why serving different content by perceived locale risks crawl/index gaps, and the Accept-Language note.

Bing / Microsoft

• How To Tell Bing Your Website’s Country and Language — the content-language meta tag, its format, and the priority order Bing uses (still the primary technical reference).
• Bing Webmaster Guidelines — the general guidelines, including language/country targeting.

Quotes from the source

On-the-record statements from Google and Bing on multilingual SEO.

Google — how language is detected

• “Google uses the visible content of your page to determine its language. We don’t use any code-level language information such as lang attributes, or the URL.” — Google Search Central docs. Jump to quote
• “Google doesn’t use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language.” Jump to quote

Google — hreflang and duplicates

• “Use hreflang to tell Google about the variations of your content, so that we can understand that these pages are localized variations of the same content.” Jump to quote
• “If two pages don’t both point to each other, the tags will be ignored.” Jump to quote
• “Localized versions of a page are only considered duplicates if the main content of the page remains untranslated.” Jump to quote

Google — redirects and definitions

• “Avoid automatically redirecting users from one language version of a site to a different language version.” Jump to quote
• “A multilingual website is any website that offers content in more than one language.” Jump to quote

Gary Illyes, Google (Search Off the Record, “Internationalization & hreflang,” July 25, 2024)

• On the LDCP algorithm: “if someone is searching in German and your page is in English, then you would get a demotion.”
• On why HTML lang is unreliable: “[Joomla] came with the Lang attribute set to English, and there was no way to override it… And then you looked at the page, and it was 100% German. So it was like you can’t trust that.”
• On hreflang triggering a verification crawl: “There is a dependency crawl triggering when we discover Hreflang, like we want to verify that.”
• On GSC reporting: “Search Console only reports canonicals… the vast majority of the Hreflang clusters… are not canonical.” Listen to the episode

John Mueller, Google

• On the HTML lang attribute: “the language attribute within the HTML markup is something we don’t use at all” and “almost always wrong. So we tend to ignore that.”
• On over-creating languages: “It’s easy to dig into endless pits of complexity with hreflang.” / “My recommendation would be first to limit the number of pages you create to those that are absolutely critical & valuable.”

The decision frameworks

1. Do you need multilingual or multi-regional? (or both)

Run this before anything else — it determines which signals you reach for:

Are you serving more than one LANGUAGE?
├─ No  → not a multilingual problem. Stop here for language work.
└─ Yes → multilingual. You need: distinct URLs per language
         + hreflang (Google/Yandex) + content-language meta (Bing)
         + real content in each language.

Are you also targeting more than one COUNTRY?
├─ No  → single-region multilingual (e.g. Swiss DE/FR/IT).
│        Use language-only hreflang codes (es, fr, de).
└─ Yes → multi-regional too. Add region to hreflang (es-MX, es-ES,
         en-GB, en-US) and consider ccTLDs for the strongest
         country signal.

The trap: treating language as a country signal. As Gary Illyes put it, “the language is absolutely not a tell for what country you are targeting.”

2. URL structure comparison

3. Content priority matrix — what to translate first

Don’t translate everything. Score candidate pages and work top-down:

Priority = (organic demand in target market)
         × (conversion value of the page)
         ÷ (translation + maintenance effort)

Practical order:

1. Proven-demand pages — use GSC to find URLs already getting impressions/clicks from a target-language query or country. Demand is already there; capture it.
2. High-traffic / high-conversion core pages — money pages and top cluster hubs.
3. Supporting cluster pages — once the core market is validated.
4. Long-tail — last, and only if the market is paying off.

Mueller’s rule sits on top of all of it: “limit the number of pages you create to those that are absolutely critical & valuable.” Every extra language version is ongoing crawl, indexation, and maintenance cost — spend it where there’s return.

Language signals — what each engine actually uses

The one table to bookmark. Google and Bing read almost opposite signals.

Bing priority order: content-language meta tag > <html lang> > page content.

Google in one line: it reads the visible text to detect language; everything code-level (lang, Content-Language, URL) is ignored for that purpose.

hreflang non-negotiables: bidirectional, self-referencing, fully-qualified URLs with https://, x-default recommended. Hint, not directive.

Don’t: auto-redirect by IP/Accept-Language (Googlebot crawls without Accept-Language, mostly from US IPs — it’ll miss your other languages); use flags for languages; dump raw, unreviewed machine translation at scale with no editorial value-add.

Multilingual SEO

Multilingual SEO is the practice of optimizing a website that serves content in more than one language so each language version is discoverable, indexable, and rankable in the right language's search results. It's about language, not geography — which makes it distinct from multi-regional SEO.

Related: International SEO, Hreflang, Localization

Multilingual SEO

Multilingual SEO is what you do when one website serves content in more than one language and you want each language version to show up in the right searcher’s results. The core problem is linguistic — getting Google and Bing to detect, connect, and serve the correct language — which is different from multi-regional SEO, where the core problem is geographic (targeting users in specific countries). The two often overlap, but they’re not the same thing, and conflating them is where a lot of international SEO goes wrong.

The primary technical tool is the hreflang attribute, which tells Google (and Yandex) that a set of URLs are language-and-region variants of the same content so it can swap in the right one per searcher. Crucially, hreflang doesn’t detect a page’s language — Google reads the visible content for that — it just maps the relationships between alternates. Bing doesn’t support hreflang at all; it uses a content-language meta tag instead.

Beyond the tags, multilingual SEO is a set of decisions: which URL structure to use (subdirectory, subdomain, or ccTLD), how to handle language detection without breaking crawlability, how good your translations need to be to avoid being flagged as auto-generated, and which pages are even worth translating in the first place.

Related: International SEO, Hreflang, Localization

Changelog