← All resources

SEO architecture for multilingual B2B websites, done properly.

Hreflang is two lines of markup and the single most common thing multilingual sites get wrong. Here is the architecture that actually holds up, and what Google’s own documentation says versus what most agency advice assumes.

Most multilingual SEO problems are not translation problems. They are architecture decisions made once, early, by whoever set up the CMS — and never revisited once the site has grown to ten languages, three regions and a legal team in every market asking for its own version of the same five pages. Google’s own documentation on hreflang and international structure is shorter and more permissive than most advice online suggests: it does not prefer one URL structure over another, and it is explicit about what actually breaks. This is that documentation, applied to a B2B site with real buying committees spread across languages, not a consumer storefront.

The four URL structures, compared

StructureExampleGoogle’s stancePick it when
ccTLDexample.deThe strongest automatic geotargeting signal, and the most infrastructure to runYou already run separate legal entities or hosting per market
Subdomainde.example.comWorks, but is often treated as a semi-separate site, which can split authorityDNS or hosting forces the separation and you accept the trade-off
Subdirectoryexample.com/de/No ranking penalty, and every page inherits the domain’s existing authorityThe default choice for most multilingual B2B sites
URL parametersexample.com?lang=deGoogle’s own documentation calls this "not recommended"Never as a deliberate choice — only ever inherited from an old CMS

Google states plainly that none of these structures carries a ranking advantage over the others — the decision is cost, hosting and maintenance, not SEO. What is not optional is telling Google about the variants at all, through hreflang, sitemaps or explicit links.

Hreflang: the two rules that break everything else

Two requirements cause almost every hreflang failure. First, the return-tag rule: if page A points to page B as its German alternate, page B must point back to page A, or Google discards the whole annotation. This is trivial on ten pages and routinely broken past a few hundred, once new language pages get added without regenerating every existing page’s tag list. Second, valid codes only — a language code from ISO 639-1, optionally paired with a region from ISO 3166-1 Alpha-2, and never a bare region code on its own. "EU", "UK" and "UN" are common, plausible-looking mistakes that Google’s documentation calls out by name; the code has to name a language first.

The x-default value, aimed at visitors whose language does not match any variant, does not need a language code of its own — it just needs a URL, typically a language-selector page or a sensible fallback like the English or primary-market version. And every page in the cluster needs to list itself among its own hreflang tags, self-referencing, which is the detail teams most often skip because it looks redundant. It is also worth being direct about what hreflang is not: Google’s documentation describes it purely as a serving signal, pointing the right visitor to the right variant. It is not, on its own, a ranking signal.

Pick one implementation, not three

Hreflang can be declared three ways — link tags in the HTML head, an HTTP header on the response, or annotations inside the XML sitemap — and Google is unusually direct about how to choose: the three methods are equivalent from its perspective, and while you can use all three at once there is no benefit in Search, only the difficulty of managing three implementations instead of one. Pick the one your stack can generate reliably from a single source of truth. On a large site the sitemap method is often the pragmatic answer, because it keeps the entire cluster in one generated file rather than scattered across every template.

The one case where the choice is made for you is non-HTML content. A PDF has no head to put a link tag in, so language variants of a document — a spec sheet, a datasheet, a localised contract template, all common on B2B sites — have to be declared through the HTTP header method or not at all. It is the single most frequently missed part of a multilingual B2B setup, precisely because the documents are usually published by a different team than the one that owns the CMS templates.

Duplicate content across languages is not the risk people think it is

Content that says the same thing in German and in English is not duplicate content in any sense that costs rankings — Google treats each language as its own audience and indexes each version on its own terms. The real duplicate-content risk in multilingual B2B sits somewhere less obvious: near-identical pages in the same language for different regions. An en-GB page and an en-US page that differ only in currency and one paragraph of legal text genuinely do compete with each other for the same query, in the same index, in a way an English and a German page never will.

The fix is either to consolidate — one English page with a canonical, rather than three near-duplicates — or to make the regional difference real: distinct pricing, distinct case studies, distinct compliance language, not just a currency symbol swapped in a template. And wherever hreflang and canonical exist on the same page, they need to agree — a canonical pointing at a different URL than the one hreflang has already declared as authoritative for that language is a contradiction Google has to resolve on your behalf, and it does not always resolve it the way you would pick.

What is actually different about B2B buyers here

A B2B buying decision is rarely one person, and it is rarely conducted entirely in one language even inside a single company — Gartner’s research on the B2B buying journey finds six to ten stakeholders typically shaping a single purchase, each independently gathering information before anyone talks to a supplier, and spending only around 17% of the total buying journey in meetings with vendors at all. A procurement lead researching in their working language, a technical evaluator reading documentation in English regardless of market, and a regional decision-maker who wants the page in their own language are frequently three different people inside the same deal — and all three need the site to hold up in whichever language they land in.

This is also where a purely mechanical translation shows. A page that is grammatically correct but reads as obviously translated undermines exactly the credibility a technical buyer is evaluating you on. CSA Research’s global consumer study found 76% of respondents prefer buying where information is presented in their own language, and that businesses are, if anything, more sensitive to this than individual consumers — because a B2B buyer is also implicitly judging whether your organisation can support their local team after the contract is signed, and thin, obviously-machine-translated pages are a visible answer to that question before anyone asks it directly.

Automatic redirects by location are the quiet killer

The most damaging thing a multilingual site can do is also the thing that feels most helpful: detecting a visitor’s IP address or browser language and redirecting them to "their" version automatically. Google’s guidance on multi-regional sites is explicit — avoid automatically redirecting users from one language version of a site to a different one, because it could prevent users and search engines from viewing all the versions of your site. A crawler that is always redirected away from a URL cannot index the page that URL was supposed to serve, which is a slow, invisible way to remove entire language trees from search results.

The sanctioned pattern is a suggestion rather than a decision: serve the requested URL, and offer a dismissible banner or a clearly visible language selector pointing at the alternate. It also matches how B2B buyers actually behave — a German procurement lead who has been sent a link to the English technical page usually wants that page, not a redirect to a German homepage that discards the context the link carried. Keep the choice reversible, keep every URL directly reachable, and let hreflang and x-default do the serving work they were designed for.

Where multilingual B2B sites actually lose rankings

Beyond broken hreflang, the recurring failures are structural rather than linguistic. A sitemap that only lists the default-language URLs, so newly added language variants never get discovered on their own. Structured data left unlocalised — an inLanguage field that says "en" on every page regardless of which language it actually is, which quietly weakens the exact machine-readable signal that is supposed to help. Machine-translated content published with no human review, which reads acceptably to a skim but fails the scrutiny a genuine buyer or a quality-focused crawler both apply.

And, less obviously: currency, date formats and legal disclaimers that stay in the source market’s convention across every locale, because a template built once for the home market gets copied rather than genuinely adapted. None of these are ranking penalties in the algorithmic sense. All of them are trust signals a careful buyer — human or automated — reads as evidence the "localised" version was translated, not built.

How we scope this in practice

A Multilingual Website engagement starts with the structural decisions in this guide — subdirectory versus subdomain, the hreflang map, sitemap and canonical strategy — before a single page gets translated, because retrofitting the architecture after content exists in five languages is a materially bigger job than deciding it up front.

If you are adding languages to a site that already ranks well in its original market, a Technical Audit is the right starting point rather than jumping straight to translation — it tells you what the existing architecture will and will not support before you commit content to it. And once the structure is right, SEO Starter work — titles, meta, internal linking, schema — needs doing per locale, not once and copied, for the same reason a template copied without adaptation reads as thin.

Sources

The hreflang rules, URL-structure guidance and buyer-behaviour figures above come from these, checked August 2026.

  • Google Search Central — Tell Google about localized versions of your page

    The return-tag requirement, valid ISO 639-1/3166-1 code formats, x-default usage, the self-referencing rule, and hreflang described explicitly as a serving signal rather than a ranking one. Also the three equivalent implementation methods (HTML tags, HTTP headers, sitemap), Google’s note that using all three brings no benefit in Search, and the HTTP header method as the option for non-HTML files such as PDFs.

  • Google Search Central — Managing multi-regional and multilingual sites

    The four URL-structure options (ccTLD, subdomain, subdirectory, URL parameters — the last one explicitly "not recommended"), with no structure claimed to carry a ranking advantage over the others. Also the instruction to avoid automatically redirecting users between language versions, because it can prevent users and search engines from viewing all versions of the site.

  • CSA Research — Consumers prefer their own language

    Global survey of 8,709 consumers across 29 countries: 76% prefer buying where information is in their own language, and 40% say they would never buy from a site in another language.

  • Gartner — The B2B Buying Journey

    B2B buying groups typically involve six to ten stakeholders, each researching independently, and spend roughly 17% of the total buying journey in meetings with potential suppliers.

Frequently asked questions

Expanding into new markets and not sure the current site can carry it?

We will audit the existing architecture and tell you exactly what needs to change before you add another language.