If you run a global brand site, you have almost certainly had this conversation: the Korean team reports that Korean users searching a Korean brand term land on the English page. Nothing is broken, exactly. The pages exist, they are indexed, they are not duplicates in any penalising sense. The search engine simply does not know they are versions of each other.
That is what hreflang is for, and it is one of the few technical SEO features where a small syntax mistake voids the entire declaration silently.
What hreflang does and does not do
hreflang tells a search engine: these URLs are the same content for different languages or regions; serve whichever fits the user.
It does not:
- Boost ranking. It swaps which URL is shown, not how highly it ranks.
- Prevent duplicate-content problems on its own —
canonicaldoes that. - Redirect anybody. It is a hint to the search engine, not to the browser.
So the realistic win is this: the page that ranks is the page in the user's language. For a brand site where the Korean and English pages compete for the same brand query, that alone can move Korean click-through rates substantially.
The three implementation options
You can declare the annotations in three places. Pick one and be consistent; mixing them is where inconsistencies creep in.
1. HTML <head> links — the most common, and the easiest to reason about:
<link rel="alternate" hreflang="en" href="https://example.com/en/products/x" />
<link rel="alternate" hreflang="ko" href="https://example.com/ko/products/x" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/products/x" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/products/x" />
2. XML sitemap annotations — best for large sites, because you edit one generator instead of every template. Covered in the sitemap guide.
3. HTTP Link headers — necessary for non-HTML documents such as PDFs.
The reciprocity rule, which is where most implementations fail
Every page in a language group must list every member of the group, including itself.
If /ko/pricing declares /en/pricing but /en/pricing does not declare /ko/pricing back, the annotation is one-directional and is discarded. Not partially honoured — discarded.
The self-referencing entry is equally non-negotiable. A set of three languages produces three <link> tags on each of the three pages, nine in total. Teams routinely ship two tags per page, omitting the self-reference, and then spend a quarter wondering why nothing changed.
Getting the language and region codes right
The value is language or language-region, using ISO 639-1 for language and ISO 3166-1 Alpha-2 for region.
| Intent | Correct | Common mistake |
|---|---|---|
| Korean, any region | ko |
kr (that is a country code, not a language) |
| Korean in Korea | ko-KR |
ko_KR (underscore), KO-kr |
| English, any region | en |
en-EN (no such region) |
| English in Singapore | en-SG |
en-SEA |
| Japanese | ja |
jp |
| Simplified Chinese | zh-Hans |
zh-CN is acceptable but script codes are safer |
ko and kr is the single most frequent error on Korean sites. kr is not a valid language code, and the entire annotation for that URL is thrown away.
Region codes narrow, they do not broaden: en-US targets English speakers in the United States. If you want all English speakers, use bare en. Declaring only en-US, en-GB and en-AU leaves English speakers in Korea with no match — which is exactly what x-default is for.
x-default
x-default marks the page to serve when no language or region matches. Use it for:
- A global English page acting as the default
- A language-selector landing page
- Any market you have not explicitly targeted
One x-default per group. Omitting it is not fatal, but it means unmatched users get whatever the search engine guesses.
Canonical and hreflang together
This pairing causes more damage than the codes do. The rules:
- Each language version canonicalises to itself, never to another language.
- The URLs in your
hreflangannotations must be the canonical URLs.
A Korean page that sets canonical to the English URL is telling the search engine "the English page is the real one, drop me" — and then the hreflang annotation pointing at the Korean page contradicts it. When those two signals disagree, canonical generally wins and the Korean page disappears from the index. It is a five-minute fix that costs months of traffic if nobody audits it.
Auditing an existing implementation
The checks, in order of how often they find something:
- Reciprocity. Crawl every page in the group, collect all annotations, and verify the graph is symmetric.
- Self-reference. Every page lists its own URL.
- Code validity. No
kr, noen-EN, no underscores, no invented regions. - Status codes. Every annotated URL returns 200. A
hreflangpointing at a redirect or a 404 is dead weight. - Canonical agreement. Each annotated URL is self-canonical.
- Absolute URLs. Relative hrefs are not valid here.
A crawl-based audit does this in one pass. DeepAnalyzer captures canonical and hreflang for every page it crawls, so the symmetry check is a diff on the exported inventory rather than manual spot-checking.
Site architecture: what comes before hreflang
hreflang can only describe a structure you already have. Decide the structure first:
| Structure | Example | Trade-off |
|---|---|---|
| ccTLD | example.kr |
Strongest geo signal, highest cost, authority split across domains |
| Subdomain | ko.example.com |
Easy to isolate infrastructure, weaker authority consolidation |
| Subdirectory | example.com/ko/ |
Authority stays on one domain — usually the best default |
| Parameter | example.com?lang=ko |
Avoid; unreliable and hard to canonicalise |
For most brand sites, subdirectories win: one domain accumulates authority, one certificate, one analytics property, and language becomes a path segment your IA already understands. See URL structure best practices for how to sequence the locale segment against the rest of the path.
FAQ
Do I need hreflang if my site is only in Korean?
No. hreflang describes relationships between language versions. With one version there is nothing to relate. Set <html lang="ko"> and move on.
Does hreflang improve rankings?
Not directly. It changes which version of a page is shown to a given user. The indirect effect — better language match, better click-through, lower bounce — can improve performance, but there is no ranking boost for the annotation itself.
What if the Korean and English pages are not exact translations?
That is fine. hreflang expects equivalent pages, not literal translations. A Korean pricing page with local currency and local payment methods is still the Korean version of the pricing page.
Can I use hreflang between different domains?
Yes. Annotations work across domains, which is why a example.kr / example.com split is viable. Both domains must declare the relationship reciprocally, and you need verified ownership of both in Search Console.
Where should I implement it — head tags or sitemap?
Head tags for sites under a few thousand pages, because they are easy to inspect in a browser. Sitemap annotations for large catalogues, because you maintain one generator instead of every template. Do not do both; two sources of truth drift.