// गाइड
अपनी साइट पर व्यवहार में GEO कैसे करते हैं?
अपडेट: 2026-08-03
// संक्षिप्त उत्तर
तकनीकी GEO जादू नहीं, स्वच्छता है। get-geo.ai पर आधे दिन के काम ने हर सिग्नल को एक होस्ट की ओर मोड़ा, AI फ़ेचर को पहली कोशिश में कंटेंट दिया, Search Console को डोमेन प्रॉपर्टी पर बदला, और पूरा गाइड-कॉर्पस प्रति-भाषा llms-full फ़ाइलों में रखा जो पेजों वाली ही रजिस्ट्री से अपने आप अपडेट होती हैं। कंटेंट तय करता है कि आपको उद्धृत करेंगे; इंजीनियरिंग तय करती है कि कोई इतना दूर पढ़ पाएगा कि उद्धृत करे।
शुरुआती बिंदु: एक साइट जो सही दिखती है
हम GEO बेचते हैं — इसलिए हमारी अपनी वेबसाइट को मिसाल होना चाहिए। यह गाइड सिद्धांत नहीं, बल्कि एक असली कार्यदिवस का प्रोटोकॉल है: हमने क्या पाया, कैसे ठीक किया और क्या जाँचा। हर उदाहरण इसी साइट से है।
get-geo.ai पहले दिन से "किताब के मुताबिक़" बनी थी: सर्वर-साइड रेंडरिंग, hreflang के साथ 8 भाषाएँ, Schema.org JSON-LD, answer-first संरचना, llms.txt। भला यहाँ ठीक करने को क्या हो सकता था? ऑडिट ने एक ऐसी समस्या खोजी जो आँखों से नहीं दिखती।
खोज #1: apex बनाम www का टकराव
साइट भौतिक रूप से www.get-geo.ai पर रहती थी, जबकि सारे सिग्नल — canonical, sitemap, hreflang, JSON-LD, llms.txt — get-geo.ai (apex, यानी बिना सबडोमेन वाला डोमेन) की ओर इशारा करते थे। और apex ख़ुद 308 रीडायरेक्ट से वापस www पर भेज देता था।
नतीजा — एक चक्र: "कैनोनिकल संस्करण apex है" → apex www पर रीडायरेक्ट करता है → www कहता है "कैनोनिकल संस्करण apex है"। Google का पारंपरिक क्रॉलर इसे झेल जाता है, हालाँकि क्रॉल-बजट जलाकर। लेकिन AI फ़ेचर अक्सर नहीं झेलते: कई के पास प्रति पेज एक-दो अनुरोधों का ही बजट होता है, और कुछ रीडायरेक्ट के पार कंटेंट तक पहुँच ही नहीं पाते। GEO के लिए यह घातक है: फ़ेचर के लिए अदृश्य फ़ाइल यानी अस्तित्वहीन फ़ाइल।
समाधान: होस्टिंग (Vercel) पर apex को प्राइमरी डोमेन बनाया गया, www को apex पर 308। एक स्विच — और सारे सिग्नल एकरूप हो गए: वास्तविक पता, canonical, आंतरिक लिंक, sitemap और llms.txt अब एक ही जगह इशारा करते हैं।
सबक़: apex और www के बीच चुनाव मायने नहीं रखता। मायने यह रखता है कि साइट ठीक उनमें से एक पर रहे और दूसरा सख़्ती से रीडायरेक्ट करे। "साइट कहाँ रहती है" और "सिग्नल कहाँ इशारा करते हैं" के बीच कोई भी अंतर — क्रॉलर की हर विज़िट पर लगने वाला टैक्स है।
खोज #2: AI एजेंट की पुरानी पड़ चुकी सलाह
निदान एक AI एजेंट कर रहा था, और उसकी चेकलिस्ट में था: "जाँचें कि apex का A-रिकॉर्ड 76.76.21.21 पर इशारा करता है"। असली DNS की जाँच ने कुछ और दिखाया: डोमेन 216.198.79.1 पर रिज़ॉल्व होता है — Vercel का नया इन्फ्रास्ट्रक्चर, जिस पर होस्टिंग मॉडल के प्रशिक्षण डेटा की कट-ऑफ़ तारीख़ के बाद माइग्रेट हुई।
सलाह हानिकारक नहीं थी — बस बासी थी। मॉडल आत्मविश्वास से अतीत को उद्धृत कर रहा था।
सबक़: सत्यापन उपकरणों के बिना AI एजेंट स्मृति है, ज्ञान नहीं। मॉडल की किसी भी तकनीकी सिफ़ारिश को सिस्टम की वास्तविक स्थिति से मिलाइए: एक DNS क्वेरी में एक सेकंड लगता है और सवाल ख़त्म। वैसे, यही ख़ुद GEO का मूल सिद्धांत है: मॉडल उसी से जवाब देते हैं जो वे पढ़ पाए — और ठीक इसीलिए हम कंटेंट को पठनीय बनाते हैं।
क़दम 3: Google Search Console — डोमेन प्रॉपर्टी
प्राइमरी होस्ट बदलने के बाद GSC की पुरानी प्रॉपर्टी (https://www.get-geo.ai/ पर URL-प्रीफ़िक्स) बेकार हो गई: वह सिर्फ़ www कवर करती है, जबकि पेज apex पर जा रहे थे।
सही कॉन्फ़िगरेशन है डोमेन प्रॉपर्टी (get-geo.ai, बिना प्रोटोकॉल और सबडोमेन): वह एक साथ apex, www, http, https और सारे सबडोमेन कवर करती है। इसका सत्यापन केवल DNS TXT रिकॉर्ड से होता है — और यहाँ एक सुखद बात: google-site-verification टोकन खाते से बंधा होता है, सत्यापन के तरीक़े से नहीं, इसलिए पहले से DNS में जोड़ा गया रिकॉर्ड तुरंत काम कर गया। फिर — apex पते से sitemap भेजना: https://get-geo.ai/sitemap.xml।
सबक़: GSC में ताज़ा भेजा गया sitemap अक्सर लाल स्थिति "प्राप्त नहीं हो सका" और शून्य पेजों के साथ लटका रहता है। यह त्रुटि नहीं, पहली प्रोसेसिंग तक का प्लेसहोल्डर है — प्रोसेसिंग असिंक्रोनस है और दो दिन तक ले सकती है। घबराने से पहले तीन चीज़ें जाँचिए: फ़ाइल सीधे URL पर खुलती है; अंदर हर <loc> सही होस्ट की ओर इशारा करता है; robots.txt में Sitemap: पंक्ति है। तीनों ठीक हैं — तो बस इंतज़ार कीजिए।
क़दम 4: sitemap एक GEO-उपकरण के रूप में, औपचारिकता नहीं
हमारे sitemap में सिर्फ़ पेज नहीं हैं। उसमें llms.txt, llms-full.txt और सभी भाषा-संस्करण llms-full/{locale} सूचीबद्ध हैं — lastmod तारीख़ों और प्राथमिकताओं के साथ।
क्यों: AI क्रॉलरों (GPTBot, ClaudeBot, PerplexityBot) को sitemap पढ़ते देखा गया है, और LLM फ़ाइलों को स्पष्ट रूप से सूचीबद्ध करना उन्हें साइट के मशीन-पठनीय संस्करण तक सीधा रास्ता देता है — इस भरोसे के बिना कि फ़ेचर /llms.txt की परिपाटी जानता होगा।
सबक़: sitemap को मशीनों के लिए मेन्यू समझिए, चेकबॉक्स नहीं। जो कुछ आप AI सिस्टम्स को दिखाना चाहते हैं, वह ईमानदार lastmod तारीख़ों के साथ वहाँ सूचीबद्ध होना चाहिए।
क़दम 5: llms-full — पूरा कंटेंट, विषय-सूची नहीं
परिपाटी दो फ़ाइलों में फ़र्क़ करती है: llms.txt — लिंकों वाली विषय-सूची; llms-full.txt — उन सिस्टम्स के लिए पूरा कंटेंट जो लिंकों पर नहीं जाते। हमारे full-संस्करण में शुरू में सिर्फ़ लैंडिंग थी: गाइड — हमारी सबसे उद्धरण-योग्य संपत्ति — सिर्फ़ पेज-दर-पेज उपलब्ध थीं।
हमने क्या बदला:
- प्रति-भाषा फ़ाइलें। गाइडों के पूरे पाठ llms-full/{locale} में गए, हर फ़ाइल पूरी तरह अपनी भाषा में। 8 भाषाओं को एक फ़ाइल में ठूँसना यानी किसी भी विशिष्ट क्वेरी के लिए उपयोगी घनत्व को आठ गुना पतला करना।
- हर शीर्षक के नीचे URL। फ़ाइल के अंदर हर गाइड शीर्षक से शुरू होती है और ठीक नीचे कैनोनिकल URL — ताकि पाठ उठाने वाला मॉडल पेज को उद्धृत कर सके, txt फ़ाइल को नहीं।
- एक ही रजिस्ट्री से स्वचालित निर्माण। फ़ाइलें उसी स्रोत से बनती हैं जिससे गाइडों के पेज। नई गाइड एक ही क्रिया में साइट, sitemap और llms-full में पहुँच जाती है। हाथ से सिंक करना महीने भर में दम तोड़ देता है — हमने उसे शुरू ही नहीं किया।
- ईमानदार गिरावट वाली सीमा। फ़ाइल की आकार-सीमा है; सीमा पार होने पर चुपचाप काटने के बजाय — छूट गई गाइडों की सूची लिंकों समेत जुड़ जाती है।
- अप्रत्याशित जगह से मिला सबक़: पहली 100 KB की सीमा को लगभग तोड़ दिया एक लिपि ने। Devanagari (हिन्दी) UTF-8 में प्रति अक्षर 3 बाइट लेती है, लैटिन 1 — हिन्दी फ़ाइल 85 KB तक पहुँची जब अंग्रेज़ी उसकी आधी थी। हमने सीमा 200 KB कर दी। अगर आपकी साइट बहुभाषी है, तो बजट लिपि को ध्यान में रखकर बनाइए: CJK और भारतीय लिपियाँ कई गुना भारी होती हैं।
दिन का नतीजा
आधे दिन का काम, कंटेंट का एक भी नया पेज नहीं — और फिर भी:
- साइट का हर सिग्नल एक ही होस्ट की ओर इशारा करता है, बिना चक्रों और फ़ालतू रीडायरेक्ट के;
- एक अनुरोध के बजट वाला AI फ़ेचर पहली कोशिश में कंटेंट पा लेता है;
- GSC पूरे डोमेन का डेटा जुटाता है, एक सबडोमेन का नहीं;
- 8 भाषाओं में गाइडों का पूरा संग्रह मशीनों को प्रति भाषा एक फ़ाइल में उपलब्ध है;
- नई गाइड प्रकाशित करने पर साइट, sitemap और llms-full अपने आप अपडेट हो जाते हैं।
स्वच्छता, जादू नहीं
यही GEO का तकनीकी हिस्सा है: जादू नहीं, स्वच्छता। कंटेंट तय करता है कि आपको उद्धृत करेंगे या नहीं। तकनीक तय करती है कि कोई आपके कंटेंट तक पढ़ पाएगा या नहीं।
संबंधित प्रश्न
क्या GEO के लिए apex बनाम www मायने रखता है?
चुनाव ख़ुद नहीं। मायने यह रखता है कि साइट ठीक एक होस्ट पर रहे और हर सिग्नल — canonical, sitemap, hreflang, JSON-LD, llms.txt — वहीं इशारा करे, और दूसरा hostname सख़्त रीडायरेक्ट करे। apex और www के बीच चक्र क्रॉल-बजट जलाता है और अक्सर उन AI फ़ेचरों को रोक देता है जो सिर्फ़ एक-दो अनुरोध करते हैं।
क्या Google Search Console में डोमेन प्रॉपर्टी इस्तेमाल करनी चाहिए?
हाँ, अगर आपको apex और www दोनों (या http और https) की परवाह है। डोमेन प्रॉपर्टी सबको एक साथ कवर करती है और DNS TXT से सत्यापित होती है। सिर्फ़ www पर URL-प्रीफ़िक्स प्रॉपर्टी प्राइमरी होस्ट के apex पर जाते ही अंधी हो जाती है।
sitemap में llms.txt क्यों सूचीबद्ध करें?
AI क्रॉलरों को sitemap पढ़ते देखा गया है। llms.txt और प्रति-भाषा llms-full फ़ाइलें सूचीबद्ध करना उन्हें मशीन-पठनीय कॉर्पस तक सीधा रास्ता देता है — बिना इस भरोसे के कि हर फ़ेचर /llms.txt परिपाटी जानता होगा।
एक बहुभाषी डंप के बजाय प्रति-भाषा llms-full फ़ाइलें क्यों?
आठ भाषाओं वाली एक फ़ाइल किसी भी विशिष्ट क्वेरी के लिए उपयोगी घनत्व को आठ गुना पतला कर देती है। प्रति भाषा एक फ़ाइल कॉर्पस को सघन रखती है, हर गाइड शीर्षक के नीचे कैनोनिकल URL रखती है, और HTML पेजों वाली ही रजिस्ट्री से बन सकती है।