Regional-Language AI Search in India: What Actually Changed
India was the first country outside the United States to get Google's AI Mode. It arrived in Search Labs on 24 June 2025 and went generally available two weeks later, on 8 July — in English only. Hindi followed that September. Search Live reached India that October, again ahead of every other market. And by March 2026 Google had extended it to Bengali, Gujarati, Kannada, Malayalam, Marathi, Odia, Tamil, Telugu and Urdu alongside English and Hindi.
Eleven languages, voice-native, camera-aware. Meanwhile the overwhelming majority of Indian business websites — including, almost certainly, your competitors' — are still English-only.
Key takeaways
- Search Live now answers in eleven Indian languages. Your site probably speaks one.
- Machine-translating into nine languages is the wrong move and will cost you more than it earns.
- Buyers code-switch inside a single session — English typed, Hindi spoken, transliterated in between. That is one behaviour, not three audiences.
- Pick the one language your buyers actually use, and do it properly. Depth in one beats thin coverage in nine.
The gap nobody is pricing in
India has well over 900 million internet users, and only a minority prefer to read and buy in English. That statistic has been quoted at conferences for a decade without changing much, because for most of that decade it did not matter commercially: search returned links, links went to English pages, and a Gujarati-speaking buyer simply put up with it.
What changed is that an assistant answering in Gujarati needs something in Gujarati to answer from. It cannot cite a page that does not exist. When the answer layer speaks the user's language and your content does not, you are not ranking lower — you are absent from the response entirely, and there is no page two to be found on.
This is the first time vernacular content has had a mechanical advantage rather than a sentimental one.
Why we tell most clients not to translate everything
The obvious response to eleven languages is to run the site through machine translation and publish nine copies. We advise against it, consistently, and it is worth being clear why.
A machine-translated page is a thin page. It carries no new information, reads as stilted to a native speaker, and produces a large volume of near-duplicate content whose only differentiator is the language tag. Search engines have been reasonably good at spotting that for years. Assistants, which are selecting a passage to quote rather than a page to list, are worse places still to be caught with unnatural phrasing — the whole point is to be quotable.
There is also a support cost that nobody budgets for. Publish in Marathi and you have implied you can handle a Marathi enquiry. If the phone gets answered in English, you have converted a visitor into a bad experience rather than a customer.
People do not stay in one language
The most useful thing to understand about Indian search behaviour is that it is not neatly segmented. The same person will type a query in English, speak the follow-up in Hindi, and use a transliterated Roman-script spelling somewhere in between. A pharmacy buyer types "chemist near me" and then asks aloud, in Hindi, whether the shop stocks a particular medicine.
Treating that as three separate audiences produces three half-built content sets. It is one behaviour, and it means your English pages need to survive being asked about in another language — which is less about translation than about being unambiguous. Product names, place names, service names and units should be stated plainly and consistently, because those are the anchors a model uses when it bridges between languages.
What actually changes technically
Assuming you have picked a language and are producing real content in it, the implementation is not exotic:
- Declare the language properly.
langon the html element, andhreflanglinking the language versions of a page to each other and back to the default. Get the return links right; one-directional hreflang is the most common way this is broken. - Put the language in your schema.
inLanguageon Article and WebPage nodes. It is a small field that removes an inference a machine would otherwise have to make. - Use the native script. Devanagari for Hindi and Marathi, Gujarati script for Gujarati. Transliterated Roman-script content is useful as a secondary signal, because people search that way, but it should not be the primary version.
- Write questions the way they are spoken. Voice queries are longer and more conversational than typed ones. Heading text that mirrors a spoken question is the single cheapest change here.
- Keep the entity consistent across languages. Your business name, address and service descriptions should resolve to the same entity whatever language the page is in. This is where most multilingual rollouts quietly fall apart.
Which language, for whom
We work across India's manufacturing belts and multi-city service businesses, and the answer differs sharply by who is buying.
Industrial and B2B. Procurement in the GIDC and MIDC clusters runs largely in English for written enquiries, because specifications, certifications and export documentation are English by default. The vernacular opportunity here is narrower than it looks, and it sits in voice and in the smaller job-work end of the market rather than in tender-driven buying. We would not translate a chemicals catalogue into Gujarati before fixing the product-level pages in English.
Consumer, retail and healthcare. The opposite. A pharmacy chain's customers ask in the language they speak at home, and increasingly they ask aloud. This is where Hindi, Gujarati and Marathi content earns its place quickly, particularly for the "is it open, do you have it, how far is it" class of question that Search Live is built for.
Professional services. Mixed, and worth testing rather than assuming. Legal and financial buyers often research in a regional language and transact in English, which argues for vernacular explanatory content feeding English conversion pages rather than a fully mirrored site.
The honest limits
Two things are worth saying plainly, because the vendor pitch around this tends to skip them.
First, nobody outside Google knows how heavily regional-language sources are weighted in these answers, or how that will change. The feature set is documented; the ranking behaviour is not. Anyone presenting a precise multiplier for vernacular content is guessing with confidence.
Second, this is a real advantage but a narrow window rather than a permanent moat. It is available because most businesses have not moved yet. Once a category's leaders publish properly in Hindi or Tamil, being the fourth firm to do it is table stakes again — which is an argument for starting in the categories where you can be first, not for starting everywhere.
Where to start this month
Pick your single highest-value question — the one a customer asks most often before buying — and answer it properly in one regional language, on one page, in the native script, with the schema and hreflang wired correctly. Then ask that question aloud to Search Live in that language and see what comes back.
That exercise costs an afternoon and tells you more than a translation quote will. If the answer names a competitor, you now know exactly what you are competing with. If it names nobody, the category is still open.
Before any of that, it is worth confirming machines can read your English site at all — vernacular content sitting on a foundation assistants cannot crawl helps nobody. Our free readiness check reads your homepage and up to ten more pages the way a non-rendering crawler does, and tells you what to fix first.
Vernacular content sitting on a site assistants cannot crawl helps nobody. Check the foundation first — 11 pages, around 35 signals.
Check if AI can read your siteOr email hello@tikbo.in