🎯 कस्टमाइज़ करने योग्य, डिटेक्शन-प्रतिरोधी क्लाउड ब्राउज़र जो स्व-विकसित Chromium द्वारा संचालित है, वेब क्रॉलर और एआई एजेंट्स के लिए डिज़ाइन किया गया। 👉अभी आज़माएं
वापस ब्लॉग पर

वेब एक एक्सेस लेयर प्राप्त कर रहा है: llms.txt, साइन किए गए एजेंट, और प्रता-पे-क्रॉल

Michael Lee
Michael Lee

Expert Network Defense Engineer

22-Jul-2026

वेब ने एकल सम्मान-प्रणाली फ़ाइल पर तीस वर्ष बिताए हैं। robots.txt नम्रतापूर्वक अनुरोध करता है, किसी को पहचानता नहीं है, और कुछ भी लागू नहीं करता है - और उस समय के अधिकांश भाग के लिए यह पर्याप्त था, क्योंकि आपके पृष्ठों को पढ़ने वाली चीज़ एक सर्च इंजन थी जो ट्रैफ़िक वापस भेजता था।

वह विनिमय टूट गया है, और अब चार अलग-अलग प्रयास इसका प्रतिस्थापन करने की कोशिश कर रहे हैं। ये समान विचारों के प्रतिस्पर्धी संस्करण नहीं हैं। ये तीन अलग-अलग प्रश्नों का उत्तर देते हैं - क्या पढ़ें, कौन पूछ रहा है, और इसका क्या लागत है - और इनमें से केवल एक एक पूर्ण मानक है।

वास्तविक रूप से गायब परत पहचान है

robots.txt क्या कर सकता है और क्या नहीं, इसके साथ शुरू करें। रोबोट्स बहिष्कार प्रोटोकॉल मानक प्रकाशकों को उपयोगकर्ता-एजेंट स्ट्रिंग के अनुसार प्राथमिकताएं व्यक्त करने का एक तरीका देता है। कमजोरी उस अंतिम वाक्य में है: एक उपयोगकर्ता-एजेंट स्ट्रिंग एक दावा है, न कि एक प्रमाणीकरण। कोई भी कोई भी स्ट्रिंग भेज सकता है, और आईपी अनुमति वाले सूचियाँ बुनियादी ढांचे के परिवर्तनों के साथ खराब हो जाती हैं।

इसलिए एक प्रकाशक जो दो क्रॉलर को अलग-अलग व्यवहार करना चाहता है, उनके बीच अंतर करने का कोई विश्वसनीय तरीका नहीं है। नीचे दिए गए प्रत्येक प्रस्ताव उस अंतर से निम्नाश्रित हैं। फ़ाइल की व्यावहारिक संरचना - वाक्य-विन्यास, निदेश, और संग्रहणकर्ताओं को इसे कैसे पढ़ना चाहिए - वेब स्क्रैपिंग के लिए robots.txt गाइड में कवर किया गया है।

llms.txt "मुझे क्या पढ़ना चाहिए?" का उत्तर देता है

llms.txt प्रस्ताव एक Markdown फ़ाइल को /llms.txt पर रखता है जिसमें एक क्यूरेटेड सारांश और एक साइट के महत्वपूर्ण पृष्ठों के साफ़ पाठ संस्करणों के लिए लिंक होते हैं। llms.txt प्रस्ताव को जेरेमी हावर्ड द्वारा सितंबर 2024 में प्रकाशित किया गया था, और इसका stated समस्या संदर्भ विंडो है: मॉडल एक पूरे साइट को नहीं ले सकते, और HTML को उपयोगी पाठ में परिवर्तित करना नुकसानदेह होता है।

इसकी स्थिति के बारे में सटीक होना महत्वपूर्ण है, क्योंकि इसे अक्सर एक मानक के रूप में वर्णित किया जाता है। साइट स्वयं इसे "एक प्रस्ताव मानकीकरण के लिए" कहती है। कोई RFC नहीं है, कोई कार्य समूह नहीं है, और किसी के लिए इसे मानने की कोई आवश्यकता नहीं है।

यह वास्तव में क्यूरेशन में अच्छा है। एक प्रकाशक जो एक लिखता है, वह कहता है यह मेरी सामग्री का अच्छा संस्करण है, जो एक अच्छी तरह से व्यवहार करने वाले पाठक की मदद करता है और एक बुरे व्यवहार करने वाले को कुछ भी नहीं लागत। यह प्राथमिकता व्यक्त करता है, अनुमति नहीं — यही सीमितता robots.txt की है।

वेब बॉट प्राधिकरण "कौन पूछ रहा है?" का उत्तर देता है

यह वह हिस्सा है जो वास्तव में पहचान के अंतर को संबोधित करता है। दृष्टिकोण: स्वचालित ग्राहक से प्रत्येक अनुरोध में एक क्रिप्टोग्राफिक संकेत होता है जो इसके ऑपरेटर के निजी कुंजी के साथ बनाया जाता है, जिससे उपस्थिति सर्वर यह सत्यापित कर सकता है कि कौन कॉल कर रहा है, header पर भरोसा करने के बजाय।

वर्तमान विशिष्टता वेब बॉट प्राधिकरण HTTP संदेश हस्ताक्षरों का मसौदा है, जो HTTP संदेश हस्ताक्षरों पर निर्मित एक सक्रिय व्यक्तिगत इंटरनेट-ड्राफ्ट है। इसका खुद का फ्रेमिंग यह है कि आईपी अनुमति सूची और उपयोगकर्ता-एजेंट स्ट्रिंग पर्याप्त पहचान नहीं हैं।

दो चेतावनियाँ महत्वपूर्ण हैं। यह एक व्यक्तिगत प्रस्तुति है न कि कार्य समूह का उत्पादन, और समान लेखकों से एक पूर्व आर्किटेक्चर ड्राफ्ट पहले ही समाप्त हो चुका है और इसे प्रतिस्थापित कर दिया गया है - मानकों के काम के लिए सामान्य, लेकिन यह एक संकेत है कि यह प्रारंभिक है। और साइनिंग आप कौन हैं यह साबित करता है, न कि आप अनुमति प्राप्त हैं। यह प्रकाशकों को निर्णय लेने के लिए कुछ देता है; यह निर्णय नहीं लेता।

पे-पर-क्रॉल और RSL "इसकी लागत क्या है?" का उत्तर देते हैं

दो प्रयास प्रतिकारी, लेकिन विपरीत दिशाओं से मुआवज़े को संबोधित करते हैं।

Cloudflare का पे-पर-क्रॉल HTTP 402 का उपयोग करता है, स्थिति कोड जो HTTP अर्थशास्त्र विशिष्टता के लिए भुगतान के लिए आरक्षित है और दशकों से अप्रयुक्त है। प्रकाशक प्रति अनुरोध मूल्य निर्धारित करते हैं और प्रत्येक क्रॉलर अनुमति देते हैं, शुल्क लेते हैं, या ब्लॉक करते हैं; क्रॉलर मूल्य शीर्षकों के माध्यम से इरादे को संकेत करते हैं और वेब बॉट प्रमाणीकरण हस्ताक्षरों द्वारा पहचाने जाते हैं। इसकी घोषणा जुलाई 2025 में की गई थी और यह निजी बीटा में है - एक सक्रिय प्रयोग, न कि बुनियादी ढांचे के खिलाफ आप निर्माण कर सकते हैं।

RSL लाइसेंसिंग मार्ग अपनाता है। वास्तव में सरल लाइसेंसिंग मानक मशीन-पठनीय लाइसेंसिंग शर्तें - श्रेय, प्रति क्रॉल भुगतान, प्रति अनुमान भुगतान - को XML के रूप में परिभाषित करता है जिसे robots.txt, HTML, HTTP हेडर, RSS फ़ीड या मीडिया फ़ाइलों से संदर्भित किया जा सकता है। RSL 1.0 ने 2025 में आकाamai, Cloudflare, Creative Commons, Fastly, Reddit, O'Reilly Media, Vox Media, Yahoo, और Ziff Davis के समर्थन के साथ भेजा।

चार में से, RSL एक प्रकाशित विशिष्टता के रूप में सबसे आगे है जो नामित उद्योग अपनाने के साथ है। इससे यह स्थिर नहीं होता है - लाइसेंसिंग व्याकरण को अब भी किसीके द्वारा लागू करने वाला होना चाहिए, और लागू करना आपको पहचान पर लौटाता है।

वे परतें जो वे प्रदर्शित करती हैं

साथ में पढ़ने पर, ये विकल्पों के बजाय परतें हैं:

  • प्राथमिकताrobots.txt और llms.txt बताते हैं कि प्रकाशक क्या चाहता है।
  • पहचान — वेब बॉट ऑथ बताता है कि कौन पूछ रहा है, क्रिप्टोग्राफ़िक रूप से।
  • शर्तें — RSL बताता है कि सामग्री का उपयोग किस लिए किया जा सकता है और किस कीमत पर।
  • निपटान — भुगतान-प्रत-क्लाइमब शैली 402 प्रवाह बताते हैं कि पैसा कैसे वास्तव में स्थानांतरित होता है।

क्रम महत्वपूर्ण है। पहचान के बिना शर्तें लागू नहीं की जा सकतीं, और शर्तों के बिना निपटान एक टोल बूथ है जिसमें कोई तय शुल्क नहीं है। पहचान वह लोड-बीयरिंग परत है, और यह सबसे कम तैयार है।

जहां यह संभवतः कम पड़ सकता है

इसका स्पष्ट विरोध: यहां कोई भी बंधा हुआ नहीं है जो भाग लेना नहीं चाहता। एक क्लाइंट जो llms.txt की अनदेखी करता है, कोई हस्ताक्षर नहीं भेजता, और कभी भी RSL फ़ाइल नहीं पढ़ता, ठीक उसी स्थिति में है जिसमें क्लाइंट हमेशा रहे हैं। ये तंत्र उन ऑपरेटरों पर काम करते हैं जो पहचान योग्य होना चाहते हैं — जो अधिकांश बड़े, जिम्मेदार होते हैं, और न ही बाकी।

दूसरी समस्या एकत्रीकरण है। हस्ताक्षर-आधारित पहचान उन ऑपरेटरों को प्राथमिकता देती है जो पर्याप्त बड़े होते हैं ताकि वे प्रमुख बुनियादी ढांचा चला सकें और उनकी कुंजियाँ मान्यता प्राप्त कर सकें। एक शोधकर्ता, एक स्टार्टअप, या एक सार्वजनिक-हित आर्काइव नए पहुंच स्तर को पहले वाले सम्मान प्रणाली की तुलना में प्रवेश करने में कठिन पा सकते हैं। यह एक वास्तविक लागत है, और इसे एक साफ़ वेब पर गोलाई के त्रुटि के रूप में मानने के बजाय उल्लेख करना उचित है।

तीसरा, इनमें से कोई भी असंतुलन को संबोधित नहीं करता जो टूटने का कारण था। खोज-युग में क्रॉलिंग ने ट्रैफ़िक के लिए पहुंच का व्यापार किया। एक मॉडल जो आपके पृष्ठ को पढ़ता है और प्रश्न का उत्तर खुद देता है, कुछ भी वापस नहीं लौटाता, और एक भुगतान रेल संबंध को पुनर्स्थापित नहीं करता — यह इसकी अनुपस्थिति की कीमत लगाता है।

वास्तव में क्या करें

अगर आप प्रकाशन करते हैं: एक llms.txt लिखें — यह सस्ता है और यह आपके द्वारा नियंत्रित क्यूरेशन को व्यक्त करता है। RSL पर नज़र रखें, क्योंकि मशीन-फुर्ती से पढ़े जाने योग्य लाइसेंस वह संग्रहीत वस्तु है जिस पर भविष्य का विवाद केंद्रित होगा। भुगतान-प्रत-क्लाइमब को एक प्रयोग के रूप में देखें न कि योजना के रूप में।

अगर आप डेटा एकत्र करते हैं: स्थायी कदम यह है कि इन प्रणालियों का समर्थन करने के लिए उस प्रकार के क्लाइंट बनें। अपनी पहचान ईमानदारी से बताएं, सार्वजनिक डेटा पर रहें, आज के निर्देशों का सम्मान करें, मात्रा को अनुपात में रखें, और आपने जो कुछ भी एकत्र किया है उसका रिकॉर्ड रखें और कहाँ से। ऊपर दिए गए हर प्रस्ताव में उन ऑपरेटरों को पुरस्कार दिया जाता है जो "आप कौन हैं और आपने क्या लिया" का उत्तर दे सकते हैं — और यह करना अब महत्वपूर्ण है, जब उत्तर अभी भी स्वैच्छिक है।

सम्मान प्रणाली समाप्त हो रही है। जो इसकी जगह लेगा वह अधूरा है, और उपयोगी दृष्टिकोण न तो इसकी प्रतीक्षा करना है और न ही इसे अनदेखा करना है, बल्कि अब ऐसे व्यवहार करना है जैसा कि तैयार संस्करण की आवश्यकता होगी।

Scrapeless मुफ्त योजना पर शुरू करें यह देखने के लिए कि Scrapeless AI एजेंट सार्वजनिक वेब डेटा को कैसे संभालता है, और जब आप संग्रह कार्यक्रम की योजना बनाते हैं तो Scrapeless मूल्य निर्धारण की समीक्षा करें।

एफएक्यू

प्रश्न: क्या llms.txt एक आधिकारिक मानक है?

नहीं। इसे मानकीकरण का प्रस्ताव के रूप में स्पष्ट रूप से प्रस्तुत किया गया है, जो सितंबर 2024 में प्रकाशित हुआ। इसके पीछे कोई RFC और न ही कार्य समूह है, और किसी क्लाइंट के लिए इसे सम्मानित करना अनिवार्य नहीं है। साइटें इसे अपनाती हैं क्योंकि क्यूरेशन अच्छे व्यवहार वाले पाठकों की मदद करती है, न कि क्योंकि कुछ इसे मजबूर करता है।

प्रश्न: क्या llms.txt robots.txt को प्रतिस्थापित करता है?

नहीं — वे अलग-अलग प्रश्नों का उत्तर देते हैं। robots.txt, RFC 9309 में मानकीकृत किया गया है, बताता है कि कौन से रास्तों को क्लाइंट नहीं लेना चाहिए। llms.txt उस सामग्री की ओर इशारा करता है जिसे एक प्रकाशक सबसे उपयोगी मानता है और इसके साफ़ पाठ संस्करणों की पेशकश करता है। एक प्रतिबंध लगाता है, दूसरा क्यूरेट करता है, और न ही क्लाइंट को प्रमाणित करता है।

प्रश्न: वेब बॉट ऑथ वास्तव में कौन सी समस्या का समाधान करता है?

यह क्रॉलर की पहचान को सत्यापित करने योग्य बनाता है। आज एक क्लाइंट अपने आप को एक यूज़र-एजेंट स्ट्रिंग के साथ पहचानता है जिसे कोई भी कॉपी कर सकता है, इसलिए प्रकाशक क्रॉलर्स के बीच विश्वसनीय रूप से अंतर नहीं कर सकते। वेब बॉट ऑथ प्रत्येक अनुरोध को ऑपरेटर की निजी कुंजी के साथ HTTP संदेश हस्ताक्षरों का उपयोग करते हुए साइन करता है, ताकि मूल यह सत्यापित कर सके कि कौन कॉल कर रहा है। यह एक सक्रिय व्यक्तिगत इंटरनेट-ड्राफ्ट है, न कि एक तैयार मानक।

प्रश्न: क्या प्रकाशक आज AI क्राउलर्स से चार्ज कर सकते हैं?

केवल प्रयोगात्मक रूप से। क्लाउडफ्लेयर का भुगतान-प्रत-क्लाइमब HTTP 402 का उपयोग करता है जिसमें प्रति-अनुरोध मूल्य निर्धारण है और इसे जुलाई 2025 में घोषित किया गया था, लेकिन यह अभी भी निजी बीटा में है। RSL, जो 2025 में एक समूह द्वारा प्रकाशित किया गया था जो बुनियादी ढांचा कंपनियों और प्रकाशकों का समर्थन करता है, मशीन-फुर्ती से पढ़े जाने योग्य लाइसेंस शर्तें परिभाषित करता है जिनमें भुगतान-प्रत-क्लाइमब और भुगतान-प्रत-इनफेरेंस शामिल हैं — लेकिन एक लाइसेंस अभी भी इस पर निर्भर करता है कि कोई व्यक्ति पहचान करता है और क्लाइंट के खिलाफ प्रवर्तन करता है।

प्रश्न: डेटा संग्रह टीम को इस बीच क्या करना चाहिए?
व्यवहार करें जैसे कि पहचान और शर्तें पहले से लागू हैं। केवल सार्वजनिक डेटा इकट्ठा करें, वर्तमान दिशानिर्देशों का सम्मान करें, अनुरोध की मात्रा उस मात्रा के अनुरूप रखें जो एक साइट प्रदान कर सकती है, और जो वसूला गया है और जहाँ से वसूला गया है उसे रिकॉर्ड करें। टेबल पर प्रत्येक प्रस्ताव उन ऑपरेटरों को पुरस्कृत करता है जो उस प्रश्न का उत्तर दे सकते हैं, इसलिए काम व्यर्थ नहीं होता चाहे जो भी जीतता है।

स्क्रैपलेस में, हम केवल सार्वजनिक रूप से उपलब्ध डेटा का उपयोग करते हैं, जबकि लागू कानूनों, विनियमों और वेबसाइट गोपनीयता नीतियों का सख्ती से अनुपालन करते हैं। इस ब्लॉग में सामग्री केवल प्रदर्शन उद्देश्यों के लिए है और इसमें कोई अवैध या उल्लंघन करने वाली गतिविधियों को शामिल नहीं किया गया है। हम इस ब्लॉग या तृतीय-पक्ष लिंक से जानकारी के उपयोग के लिए सभी देयता को कोई गारंटी नहीं देते हैं और सभी देयता का खुलासा करते हैं। किसी भी स्क्रैपिंग गतिविधियों में संलग्न होने से पहले, अपने कानूनी सलाहकार से परामर्श करें और लक्ष्य वेबसाइट की सेवा की शर्तों की समीक्षा करें या आवश्यक अनुमतियाँ प्राप्त करें।

सबसे लोकप्रिय लेख

सूची