For an Indian site with English and Hindi versions, use hreflang to tell Google which URL serves which language: en (or en-IN if you really have India-specific English content) and hi, each page listing itself and every other version, plus an x-default if you have a language selector. Google's documentation says hreflang tags are ignored unless the pages point to each other, and that Google detects a page's language from its content, not from hreflang or the lang attribute. This guide gives the exact tag sets, a decision table and a QA checklist. Facts are as of 14 October 2026.
Key Takeaways
- Google treats the three hreflang methods (HTML tags, HTTP headers, XML sitemap) as equivalent. Pick one and use it everywhere.
- Every version must list itself and all alternates, and every alternate must point back. One-way tags are ignored.
- Use a language code on its own (
hi,ta,bn) unless you have genuinely different content for a country. For India-only sites, region codes usually add nothing. - Hinglish (Hindi written in Latin script) has no officially documented Google handling in the sources I opened; treat any
hi-Latnsetup as an experiment, not a recommendation. - Machine-translating your English pages in bulk is the biggest risk, because Google's spam policies list automated translation among scaled-content abuse patterns.
What hreflang does, and what it doesn't
Hreflang is an annotation that says "these URLs are alternates of one another, for these languages or regions." Google's guide, Tell Google about localized versions of your page, states that localized pages are only considered duplicates if the main content stays untranslated. It also states that Google does not use hreflang or the HTML lang attribute to detect the language of a page. Google uses its own algorithms.
So hreflang does not fix poor translation, and it is not a redirect. Search Engine Land's hreflang guide (last updated 27 November 2025) adds that Google reiterated in May 2025 that hreflang signals are treated as hints, so canonicals, site structure and indexing status can still change which version appears. Treat it as one signal among several.
The three methods, and which to pick
Google says the methods are equivalent from its perspective and using all three gives no benefit. Choose based on your stack.
| Method | Best for | Watch out for |
|---|---|---|
HTML <link rel="alternate" hreflang> in <head> | Small to mid-size sites, templated CMS | Tags must be in a well-formed head; scripts that inject them late can fail |
XML sitemap with xhtml:link | Large catalogues, many language versions | Sitemap can only list URLs under its own directory; keep it current |
HTTP Link header | PDFs and other non-HTML files | Headers lost at a CDN or cache |
All three share the same rules from the Google guide: fully qualified URLs with protocol, self-reference, and identical sets on every version. For PDFs such as prospectuses, the header method is the one that works; see my PDF SEO checklist if you publish brochures in Hindi and English.
Which codes to use for India
Google's format is an ISO 639-1 language code, optionally followed by an ISO 3166-1 Alpha 2 region code. A region alone is invalid; a language alone is fine. Unlisted codes such as es-419 are not supported.
Here is how I'd decide, based on those rules and the W3C's "golden rule" of keeping a language tag as short as possible (W3C guidance on choosing language tags):
| Situation | Suggested tags | Why |
|---|---|---|
| English and Hindi, India audience only | en, hi, x-default | Short tags; no region distinction needed |
| English with India-specific pricing, spelling or policies plus a global English site | en-IN, en (global), hi | The region code separates genuinely different English content |
| Hindi for India and Hindi for another market (for example the UAE diaspora) with different content | hi-IN, hi-AE | Region matters only when content differs |
| Tamil, Telugu, Bengali, Marathi etc. | ta, te, bn, mr | Language code alone is valid and sufficient |
| Hindi written in Latin script (Hinglish) | Not documented by Google in the sources I read | See the Hinglish section below |
A note on conflicting advice. One Indian agency guide I read (Upgrowth's "What is hreflang", published 13 March 2026) uses hi-in as its syntax example but bare hi with a /hi/ path in its blog example, without explaining when to choose which. It also claims a 25-40% visibility lift without citing data, so I'd not rely on that figure. The reasoning above is the one I'd use: bare hi unless there's a real regional content difference.
Copy-ready tag sets
Assume three versions of a course page: English, Hindi and Tamil.
<link rel="alternate" hreflang="en" href="https://example.in/courses/data-analytics" />
<link rel="alternate" hreflang="hi" href="https://example.in/hi/courses/data-analytics" />
<link rel="alternate" hreflang="ta" href="https://example.in/ta/courses/data-analytics" />
<link rel="alternate" hreflang="x-default" href="https://example.in/courses/data-analytics" />The identical block goes on all three pages. The page lists itself, which Google's guide requires.
For a sitemap, declare xmlns:xhtml="http://www.w3.org/1999/xhtml" and put the same xhtml:link children under each <url>. Google notes these child links do not count toward the sitemap URL limit.
x-default is the fallback for users whose language settings match none of your versions, and Google says it works best on language selector pages. It takes no language code.
Canonicals and hreflang must agree
This is where most Indian multilingual sites I look at go wrong. Google's guidance on consolidating duplicate URLs says that if you use hreflang you should specify a canonical page in the same language, and that Google prefers URLs inside a reciprocal hreflang cluster when choosing canonicals. It also says not to name different canonicals for the same page across methods, and to give each canonical page a self-referencing rel="canonical".
In practice: the Hindi page should canonical to itself, not to the English page. If you canonical Hindi to English, you are telling Google the Hindi page is a duplicate, which cancels the point of having it. Search Engine Land lists "canonical pointing to a non-matching locale" among the common errors.
URL structure for Hindi and regional versions
Google's multi-regional and multilingual site guide is clear that you should use separate URLs for each language rather than cookies or browser settings, and that you shouldn't automatically redirect users based on guessed language. It compares structures:
- Subdirectories (
/hi/,/ta/): easy and low maintenance, one server location. This is what I'd default to for most Indian edtech and D2C sites. - Subdomains (
hi.example.in): possible, but users may not tell whether the label means language or country. - ccTLDs: clearest geo signal, but costly and limited to one country. For India-only audiences, a
.indomain is already your country signal. - URL parameters (
?lang=hi): Google says not recommended.
Avoid IP-based adaptation. Google notes that IP location is unreliable and Googlebot mainly crawls from the US, so it may never see your Hindi version if you serve by IP.
The translation quality trap
Hreflang assumes there are genuinely different pages. If your Hindi pages are a lightly cleaned machine translation of English pages at scale, you're in risky territory. Google's spam policies list "automated transformations like synonymizing, translating, or other obfuscation techniques" among scaled content abuse patterns where little value is added, and list using generative AI to produce many pages without adding value as another example. Doorway abuse, creating pages to rank for specific similar queries that funnel users onward, is a separate policy.
My approach for a regional rollout:
- Start with the five to ten pages that already earn leads in English.
- Have a native speaker adapt, not just translate: local examples, fee amounts in rupees, local payment options.
- Keep unfinished languages out of the sitemap and out of hreflang until they're ready.
I wrote about auditing course sites for exactly these templated-page risks in my edtech SEO audit after the spam update.
Hinglish and mixed-script content
Many Indian users type Hindi in Latin script. The W3C guidance says a script subtag can mark transliterated text (its example is ru-Latn), so hi-Latn is structurally how you'd tag Romanised Hindi. But Google's hreflang page only documents script codes with Chinese examples (zh-Hans, zh-Hant) and says unlisted codes are unsupported. I didn't find Google documentation confirming hi-Latn behaviour in hreflang, so I'd not build a separate Hinglish URL tree on that assumption.
What I'd do instead:
- Write the Hindi page in Devanagari and the English page in English.
- Where Hinglish phrasing is how users actually search, include those terms naturally in headings and FAQs of the existing page.
- If you do test a separate Hinglish page, log it as an experiment, check indexing in Search Console, and don't put it into a cluster you rely on.
For context on how Google has approached Indian languages, a 2021 Infidigit report on Google for India says Search could translate results into Hindi, Kannada, Tamil, Telugu and Malayalam. That is historical and secondary reporting, not a reason to skip real localisation.
Regional languages: AI search and what's unproven
An agency article on regional-language AI search in India argues that regional citation pools are less crowded and that machine-translated content is deprioritised by AI citation systems. It links no sources for its figures or for those system-behaviour claims, so treat them as hypotheses. The safe reading is: native-quality pages in regional languages are worth testing because competition may be thinner, but I haven't seen evidence I'd quote for the size of the advantage.
An hreflang QA checklist
Run this before launch and after every template change.
- Every URL in a cluster returns 200 (no redirects, 404s or noindex).
- Every page includes a self-referencing tag.
- Every alternate points back (check both directions).
- All URLs are absolute and HTTPS; no HTTP alternates if HTTPS exists.
- Codes are valid:
en-GB, noten-UK; no region-only values; no reserved regions. - Canonical on each page points to itself in the same language.
- Only one method in use.
- Language selector links are crawlable
<a href>links. x-defaultpoints to a sensible fallback or selector.- Spot-check in Search Console's URL Inspection that Google selected the expected canonical.
Search Engine Land cites a study finding 31% of international sites had conflicting hreflang directives and 16% were missing self-referencing tags, which is why I audit even "finished" sites.
Rollout order I'd use for an Indian site
| Phase | What | Gate to move on |
|---|---|---|
| 1 | Audit English URLs; fix canonicals, status codes | Clean crawl |
| 2 | Ship Hindi for the top 10 revenue pages with adapted copy | Pages indexed, reviewed by a native speaker |
| 3 | Add hreflang (one method), selector and x-default | QA checklist passes |
| 4 | Add Tamil, Telugu, Bengali, etc. based on lead data | Same gate per language |
| 5 | Monitor indexation and queries by language folder | Monthly review |
Festive-season campaigns often drive regional pages; plan translations before peaks, as in my festive season SEO notes for India.
FAQ
Do I need hreflang if my site is only in English for India?
No. Hreflang is for pages that have alternate language or regional versions. A single English version for India doesn't need it. Add it when a second version exists.
Should I use hi or hi-IN?
Google accepts both. Because the W3C advises keeping tags as short as possible, I'd use hi unless you have separate Hindi content for another country and need to tell them apart.
Is en-IN better than en for an Indian site?
Only if you also have another English version (for example a global one) and the Indian one differs in pricing, policies or spelling. If there is just one English site, en is enough.
Does Google use hreflang or the lang attribute to detect language?
Google's documentation says it uses neither. It uses its own algorithms on the page's content, which is why you shouldn't leave main content untranslated on a localized page.
What does x-default do?
It marks the fallback page for users whose language settings match none of your versions. Google says it works best on language selector pages, and it takes no language code.
Can I put hreflang in HTML, sitemap and headers at once?
You can, but Google says the three are equivalent and using all gives no Search benefit. One method is easier to maintain and debug.
Will hreflang fix duplicate content between English and Hindi?
They aren't treated as duplicates if the Hindi main content is genuinely translated. Hreflang helps Google show the right version, but it doesn't replace good canonicals and real translation.
Can I auto-redirect Hindi speakers to the Hindi page?
Google recommends against automatic redirects based on guessed language preferences because they can keep users and crawlers from reaching all versions. Use visible links to alternates instead.
Does Bing use hreflang?
I haven't verified Bing's current treatment in this research, so check Bing Webmaster documentation directly before relying on hreflang there.
Work with me
I'm Younus Fardeen, an SEO and AEO strategist in India with 4+ years of marketing experience across edtech and startup projects. If you're planning an English, Hindi or regional-language rollout and want a second pair of eyes on structure and rollout order, see my work and send a note through the contact form at https://younusfardeen.in.
Sources opened for this guide on 14 October 2026: Google Search Central (localized versions, multi-regional sites, duplicate URL consolidation, spam policies), W3C Internationalization, Search Engine Land, and three secondary Indian agency or news pages as labelled.