// गाइड
अपनी साइट पर व्यवहार में GEO कैसे करते हैं?
लेखक: Dmitry Filippov, Founder, GET-GEO.AI
प्रकाशित: 2026-08-03 · अपडेट: 2026-09-22
// संक्षिप्त उत्तर
get-geo.ai पर आधे दिन के तकनीकी काम में हमने सभी संकेत एक मुख्य डोमेन से जोड़े, क्रॉलर को सीधे सामग्री उपलब्ध कराई, Search Console में डोमेन प्रॉपर्टी बनाई और सभी गाइड हर भाषा की llms-full फ़ाइल में शामिल कीं। फ़ाइलें पेजों के साथ अपने-आप अपडेट होती हैं। उद्देश्य था कि उपयोगी सामग्री तक पहुँच में तकनीकी रुकावट न रहे।
- अपनी साइट पर GEO करने में आधा दिन लगा और कोई नया पेज नहीं बना: एक प्राइमरी होस्ट, Search Console की domain property और दोबारा बनाए गए llms-full एक्सपोर्ट।
- हर सिग्नल apex की ओर इशारा करता था, जबकि apex ख़ुद 308 रीडायरेक्ट से www पर भेजता था: ऐसा चक्र जिसे एक-अनुरोध के बजट वाले AI fetchers कभी पार नहीं करते।
- AI एजेंट की चेकलिस्ट कहती थी कि apex का A record 76.76.21.21 पर हो; असली DNS ने 216.198.79.1 दिखाया, Vercel का नया इन्फ्रास्ट्रक्चर — इसलिए मॉडल की सलाह को लाइव सिस्टम से जाँचें।
- ताज़ा जमा किया गया sitemap कुछ दिनों तक "Couldn't fetch" दिखा सकता है; तीन चीज़ें जाँचें: फ़ाइल खुलती है, हर loc में सही होस्ट है, robots.txt में वह सूचीबद्ध है।
- llms-full अब 9 भाषाओं के लिए हर locale की एक फ़ाइल देता है; देवनागरी में हर अक्षर 3 बाइट लेता है, इसलिए हिन्दी फ़ाइल 85 KB पहुँची और सीमा बढ़ाकर 300 KB की गई।
शुरुआती बिंदु: एक साइट जो सही दिखती है
हम अपनी GEO सेवाओं के तरीक़े इस साइट पर भी लागू करते हैं। इस गाइड में एक कार्यदिवस के दौरान मिली समस्याएँ, किए गए सुधार और उनकी जाँच दर्ज है। सभी उदाहरण get-geo.ai के हैं।
get-geo.ai में शुरू से सर्वर पर तैयार पेज, hreflang के साथ 9 भाषाएँ, Schema.org JSON-LD, सीधे जवाब देने वाली संरचना और 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 का पारंपरिक crawler इसे झेल जाता है, हालाँकि क्रॉल-बजट जलाकर। लेकिन AI fetchers अक्सर नहीं झेलते: कई के पास प्रति पेज एक-दो अनुरोधों का ही बजट होता है, और कुछ रीडायरेक्ट के पार सामग्री तक पहुँच ही नहीं पाते। GEO के लिए यह घातक है: fetcher के लिए अदृश्य फ़ाइल यानी अस्तित्वहीन फ़ाइल।
समाधान: hosting (Vercel) पर apex को प्राइमरी डोमेन बनाया गया, www को apex पर 308। एक स्विच — और सारे सिग्नल एकरूप हो गए: वास्तविक पता, canonical, आंतरिक लिंक, sitemap और llms.txt अब एक ही जगह इशारा करते हैं।
www के साथ या उसके बिना पता चुनना मुख्य बात नहीं है। ज़रूरी है कि साइट का एक मुख्य पता हो और दूसरा उसी पर भेजे। वास्तविक पते, canonical और बाकी संकेतों में अंतर होने पर क्रॉलर को अतिरिक्त अनुरोध करने पड़ते हैं।
खोज #2: AI एजेंट की पुरानी पड़ चुकी सलाह
निदान एक AI एजेंट कर रहा था, और उसकी चेकलिस्ट में था: "जाँचें कि apex का A record 76.76.21.21 पर इशारा करता है"। असली DNS की जाँच ने कुछ और दिखाया: डोमेन 216.198.79.1 पर resolve होता है — Vercel का नया इन्फ्रास्ट्रक्चर, जिस पर hosting मॉडल के प्रशिक्षण डेटा की कट-ऑफ़ तारीख़ के बाद माइग्रेट हुई।
सलाह पुरानी जानकारी पर आधारित थी। मॉडल का भरोसेमंद लहजा उसकी जानकारी के मौजूदा होने का प्रमाण नहीं था।
तकनीकी सलाह को सिस्टम की वास्तविक स्थिति से मिलाएँ। इस मामले में एक सेकंड की DNS जाँच से अंतर स्पष्ट हो गया। AI एजेंट को सत्यापन के टूल देना ज़रूरी है, ताकि वह केवल प्रशिक्षण में मिली जानकारी पर निर्भर न रहे।
क़दम 3: Google Search Console — डोमेन property
प्राइमरी होस्ट बदलने के बाद GSC की पुरानी property (https://www.get-geo.ai/ पर URL-prefix) बेकार हो गई: वह सिर्फ़ www कवर करती है, जबकि पेज apex पर जा रहे थे।
सही configuration है डोमेन property (get-geo.ai, बिना प्रोटोकॉल और सबडोमेन): वह एक साथ apex, www, http, https और सारे सबडोमेन कवर करती है। इसका सत्यापन केवल DNS TXT record से होता है — और यहाँ एक सुखद बात: google-site-verification token खाते से बंधा होता है, सत्यापन के तरीक़े से नहीं, इसलिए पहले से DNS में जोड़ा गया record तुरंत काम कर गया। फिर — apex पते से sitemap भेजना: https://get-geo.ai/sitemap.xml।
सबक़: GSC में ताज़ा भेजा गया sitemap अक्सर लाल स्थिति "प्राप्त नहीं हो सका" और शून्य पेजों के साथ लटका रहता है। यह त्रुटि नहीं, पहली processing तक का placeholder है — processing असिंक्रोनस है और दो दिन तक ले सकती है। घबराने से पहले तीन चीज़ें जाँचिए: फ़ाइल सीधे URL पर खुलती है; अंदर हर <loc> सही होस्ट की ओर इशारा करता है; robots.txt में Sitemap: पंक्ति है। तीनों ठीक हैं — तो बस इंतज़ार कीजिए।
क़दम 4: sitemap से उपयोगी फ़ाइलों तक पहुँच
हमारे sitemap में सिर्फ़ पेज नहीं हैं। उसमें llms.txt, llms-full.txt और सभी भाषा-संस्करण llms-full/{locale} सूचीबद्ध हैं — lastmod तारीख़ों और प्राथमिकताओं के साथ।
क्यों: AI crawlers (GPTBot, ClaudeBot, PerplexityBot) को sitemap पढ़ते देखा गया है, और LLM फ़ाइलों को स्पष्ट रूप से सूचीबद्ध करना उन्हें साइट के मशीन-पठनीय संस्करण तक सीधा रास्ता देता है — इस भरोसे के बिना कि fetcher /llms.txt की परिपाटी जानता होगा।
sitemap में वे पेज और फ़ाइलें दर्ज करें जिन्हें खोज प्रणालियों के लिए उपलब्ध कराना चाहते हैं। lastmod में वास्तविक बदलाव की तारीख़ दें।
क़दम 5: llms-full — पूरी सामग्री, विषय-सूची नहीं
llms.txt प्रमुख पेजों के लिंक देता है; llms-full.txt में पूरी सामग्री होती है, ताकि उसे पढ़ने के लिए हर लिंक अलग से न खोलना पड़े। शुरू में हमारे पूरे पाठ वाले संस्करण में केवल लैंडिंग पेज था। गाइड, जिनमें उद्धृत करने योग्य विस्तृत जानकारी थी, अलग-अलग पेजों पर ही उपलब्ध थीं।
हमने क्या बदला:
- हर भाषा की अलग फ़ाइल। गाइडों के पूरे पाठ llms-full/{locale} में रखे गए। 9 भाषाएँ एक साथ रखने पर किसी एक भाषा में पूछे गए सवाल के लिए बहुत-सा असंबंधित पाठ भी पढ़ना पड़ता है।
- हर शीर्षक के नीचे URL। फ़ाइल के अंदर हर गाइड शीर्षक से शुरू होती है और ठीक नीचे कैनोनिकल URL — ताकि पाठ उठाने वाला मॉडल पेज को उद्धृत कर सके, txt फ़ाइल को नहीं।
- एक ही स्रोत से स्वचालित निर्माण। फ़ाइलें उन्हीं सामग्री मॉड्यूल से बनती हैं जिनसे गाइड पेज बनते हैं। नई गाइड प्रकाशित होने पर साइट, sitemap और llms-full साथ अपडेट होते हैं; अलग से हाथ से बदलाव करने की ज़रूरत नहीं पड़ती।
- आकार सीमा पार होने पर स्पष्ट जानकारी। फ़ाइल में पूरा पाठ न समा पाए, तो उसे चुपचाप काटने के बजाय छूटी हुई गाइडों की सूची और उनके लिंक दिए जाते हैं।
- अप्रत्याशित जगह से मिला सबक़: पहली 100 KB की सीमा को लगभग तोड़ दिया एक लिपि ने। Devanagari (हिन्दी) UTF-8 में प्रति अक्षर 3 बाइट लेती है, लैटिन 1 — हिन्दी फ़ाइल 85 KB तक पहुँची जब अंग्रेज़ी उसकी आधी थी। हमने सीमा 300 KB कर दी। अगर आपकी साइट बहुभाषी है, तो बजट लिपि को ध्यान में रखकर बनाइए: CJK और भारतीय लिपियाँ कई गुना भारी होती हैं।
दिन का नतीजा
आधे दिन का काम, सामग्री का एक भी नया पेज नहीं — और फिर भी:
- साइट का हर सिग्नल एक ही होस्ट की ओर इशारा करता है, बिना चक्रों और फ़ालतू रीडायरेक्ट के;
- एक अनुरोध के बजट वाला AI fetcher पहली कोशिश में सामग्री पा लेता है;
- GSC पूरे डोमेन का डेटा जुटाता है, एक सबडोमेन का नहीं;
- 9 भाषाओं में गाइडों का पूरा संग्रह मशीनों को प्रति भाषा एक फ़ाइल में उपलब्ध है;
- नई गाइड प्रकाशित करने पर साइट, sitemap और llms-full अपने आप अपडेट हो जाते हैं।
तकनीकी सुधार सामग्री तक पहुँच आसान करते हैं
GEO के इस हिस्से का उद्देश्य तकनीकी बाधाएँ दूर करना है। सामग्री उपयोगी होनी चाहिए, लेकिन उसके चुने जाने से पहले सिस्टम को उसे खोलने और पढ़ने में सक्षम होना चाहिए।
संबंधित प्रश्न
क्या GEO के लिए apex बनाम www मायने रखता है?
चुनाव ख़ुद नहीं। मायने यह रखता है कि साइट ठीक एक होस्ट पर रहे और हर सिग्नल — canonical, sitemap, hreflang, JSON-LD, llms.txt — वहीं इशारा करे, और दूसरा hostname सख़्त रीडायरेक्ट करे। apex और www के बीच चक्र क्रॉल-बजट जलाता है और अक्सर उन AI fetchers को रोक देता है जो सिर्फ़ एक-दो अनुरोध करते हैं।
क्या Google Search Console में डोमेन property इस्तेमाल करनी चाहिए?
पूरे डोमेन के आँकड़े देखने हों, तो डोमेन प्रॉपर्टी उपयोगी है। इसमें www के साथ और उसके बिना पते, http और https तथा अन्य सबडोमेन शामिल होते हैं। इसका सत्यापन DNS TXT से होता है। केवल www की URL-prefix प्रॉपर्टी मुख्य पता बदलने के बाद नए पते का डेटा नहीं दिखाती।
sitemap में llms.txt क्यों सूचीबद्ध करें?
sitemap में llms.txt और भाषा के अनुसार llms-full फ़ाइलों का पता देने से मशीन-पठनीय सामग्री का स्थान स्पष्ट होता है। लेकिन इससे यह सुनिश्चित नहीं होता कि हर AI क्रॉलर इन फ़ाइलों को पढ़ेगा या उनका उपयोग करेगा।
हर भाषा के लिए अलग llms-full फ़ाइल क्यों रखें?
नौ भाषाएँ एक फ़ाइल में होने पर किसी एक भाषा के सवाल के लिए बाकी पाठ भी पढ़ना पड़ता है। अलग फ़ाइल में केवल उसी भाषा की सामग्री रहती है। हर गाइड के शीर्षक के नीचे उसका canonical URL दिया जा सकता है और फ़ाइल उन्हीं सामग्री मॉड्यूल से बन सकती है जिनसे HTML पेज बनते हैं।
संबंधित गाइड
स्रोत
// साझा करें
इस पेज को कैसे उद्धृत करें
आप इस सामग्री को उद्धृत और दोबारा इस्तेमाल कर सकते हैं। स्रोत के रूप में इस पेज का लिंक दें।
“अपनी साइट पर व्यवहार में GEO कैसे करते हैं?” — GET-GEO.AI, 2026-09-22. https://get-geo.ai/hi/guides/how-we-do-geo-ourselves