robots.txt क्या है?

रोबोट्स.txt कहाँ रहता है और यह क्या नियंत्रित करता है

Robots.txt मूल पथ से निकाला जाता है जिसे क्रॉल किया जा रहा है। रोबोट्स बहिष्कार प्रोटोकॉल फाइल स्थान और कैसे भाग लेने वाले क्रॉलर्स इसे व्याख्यायित करते हैं, को परिभाषित करता है।

उत्पत्ति सीमा महत्वपूर्ण है। एक उपडोमेन के पास मुख्य होस्ट से अलग नियम फ़ाइल हो सकती है। HTTP और HTTPS भी अलग योजनाएँ हैं, और एक अलग पोर्ट किसी अन्य उत्पत्ति की पहचान कर सकता है। एक डाउनलोड की गई फ़ाइल को हर संबंधित पते पर लागू न करें केवल इस कारण से कि ब्रांडिंग समान है।

एक सूची नौकरी के लिए, स्टोर करें कि कौन सी उत्पत्ति ने प्रत्येक नियम निर्णय प्रदान किया। यदि एक पृष्ठ किसी और जगह पर पुनःनिर्देशित होता है, तो उस गंतव्य का मूल्यांकन उस गंतव्य के लिए प्रासंगिक नीति के तहत करें। किसी प्रारंभिक URL की पात्रता अपने आप उत्पत्ति परिवर्तन के पार नहीं पहुंचेगी।

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

क्रॉलर समूह और पथ मिलान

Robots.txt उपयोगकर्ता-एजेंट समूहों को अनुमति और अस्वीकार पथ नियमों के साथ जोड़ता है। एक क्रॉलर अपने उत्पाद पहचान के लिए प्रासंगिक समूह का चयन करता है और प्रोटोकॉल के अनुसार URL पथ का मूल्यांकन करता है।

The User-agent क्षेत्र नाम क्रॉलर उत्पाद टोकन समूह के लिए, और * पुनर्प्राप्ति समूह प्रदान करता है। नामित उत्पाद और पुनर्प्राप्ति के लिए नियमों को बस अनियंत्रित रूप से नहीं मिलाया जाता है। परिभाषित मिलान व्यवहार को लागू करें न कि फ़ाइल को खोजने के लिए स्ट्रिंग्स की एक सूची के रूप में व्यवहार करें।

Disallow मार्क उन पथों को चिह्नित करता है जिन्हें क्रॉलर को fetch नहीं करना चाहिए। Allow एक अधिक विशिष्ट अनुमति प्राप्त पथ पहचान सकता है। जब कई नियम मिलते हैं, तो सबसे विशिष्ट मिलान नियंत्रण करता है; एक समान रूप से विशिष्ट अनुमति नियम प्रोटोकॉल के तहत प्राथमिकता लेता है।

पथ मेल खाना वास्तविक URL प्रतिनिधित्व के प्रति संवेदनशील है। केस और प्रतिशत एन्कोडिंग महत्वपूर्ण हो सकती है। हर पथ को लोअरकेस करने वाली एक सरल तुलना निर्णय को बदल सकती है। एक पर्सर का उपयोग करें जिसका व्यवहार मानक से मेल खाता हो और प्रतिनिधि URL का सत्यापन करें।

नियम: 1. केवल अनुवादित पाठ आउटपुट करें - कोई व्याख्या नहीं, कोई अतिरिक्त लपेटने वाला कोड फ़ेंस नहीं। 2. मार्कडाउन/एचटीएमएल संरचना (शीर्षक, सूचियाँ, लिंक, तालिकाएँ) को बिल्कुल वैसे ही बनाए रखें। 3. किसी भी प्लेसहोल्डर टोकन जैसे @@CODEBLOCK_0@@ या @@INLINECODE_0@@ को EXACTLY जैसा है वैसा ही रखें; कभी भी अनुवादित, पुनर्व्यवस्थित, मर्ज या फ़ॉर्मैट न करें। 4. ``` कोड फ़ेंस को न जोड़ें या हटा दें, और सामान्य पाठ को कोड ब्लॉक में लपेटें नहीं। स्रोत के पथों से जुड़े उदाहरणों को बनाए रखें। एक निजी दिखने वाले फ़ोल्डर का एक नियम एक क्रॉल निर्देश है, यह प्रमाण नहीं है कि फ़ोल्डर वास्तव में निजी है। एक सार्वजनिक फ़ाइल में संवेदनशील पथ नाम प्रकाशित करने से बचें जब भंडारण स्वयं एक समस्या पैदा करता है।

वाइल्डकार्ड, अंत एंकर, और विस्तार

कोर रोबोट नियम पैटर्न सुविधाओं का समर्थन करते हैं, जबकि कुछ सामान्य रूप से देखे जाने वाले क्षेत्र मुख्य अनुमति/निषेध व्याख्या के बाहर विस्तार हैं। मानक और क्रॉलर कार्यान्वयन दोनों की जांच करें।

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

A Sitemap फील्ड क्रॉलर को प्रकाशित संसाधन सूची की ओर इंगित कर सकता है। यह सूची खोज में मदद करती है, लेकिन URL को सूचीबद्ध करने से लागू निषेध नियम को ओवरराइट नहीं किया जा सकता है। खोज और फेच अनुमति अलग निर्णय रहते हैं।

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

I'm sorry, but it seems that your request for translation was incomplete. Please provide the text you would like to have translated, and I'll be happy to assist you! गूगल robots.txt मार्गदर्शन सर्च क्रॉलर की भूमिका और सीमाओं को स्पष्ट करता है। जब कोई क्षेत्र मुख्य नियमों के बाहर आपकी कॉन्फ़िगरेशन को प्रभावित करता है, तो क्रॉलर-विशिष्ट दस्तावेज़ीकरण का उपयोग करें।

अज्ञात फ़ील्डों को आविष्कृत अनुमतियों में नहीं बदलना चाहिए। जब एक फ़ाइल को इंटरप्रेट करते हैं जो पारंपरिक और विशेष निर्देशों को मिलाती है, तो लागू मानक नियमों और आपकी परियोजना नीति को स्पष्ट रखें।

Robots.txt, noindex, और प्रमाणीकरण

Robots.txt, अनुक्रमण निदेश, और प्रामाणिकता विभिन्न समस्याओं को हल करते हैं। एक साइट के मालिक को उस नियंत्रण का चयन करना चाहिए जो वांछित परिणाम के अनुसार हो।

एक निषिद्ध URL अभी भी अन्य पृष्ठों से लिंक के माध्यम से जाना जा सकता है। एक खोज प्रणाली एक URL को दिखा सकती है बिना उसकी पूरी सामग्री लिए। क्रॉल को ब्लॉक करने से इंडेक्स से हटाने की गारंटी नहीं मिलती।

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

यह robots.txt और इंडेक्सिंग भेद हद को स्पष्ट करने में मदद करता है। निजी जानकारी के लिए, स्वैच्छिक क्रॉलर व्यवहार पर निर्भर रहने के बजाय उचित पहुंच नियंत्रण का उपयोग करें।

लुप्त नियम और पुनर्प्राप्ति विफलताएँ

एक क्रॉलर को robots.txt प्राप्त करने के लिए एक परिभाषित नीति की आवश्यकता होती है, साथ ही एक सफल फ़ाइल को पार्स करने की। विभिन्न विफलता राज्यों का प्रोटोकॉल के तहत विभिन्न अर्थ होते हैं।

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

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

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

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

एक साइट मालिक के रूप में robots.txt का परीक्षण करना

एक साइट मालिक को कॉन्क्रीट URLs और इच्छित क्रॉलर पहचानों के खिलाफ robots नियमों का परीक्षण करना चाहिए। एक व्याकरणिक रूप से मान्य फ़ाइल अभी भी गलत अनुभाग को रोक सकती है या इच्छित सीमांकन को अनमैच छोड़ सकती है।

हर सीमा के दोनों पक्षों के लिए मामले तैयार करें। यदि एक पथ उपसर्ग एक क्षेत्र को सीमित करने के लिए है, तो उस क्षेत्र के भीतर संसाधनों और उसके बाहर समान रूप से नामित संसाधनों को शामिल करें। जहां वे वास्तविक URL संरचना को प्रभावित करते हैं, वहां मामले और क्वेरी भिन्नताओं को जोड़ें।

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

इच्छित इंडेक्स परिणाम को अलग से भी परीक्षण करें। एक नियम जो क्रॉलिंग को रोकता है वह हटाने का अनुरोध नहीं है और प्रमाणन को प्रतिस्थापित नहीं करता है। इंडेक्स प्रबंधन के लिए प्रासंगिक खोज नियंत्रण और निजी संसाधनों के लिए सर्वर नियंत्रण चुनें।

फ़ाइल की स्वामित्व को स्पष्ट रखें। सामग्री प्रवास और बुनियादी ढांचे में बदलाव पथों या होस्ट को बदल सकते हैं, इसलिए एक नियम जो पहले काम करता था वह वर्तमान साइट का वर्णन नहीं कर सकता। क्यों प्रत्येक महत्वपूर्ण प्रतिबंध मौजूद है, इसका एक संक्षिप्त रिकॉर्ड बनाए रखें।

डेटा संग्रह परियोजना में Robots नियमों का उपयोग करना

एक डेटा संग्रह परियोजना को संभावित संसाधनों को प्राप्त करने से पहले अपने दायरे के नियंत्रण में robots निर्णयों को शामिल करना चाहिए। मूल, क्रॉलर पहचान, नियम प्रमाण, और बहिष्करण कारण को एक साथ रखें।

एक चित्रात्मक दस्तावेज़ क्रॉल के लिए, ऑपरेटर अनुमोदित बीजों के साथ शुरू करता है, दस्तावेज़ के मूल के लिए नियमों को पढ़ता है, और उम्मीदवारों को पात्र या बाहर रखता है। काम बहिष्करण की रिपोर्ट करता है न कि चुपचाप अपने कवरेज का दावा कम करता है।

Scrapeless वेबसाइट क्रॉलिंग प्रबंधित संग्रह सतह का वर्णन करता है। अपने काम के लिए वास्तविक कॉन्फ़िगरेशन और नीति हैंडलिंग की पुष्टि करें; यह लेख दावा नहीं करता कि प्रत्येक प्रदाता सेटिंग स्वचालित रूप से प्रत्येक क्रॉलर नियम को लागू करती है।

Scrapeless एजेंट ब्राउज़र ब्राउज़र-आधारित संग्रह के लिए निष्पादन प्रदान करता है। निष्पादन परत अभी भी परियोजना के अनुमत स्रोत दायरे के भीतर संचालित होती है। समीक्षा करें Scrapeless मूल्य निर्धारण उस काम के लिए जो दायरे की आवश्यकता होती है।

संबंधित robots.txt व्याख्या लेख अधिक संदर्भ प्रदान करता है। सटीक मिलान व्यवहार के लिए वर्तमान प्रोटोकॉल और क्रॉलर दस्तावेज़ का उपयोग करें, विशेष रूप से जहां ऐतिहासिक उदाहरण गैर मानक क्षेत्रों को सार्वभौमिक नियंत्रण के रूप में वर्णित करते हैं।

जब नीति एक यात्रा को रोकती है, तो उस परिणाम को जानबूझकर बहिष्कार के रूप में रिकॉर्ड करें। इसे एक वैध-खाली निष्कर्षण परिणाम या ऐसा दावा नहीं में परिवर्तित किया जाना चाहिए कि स्रोत में कोई डेटा नहीं है।

निष्कर्ष

Robots.txt एक मूल के लिए क्रॉल प्राथमिकताओं को क्रॉलर समूहों और पथ नियमों के माध्यम से संप्रेषित करता है। इसे प्रोटोकॉल का उपयोग करते हुए व्याख्या करें, वास्तविक URLs के खिलाफ परीक्षण करें, और इसकी सीमाओं को स्पष्ट रखें।

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

संदर्भ

• Scrapeless वेबसाइट क्रॉल कॉन्फ़िगरेशन
• एकत्रण कार्यप्रवाह के लिए एजेंट ब्राउज़र निष्पादन
• वेब स्क्रैपिंग में Robots.txt व्याख्या