Give each language its own URL, keep them in subdirectories, and validate your hreflang
If you run a site in two or three languages, the structure that works for multilingual SEO is specific: serve each language on its own crawlable URL, keep those URLs in subdirectories of one domain, and annotate every page with hreflang that references itself plus every language sibling. Google's documentation on multi-regional and multilingual sites lays out the same shape. The part most teams get wrong is not the setup. It is that their hreflang is quietly broken and doing nothing.
This post covers the four decisions that carry the most weight for a bilingual or trilingual site, in order of leverage. For the wider picture of ranking across India's language markets, start with the pillar on SEO in India, which this article expands on.
Rule 1: one distinct URL per language, never a cookie or auto-redirect
Google needs a separate, indexable URL for each language version of a page. Do not swap content based on a browser cookie, an Accept-Language header, or the visitor's IP while keeping the same URL. Googlebot crawls primarily from US IP addresses with Accept-Language unset, so if your Hindi content only appears after an IP or header check, Google never sees it. Google's locale-adaptive pages guidance says the same thing: it does not recommend serving different content on the same URL by locale.
The same applies to automatic redirects. If a visitor in Chennai lands on your English URL and you force-redirect them to the Tamil version, you have blocked Googlebot from crawling the English page it arrived on. Offer a visible language switcher instead, and let both the reader and the crawler choose.
Rule 2: subdirectories beat subdomains and ccTLDs for a single business
You have three URL patterns for language variants:
| Structure | Example | Best for |
|---|---|---|
| Subdirectory | example.com/hi/, example.com/ta/ | A single business consolidating authority (recommended default) |
| Subdomain | hi.example.com | Separate infrastructure or teams per language |
| ccTLD | example.in, example.fr | Distinct legal entities or strong per-country targeting |
For a two- or three-language site run by one company, use subdirectories. The reason is authority consolidation. Every internal link, backlink, and ranking signal accrues to one domain instead of being split across separate hosts. Google treats subdomains and ccTLDs as more separate, so you rebuild authority from near zero on each one. ccTLDs also cost more, need their own hosting decisions, and require you to register and defend each country domain.
Language codes in your paths should follow ISO 639-1 (hi for Hindi, ta for Tamil, bn for Bengali). If you target a language-region pair, add the ISO 3166-1 region code: en-in for English served in India. Keep it lowercase and consistent across the whole site.
Rule 3: hreflang, and the self-plus-all-others rule
Hreflang tells Google that two URLs are the same content in different languages, so it can serve the right one and avoid treating them as duplicates. Per Google's guide to localized versions of your pages, every page in a language cluster must list:
- A self-referencing tag pointing to its own URL
- One tag for each of the other language versions
- One x-default tag for a fallback page (usually a language selector or your primary language)
All URLs must be fully qualified, with the https and the domain. Relative URLs are ignored. For a bilingual English and Hindi page, the English page carries all three of these, and so does the Hindi page. That reciprocity is the rule people miss.
Placed in the HTML head, a two-language pair carries three alternate link tags: one hreflang="en-in" pointing to the English URL, one hreflang="hi-in" pointing to the Hindi URL, and one hreflang="x-default" pointing to the English URL as the fallback. Every one of the paired pages repeats all three.
You can deliver the same annotations via HTTP headers (useful for PDFs) or an XML sitemap (cleanest for large sites, because you edit one file instead of every page's head). Pick one method and do not mix them for the same set of URLs.
The x-default value deserves attention. It names the page to show when no language variant matches the reader's preference. On a bilingual site, point it at your language-neutral entry page or your primary-language page. Search Engine Land's guide to hreflang covers how to choose an x-default target.
Rule 4: validate, because broken hreflang is the real failure mode
Here is the insight that changes where you spend your time. The common problem is not missing hreflang. It is broken hreflang. In a 2017 analysis of 19,044 domains, Ahrefs found that 67% of sites using hreflang had at least one error, with missing return tags and no self-referencing tag among the most frequent. Both faults silently disable the annotation.
Hreflang is reciprocal. If page A points to page B but page B does not point back to page A, Google discards the entire relationship, as its own documentation confirms: if two pages do not both point to each other, the tags are ignored. One missing return tag can invalidate a whole cluster, and you get no error message. The tags simply stop counting. That is why adding more tags is lower leverage than confirming the ones you have actually reciprocate.
Your validation checklist:
- Every page references itself with the correct language code
- Every alternate points back (A to B and B to A, for all pairs)
- All URLs are absolute and return 200, not 301 or 404
- Language and region codes are valid ISO values, not invented ones like en-uk
- Exactly one x-default per cluster
- No page appears in two clusters with conflicting codes
Crawl your own site and check the hreflang cluster on every localized URL. A site audit that flags missing return tags and non-200 alternates catches these before they cost you rankings. Recrawl after any URL change, because a migration that renames paths breaks every hreflang reference at once.
The machine-translation trap
Do not run Google Translate over your English pages and publish the raw output as your Hindi or Bengali site. Google treats unedited, auto-generated translation as low-quality content and can suppress it, and low quality on one language version can drag down the others. Its guidance on creating helpful content is the standard your translated pages are measured against.
Machine translation is fine as a first draft. What matters is that a fluent speaker edits it for accuracy, tone, and the actual search terms people use, which are rarely literal translations. In Hindi and other Indian-language markets, readers often search in Roman script rather than the native script, so your keyword research has to account for both. Our notes on transliteration and SEO and on ranking with Hindi SEO show how that plays out. If you are expanding into southern markets, Tamil SEO and Telugu SEO cover the script and query-behavior differences that generic advice ignores. Voice queries add another layer, since spoken Indian-language search rarely matches typed keywords; the piece on voice search SEO in India goes deeper.
How Google decides what language a page is in
Google determines a page's language from the visible content, not from code-level hints. The lang attribute in your HTML and your hreflang tags help Google serve the right version, but they do not override what the on-page text says. So the practical order is: write genuinely localized content, mark it with the correct lang attribute, then add hreflang to connect the versions. Do not mix two languages heavily on one page, and do not lean on tags to compensate for thin or auto-translated text.
Keyword research for each language should be done in that language against local search volume, not translated from your English list. A tool with per-language and city-level SERP data, like DeployFlare's keyword research, shows what people in a specific market actually type, which is the input every other decision on this page depends on. DeployFlare starts at ₹499/month, billed in INR with UPI and GST.
Putting it together for a bilingual site
For a typical English-plus-one-Indian-language site:
- Serve each language in a subdirectory on one domain (example.com/ and example.com/hi/)
- Give every page a distinct, crawlable URL with no cookie or IP swapping
- Add self-referencing, reciprocal hreflang plus one x-default, all absolute URLs
- Validate the hreflang clusters and recrawl after any structural change
- Have a human editor localize the content and the keyword research, never ship raw machine translation
Do these five and your structure is sound. The ongoing work is validation and content quality, not tag volume. For more on ranking in India's language markets, the SEO in India pillar ties this technical structure to the regional strategy, and regional language SEO covers markets beyond the big two or three.