You’ve launched simplified Chinese, traditional Chinese, and English versions — and Taiwanese users end up on the simplified pages while American users see the Chinese site. Almost all the classic multilingual-site problems trace back to hreflang.
hreflang has only three hard rules: bidirectional pairing, self-referencing every URL, and adding an x-default fallback. Miss any of the three and the whole annotation set gets ignored — configuring it becomes equivalent to not configuring it at all. Don’t verify by gut feeling after deployment; work through the errors one by one in Search Console’s international targeting report, and check the country breakdown of impressions within two weeks.
Three hard rules: pairing, self-reference, fallback
hreflang is a symmetric relationship. If page A declares B as its English version, B must also declare A as its Chinese version; a one-way declaration is judged unreliable and the whole set gets invalidated. The most foolproof approach is to have every page output the full version list, including the entry pointing to itself.
In terms of markup, output one link tag per language in the head — rel=”alternate”, hreflang with the language and region code, href with the full absolute URL. The self-referencing line cannot be skipped. Three versions mean three lines; with x-default that’s four lines, identical on every page.
Use ISO 639-1 for the language code and ISO 3166-1 Alpha-2 for the region code, joined with a hyphen. Writing just “en” instead of “en-US” or “en-GB” makes the search engine guess; for simplified vs. traditional, use zh-CN and zh-TW, not script codes like zh-Hans — they’re less reliable in compatibility.
- href must be an accessible absolute URL with protocol and domain — no relative paths.
- The page href points to must return 200, not a 301 redirect or 404.
- The annotated target page must not be blocked by robots or carry noindex.
Where should x-default actually point
x-default catches the traffic that doesn’t match any language version. A French user lands on your page, and you only have Chinese and English versions — they get sent to whatever x-default points to.
It can point to the international English page or a language selector page. Don’t point it at an auto-redirecting intermediary page, since the redirect makes crawlers loop between versions; and don’t let a regional page point x-default at itself, which creates a self-loop usually reported as “missing fallback page”.
For regions that don’t have a dedicated page yet, letting them fall back to x-default is fine. When multiple language versions are highly similar in content, each version should self-reference its canonical rather than pointing them all at the same URL — otherwise hreflang and canonical fight each other. To see how the two work together, check the canonical guide on avoiding duplicate-content dilution.
The four most common failure points and how to fix them
The problems below make up the vast majority of errors in the international targeting report. Checking against them one by one is far faster than blindly adding tags.
| Error symptom | Consequence | Fix |
|---|---|---|
| Only “en” written, no en-US / en-GB | Region can’t match precisely; assignment is a guess | Add region codes, split by target market |
| A points to B, B doesn’t point back to A | Entire annotation set ignored | Have every page output the full list and self-reference |
| Localized URL returns 404 or 301 | Report errors, weight leaks | Clean dead links and redirect chains first, then add annotations |
| hreflang target page carries noindex | Annotation conflicts with the index directive | Remove noindex or drop it from the list |
| Wrong language code used (e.g., cn, uk) | Annotation invalid, silently skipped | Change to valid combos like zh, en-GB |
The third type is especially common: you mass-replace URLs during a redesign while hreflang still points at old addresses. Run the dead-link and redirect-chain cleanup before launch.
How to choose among the three deployment locations
hreflang can live in three places; pick one. Mixing them only raises the odds of missing and conflicting configurations. Which one you choose depends mainly on site size and technical setup.
| Deployment location | Best for | Main drawback |
|---|---|---|
| link tags in HTML head | Mid-size sites with controllable templates | Head gets bloated with many versions |
| XML sitemap | Large sites with hundreds of language versions | Harder to debug; needs tooling to validate |
| HTTP response header | Non-HTML assets like PDFs, images | Requires server configuration access |
WordPress multilingual plugins usually output the head tags automatically, but after a theme switch or permalink change they easily fall out of sync — check the source before launch. If you deploy via sitemap, make sure the sitemap index file includes all language splits; the submission-path notes can be cross-checked with the robots.txt and sitemap configuration guide.
How to verify after launch
- Randomly pull 5 pages and inspect the source, confirming the version list is complete with self-reference and x-default.
- Run a full-site crawl and focus on whether all hreflang target pages return 200.
- Submit the corresponding-language sitemaps to trigger re-crawling.
- After two weeks, check whether the international targeting report errors are cleared, and split impressions by country/region in the performance report.
- Confirm the target market’s share of impressions is rising, rather than several versions fighting over the same users.
hreflang only takes effect after all versions are re-crawled and aligned, usually stabilizing in one to two weeks — don’t declare failure on day three. After adding a new language version, walk through the verification again; if the list changed, the old pages’ annotations need updating too.
When it comes to execution, the steps are clear: today open the Search Console international targeting report and group the existing errors by type; spot-check the source of 5 core pages to confirm pairing, self-reference, and x-default are all in place; this week run a full-site crawl and fix hreflang-pointed 404s and redirect chains; unify the deployment location to either head tags or sitemap, removing duplicate config; submit the updated sitemap and recheck error counts and per-country impression share after two weeks. hreflang looks fiddly, but it’s highly pattern-driven — hold the three hard rules and walk through the verification steps, and your multilingual site won’t embarrass you with “Taiwanese users seeing simplified Chinese, Americans seeing Chinese” anymore.
FAQ
Where should hreflang tags go?
Pick one of three: link tags in the HTML head, XML sitemap, or HTTP response header. Mid-size sites choose head, large sites use sitemap, PDF-like assets use the header — don’t mix.
Does hreflang need self-referencing?
Yes. Every page must include the entry pointing to its own URL in its version list, with bidirectional pairing and an x-default fallback — miss any and the whole set is ignored.
What if hreflang and canonical conflict?
When language versions are highly similar, each version self-references its canonical. Don’t point the versions in hreflang at the same URL, or the two signals fight and drag each other’s rankings down.
How long until hreflang takes effect?
You have to wait for all versions to be re-crawled and aligned, usually one to two weeks. Check whether the international targeting report errors clear after two weeks — don’t declare failure on day three.
Where should x-default point?
Point it at the page shown when no language matches — an international English page or a language selector. Don’t use an auto-redirecting intermediary, and don’t let a regional page point to itself and create a loop.
Figure: hreflang multilingual/multi-region deployment guide — key points (compiled by Operations GO)
