इस आर्टिकल में
- एक ही सवाल, तीन स्क्रिप्ट
- hi और en पेज के लिए hreflang
- URL slug: देवनागरी या रोमन
- सस्ते Android फ़ोन पर फ़ॉन्ट और Core Web Vitals
- हिंदी पब्लिशर के लिए Google Discover छोड़ने वाली चीज़ नहीं है
- हिंदी में keyword tool कमज़ोर हैं, इसका क्या करें
- मशीन से ट्रांसलेट किए पेज सबसे बड़ी गलती हैं
- हिंदी में structured data
- AMP की अब ज़रूरत नहीं है
- एक हफ़्ते का काम, क्रम से
- हमारे टूल कहाँ फ़िट होते हैं, और कब नहीं लेने चाहिए
- अक्सर पूछे जाने वाले सवाल
SEO की ज़्यादातर सलाह उन लोगों ने लिखी है जिन्होंने ज़िंदगी में कभी देवनागरी में कोई query टाइप नहीं की। उसमें से बहुत कुछ हिंदी साइट पर भी वैसा ही चलता है: title अब भी मायने रखता है और धीमा पेज अब भी पिछड़ता है। लेकिन हिंदी में लिखने वाली साइट के सामने कुछ दिक्कतें अलग से आती हैं, जो अंग्रेज़ी साइट के सामने कभी नहीं आतीं, और ट्रैफ़िक अक्सर उन्हीं पर टिकता है। यह गाइड उन्हीं के बारे में है।
यह उनके लिए है जो भारत के पाठकों के लिए हिंदी या Hinglish में लिख रहे हैं: पब्लिशर, ब्लॉगर, या कोई छोटा बिज़नेस जिसकी साइट हिंदी में है। अगर आपकी साइट अंग्रेज़ी में है और आप सिर्फ़ भारत को टारगेट कर रहे हैं, तो इसमें से आधी बातें आपकी समस्या नहीं हैं। और अगर आप अंग्रेज़ी साइट में हिंदी सेक्शन जोड़ने की सोच रहे हैं, तो hreflang और मशीन ट्रांसलेशन वाले हिस्से दो बार पढ़ लीजिए, शुरू करने से पहले।
एक ही सवाल, तीन स्क्रिप्ट
सस्ता लैपटॉप ढूँढ़ने वाला हिंदी भाषी तीन तरह से सर्च कर सकता है:
| रूप | उदाहरण | Google को क्या दिखता है |
|---|---|---|
| देवनागरी | सस्ता लैपटॉप | हिंदी भाषा की query |
| रोमन Hinglish | sasta laptop | दुविधा: हिंदी शब्द, Latin script में |
| अंग्रेज़ी | cheap laptop | अंग्रेज़ी query, लोकेशन भारत |
Google समझता है कि पहले दो का मतलब एक ही है, और Hinglish query पर भी अक्सर देवनागरी पेज दिखा देता है, हालाँकि हर बार नहीं। इसलिए अंदाज़ा लगाने की जगह तीनों रूप खुद सर्च करके देखिए, भारत की लोकेशन से (ब्राउज़र में लोकेशन सेट कर लीजिए, या सीधे मोबाइल डेटा पर फ़ोन से देख लीजिए)। जानकारी वाली query पर देवनागरी और Hinglish के नतीजे काफ़ी हद तक एक जैसे निकलते हैं। लेकिन जहाँ खरीदने की नीयत है, वहाँ Hinglish query अक्सर अंग्रेज़ी e-commerce पेज खींच लाती है, क्योंकि Latin में टाइप करने वाले लोग आमतौर पर उन्हीं पर क्लिक करते हैं।
इससे एक सीधा नियम निकलता है। हर पेज के लिए एक स्क्रिप्ट चुनिए, उसी query के SERP को देखकर, और उसी query के रोमन रूप के लिए अलग पेज मत बनाइए। नीयत तो एक ही है। देवनागरी आर्टिकल के अंदर Hinglish रूप एक बार आ जाए, जहाँ पढ़ने में स्वाभाविक लगे, तो काफ़ी है। हिंदी लिखने वाले वैसे भी ऐसे ही लिखते हैं: “सस्ता लैपटॉप, यानी budget laptop”। इतने से Google दोनों को जोड़ लेता है। वही रोमन शब्द दस बार ठूँसने से कुछ नहीं होता, बस आर्टिकल पढ़ने में मशीन का लिखा लगने लगता है।
एक और बात, जो हिंदी में ही होती है। ज़्यादातर लोग फ़ोन के कीबोर्ड पर Hinglish ही टाइप करते हैं, क्योंकि Gboard में हिंदी पर स्विच करना एक झंझट है और transliteration कभी-कभी अजीब शब्द बना देता है। इसीलिए यहाँ voice search का हिस्सा अंग्रेज़ी बाज़ारों से बड़ा है। बोलकर की गई query देवनागरी में पहुँचती है, क्योंकि Google हिंदी बोली को देवनागरी में लिखता है। अगर आपके Search Console में देवनागरी query Hinglish से तेज़ी से बढ़ रही हैं, तो वजह आमतौर पर यही होती है।
hi और en पेज के लिए hreflang
hreflang का काम सिर्फ़ इतना है कि Google को बताए: ये दो पेज एक ही कंटेंट हैं, अलग-अलग भाषा में। अगर लैपटॉप पर आपका हिंदी आर्टिकल और लैपटॉप पर आपका अंग्रेज़ी आर्टिकल असल में अलग-अलग आर्टिकल हैं, तो वे जोड़ी नहीं हैं, और उनके बीच hreflang लगाना गलत है।
जहाँ सचमुच जोड़ी बनती है, वहाँ:
hi-INऔरen-INइस्तेमाल कीजिए। Google की डॉक्यूमेंटेशन कहती है कि सिर्फ़ ISO 639-1 भाषा कोड और ISO 3166-1 alpha-2 रीजन कोड ही समर्थित हैं (21 सितंबर 2026 को देखा गया), और ये दोनों उसी में आते हैं। अगर रीजन अलग करने की कोई वजह नहीं है तो सादाhiऔरenभी ठीक है।- दोनों पेज एक-दूसरे की तरफ़ इशारा करने चाहिए। Google की भाषा में कोई गोलमोल नहीं है: “If two pages don’t both point to each other, the tags will be ignored.” भारतीय साइटों पर hreflang सबसे ज़्यादा इसी वजह से टूटा मिलता है, एकतरफ़ा रह जाता है, क्योंकि टैग अंग्रेज़ी टेम्पलेट में लग गया और हिंदी टेम्पलेट में रह गया।
x-defaultभी जोड़िए, उस पेज पर जो ऐसे आदमी को मिलना चाहिए जिसकी ब्राउज़र भाषा दोनों में से किसी से मेल नहीं खाती। ज़्यादातर भारतीय साइटों के लिए वह अंग्रेज़ी पेज होगा, क्योंकि भारत के बाहर से आने वाला आदमी अंग्रेज़ी पढ़ लेगा, हिंदी शायद नहीं।- हिंदी पेज के
<html>एलिमेंट परlang="hi"ज़रूर रखिए। यह hreflang नहीं है, पर ब्राउज़र, स्क्रीन रीडर और फ़ॉन्ट shaping तीनों इसी को देखते हैं।
अगर आपका CMS hreflang ठीक से नहीं निकाल पाता, तो आधा-अधूरा निकालने से बेहतर है कि रहने दीजिए। Google दोनों पेज तब भी index करेगा और भाषा देखकर आमतौर पर सही वाला चुन लेगा।
URL slug: देवनागरी या रोमन
Google की URL गाइडेंस कहती है कि ASCII से बाहर के characters “should be percent encoded” (21 सितंबर 2026 को देखा गया)। यानी /सस्ता-लैपटॉप/ जैसा slug चलेगा, Google उसे index भी कर लेगा। दिक्कत encode होने के बाद की शक्ल है: हर देवनागरी अक्षर तीन बाइट का होता है, तो address bar से कॉपी करते ही URL /%E0%A4%B8%E0%A4%B8%E0%A5%8D%E0%A4%A4%E0%A4%BE-... में बदल जाता है।
भारत में यह बात बाकी जगहों से ज़्यादा भारी पड़ती है, क्योंकि हिंदी साइटों पर आने वाला बड़ा हिस्सा WhatsApp और Telegram के फ़ॉरवर्ड से आता है। रोमन slug (/sasta-laptop-under-30000/) कॉपी-पेस्ट में बच जाता है, मैसेज में ठीक दिखता है, और पढ़ने वाला टैप करने से पहले समझ जाता है कि लिंक किस चीज़ का है। percent-encoded वाला इनमें से कुछ नहीं करता। किसी फ़ैमिली ग्रुप में परसेंट के निशानों की दीवार चिपकाइए और देखिए कौन खोलता है।
रैंकिंग में किसी एक तरफ़ फ़ायदा है, ऐसा Google ने कहीं नहीं कहा, और हमने भी नापा नहीं है। फ़ैसला शेयरिंग का है, और अपनी ही analytics रिपोर्ट पढ़ पाने का, जहाँ encoded slug बिल्कुल नहीं पढ़ा जाता। तो रोमन, hyphen वाले slug रखिए। देवनागरी title, H1 और body में रहेगी, जहाँ उसका असली काम है।
दो चेतावनियाँ। रोमन spelling एक जैसी रखिए: एक पेज पर laptop और दूसरे पर leptop लिखा तो आपकी अपनी internal linking दो हिस्सों में बँट जाएगी। और अगर आपकी देवनागरी URL पहले से रैंक कर रही हैं, तो उन्हें हाथ मत लगाइए। slug बदलने का मतलब है 301, कुछ हफ़्तों की गिरावट, और एक जोखिम, जो सिर्फ़ दिखने में सुधार के लिए उठाने लायक नहीं है।
सस्ते Android फ़ोन पर फ़ॉन्ट और Core Web Vitals
देवनागरी को ऐसा फ़ॉन्ट चाहिए जो संयुक्ताक्षर बना सके और मात्राएँ लाइन के ऊपर-नीचे सही जगह बिठा सके। यह ठीक से करने वाली web font फ़ाइलें बड़ी होती हैं। पूरी Noto Sans Devanagari, बिना subset किए, किसी Latin फ़ॉन्ट से कई गुना भारी है। और जो WordPress थीम उसके दो weight, ऊपर से एक Latin fallback, ऊपर से एक icon font लोड करती है, उसका performance बजट आर्टिकल दिखने से पहले ही खत्म हो चुका होता है।
उधर आपका पाठक 8,000 से 15,000 रुपये वाले फ़ोन पर है, कम RAM के साथ, Jio या Airtel के 4G पर, जो शहर में तेज़ है और कस्बे से बाहर निकलते ही लड़खड़ाने लगता है। Google की “good” सीमाएँ (web.dev, 21 सितंबर 2026 को देखा गया) हैं: LCP 2.5 सेकंड के अंदर, INP 200 मिलीसेकंड या कम, और CLS 0.1 या कम, असली विज़िट के 75वें percentile पर नापकर। उस हार्डवेयर पर भारी थीम तीनों में फ़ेल होती है।
जो काम करता है:
- सिस्टम का देवनागरी फ़ॉन्ट इस्तेमाल कीजिए। Android में Noto Sans Devanagari पहले से है और iOS में Devanagari Sangam MN। इन दोनों को नाम से लिखकर
system-uiपर गिरने वाला font stack एक भी बाइट डाउनलोड नहीं कराता। जो हिंदी न्यूज़ साइटें तेज़ खुलती हैं, ज़्यादातर यही करती हैं। - अगर ब्रांड को web font चाहिए ही (Mukta, Hind और Poppins तीनों में देवनागरी है), तो उसे देवनागरी और Latin ब्लॉक तक subset कीजिए, एक ही weight लोड कीजिए,
font-display: swapलगाइए और उसे preload कीजिए। subset फ़ाइल पूरी फ़ाइल के सामने कुछ भी नहीं है। - CLS पर खास नज़र रखिए। मात्राओं की वजह से देवनागरी की लाइन Latin से ऊँची बैठती है। अगर fallback फ़ॉन्ट और web font के vertical metrics अलग हुए, तो web font आते ही हर पैराग्राफ़ उछलता है। हिंदी body text के लिए
line-heightकम से कम 1.6 रखिए, इससे दोनों फ़ॉन्ट को जगह मिल जाती है और झटका घटता है। - सबसे पहले JavaScript काटिए। सस्ते फ़ोन पर INP का मतलब ज़्यादातर main thread पर बीता हुआ वक़्त है, और पब्लिशर साइट पर वह वक़्त ad स्क्रिप्ट, सोशल embed और उस slider में जाता है जिसे कोई स्क्रॉल नहीं करता। Search Console की Core Web Vitals रिपोर्ट देखिए, लैपटॉप पर चलाए गए lab टूल को नहीं, क्योंकि field डेटा आपके असली पाठकों के असली फ़ोन से आता है।
टेस्ट उसी फ़ोन पर कीजिए जो आपका पाठक चलाता है। तीन साल पुरानी Redmi, धीमे कनेक्शन पर, किसी भी Lighthouse स्कोर से ज़्यादा बता देती है।
हिंदी पब्लिशर के लिए Google Discover छोड़ने वाली चीज़ नहीं है
बहुत सी हिंदी न्यूज़ और कंटेंट साइटों पर Discover से Search से ज़्यादा विज़िट आती हैं। यह वही फ़ीड है जो Google app के होम पर और Android के होम स्क्रीन पर बाईं तरफ़ खुलती है, और ठीक वही लोग उसे चलाते हैं जिन्हें हिंदी पब्लिशर पकड़ना चाहते हैं।
Google की Discover डॉक्यूमेंटेशन (21 सितंबर 2026 को देखा गया) छोटी है और पूरी पढ़ने लायक है। काम की बातें ये हैं:
- “Content is automatically eligible to appear in Discover if it is indexed by Google and meets Discover’s content policies.” यानी कोई फ़ीड जमा नहीं करनी, कोई Discover sitemap नहीं होता।
- इमेज “at least 1200 px wide” होनी चाहिए, और बड़ा preview “enabled by the max-image-preview:large setting, or by using AMP” होता है। आर्टिकल पेज पर
<meta name="robots" content="max-image-preview:large">लगा दीजिए। हिंदी साइटों पर Discover की सबसे बड़ी और सबसे आम कमी यही एक टैग है। - “Use page titles and headlines that capture the essence of the content.” Discover की पॉलिसी clickbait और बात छिपाने वाले title पर सख़्त है, और यह उन तमाम हिंदी वायरल साइटों के लिए दिक्कत है जिन्होंने headline लिखना Facebook से सीखा है।
Discover का ट्रैफ़िक बहुत ऊपर-नीचे होता है। एक स्टोरी एक दिन में दो लाख विज़िट दे सकती है और अगले हफ़्ते सन्नाटा रहता है। इसलिए साइट की कमाई का हिसाब Search पर बिठाइए और Discover को ऊपर की कमाई मानिए।
हिंदी में keyword tool कमज़ोर हैं, इसका क्या करें
हम खुद ये टूल बेचते हैं, इसलिए पहले यह कह देना ठीक रहेगा कि ये कहाँ काम नहीं करते।
Semrush अपना keyword डेटा देश के हिसाब से रखता है, भाषा के हिसाब से नहीं। उसका knowledge base “more than 140 databases” गिनाता है, जिसमें भारत IN है (semrush.com/kb/287, 21 सितंबर 2026 को देखा गया), और हिंदी भाषा का कोई अलग database नहीं है। देवनागरी query भारत वाले database में तभी दिखती हैं जब Semrush की अपनी collection ने उन्हें उठाया हो, इसलिए जिस query को आप रोज़ चलती देखते हैं वह अक्सर बहुत कम volume पर दिखती है या दिखती ही नहीं। Hinglish का हाल और पतला है, क्योंकि एक ही बात पाँच spelling में लिखी जाती है।
Ahrefs की कहानी भी वैसी ही है। Keywords Explorer “217 Locations” और “28.7B Keywords” का दावा करता है (ahrefs.com/keywords-explorer, 21 सितंबर 2026 को देखा गया)। आप location में भारत चुनते हैं और देवनागरी में टाइप करते हैं। पहले से बेहतर coverage मिलती है, फिर भी अंग्रेज़ी के सामने बहुत पतली। किसी भी हिंदी query के लिए इन दोनों में से किसी टूल का volume आँकड़ा मोटे अंदाज़े से ज़्यादा मत मानिए।
तो तरीका अंग्रेज़ी साइट वाले तरीके से अलग होगा। टूल से वही काम लीजिए जो वे ठीक करते हैं, और हिंदी की माँग कहीं और से निकालिए।
आपका अपना Search Console ही सबसे अच्छा हिंदी keyword tool है
Search Console हर वह query दिखाता है जिस पर आपकी साइट दिखी, उसी स्क्रिप्ट में जिसमें सर्च करने वाले ने लिखी थी। query फ़िल्टर regular expression लेता है, तो [ऀ-ॿ] (custom regex, “matches”) लगाने पर सिर्फ़ देवनागरी query बचती हैं, और उल्टा करने पर Hinglish और अंग्रेज़ी। 16 महीने के डेटा पर यह चलाइए और आपके पास ऐसी हिंदी keyword list आ जाएगी जो किसी वेंडर के पास नहीं है, क्योंकि वह आपके पाठकों की है। impressions से sort कीजिए और कम CTR वाली query छाँटिए, वहीं वे पड़ी हैं जिन पर आप दूसरे पेज पर रैंक कर रहे हैं।
अंदाज़ा लगाने की जगह competitor उल्टा खोलिए
यहाँ Ahrefs और Semrush दोनों काम आते हैं। किसी हिंदी पब्लिशर का domain Site Explorer या Domain Overview में डालिए, भारत का फ़िल्टर लगाइए, और organic keywords रिपोर्ट पढ़िए। वह domain जिन देवनागरी query पर रैंक कर रहा है, वे असली query हैं जिन पर असली ट्रैफ़िक है, volume कॉलम चाहे जो कह रहा हो। अपनी niche की पाँच-छह साइटों पर यही कीजिए और नतीजों को cluster कर लीजिए। keyword tool में अंदाज़े टाइप करने से यह तेज़ भी है और ईमानदार भी। हमारे यहाँ अकेला Ahrefs ₹1,199/महीना पड़ता है और Semrush ₹199/महीना; Ahrefs का टूल पेज और Semrush का टूल पेज दोनों बताते हैं कि shared access में क्या मिलता है और क्या नहीं।
Autocomplete, People also ask और Trends
Google की अपनी सतहों पर database वाली दिक्कत नहीं है, क्योंकि वे Google हैं। भारत की लोकेशन से सर्च बॉक्स में देवनागरी seed टाइप कीजिए और autocomplete के सुझाव नोट कीजिए, वे असली query से बनते हैं। हिंदी “People also ask” के बॉक्स खोलकर फैलाइए। और Google Trends में region भारत रखकर देवनागरी शब्द की तुलना उसकी Hinglish spelling से कीजिए; दोनों लाइनें बता देंगी कि उस विषय पर आपके पाठक असल में कौन सी स्क्रिप्ट चलाते हैं, यानी ठीक वही फ़ैसला जो इस गाइड के पहले हिस्से ने आपसे माँगा था।
ChatGPT से variant लीजिए, volume कभी नहीं
इस पूरे काम में language model एक ही चीज़ अच्छी करता है: एक ही बात कहने के बीस तरीके निकाल देना। देवनागरी में, Hinglish में, इलाके के हिसाब से बदले शब्दों में (पटना का पाठक और मुंबई का पाठक हर चीज़ को एक ही नाम से नहीं बुलाते), और उन अंग्रेज़ी शब्दों के साथ जो असली हिंदी में रोज़ चलते हैं। यह उससे माँगिए, फिर हर variant autocomplete या Search Console में जाँचिए। search volume उससे मत पूछिए। वह पूरे आत्मविश्वास के साथ एक नंबर देगा और वह नंबर गढ़ा हुआ होगा। ChatGPT हमारे यहाँ ₹299/महीना है; ChatGPT का टूल पेज shared account की सीमाएँ बताता है।
मशीन से ट्रांसलेट किए पेज सबसे बड़ी गलती हैं
अंग्रेज़ी साइट वालों को सबसे आसान रास्ता यही दिखता है: हर आर्टिकल translator में डालो और नतीजा /hi/ के नीचे छाप दो। यह दो वजहों से बुरा विचार है।
पहली, Google की spam policies में scaled content abuse के नीचे साफ़ लिखा है कि “automated transformations like synonymizing, translating, or other obfuscation techniques, where little value is provided to users” इसी में आते हैं (21 सितंबर 2026 को देखा गया)। थोक में ट्रांसलेट करने वाली साइट ठीक यही पैटर्न है, और खतरा सिर्फ़ हिंदी सेक्शन पर नहीं, पूरे domain पर आता है।
दूसरी, पॉलिसी को एक तरफ़ रख दीजिए तो भी मशीन की हिंदी पहले वाक्य में पकड़ी जाती है। वह ऐसे शुद्ध शब्द उठा लाती है जो कोई नहीं बोलता (फ़ोन के लिए दूरभाष), tone गलत बैठाती है, और अंग्रेज़ी मुहावरों का ऐसा अनुवाद करती है जिसका कोई मतलब नहीं निकलता। पाठक वापस चला जाता है, और वह वापस जाना हर उस signal में दिखता है जो Google देख सकता है।
चलने वाला तरीका यह है: हिंदी लिखने वाला आदमी, और language model उसके ड्राफ़्ट में मदद के लिए। अपने अंग्रेज़ी brief से ChatGPT से पहला हिंदी ड्राफ़्ट बनवाइए, फिर उसे कोई ऐसा आदमी दोबारा लिखे जो हिंदी में लिखता है, उन्हीं शब्दों में जो हिंदी पाठक पढ़ता है, अंग्रेज़ी शब्दों समेत। जिन पेज को यह इलाज मिल गया, उन्हें hreflang के साथ छापिए; जिन्हें नहीं मिला, उन्हें index से बाहर रखिए जब तक मिल न जाए।
हिंदी में structured data
Schema.org markup किसी भी भाषा में चलता है। लोग इन जगहों पर फँसते हैं:
- अपने
ArticleयाNewsArticleमेंinLanguageकोhiरखिए, औरheadlineदेवनागरी में रखिए, वैसा ही जैसा दिखने वाला title है। FAQPagemarkup हिंदी सवाल-जवाब के साथ चलता है, और हिंदी FAQ rich result भारतीय SERP में दिखते भी हैं।BreadcrumbListके नाम पढ़ने लायक रखिए। breadcrumb का text देवनागरी में है तो कोई हर्ज नहीं; बस breadcrumb केitemURL आपके canonical से अलग तरीके से percent-encoded नहीं होने चाहिए।- टेम्पलेट में कुछ भी बदलने के बाद Rich Results Test चलाइए। देवनागरी string में एक गलत quote पूरा ब्लॉक तोड़ देता है, और रेंडर हुए पेज को देखकर आपको पता भी नहीं चलेगा।
AMP की अब ज़रूरत नहीं है
बहुत से हिंदी पब्लिशर आज भी हर आर्टिकल का AMP वर्ज़न बनाए रखते हैं, क्योंकि कई साल पहले Top Stories के carousel में घुसने का और Discover में बड़ी इमेज पाने का वही एक रास्ता था। अब दोनों बातें सही नहीं हैं। Google की Discover डॉक्यूमेंटेशन AMP को सिर्फ़ max-image-preview:large के विकल्प के तौर पर गिनाती है (21 सितंबर 2026 को देखा गया), और Top Stories 2021 के page experience update के बाद से गैर-AMP पेज भी लेता है।
AMP की कीमत यह है कि आपको दूसरा टेम्पलेट सँभालना पड़ता है, ad का दूसरा सेटअप करना पड़ता है, और URL का एक ढाँचा और बन जाता है जो आपकी analytics को उलझा देता है। ऊपर वाला robots टैग लगा हुआ तेज़ canonical पेज वही काम कर देता है। AMP बंद करें तो पुराने /amp/ URL को canonical पर redirect ज़रूर कीजिए, 404 मत छोड़िए, क्योंकि वे सालों से index और शेयर होते आए हैं।
एक हफ़्ते का काम, क्रम से
- सोमवार: Search Console से 16 महीने की query निकालिए, regex फ़िल्टर से देवनागरी और Hinglish अलग कीजिए, और ऐसी 50 query की लिस्ट बनाइए जिन पर impressions हैं पर क्लिक कम हैं।
- मंगलवार: ऊपर के दस विषयों के लिए तीनों स्क्रिप्ट में भारत की लोकेशन से सर्च कीजिए और नोट कीजिए कि SERP किस स्क्रिप्ट को पसंद कर रहा है। हर पेज की स्क्रिप्ट वहीं तय कर लीजिए।
- बुधवार:
max-image-preview:largeलगाइए, हर आर्टिकल की इमेज 1200 px या ज़्यादा चौड़ी है यह जाँचिए, और न हो तो featured image वाला टेम्पलेट ठीक कीजिए। - गुरुवार: साइट को सस्ते Android फ़ोन पर, मोबाइल डेटा पर चलाकर देखिए। web font हटाइए या subset कीजिए; दो सबसे भारी स्क्रिप्ट निकाल दीजिए। अगले महीने भर Search Console की Core Web Vitals रिपोर्ट देखते रहिए।
- शुक्रवार: hi/en की असली जोड़ियाँ हैं तो hreflang की दोतरफ़ा जाँच कीजिए। मशीन से ट्रांसलेट हुए पेज हैं तो उन्हें दोबारा लिखे जाने तक noindex कर दीजिए।
इसमें से किसी काम के लिए paid tool ज़रूरी नहीं है। keyword वाले हिस्से में competitor उल्टा खोलने के लिए ज़रूरी है, और हमारे plan वहीं काम आते हैं।
हमारे टूल कहाँ फ़िट होते हैं, और कब नहीं लेने चाहिए
ऊपर वाली competitor research और drafting के लिए अगर आपको Semrush, Ahrefs और ChatGPT तीनों एक साथ चाहिए, तो Advanced plan ₹1,499/महीना में 25 टूल देता है। हमारे यहाँ ये तीनों अलग-अलग लेने पर जोड़ हर करेंसी में plan से थोड़ा ऊपर चला जाता है, तो तीनों के लिए plan ही सस्ता पड़ता है। लेकिन अगर आपको सिर्फ़ Semrush चाहिए, तो single ही लीजिए, ₹199/महीना, यह उसे रखने वाले किसी भी plan से सस्ता है।
shared access का सीधा मतलब यह है: आप my.bundledseo.com के dashboard से ब्राउज़र में एक साझा वेंडर अकाउंट में लॉगिन करते हैं। API key नहीं मिलती, इसलिए Ahrefs या Semrush के API पर कुछ भी स्क्रिप्ट करके चलाना यहाँ नहीं होगा। रोज़ की report limit और export rows अकाउंट पर बैठे बाकी लोगों के साथ बँटती हैं, तो किसी और का भारी दिन आपके लिए धीमा दिन बन जाता है। अकाउंट समय-समय पर रीसेट होते हैं, इसलिए Position Tracking का project या सेव की हुई keyword list बची रहेगी, इसका भरोसा मत कीजिए। जो चाहिए, उसे साथ-साथ किसी sheet में export करते चलिए।
भारत में UPI से, कार्ड से, और चाहें तो USDT से पेमेंट हो जाता है। लेने से पहले हमारी गाइड में देख लीजिए कि Ahrefs की अकेली seat रुपये में कितने की पड़ती है, और तुलना कीजिए; जिस साइट को ऊपर बताया गया Search Console वाला तरीका ही चाहिए, उसके लिए सही जवाब retail हो सकता है, या कुछ भी न लेना। छोटे भारतीय SEO सेटअप का पूरा खर्च जानना हो तो टूल स्टैक का खर्च वाला पोस्ट वही हिसाब लगाता है, और लोकल बिज़नेस keyword गाइड Hinglish query की दिक्कत को दुकान वाले की तरफ़ से देखता है।
अक्सर पूछे जाने वाले सवाल
हिंदी साइट देवनागरी में लिखूँ या Hinglish में?
पेज की body लगभग हमेशा देवनागरी में। Google Hinglish को देवनागरी query की एक spelling की तरह लेता है, अलग भाषा की तरह नहीं, इसलिए देवनागरी पेज दोनों पर रैंक कर सकता है। दूसरी तरफ़ पूरी तरह रोमन में लिखा पेज बहुत से पाठकों को घटिया लगता है और Google के लिए भी उसे भाषा के खाने में डालना मुश्किल होता है। Hinglish URL slug में रखिए, और body में वहाँ जहाँ वह शब्द चलता ही उसी रूप में है।
क्या देवनागरी और Hinglish वाले keyword के लिए अलग-अलग पेज बनाने चाहिए?
नहीं। नीयत एक ही है, और एक ही नीयत पर बने दो पेज आपस में लड़ते हैं। एक पेज, body के लिए एक स्क्रिप्ट, और दूसरा रूप एक बार वहाँ जहाँ पढ़ने में सहज लगे।
मेरे हिंदी पेज अंग्रेज़ी पेज से अलग आर्टिकल हैं, तब hreflang से फ़ायदा है?
नहीं, नुकसान हो सकता है। hreflang एक दावा है कि दो URL एक-दूसरे का अनुवाद हैं। कंटेंट अलग हुआ तो Google या तो टैग को अनदेखा कर देगा, या इससे भी बुरा, नतीजों में एक पेज की जगह दूसरा दिखा देगा जहाँ ऐसा करने का कोई तुक नहीं बनता। इसे सिर्फ़ असली अनुवाद जोड़ियों पर लगाइए।
जिस हिंदी keyword को मैं चलता हुआ जानता हूँ, Semrush उस पर लगभग शून्य volume क्यों दिखाता है?
क्योंकि Semrush का डेटा भाषा के नहीं, देश के हिसाब से बनता है, और उसका भारत वाला database उन्हीं query से बना है जो वह जुटा पाया। उसमें देवनागरी कम आती है और Hinglish और भी कम। उस आँकड़े को कम से कम की सीमा मानिए, query को Google Trends और autocomplete में जाँचिए, और जो keyword सचमुच मायने रखते हैं उनके लिए अपने Search Console पर भरोसा कीजिए।
क्या देवनागरी URL SEO के लिए खराब है?
रैंकिंग के लिए खराब होने का कोई सबूत आज तक किसी ने नहीं दिखाया। Google percent-encoded URL ठीक से index करता है और उसने कोई पसंद नहीं बताई। खराब यह शेयरिंग के लिए है: WhatsApp पर encoded रूप परसेंट के निशानों की दीवार बन जाता है। नई साइट रोमन slug रखे; जिस पुरानी साइट की देवनागरी slug पहले से रैंक कर रही हैं, वह उन्हें छेड़े नहीं।
क्या मैं अपने अंग्रेज़ी आर्टिकल ChatGPT से हिंदी में करवा सकता हूँ?
हाँ, पहले ड्राफ़्ट के तौर पर, जिसे बाद में कोई हिंदी लिखने वाला दोबारा लिखे। गड़बड़ वहाँ होती है जहाँ कच्चा output सीधे छाप दिया जाता है: थोक में मशीन से किया अनुवाद Google की spam policies में scaled content abuse के नीचे नाम लेकर गिनाया गया है, और पॉलिसी को छोड़ भी दें तो वह हिंदी पाठक को पहले ही वाक्य में गलत लगती है।
Google Discover या Top Stories के लिए क्या अब भी AMP चाहिए?
नहीं। Discover में बड़ी इमेज max-image-preview:large वाले robots टैग से आती है, AMP को Google सिर्फ़ उसके विकल्प के तौर पर गिनाता है, और Top Stories 2021 से गैर-AMP पेज ले रहा है। तेज़ और सामान्य पेज वही काम कर देता है, दो टेम्पलेट की जगह एक सँभालकर।
