In this article
- One query, three scripts
- hreflang for a hi/en pair
- URL slugs: Devanagari or romanised
- Fonts and Core Web Vitals on a budget Android phone
- Google Discover is not optional for Hindi publishers
- Keyword tools are weak on Hindi. Here is what to do about it
- Machine-translated pages are the thing to avoid
- Structured data in Hindi
- You do not need AMP
- A week’s worth of work, in order
- Where our tools fit, and when not to buy
- Frequently asked questions
Most SEO advice is written by people who have never typed a query in Devanagari. It mostly still applies: titles matter and slow pages lose. A Hindi site for Indian readers also has a handful of problems an English site never meets, and those tend to decide whether the site gets traffic. This guide covers those.
It is for a publisher, a blogger or a small business writing in Hindi or Hinglish for readers in India. If you run an English site aimed at India, most of this is not your problem. If you are planning to add a Hindi section to an English site, read the hreflang and machine-translation parts twice before you start.
One query, three scripts
A Hindi speaker looking for a cheap laptop can search in three ways:
| Form | Example | What it looks like to Google |
|---|---|---|
| Devanagari | सस्ता लैपटॉप | Hindi-language query |
| Romanised Hinglish | sasta laptop | Ambiguous: Hindi words in Latin script |
| English | cheap laptop | English query, Indian location |
Google understands that the first two mean the same thing, and it will often show Devanagari pages for a Hinglish query, though not reliably. Search all three forms yourself from an Indian location (set the location in a browser profile, or just use your phone on a mobile connection) and look at the results. On informational queries the Devanagari and Hinglish results tend to overlap heavily. On commercial queries the Hinglish form often pulls English e-commerce pages instead, because that is what people who type in Latin script tend to click.
The practical rule that falls out of this: pick one script for each page based on what the SERP for its query shows, and do not build a separate page for the romanised form of the same query, because it is the same intent. A Devanagari article can carry the Hinglish form once in the body where it reads naturally (Hindi writers do this anyway: “सस्ता लैपटॉप, यानी budget laptop”). That is enough for Google to connect the two. Repeating the romanised form ten times does nothing except make the article read like it was written for a machine.
Hinglish is also the script most people use on a phone keyboard, so voice search matters more here than it does in English markets. Voice queries arrive in Devanagari because Google transcribes Hindi speech to Devanagari. If your analytics show Devanagari queries growing faster than Hinglish ones, that is usually why.
hreflang for a hi/en pair
hreflang tells Google that two pages are the same content in different languages. It is only for that. If your Hindi article about laptops and your English article about laptops are different articles, they are not a pair, and hreflang between them is wrong.
When you do have real pairs:
- Use
hi-INanden-IN. Google’s documentation says only ISO 639-1 language codes and ISO 3166-1 alpha-2 region codes are supported (checked 21 Sep 2026), and both of those are valid. Plainhiandenare also fine if you have no reason to split regions. - Both pages must point at each other. Google’s wording is blunt: “If two pages don’t both point to each other, the tags will be ignored.” Most broken hreflang on Indian sites is one-directional because the English template got the tag and the Hindi template did not.
- Add
x-defaultpointing at whichever page should serve someone whose browser language matches neither. For most Indian sites that is the English page, since a visitor from outside India is more likely to read English. - Put
lang="hi"on the<html>element of the Hindi page. It is not hreflang, but browsers, screen readers and font shaping all use it.
If your CMS cannot emit hreflang reliably, skip it rather than emit it half right. Google will still index both pages and usually pick the right one by language.
URL slugs: Devanagari or romanised
Google’s URL guidance says characters outside the ASCII range “should be percent encoded” (checked 21 Sep 2026). A Devanagari slug like /सस्ता-लैपटॉप/ is legal, and Google will index it. The cost is what it looks like once encoded: every Devanagari character becomes three bytes, so the URL turns into /%E0%A4%B8%E0%A4%B8%E0%A5%8D%E0%A4%A4%E0%A4%BE-... the moment it is copied out of the address bar.
That matters in India more than elsewhere because so much traffic to Hindi sites arrives through WhatsApp and Telegram forwards. A romanised slug (/sasta-laptop-under-30000/) survives a copy-paste, fits in a message, and a reader can see what it is before tapping. A percent-encoded one does not.
Google has published no ranking preference either way, and we have not measured one. The choice is about sharing and about your own sanity in analytics reports, where an encoded slug is unreadable. Use romanised, hyphenated slugs. Keep the Devanagari in the title, the H1 and the body, which is where it does the work.
Two cautions. Do not romanise inconsistently: laptop on one page and leptop on another splits your own internal linking. And if you already have Devanagari URLs that rank, leave them. Changing slugs means 301s, a temporary dip, and a risk that is not worth a cosmetic gain.
Fonts and Core Web Vitals on a budget Android phone
Devanagari needs a font that can shape conjuncts and stack matras above and below the baseline. Web fonts that do this properly are large. A full Noto Sans Devanagari file, unsubsetted, is several times the size of a Latin font, and a WordPress theme that loads two weights of it plus a Latin fallback plus an icon font has already spent its performance budget before the article renders.
Meanwhile your reader is on a phone that cost eight to fifteen thousand rupees, with limited RAM, on Jio or Airtel 4G that is fast in the city and patchy everywhere else. Google’s “good” thresholds (web.dev, checked 21 Sep 2026) are LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of real visits. On that hardware, a heavy theme fails all three.
What works:
- Use the system Devanagari font. Android ships Noto Sans Devanagari and iOS ships Devanagari Sangam MN. A font stack that names them and falls back to
system-uicosts zero bytes to download. Most Hindi news sites that load quickly do this. - If the brand insists on a web font (Mukta, Hind and Poppins all have Devanagari), subset it to the Devanagari and Latin blocks, load one weight, use
font-display: swap, and preload it. The subset file is a fraction of the full one. - Watch CLS specifically. Devanagari line boxes are taller than Latin ones because of the marks above and below. If the fallback font and the web font have different vertical metrics, every paragraph jumps when the web font lands. Setting
line-heightto at least 1.6 for Hindi body text gives both fonts room and reduces the shift. - Cut JavaScript before anything else. INP on a cheap phone is mostly main-thread time, and on a publisher site that is ad scripts, social embeds and a slider nobody scrolls. Check the Core Web Vitals report in Search Console rather than a lab tool run from a laptop, because the field data comes from your actual readers on their actual phones.
Test on the phone your readers use. A three-year-old Redmi with a throttled connection tells you more than any Lighthouse score.
Google Discover is not optional for Hindi publishers
For a lot of Hindi news and content sites, Discover sends more visits than Search does. It is the feed on the Google app home screen and on the left of the Android home screen, and it is heavily used by exactly the readers Hindi publishers want.
Google’s Discover documentation (checked 21 Sep 2026) is short and worth reading in full. The points that matter:
- “Content is automatically eligible to appear in Discover if it is indexed by Google and meets Discover’s content policies.” There is no feed to submit and no Discover sitemap.
- Images need to be “at least 1200 px wide”, and large previews are “enabled by the max-image-preview:large setting, or by using AMP”. Put
<meta name="robots" content="max-image-preview:large">on article pages. That one tag is the single biggest Discover fix we see missing on Hindi sites. - “Use page titles and headlines that capture the essence of the content.” Discover’s policies penalise clickbait and withholding titles, which is a problem for a lot of Hindi viral-content sites that learned their headline style from Facebook.
Discover traffic is volatile. A story can bring two lakh visits in a day and the next week brings nothing, so plan the site’s income around Search and treat Discover as extra.
Keyword tools are weak on Hindi. Here is what to do about it
We sell access to these tools, so it is worth saying where they fall short before saying where they help.
Semrush organises its keyword data by country, not by language. Its knowledge base lists “more than 140 databases” with India as IN (semrush.com/kb/287, checked 21 Sep 2026), and there is no separate Hindi-language database. Devanagari queries appear in the India database only where Semrush’s own collection has picked them up, so a query you know is common often shows as a low volume or does not appear at all. Hinglish queries are patchier still, because the same phrase gets spelled five ways.
Ahrefs has the same shape. Keywords Explorer advertises “217 Locations” and “28.7B Keywords” (ahrefs.com/keywords-explorer, checked 21 Sep 2026). You pick India as the location and type in Devanagari. Coverage of Devanagari terms is better than it was, and still far thinner than English. Neither tool’s volume figure for a Hindi query should be treated as more than a rough order of magnitude.
So the workflow is different from an English site. Use the tools for what they are good at and get Hindi demand from elsewhere.
Your own Search Console is the best Hindi keyword tool you have
Search Console reports every query your site was shown for, in the script the searcher used. Its query filter accepts regular expressions, so a filter of [ऀ-ॿ] (custom regex, “matches”) shows only Devanagari queries, and the inverse shows Hinglish and English. Run that over 16 months of data and you have a Hindi keyword list that no vendor can match, because it is your readers. Sort by impressions with low click-through to find the queries you already rank for on page two.
Reverse the competitors instead of guessing
Ahrefs and Semrush are useful here. Put a Hindi publisher’s domain into Site Explorer or Domain Overview, filter to India, and read the organic keywords report. The Devanagari queries that domain ranks for are real queries with real traffic, regardless of what the volume column says. Do this for five or six sites in your niche and cluster the results. It is faster and more honest than typing guesses into a keyword tool. Ahrefs on its own is ₹1,199/month through us, Semrush is ₹199/month, and both are on the Ahrefs tool page and the Semrush tool page with what shared access does and does not include.
Autocomplete, People also ask, and Trends
Google’s own surfaces do not have the database problem, because they are Google. Type a Devanagari seed into the search box from an Indian location and note the autocomplete suggestions, which are drawn from real queries. Open the Hindi “People also ask” boxes and expand them. Use Google Trends with India as the region to compare a Devanagari term against its Hinglish spelling; the relative line tells you which script your readers actually use for that topic, which is exactly the decision the first section of this guide asked you to make.
Use ChatGPT for variants, never for volume
A language model is good at one piece of this: producing the twenty ways a Hindi speaker might phrase a query, across Devanagari, Hinglish, regional word choices (a Bihar reader and a Mumbai reader do not use the same word for everything) and the English loanwords real Hindi uses. Ask it for those, then check each one in autocomplete or Search Console. Do not ask it for search volumes. It will produce a confident number, and the number is invented. ChatGPT is ₹299/month through us; the tool page explains the shared-account limits.
Machine-translated pages are the thing to avoid
The tempting shortcut for an English site is to run every article through a translator and publish the output under /hi/. It is a bad idea for two reasons.
Google’s spam policies list, under scaled content abuse, content generated through “automated transformations like synonymizing, translating, or other obfuscation techniques, where little value is provided to users” (checked 21 Sep 2026). A site that bulk-translates is exactly that pattern, and the risk is to the whole domain, not just the Hindi section.
Policy aside, machine-translated Hindi reads wrong to a Hindi reader in the first sentence. It uses शुद्ध Hindi words nobody says (दूरभाष for a phone), gets the register wrong, and turns English idioms into nonsense. Readers bounce, and the bounce shows up in every engagement signal Google can see.
The workable version is a Hindi writer, with a language model as a drafting aid. Let ChatGPT produce a first Hindi draft from your English brief, then have someone who writes Hindi rewrite it in the words Hindi readers use, including the English loanwords. Publish the pages that got that treatment with hreflang; leave the ones that did not out of the index until they get it.
Structured data in Hindi
Schema.org markup works in any language. The things that trip people up:
- Set
inLanguagetohion yourArticleorNewsArticle, and keepheadlinein Devanagari matching the visible title. FAQPagemarkup works with Hindi questions and answers, and Hindi FAQ rich results do show in Indian SERPs.- Keep
BreadcrumbListnames readable. If your breadcrumb text is Devanagari, fine; just do not let the breadcrumbitemURLs be percent-encoded differently from your canonical. - Validate with the Rich Results Test after any template change. A single malformed quote in a Devanagari string breaks the whole block, and you will not notice from the rendered page.
You do not need AMP
Many Hindi publishers still maintain an AMP version of every article because, years ago, it was the only route into the Top Stories carousel and the only way to get large Discover images. Neither is true now. Google’s Discover documentation lists AMP only as an alternative to max-image-preview:large (checked 21 Sep 2026), and Top Stories has been open to non-AMP pages since the 2021 page experience update.
AMP costs you a second template to maintain, a second set of ad integrations, and a URL structure that confuses your analytics. A fast canonical page with the robots tag above does the same job. If you switch AMP off, make sure the old /amp/ URLs redirect to the canonical rather than 404, because they have been indexed and shared for years.
A week’s worth of work, in order
- Monday: pull 16 months of Search Console queries, split Devanagari from Hinglish with the regex filter, and list the top 50 queries with impressions but poor clicks.
- Tuesday: for the top ten topics, search all three script forms from an Indian location and record which script the SERP favours. Decide the script per page.
- Wednesday: add
max-image-preview:large, check every article image is 1200 px wide or more, and fix the featured image template if not. - Thursday: test the site on a cheap Android phone on mobile data. Cut the web font or subset it; remove the two heaviest scripts. Re-check the Search Console Core Web Vitals report over the next month.
- Friday: if you have hi/en pairs, audit hreflang for reciprocity. If you have machine-translated pages, noindex them until they are rewritten.
None of that needs a paid tool. The competitor-reversal step in the keyword section does, which is where our plans come in.
Where our tools fit, and when not to buy
If you want Semrush, Ahrefs and ChatGPT together for the competitor research and drafting work above, the Advanced plan is ₹1,499/month for 25 tools. Bought one by one through us, those three add up to a little more than the plan in every currency we bill in, so for the trio the plan is the cheaper route. If you only want Semrush, buy the single at ₹199/month; it is cheaper than any plan that contains it.
What shared access means, in plain terms: you log into a shared vendor account through the dashboard at my.bundledseo.com, in the browser. There are no API keys, so anything scripted against the Ahrefs or Semrush API is out. Daily report limits and export rows are shared with the other people on the account, so a heavy day for someone else is a slower day for you. Accounts get reset from time to time, so a Position Tracking project or a saved keyword list may not survive. Export what you need to a sheet as you go.
In India you can pay by UPI or card, and USDT works if you prefer. Compare it against what an individual Ahrefs seat costs in rupees in our Ahrefs price in India guide before deciding; for a site that only needs the Search Console workflow above, retail or nothing may be the right answer. If you want the full cost picture for a small Indian SEO setup, the tool stack cost breakdown does that math, and the local business keyword guide covers the Hinglish query problem from the business owner’s side.
Frequently asked questions
Should I write my Hindi site in Devanagari or in Hinglish?
Devanagari for the body of the page, almost always. Google treats Hinglish as a spelling variant of the Devanagari query rather than a separate language, so a Devanagari page can rank for both, while a page written entirely in romanised Hindi reads as low-quality to many readers and is harder for Google to classify. Use Hinglish in the URL slug, and in the body where a term is actually used that way.
Do I need separate pages for the Devanagari and Hinglish versions of a keyword?
No. They are the same intent, and two pages targeting one intent compete with each other. One page, one script for the body, with the other form mentioned once where it reads naturally.
Does hreflang help if my Hindi pages are different articles from my English ones?
No, and it can hurt. hreflang is a claim that two URLs are translations of each other. If the content differs, Google may ignore the tags or, worse, swap one page for the other in results where the swap makes no sense. Use it only for real translated pairs.
Why does Semrush show almost no volume for a Hindi keyword I know is popular?
Because Semrush’s data is organised by country rather than language and its India database is built from queries it has been able to collect, which under-represents Devanagari and especially Hinglish. Treat the volume as a lower bound, check the query in Google Trends and autocomplete, and rely on your own Search Console data for the queries that matter.
Is a Devanagari URL bad for SEO?
Not for ranking, as far as anyone has shown. Google indexes percent-encoded URLs fine and has not published a preference. It is bad for sharing: on WhatsApp the encoded form is a wall of percent signs. New sites should use romanised slugs; existing sites with Devanagari slugs that already rank should leave them alone.
Can I use ChatGPT to translate my English articles into Hindi?
Yes, as a first draft that a Hindi writer then rewrites. Publishing the raw output is where it goes wrong: bulk automated translation is named in Google’s spam policies under scaled content abuse, and the output reads wrong to Hindi speakers regardless of the policy.
Do I still need AMP for Google Discover or Top Stories?
No. Discover’s large image previews come from the max-image-preview:large robots tag, with AMP listed by Google only as an alternative, and Top Stories has accepted non-AMP pages since 2021. A fast, normal page does the job with one template to maintain instead of two.
