A bilingual site is one of the highest-leverage organic moves available to a B2B company, every page you publish can work two query markets, and in most languages other than English the competition for any given topic is a fraction as deep. It's also one of the easiest things to wire wrong. Done correctly, hreflang tells search engines these two pages are the same content for different audiences, and each version ranks in its market. Done wrong, the two versions compete with each other, get treated as duplicates, or serve the wrong language to the wrong user, and your authority splits instead of doubling. The mechanics are fully learnable; here they are.
Hreflang fundamentals, done correctly
Hreflang is an annotation, not a directive: it tells search engines that a set of URLs are language or regional alternates of one another, so the right version can be shown for the right user. The rules that make it actually work: every page in the set lists every alternate including itself (the self-reference is required, not optional); every annotation must be reciprocated, if the English page points to the German page but the German page doesn't point back, the pair is ignored; codes are ISO 639-1 for language, optionally plus ISO 3166-1 for region (de or de-DE, and note en-UK is invalid, it's en-GB); and one x-default entry names the fallback version for users matching no listed language. You can implement it in the HTML head, in HTTP headers, or in the XML sitemap, pick exactly one method sitewide, because two methods disagreeing is worse than either alone.
| Annotation | Points to | Why it's there |
|---|---|---|
| hreflang="en" | https://example.com/en/pricing | The English alternate, present on both versions |
| hreflang="de" | https://example.com/de/preise | The German alternate, present on both versions |
| hreflang="x-default" | https://example.com/en/pricing | The fallback for users matching neither, typically your primary market's version |
The canonical interplay, where most implementations break
Hreflang and rel=canonical answer different questions, which version for which user versus which URL is the real one, and they must not contradict each other. The iron rule: every URL referenced in an hreflang set must be indexable and self-canonical. The classic bug is canonicalizing the German page to the English one on the theory that they're 'the same content': that tells the engine the German URL isn't real, so its hreflang annotations are discarded, and German users get English results. The second classic: hreflang entries pointing at URLs that redirect, are noindexed, or return errors, each of those silently voids the annotation for that pair. Translated pages are alternates, not duplicates; each language version canonicalizes to itself, always.
Translate or write natively? The decision that outranks the markup
Hreflang gets each version into the right market's results; it does nothing to make that version worth ranking. For long-tail informational pages, a high-quality translation with light localization is usually fine and scales well. But in competitive categories, the queries with real commercial weight, natively written content wins, because searchers in different languages don't just use different words, they ask different questions, compare against different competitors, operate under different regulations, and respond to different examples. A translated page answers the source market's questions in the target market's words. The practical split: translate the library's long tail, natively write (or natively rework after translation) the pillar pages, comparison pages and anything targeting a competitive head term, with a native-speaking editor owning quality either way. Machine translation published raw, at scale, without review sits inside scaled-content territory and reads as foreign to the users it's meant to convert.
URL architecture: subdirectory, subdomain or ccTLD
Where the second language lives shapes how authority accumulates. Subdirectories (example.com/de/) keep every language on one domain, so links and authority pool together, one property to maintain, one domain to build, which is why they're the default recommendation for bilingual B2B sites. Subdomains (de.example.com) are treated more separately by search engines in practice; the second language builds authority more independently, which is usually a cost, not a benefit, for a company that isn't operationally split. ccTLDs (example.de) send the strongest country signal and may matter for local trust in some markets, but each domain starts from zero authority and doubles the technical estate. Unless there's a legal or strong brand reason, a bilingual company consolidates: subdirectories, one domain, hreflang wiring the pairs together.
| Architecture | Authority | Effort | When it's right |
|---|---|---|---|
| Subdirectory (example.com/de/) | Pools on one domain, both languages benefit | Lowest, one property | The default for bilingual B2B, pick this absent a specific reason not to |
| Subdomain (de.example.com) | Largely builds separately | Medium, near-separate site | Genuinely separate teams, infrastructure or product per language |
| ccTLD (example.de) | Starts from zero per domain | Highest, full separate estate | Country-level legal or brand requirements that justify the cost |
The common hreflang bugs, a field checklist
- Missing return links, A annotates B but B doesn't annotate A, so the pair is silently dropped. Audit reciprocity with a crawler, not by eye.
- No self-reference, each page must include itself in its own hreflang set.
- Hreflang pointing to redirected, noindexed or 404 URLs, every target must be a live, indexable, self-canonical page.
- Canonical contradicting hreflang, a language version canonicalized to another language voids its annotations.
- Invalid codes, en-UK instead of en-GB, language-region pairs that don't exist, or country codes used without a language.
- Mixed implementation methods, head links saying one thing while the sitemap says another.
- Auto-redirecting users by IP or browser language instead of letting the annotated version rank, this also blinds crawlers, which mostly crawl from one region. Suggest the switch with a banner; don't force it.
- Forgetting new pages, hreflang decays as content ships in one language first. Make the annotation part of the publish checklist, and audit quarterly.
How multilingual signals play in AI answer engines
AI answer engines assemble citations per language: a German question is answered predominantly from German-language sources, retrieved from a pool that is, in most B2B categories, dramatically shallower than the English one. That changes the strategy from a compliance exercise into an offensive one. The English half of your site might be fighting hundreds of established competitors for citation; the same content in German, French or Turkish may be competing against a handful, so the second language is often your fastest route to being the cited default in a category. The playbook carries over directly: clean extractable structure, clear headings, direct answers, consistent entity naming in both languages, and native quality on the pages that matter, an awkward translation is as unconvincing to an answer engine's quality filters as it is to a human reader.
