Hreflang Tags for Indian Language Sites: The Setup Rules

The return-link rule, the Indian pattern, and what hreflang is not.

What hreflang actually does — and what it does not

Hreflang is an annotation that says "this URL is the same page as that URL, in a different language or for a different region". Google uses it to serve the version that fits the searcher.

That is the whole job. It sits in the same family of crawl-and-index signals as the rest of our technical SEO pillar — useful, specific, and narrower than people assume.

Google's own documentation frames it that way: the point is to "tell Google about these different variations" so Search can point users to the most appropriate version by language or region (Tell Google about localized versions of your page, last updated 21 September 2026).

Three things it is not, stated plainly, because getting this wrong is why so many Indian sites implement it for the wrong reason:

• It is not a ranking boost. Neither of Google's international documents lists hreflang as a ranking factor. The multi-regional guide names it as one of the locale signals Google relies on to work out who a page is for (Managing multi-regional and multilingual sites, last updated 10 December 2025) — and the same page warns that geotargeting "can improve your page rankings in the target country, but at the expense of results in other locales or languages". Better targeting, not more authority.
• It is not a duplicate-content fix. The localized-versions doc is explicit that localized versions are only treated as duplicates if the main content of the page remains untranslated. Properly translated pages were never the duplicate problem; hreflang does not rescue the ones that are.
• It is not a directive. Google processes it as an annotation it can ignore — most obviously when the links are not reciprocal, which we come to below.

The Indian case: one country, many languages

Almost every hreflang article you will read is built around a multi-country setup: en-US, en-GB, en-AU, one site per market. Copy that pattern onto an Indian site and you will write the wrong codes.

The common Indian situation is the opposite shape. One market — India — and several languages inside it. A Hindi page and an English page serving the same customers in the same country.

That is hi-IN and en-IN. Two language versions for one region, not two country sites. The region half of the code is identical; only the language half changes.

Why it matters practically: if you treat it as country targeting you start reaching for separate ccTLDs, separate properties and separate geotargeting — infrastructure for a problem you do not have. And if you write hreflang="IN" because "the market is India", the annotation is invalid. Google's guideline is blunt about it: you cannot specify the country code by itself.

A language code on its own is allowed, and often the better choice. If your Hindi page is for Hindi speakers wherever they are, hi is enough. Use hi-IN only when you genuinely also have, or plan, a Hindi version for a different region.

Which Indian languages you can actually use

Google supports only language codes listed in ISO 639-1 and region codes listed in ISO 3166-1 Alpha 2. That constraint matters more in India than anywhere else, because several widely spoken Indian languages have no two-letter code at all.

The codes below are taken from the Library of Congress ISO 639-2 registry, which carries the ISO 639-1 column (ISO 639-2 code list, codes last updated 15 January 2026).

Checked in the same registry and carrying no ISO 639-1 code: Maithili, Konkani, Manipuri, Santali, Dogri, Bhojpuri and Awadhi. There is nothing valid to put in the attribute for those, so the annotation is not available to you — publish the pages, link them internally, and let Google's own language detection do the work.

One naming note: the registry still labels the language "Oriya" rather than "Odia", but the code is or either way.

The three implementation methods — pick one

Google documents three ways to declare the set, and says they are equivalent from its perspective: HTML link elements in the <head>, an HTTP Link header, or annotations in your XML sitemap.

You can use all three at once. There is no benefit in Search for doing so, and three implementations to keep in sync is how sets drift out of agreement. Choose one and keep it.

HTML method, for an EMI calculator page in English, Hindi and Marathi. The identical block goes in the <head> of all three URLs:

<link rel="alternate" hreflang="en-IN" href="https://example.in/emi/" />
<link rel="alternate" hreflang="hi-IN" href="https://example.in/hi/emi/" />
<link rel="alternate" hreflang="mr-IN" href="https://example.in/mr/emi/" />
<link rel="alternate" hreflang="x-default" href="https://example.in/emi/" />

Sitemap method, same set. Every URL gets its own <url> entry listing all the variants, including itself — see how to structure an XML sitemap for the rest of the file:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.in/emi/</loc>
    <xhtml:link rel="alternate" hreflang="en-IN"
                href="https://example.in/emi/"/>
    <xhtml:link rel="alternate" hreflang="hi-IN"
                href="https://example.in/hi/emi/"/>
  </url>
</urlset>

HTTP header method, for a rate card published as a PDF. Note the angle brackets around each URL — Google's spec requires them:

Link: <https://example.in/rates.pdf>; rel="alternate"; hreflang="en-IN",
      <https://example.in/hi/rates.pdf>; rel="alternate"; hreflang="hi-IN"

Whichever you pick, every URL in the set must be fully qualified, protocol included. Google rejects //example.in/foo and /foo; it wants https://example.in/foo.

Return links: every page links to every page, including itself

This is the single commonest failure, and it is worth stating in full. Each language version must list itself as well as all other language versions. The self-reference is not optional padding — it is part of the rule.

And the links have to be mutual. Google's guideline: if two pages do not both point to each other, the tags will be ignored. The reason it gives is sensible — otherwise anyone could add a tag on their own site naming themselves as an alternative version of your page.

So in a three-language set, each of the three URLs carries four annotations: one for each of the three versions, plus x-default. The block is identical on all three. If you find yourself writing a different block per page, something has gone wrong.

Google does allow a pragmatic shortcut: if a complete bidirectional set becomes unmaintainable, you can omit some languages on some pages, and it will still process the pairs that do point at each other. It adds that newly added language pages should at minimum be linked bidirectionally to your original or dominant language. Treat that as a fallback, not a plan.

x-default: what it is actually for

The reserved x-default value is used when no other language or region matches the user's browser setting. It is the "none of the above" entry in your set.

Google documents it as designed for language selector pages, and its guidelines suggest a fallback for unmatched languages especially on language or country selectors and auto-redirecting home pages. You can point it at any page, including one of your specific versions.

What it is not: a way to say "this is my main page". A set without x-default is still valid. If you have no selector and no auto-redirect, pointing it at your widest-reach version — usually the English one on an Indian site — is a reasonable default rather than a requirement.

Hreflang and canonical tags, in one sentence

Every language version should canonicalise to itself, never to another language's URL — because a cross-language canonical tells Google the translated URL should not be indexed, which leaves the hreflang set pointing at pages Google has dropped.

Google's canonicalisation doc backs this up from both ends: it says to specify a canonical page in the same language, that rel="canonical" annotations carrying hreflang, lang, media or type attributes are not used for canonicalisation at all, and that Google prefers URLs that are part of hreflang clusters when choosing a canonical (How to specify a canonical URL, last updated 10 July 2026). If canonicals are the part you are least sure about, read our canonical tags guide before you touch hreflang.

Every rule, the mistake it invites, and the fix

One table to check an implementation against. If you are auditing someone else's work, start here.

The three errors behind most broken implementations

1. A set that is not reciprocal. Usually because the self-reference was dropped, or because a new language was added to the template on the new pages only. The annotation silently stops counting — nothing breaks visibly.
2. Codes that are not in the standard. A region code on its own, a reserved code like UK, or a language with no ISO 639-1 entry. Google ignores the part it cannot parse.
3. URLs in the set that Google cannot index. An alternate that 404s, redirects, carries a noindex, or canonicalises somewhere else. Google's canonicalisation doc specifically says not to include the HTTP version of your pages in your sitemap or hreflang annotations — a classic leftover after a migration.

All three are crawl-level problems, which is why we fold hreflang checks into the same pass as redirects and indexation rather than treating it as a separate project. The broader checklist sits in our technical SEO post, and the implementation itself is part of how we scope SEO services for multilingual sites.

How to check whether yours is working

Be realistic about Search Console here. It no longer reports on this. The International Targeting report has been deprecated, and Google's help page says country targeting for search results is no longer supported because it was judged to have little value for the ecosystem (The International Targeting report is deprecated — no last-updated date is printed on that page; read 8 October 2026). It names no replacement tool and confirms hreflang itself is still supported.

What you can still do inside Search Console:

• URL Inspection → View crawled page. The tool's help page does not mention hreflang, but it does give you the raw HTML Google fetched — which is how you confirm the link elements survived your template, your cache and any JavaScript.
• URL Inspection → canonicals. It reports the user-declared and the Google-selected canonical. If the Hindi URL's Google-selected canonical is the English URL, your hreflang has nothing to serve.
• Performance report → Countries and Queries. Both are dimension tabs. Useful for the outcome question — are Hindi queries landing on the Hindi URL — not for validating markup.

(Both Search Console Help pages above carry no printed last-updated date; read 8 October 2026.)

For the markup itself, crawl your own site and assert three things: every URL in a set returns 200, every set is reciprocal, and every set includes the self-reference. That is a crawler's job, not a dashboard's.

What we ask before we agree to implement it

Before we write a single annotation, we ask one question: show us the Hindi page you want us to point at — who wrote it, who owns it, and what changed on it in the last six months?

The answer that means the client should not implement hreflang: "it was run through a translation plugin when the site launched, and nobody has touched it since."

Hreflang is a pointer. If it points at a page nobody maintains, all you have done is make an unmaintained page easier for Google to serve to the people most likely to notice. A machine-translated page with no owner is a liability, and the annotation does not fix the quality problem underneath it — it advertises it.

When that is the answer, the honest sequence is: fix or retire the translation first, then annotate. Hreflang is worth implementing only when you genuinely have equivalent, maintained pages in each language.

When not to bother

• A single-language site. No alternate versions, nothing to annotate. A self-referencing hreflang on a one-language site does nothing.
• Pages that differ only by a city name. "Dentist in Pune" and "Dentist in Nagpur" are not language or region variants of one page — they are different pages. Hreflang is the wrong tool; that is a content and internal linking question.
• Translations you cannot maintain. Covered above. Publish them unannotated, or not at all.
• A language with no ISO 639-1 code. There is no valid value to write.

Where to go from here

The payoff is correctness rather than growth: the right version in front of the right searcher. If the languages are not the issue and the underlying pages are, that is a planning problem before it is a markup problem — start with how to build an SEO strategy and come back to the annotation when the content set is real.