संक्षेप में जवाब
robots.txt सहयोग करने वाले क्रॉलरों के लिए एक मानकीकृत निर्देश तंत्र है; llms.txt एक स्वैच्छिक खोज प्रस्ताव है। इनमें से कोई भी सुरक्षा सीमा नहीं है, और देखी गई रिक्वेस्ट जाँचने के लिए लॉग अनिवार्य हैं।
यहाँ तीन अलग समस्याएँ आपस में गड्डमड्ड हो रही हैं
साइट के मालिक अक्सर `robots.txt`, `llms.txt` और «एआई क्रॉलर नियंत्रण» को एक ही डिब्बे में डाल देते हैं, जबकि ये तीनों अलग-अलग समस्याएँ हल करते हैं। RFC 9309 में मानकीकृत रोबोट्स एक्सक्लूज़न प्रोटोकॉल एक परंपरा है, जिससे कोई क्रॉलर यह पता कर सके कि उससे किन पथों पर जाने का अनुरोध है और किन पर नहीं। Google के दस्तावेज़ भी अपने क्रॉलरों के लिए यही व्यावहारिक उपयोग बताते हैं। यह प्रोटोकॉल व्यापक रूप से लागू है, पर RFC एक महत्वपूर्ण सीमा साफ़ बताता है: ये नियम पहुँच का प्राधिकरण नहीं हैं। जिस URL को मना किया गया है, वह उस व्यक्ति या सिस्टम के लिए तब भी खुला रह सकता है जो उसका पता जानता है — जब तक सर्वर ख़ुद प्रमाणीकरण न माँगे या रिक्वेस्ट किसी और तरह से अस्वीकार न करे।
`llms.txt` उद्देश्य और परिपक्वता, दोनों में अलग है। परियोजना की साइट इसे एक Markdown फ़ाइल का प्रस्ताव बताती है, जो आमतौर पर `/llms.txt` पर रखी जाती है और भाषा-मॉडल आधारित प्रणालियों के लिए उपयोगी लिंक तथा संदर्भ प्रस्तुत करती है। इसका इरादा खोज और दिशा-निर्देश में मदद करना है, कोई स्थापित पहुँच-नियंत्रण प्रोटोकॉल बनना नहीं। इसका मतलब यह है कि व्यावहारिक तुलना «कौन-सी फ़ाइल एआई को बेहतर रोकती है?» नहीं है। काम के सवाल ये हैं: कौन-सा क्रॉलर `robots.txt` का पालन करता है; कोई विशेष टूल `llms.txt` पढ़ना चुनता है या नहीं; और जो सामग्री सचमुच निजी रहनी चाहिए, उसके लिए वेबसाइट के पास सर्वर-साइड नियंत्रण हैं या नहीं।
robots.txt किस चीज़ को मानकीकृत करता है
RFC 9309 बताता है कि सहयोगी क्रॉलर `/robots.txt` को कैसे प्राप्त और व्याख्यायित कर सकते हैं — इसमें यूज़र-एजेंट समूह, `Allow` और `Disallow` नियम तथा मिलान का व्यवहार शामिल है। यह फ़ाइल किसी ऑरिजिन के शीर्ष स्तर पर रहती है, और नियम उसी दायरे में लागू होते हैं। यह मानकीकरण इसलिए मायने रखता है कि असंगत पार्सिंग से क्रॉलरों का व्यवहार चौंकाने वाला हो सकता है। इस फ़ाइल का उपयोग करने वाले व्यवसाय को सरल नियम बनाने चाहिए, आकस्मिक सिंटैक्स टकराव से बचना चाहिए, और ठीक उन्हीं पथों की जाँच करनी चाहिए जिनकी उसे परवाह है। सर्च प्रदाता अपने उपकरण और अतिरिक्त दस्तावेज़ प्रकाशित कर सकते हैं, पर प्रोटोकॉल स्वयं क्रॉलर को निर्देश देने का तंत्र है, कोई सामान्य फ़ायरवॉल नहीं।
संवेदनशील सामग्री के मामले में यह भेद ख़ास तौर पर अहम है। कोई robots नियम किसी चालान, स्टेजिंग साइट, ग्राहक निर्यात या निजी PDF को गोपनीय नहीं बना देता। RFC चेतावनी देता है कि इस प्रोटोकॉल को सुरक्षा की तरह इस्तेमाल करने से पथ उजागर हो सकते हैं, क्योंकि यह फ़ाइल सार्वजनिक होती है और उन्हीं पथों को गिनाती है। अगर सामग्री को सुरक्षा चाहिए, तो असली प्राधिकरण लगाएँ: प्रमाणित पहुँच, नेटवर्क नियंत्रण, उपयुक्त अवधि वाले हस्ताक्षरित URL, या ऐसी सर्वर प्रतिक्रियाएँ जो अनधिकृत रिक्वेस्ट अस्वीकार कर दें। `robots.txt` नियम मानने वाली क्रॉलिंग घटा सकता है; रहस्य सँभालने का बोझ उस पर कभी नहीं होना चाहिए। इसी तरह, क्रॉलिंग रोकना और किसी इंडेक्स से हटाने का अनुरोध करना या पहले से जमा सामग्री मिटवाना — ये एक ही काम नहीं हैं।
Google अपनी robots फ़ाइल के बारे में क्या कहता है
Google Search के दस्तावेज़ बताते हैं कि `robots.txt` मुख्य रूप से क्रॉलर ट्रैफ़िक प्रबंधित करने और यह रोकने के लिए है कि Google के क्रॉलर कुछ निर्दिष्ट फ़ाइलें माँगें। वे यह चेतावनी भी देते हैं कि इस तंत्र का उपयोग किसी वेब पेज को Google Search से बाहर रखने के लिए नहीं करना चाहिए। जिस URL को ब्लॉक किया गया है, वह लिंक या अन्य संकेतों से तब भी ज्ञात हो सकता है, भले ही उसकी सामग्री क्रॉल न हुई हो। प्रकाशकों के लिए यह Google से आगे भी काम का मॉडल है: क्रॉल की अनुमति, इंडेक्सिंग का व्यवहार, प्रदर्शन का व्यवहार और पहुँच नियंत्रण — ये अलग-अलग परतें हैं, और इन्हें आपस में बदले जा सकने वाले स्विच नहीं मानना चाहिए।
इसलिए भरोसेमंद कार्यान्वयन वांछित परिणाम से शुरू होता है। अगर मक़सद डुप्लिकेट फ़ैसेटेड URL की क्रॉलिंग घटाना है, तो robots नियम उपयुक्त हो सकता है। अगर मक़सद सार्वजनिक पहुँच रोकना है, तो प्राधिकरण सर्वर का काम है। अगर मक़सद सर्च में प्रस्तुति नियंत्रित करना है, तो यह मान लेने के बजाय कि क्रॉल ब्लॉक वही असर करेगा, संबंधित सर्च सेवा के दस्तावेज़ों में बताए गए तंत्र इस्तेमाल करें। एआई सेवाएँ एक और परत जोड़ती हैं, क्योंकि एक ही कंपनी मॉडल प्रशिक्षण, सर्च पुनर्प्राप्ति या उपयोगकर्ता के अनुरोध पर लाए जाने के लिए अलग-अलग यूज़र एजेंट चला सकती है। साइट के मालिक को «एआई» शब्द से उद्देश्य का अनुमान लगाने के बजाय उस प्रदाता के मौजूदा दस्तावेज़ देखने चाहिए।
llms.txt वास्तव में क्या देता है
`llms.txt` का प्रस्ताव किसी फाटक से ज़्यादा एक चुने हुए नक़्शे जैसा है। इसका विनिर्देश Markdown का उपयोग करता है, ताकि प्रकाशक किसी परियोजना का वर्णन कर सके और भाषा-मॉडल टूल को दस्तावेज़ों या अन्य महत्वपूर्ण संसाधनों की ओर भेज सके। यह उन साइटों पर उपयोगी हो सकता है जहाँ अहम सामग्री नेविगेशन में बिखरी हो, क्लाइंट-साइड बनती हो, या ऐसे इंटरफ़ेस तत्वों से घिरी हो जो मशीन के लिए सुविधाजनक नहीं हैं। एक संक्षिप्त फ़ाइल बता सकती है कि साइट में क्या है और कौन-से कैनोनिकल संसाधन हैं। इनमें से कुछ भी किसी एआई उत्पाद को उन संसाधनों को लाने, उन पर भरोसा करने या उन्हें उद्धृत करने के लिए बाध्य नहीं करता, और यह प्रस्ताव सामान्य वेब आर्किटेक्चर की जगह नहीं लेता।
यह परियोजना पहली बार 2024 में प्रकाशित हुई और तब से बदलती रही है; इसलिए प्रस्ताव का मौजूदा प्रारूप समझने के लिए उसके अपने चेंज लॉग को ही प्रामाणिक जगह मानना चाहिए। इसे अपनाना स्वैच्छिक है और असमान भी। प्रकाशक को इस फ़ाइल को हितधारकों के सामने उद्योग-मानक क्रॉलर निर्देश या आंसर इंजन में दृश्यता की गारंटी बताकर पेश नहीं करना चाहिए। इसका मूल्य अनुभव से आँकना सबसे अच्छा है: अगर रखरखाव की लागत कम है तो सुगठित फ़ाइल जोड़ें, नीचे के पेजों को अपने बल पर उपयोगी बनाए रखें, और देखें कि जिन सेवाओं में आपकी रुचि है वे सचमुच वह फ़ाइल या उसमें दिए संसाधन माँगती हैं या नहीं।
llms.txt को दूसरा कंटेंट सिस्टम न बनने दें
कार्यान्वयन की एक आम ग़लती यह है कि हाथ से लिखा हुआ चमकदार `llms.txt` सारांश धीरे-धीरे साइट से दूर खिसकता जाता है। उत्पाद की उपलब्धता बदल जाती है, कोई API संस्करण हटा दिया जाता है, कोई नीति अपडेट हो जाती है, पर मशीन के लिए बनी फ़ाइल जमी रहती है। अगर यह फ़ाइल अपनाई जाए, तो उसे उसी कैनोनिकल स्रोत सूची से बनाएँ या जाँचें जिससे नेविगेशन और दस्तावेज़ बनते हैं। उसमें ऐसे दावे रखने से बचें जो किसी सुलभ स्रोत पेज पर मौजूद ही नहीं हैं। फ़ाइल को खोज की रुकावट घटानी चाहिए, न कि एक छाया ज्ञान-कोष बन जाना चाहिए जो सामान्य सामग्री वाले प्रशासन के बिना अपने अलग तथ्य ढोता हो।
यही नियम प्रस्ताव में वर्णित तथाकथित `llms-full.txt` रूपों पर भी लागू होता है। बड़े, मशीन-अनुकूल निर्यात सुविधाजनक हो सकते हैं, पर आकार अपने आप गुणवत्ता नहीं है। दोहराई गई, बासी या पहुँच के लिहाज़ से अनुपयुक्त सामग्री पुनर्प्राप्ति को बिगाड़ सकती है और रखरखाव का जोखिम बढ़ा सकती है। जहाँ उपयुक्त हो वहाँ उद्गम, अपडेट तिथियाँ और स्थिर URL बनाए रखें। अगर कुछ दस्तावेज़ व्यापक रूप से नहीं लाए जाने चाहिए, तो उन्हें केवल इसलिए शामिल न करें कि मशीन-पठनीय बंडल बनाना तकनीकी रूप से आसान है। खोज के संकेतों को साइट की सूचना संरचना और प्राधिकरण मॉडल को दर्शाना चाहिए, उन्हें लाँघना नहीं।
सर्वर लॉग का उपयोग देखने के लिए करें, अनुमान लगाने के लिए नहीं
किसी सार्वजनिक साइट से क्या-क्या माँगा जा रहा है, यह जानने का सबसे ठोस तरीक़ा HTTP एक्सेस लॉग या समकक्ष CDN और एज टेलीमेट्री देखना है। कम से कम टाइमस्टैम्प, माँगा गया पथ, प्रतिक्रिया की स्थिति, यूज़र एजेंट, बाइट्स, उपलब्ध हो तो रेफ़रर, होस्ट और एक रिक्वेस्ट पहचानकर्ता दर्ज करें; IP संबंधी जानकारी केवल उपयुक्त गोपनीयता और सुरक्षा नीति के तहत ही रखें। `/robots.txt`, `/llms.txt`, मुख्य सामग्री पथों और ज्ञात क्रॉलर यूज़र एजेंट के लिए अलग व्यू बनाएँ। आवृत्ति, स्थिति कोड और यह मापें कि खोज फ़ाइल के बाद कौन-से संदर्भित पेज लाए गए। इससे पता चलता है कि आपके सर्वर ने क्या देखा — जो इस अनुमान से कहीं मज़बूत है कि फ़ाइल मौजूद है इसलिए किसी सेवा ने उसे इस्तेमाल किया होगा।
फिर भी लॉग की व्याख्या करनी पड़ती है। यूज़र-एजेंट स्ट्रिंग कोई दूसरा क्लाइंट भी नक़ल कर सकता है, इसलिए वह पहचान का क्रिप्टोग्राफ़िक प्रमाण नहीं है। कुछ बड़े प्रदाता क्रॉलर IP या रिवर्स DNS सत्यापित करने की विधियाँ प्रकाशित करते हैं; जहाँ पहचान मायने रखती है वहाँ प्रदाता की उन्हीं मौजूदा विधियों का उपयोग करें। प्रॉक्सी और उपयोगकर्ता द्वारा शुरू की गई फ़ेच स्वायत्त क्रॉलरों से अलग बर्ताव कर सकती हैं। `llms.txt` की एक रिक्वेस्ट को अंतर्ग्रहण, प्रशिक्षण, रैंकिंग या उद्धरण के बराबर न मानें। कोई फ़ेच केवल यह सिद्ध करती है कि एक रिक्वेस्ट सर्वर तक पहुँची। उस सामग्री का आगे क्या उपयोग हुआ, यह माँगने वाली सेवा के दस्तावेज़ित व्यवहार और नीतियों पर निर्भर है।
हर सेवा के लिए एक सत्यापन मैट्रिक्स बनाएँ
जिन सर्च या एआई सेवाओं की आपको परवाह है, उनमें से हर एक के लिए एक छोटी मैट्रिक्स रखें: दस्तावेज़ित क्रॉलर नाम, घोषित उद्देश्य, robots के प्रति व्यवहार, सत्यापन की विधि, प्रासंगिक नियंत्रण, दस्तावेज़ों की अंतिम समीक्षा तिथि, और आपके लॉग वास्तव में क्या दिखाते हैं। जहाँ प्रदाता ख़ुद ऐसा करता है, वहाँ प्रशिक्षण-केंद्रित क्रॉलर, सर्च या पुनर्प्राप्ति बॉट और उपयोगकर्ता द्वारा शुरू की गई फ़ेच को अलग-अलग रखें। यह मैट्रिक्स किसी पुरानी ब्लॉग पोस्ट से नक़ल किए गए नियम को स्थायी बुनियादी ढाँचा बनने से रोकती है। वह विरोधाभास भी सामने ला देती है — जैसे प्रदाता एक बॉट का दस्तावेज़ देता हो जबकि लॉग में कोई और यूज़र एजेंट उन्हीं पथों पर आता दिखे, जो नीति के बारे में जल्दबाज़ी में निष्कर्ष निकालने के बजाय जाँच की माँग करता है।
बदलावों का परीक्षण सोच-समझकर करें। पिछली robots फ़ाइल सहेजें, एक साफ़ नियम तैनात करें, समय नोट करें और उसके बाद की रिक्वेस्ट देखें। सुरक्षित डेटा पर निर्भर रहने के बजाय किसी ग़ैर-संवेदनशील परीक्षण पथ का उपयोग करें। `llms.txt` के लिए फ़ाइल और उससे जुड़े विशिष्ट संसाधनों — दोनों की रिक्वेस्ट लॉग करें। कैशिंग और क्रॉल अंतराल का हिसाब रखें; तुरंत रिक्वेस्ट न आना इसका प्रमाण नहीं कि नियंत्रण अनदेखा किया जा रहा है। अगर व्यवसाय के पास स्वचालित उपयोग सीमित करने के क़ानूनी या संविदात्मक कारण हैं, तो केवल स्वैच्छिक क्रॉलर परंपराओं पर भरोसा करने के बजाय क़ानूनी सलाह और तकनीकी सुरक्षा को साथ लें। वेबसाइट का विन्यास लागू किए जा सकने वाले अधिकारों और दायित्वों का केवल एक हिस्सा है।
2026 के लिए एक व्यावहारिक नीति
`robots.txt` का उपयोग सहयोगी क्रॉलरों को मानक-आधारित निर्देश देने के लिए करें, और उसके नियम जानबूझकर सरल रखें। जो कुछ सार्वजनिक नहीं होना चाहिए, उसके लिए सर्वर-साइड प्रमाणीकरण और प्राधिकरण लगाएँ। `llms.txt` को एक वैकल्पिक खोज परत मानें, तब जब साइट के पास अच्छी तरह प्रशासित कैनोनिकल संसाधन हों जिन्हें मशीन प्रणालियाँ ढूँढ़ पाएँ तो लाभ हो। उसमें गोपनीय सामग्री की नक़ल न रखें और यह वादा न करें कि उसे प्रकाशित करने से उद्धरण मिलेंगे। हर प्रदाता के क्रॉलर दस्तावेज़ अलग से देखें, क्योंकि कोई मानक फ़ाइल आपको यह नहीं बता सकती कि हर एआई सेवा कोई रिक्वेस्ट क्यों भेजती है।
फिर साक्ष्य से इस चक्र को पूरा करें। दोनों फ़ाइलों का संस्करण रखें, परिनियोजन की तिथियाँ सुरक्षित रखें, सर्वर लॉग जाँचें, जहाँ व्यावहारिक हो वहाँ क्रॉलर की पहचान सत्यापित करें, और फ़ेच के बाद क्या होता है इसका बढ़ा-चढ़ाकर दावा किए बिना देखा गया व्यवहार दर्ज करें। इसलिए «llms.txt बनाम robots.txt» का असली सार दो प्रतिस्पर्धी बहिष्करण प्रणालियों में से एक चुनना नहीं है। एक मानकीकृत क्रॉलर निर्देश प्रोटोकॉल है; दूसरा सामग्री-खोज का स्वैच्छिक प्रस्ताव। इनमें से कोई भी सुरक्षा सीमा नहीं है। एक बार ये भूमिकाएँ अलग हो जाएँ, तो कार्यान्वयन कहीं कम रहस्यमय — और परखने में कहीं आसान — हो जाता है।
व्यावहारिक चेकलिस्ट
- तय करें कि असली लक्ष्य क्रॉल नियंत्रण है, इंडेक्स नियंत्रण, खोज, या पहुँच नियंत्रण।
- robots.txt के नियम सरल रखें और उन्हें गोपनीय पथ बचाने के लिए कभी इस्तेमाल न करें।
- llms.txt को कैनोनिकल सामग्री से बना वैकल्पिक खोज मेटाडेटा मानें।
- दोनों फ़ाइलों और प्रतिनिधि लिंक किए गए पेजों की रिक्वेस्ट लॉग करें।
- जहाँ पहचान मायने रखती है, वहाँ प्रदाता की मौजूदा विधियों से क्रॉलर की पहचान सत्यापित करें।
- कॉन्फ़िगरेशन के बदलावों का संस्करण रखें और अवलोकन की अवधि दर्ज करें।
सवाल और जवाब
क्या robots.txt किसी एआई कंपनी को पेज तक पहुँचने से रोक सकता है?
वह किसी सहयोगी क्रॉलर से अनुरोध कर सकता है कि वह कोई पथ न लाए, पर RFC 9309 इस अनुरोध को प्राधिकरण तंत्र नहीं बनाता। सर्वर अब भी वह URL किसी भी ऐसे क्लाइंट को दे सकता है जिसे अन्यथा पहुँच की अनुमति है। अलग-अलग प्रदाता अलग-अलग क्रॉलर चलाते हैं और अपनी नीतियाँ ख़ुद प्रकाशित करते हैं, इसलिए संबंधित यूज़र एजेंट को मौजूदा दस्तावेज़ों से मिलाकर देखना चाहिए। अगर पेज निजी ही रहना चाहिए, तो robots.txt पर निर्भर रहने के बजाय प्रमाणीकरण या कोई अन्य सर्वर-साइड नियंत्रण लागू करें।
क्या llms.txt प्रकाशित करने से साइट के आंसर इंजन द्वारा उद्धृत होने की संभावना बढ़ती है?
इसकी कोई सामान्य गारंटी नहीं है। llms.txt परियोजना महत्वपूर्ण संसाधनों का एक सुविधाजनक Markdown नक़्शा सुझाती है, पर उसे अपनाना और आगे का व्यवहार हर सेवा पर निर्भर है। फ़ाइल के लिए आई कोई रिक्वेस्ट यह सिद्ध नहीं करती कि उसके लिंक इंडेक्स हुए, किसी उत्तर में इस्तेमाल हुए या उद्धृत हुए। प्रकाशक इसे कम लागत वाला खोज प्रयोग मान सकते हैं, बशर्ते वे इसे अद्यतन रख सकें; फिर एक्सेस लॉग और नियंत्रित प्रश्न ऑडिट से व्यवहार देखें। कैनोनिकल पेजों की गुणवत्ता और तथ्यात्मक साक्ष्य फिर भी अपने बल पर टिकने चाहिए।
मैं कैसे जानूँ कि किसी एआई क्रॉलर ने बदलाव का सम्मान किया या नहीं?
परिनियोजन का ठीक समय दर्ज करें, संबंधित यूज़र एजेंट और पथों के लिए सर्वर या CDN लॉग जाँचें, और क्रॉल के कार्यक्रम तथा कैशिंग का हिसाब रखें। अगर प्रदाता IP सत्यापन या DNS की प्रक्रिया प्रकाशित करता है, तो जहाँ क्रॉलर की पहचान महत्वपूर्ण है वहाँ उसका उपयोग करें, क्योंकि यूज़र एजेंट स्ट्रिंग नक़ली भी हो सकती है। किसी ग़ैर-संवेदनशील पथ पर परीक्षण करें और बदलाव से पहले तथा बाद की रिक्वेस्ट की तुलना करें। लॉग यह स्थापित कर सकता है कि रिक्वेस्ट सर्वर तक पहुँची; वह अकेले यह स्थापित नहीं कर सकता कि सेवा ने पहले प्राप्त की गई सामग्री का क्या किया।