Hreflang tells Google which language or region version of a page to serve, it does not help you rank
Hreflang is an HTML attribute that tells Google which of your localized URLs to serve to a given user, based on their language and, optionally, their region. If you run one page in English and an equivalent page in Hindi, hreflang is what stops the wrong one from appearing in the wrong search result. That is the whole job. It swaps which of your already-indexed URLs shows to the right person. It is not a ranking signal, and it will not lift a page that is not already competitive.
This matters because most guides oversell it. Hreflang is a duplicate-content and user-experience tool for multi-locale sites, not a growth lever. If you expect it to move rankings, you will be disappointed. If you use it to stop your Tamil page from cannibalizing your English page in Google's eyes, and to serve each audience its own language, it does exactly that. It sits in the same layer as your technical SEO fundamentals: plumbing that either works silently or breaks in ways that are hard to diagnose.
When you actually need hreflang (and when you don't)
You need hreflang if you have the same or closely equivalent content in multiple languages, or the same language aimed at different regions (say, en-IN pricing pages in rupees versus en-US pricing pages in dollars). You do not need it for a single-language site, even one that gets international traffic. A blog written only in English does not need hreflang just because readers in different countries visit it.
Per Google Search Central's guidance on localized versions, the three cases hreflang covers are: fully translated content, largely similar content with regional variations (currency, shipping), and boilerplate templates with translated main content. If your pages are genuinely different content, hreflang is the wrong tool.
The mistake that breaks most implementations: it must be bidirectional and self-referencing
Here is the rule that sinks most broken setups. Every hreflang annotation must be reciprocal and self-referencing. If page A lists page B as its Hindi alternate, then page B must list page A as its English alternate. Google's own documentation is blunt about this: if two pages don't both point to each other, the tags are ignored, and the entire cluster is discarded. On top of that, every page must list itself among its own alternates.
So a two-page English/Hindi cluster needs three lines on each page: one pointing to the English URL, one to the Hindi URL, and the self-reference. Both pages carry the identical block.
A correct block on the English page looks like this:
- link rel alternate hreflang en-US href https://example.com/en/pricing
- link rel alternate hreflang hi-IN href https://example.com/hi/pricing
- link rel alternate hreflang x-default href https://example.com/en/pricing
The Hindi page carries the same three lines, unchanged. Miss the return link or the self-reference and the whole thing silently fails. Google Search Console's International Targeting report is where you catch this. It flags "no return tags" errors specifically, and that report is the fastest way to audit a live cluster.
Getting the language and region codes right
Codes follow BCP 47. You have two valid formats:
- Language only: en, hi, ta, mr
- Language plus region: en-GB, en-IN, hi-IN, ta-IN
You cannot target a country alone. This is the single most common code error. There is no such thing as hreflang="UK" or hreflang="en-UK". The United Kingdom's region code is GB, so it is en-GB. Country by itself is invalid because hreflang's primary axis is language, with region as an optional refinement.
| What you want | Correct code | Common wrong version |
|---|---|---|
| English, United Kingdom | en-GB | en-UK |
| English, India | en-IN | en-india |
| Hindi, India | hi-IN | hindi |
| Tamil, India | ta-IN | ta-tamil |
| Any English speaker | en | en-ALL |
Use language-region only when the region genuinely matters. If your English content is identical for every English speaker, use plain en and do not fragment it into en-US, en-GB, en-IN clones that dilute your own annotations.
x-default: the fallback for everyone else
x-default is the page Google serves when no other hreflang entry matches the user's language and region. Someone browsing in Japanese with a French locale hits none of your en, hi, or ta entries, so they get your x-default. Most sites point x-default at their global English homepage or a language-selector page. It is optional but strongly recommended, because without it Google guesses, and its guess is worse than your explicit choice.
Hreflang vs canonical: keep them consistent or lose the cluster
This is where implementations quietly self-destruct. Hreflang and canonical tags must agree. A localized page's canonical must point to itself, never to another locale. Google's guide to consolidating duplicate URLs is explicit: when you use hreflang, specify a canonical page in the same language, because Google prefers URLs that are part of an hreflang cluster for canonicalization.
The failure pattern: the Hindi page sets its canonical to the English URL because someone decided English was "the original." Now you are telling Google two contradictory things. Hreflang says "these are equal alternates, serve the right one," and canonical says "the Hindi page is a duplicate, index the English one instead." Canonical wins that fight. Google drops the Hindi page from the index and your hreflang cluster collapses.
Rule: on the Hindi page, canonical points to the Hindi URL. On the English page, canonical points to the English URL. Hreflang handles the relationship between them; canonical only ever confirms the page is its own master copy. If you are shaky on this, our guide to crawling and indexing covers how Google chooses which URL to index.
Where to put hreflang: HTML head, HTTP header, or sitemap
Three delivery methods, and you pick exactly one per set of URLs. Never mix them for the same pages.
- HTML head. Link elements in the head of every page. Simple, but every page carries the full annotation set, so a 20-locale site means 20-plus lines on every page. Heavy at scale.
- HTTP header. For non-HTML files like PDFs, where there is no head to hold the tags.
- XML sitemap. The cleanest option at scale. You declare all alternates inside each URL entry using xhtml:link markup, keeping your HTML lean and centralizing hreflang in one file.
For large multi-locale sites, the sitemap method wins because you edit one file instead of head markup across thousands of pages. It pairs with the discipline in our XML sitemap guide. If your pages render alternates through client-side scripts, confirm Google sees them in the raw HTML. See JavaScript SEO for why injected hreflang is risky.
Common hreflang errors and how to catch them
The recurring failures, in rough order of frequency:
- No return tags. A points to B, B does not point back. Cluster discarded. Fix the reciprocity.
- Missing self-reference. Every page must list itself. Easy to forget in templated setups.
- Invalid codes. en-UK, country-only codes, typos like en_US with an underscore instead of a hyphen.
- Canonical conflict. Cross-locale canonicals overriding hreflang, covered above.
- URLs that redirect or 404. Every hreflang target must be a live, indexable, 200-status URL. Pointing at a redirect breaks the annotation.
- Mixed delivery methods. Some pages in the head, the same pages also in the sitemap, with conflicting data.
The International Targeting report in Search Console surfaces most of these. A full technical SEO audit should include an hreflang pass whenever a site has more than one language or region. This is a validation problem, not a rendering-speed problem, so it will not show up in Core Web Vitals or page speed work. You have to check it explicitly.
The India angle: multi-language SERPs are where hreflang earns its keep
Hreflang pays off most where a single country genuinely runs multiple languages in search. India is the clearest example. A user in Chennai may search in Tamil, a user in Pune in Marathi, a user in Delhi in Hindi, all within the same market, and Google serves language-specific results for each. If you publish the same product page in English, Hindi, Tamil, and Marathi, hreflang is what makes sure the Marathi searcher gets the Marathi page and not the English one.
This is where vernacular rank tracking matters. You cannot verify hreflang is working unless you track how each language version ranks in its own SERP. Our rank tracking supports city-level and vernacular queries across Hindi, Tamil, Marathi and more, so you can confirm the Tamil page ranks in Tamil results and the Hindi page in Hindi results. That is the check that closes the loop on any hreflang deployment. Pair it with a site audit that flags broken return tags and canonical conflicts before they cost you the cluster.
Set hreflang up once, correctly: reciprocal self-referencing annotations, valid BCP 47 codes, an x-default fallback, and canonicals that point to self. Then verify with the International Targeting report and vernacular rank tracking. Done right, it is invisible plumbing that puts the right page in front of the right reader.