वेबसाइट पर robots.txt कैसे जांचें

कैसे जांचें कि किसी वेबसाइट पर robots.txt फ़ाइल है या नहीं

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

अगर आप जानना चाहते हैं कि किसी वेबसाइट पर robots.txt फ़ाइल है या नहीं, तो सबसे पहले साइट का सटीक ओरिजिन देखें। फिर सर्वर के जवाब और फ़ाइल की सामग्री को जांचें। वेबसाइट की robots.txt फ़ाइल कैसे देखें, यह जानने के लिए उसका पूरा URL खोलें और जवाब का स्टेटस नोट करें। ये बातें अहम हैं: एक सबडोमेन की फ़ाइल से दूसरे सबडोमेन के बारे में कुछ पता नहीं चलता, और ब्राउज़र में दिखने वाली त्रुटि का मतलब हमेशा यह नहीं होता कि फ़ाइल मौजूद नहीं है।

1. जानें कि robots.txt क्या बता सकती है और क्या नहीं

robots.txt में ऑटोमेटेड क्रॉलर्स के लिए नियम होते हैं। कोई नियम किसी निर्देश का पालन करने वाले सर्च बॉट से /private/जैसे पाथ को क्रॉल न करने के लिए कह सकता है। यह निर्देश एक अनुरोध है, ऐक्सेस कंट्रोल का तरीका नहीं: कोई व्यक्ति फिर भी उस URL को खोल सकता है और कोई बॉट इस अनुरोध को अनदेखा कर सकता है।

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

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

2. वेबसाइट की robots.txt फ़ाइल सही ओरिजिन पर ढूंढें

https://example.com वाली साइट के लिए आम तौर पर फ़ाइल https://example.com/robots.txt पर होती है। वेबसाइट की robots.txt फ़ाइल ढूंढने के लिए, एड्रेस बार में दिख रहे प्रोटोकॉल और होस्टनेम को ज्यों का त्यों रखें। अगर साइट किसी ऐसे पोर्ट का इस्तेमाल करती है जो डिफ़ॉल्ट नहीं है, तो उसे भी शामिल करें। फ़ाइल उस ओरिजिन के रूट पर होती है, /blog/ जैसे किसी फ़ोल्डर के अंदर नहीं।

प्रोटोकॉल या होस्टनेम बदलने पर नतीजा भी अलग हो सकता है। उदाहरण के लिए, http://example.com/robots.txt и https://example.com/robots.txt अलग-अलग अनुरोध हैं, भले ही उनमें से एक दूसरे पर रीडायरेक्ट हो जाए। इसी तरह, www.example.com и example.com को अलग-अलग कॉन्फ़िगर किया जा सकता है।

हर सबडोमेन का अपना ओरिजिन होता है। https://shop.example.com/robots.txt पर मौजूद फ़ाइल अपने-आप https://example.com/ या https://help.example.com/पर लागू नहीं होती। जिस होस्ट को जांचना है, उसी को देखें—खासकर तब, जब किसी कंपनी की ऑनलाइन दुकान, सहायता केंद्र और मुख्य साइट अलग-अलग सबडोमेन पर हों।

शुरुआती जांच के लिए एड्रेस बार का इस्तेमाल करें: robots.txt का पूरा URL डालें और देखें कि क्या खुलता है। robots.txt फ़ाइल मौजूद है या नहीं कैसे जांचें, यह समझने के लिए सिर्फ़ पेज खुलने पर निर्भर न रहें; सादा टेक्स्ट दिखना आम बात है, लेकिन ब्राउज़र में फ़ॉर्मैट किया हुआ दृश्य भी ठीक है। अहम बात यह है कि आपने कौन-सा URL खोला और सर्वर ने क्या जवाब दिया।

3. ब्राउज़र में दिखने वाले पेज के साथ सर्वर का जवाब भी जांचें

सफल जवाब का आम तौर पर मतलब है कि सर्वर ने उस URL के लिए सामग्री भेजी है। कई साइटें 200जैसा HTTP स्टेटस लौटाती हैं, लेकिन दिखाई देने वाला टेक्स्ट नियमों की सूची, खाली फ़ाइल या कोई अनपेक्षित पेज भी हो सकता है। सिर्फ़ पेज खुल जाने को मान्य robots.txt फ़ाइल का प्रमाण न मानें; स्टेटस और जवाब—दोनों देखें।

आमतौर पर 404 जैसा ‘नहीं मिला’ जवाब बताता है कि उस समय उस ओरिजिन पर अनुरोधित पाथ मौजूद नहीं था। यह उपयोगी जानकारी है, लेकिन पहले होस्टनेम और रीडायरेक्ट जांच लें। टाइपो या किसी दूसरे सबडोमेन की वजह से भी यही नतीजा मिल सकता है।

रीडायरेक्ट को थोड़ा ध्यान से समझना चाहिए। अनुरोधित URL आपको किसी दूसरे होस्ट या पाथ पर भेज सकता है और उस जगह से मिलने वाली सामग्री किसी दूसरे ओरिजिन की हो सकती है। यह तय करने से पहले कि आपने किस साइट के निर्देश पढ़े हैं, मूल URL और आखिरी डेस्टिनेशन—दोनों नोट कर लें।

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

साइट की जांच से जुड़े एक और काम के लिए, आप यह भी पढ़ सकते हैं कि कैसे जांचें कि कोई वेबसाइट एफिलिएट संबंधी जानकारी प्रकाशित करती है या नहीं। यह जांच पाठकों को दिखाई देने वाली नीति से जुड़ी है, क्रॉलर के निर्देशों से नहीं।

4. जिस क्रॉलर की जांच कर रहे हैं, उसके लिए robots.txt के निर्देश देखें

robots.txt के निर्देश कैसे पढ़ें, इसके लिए हर नियम-समूह को उसके संदर्भ में देखें। User-agent वाली पंक्ति क्रॉलर का नाम बताती है, जबकि Disallow और Allow वाली पंक्तियां उन पाथ का विवरण देती हैं जिन्हें उस क्रॉलर से क्रॉल न करने या क्रॉल करने के लिए कहा गया है। इनका सटीक अर्थ क्रॉलर के हिसाब से बदल सकता है, इसलिए नतीजा अहम हो तो उसके दस्तावेज़ देखें।

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

पाथ भी मायने रखते हैं। /images/ का नियम /के नियम जैसा नहीं है, और /drafts/ का नियम ज़रूरी नहीं कि किसी दूसरी जगह मौजूद मिलते-जुलते पाथ को भी कवर करे। किसी URL पर नियम लागू करने से पहले पूरा पाथ और वह किस समूह के तहत दिया गया है—दोनों देखें।

मान लें कि किसी सामान्य यूज़र-एजेंट समूह के तहत फ़ाइल में Disallow: /private/लिखा है। इसका मतलब है कि संबंधित क्रॉलर्स से उस डायरेक्टरी के अंदर के पाथ क्रॉल न करने का अनुरोध किया गया है। इससे कोई व्यक्ति जाना-पहचाना URL खोलने से नहीं रुकता और न ही यह साबित होता है कि हर बॉट इस निर्देश का पालन करेगा।

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

5. खाली, गायब और अमान्य फ़ाइल में अंतर समझें

खाली जवाब और गायब फ़ाइल, दो अलग बातें हैं। अगर सर्वर बिना किसी दिखाई देने वाले टेक्स्ट के सफल जवाब देता है, तो हो सकता है फ़ाइल मौजूद हो, लेकिन उसमें कोई निर्देश न हों। अगर सर्वर ‘नहीं मिला’ स्टेटस लौटाता है, तो उसे अनुरोधित URL पर फ़ाइल नहीं मिली। स्टेटस और सामग्री—दोनों दर्ज करें, ताकि इन स्थितियों में गड़बड़ी न हो।

अनपेक्षित सामग्री को दोबारा जांचना चाहिए। अगर पेज पर साइट-व्यापी त्रुटि संदेश, लॉगिन स्क्रीन या HTML मार्कअप दिखता है, तो हो सकता है अनुरोध सामान्य robots.txt फ़ाइल के बजाय किसी डिफ़ॉल्ट पेज पर पहुंचा हो। URL सफलतापूर्वक खुल सकता है, फिर भी उसमें क्रॉलिंग के निर्देशों के लिए अनुपयोगी सामग्री हो सकती है।

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

6. किसी दूसरे तरीके से नतीजों की पुष्टि करें

अगर ब्राउज़र का नतीजा स्पष्ट नहीं है, तो कमांड लाइन से अनुरोध करें। उदाहरण के लिए, curl -i https://example.com/robots.txt एक ही अनुरोध में रिस्पॉन्स हेडर और सर्वर से मिली सामग्री दिखा सकता है। उदाहरण वाले पते की जगह वही सटीक ओरिजिन डालें जिसकी जांच कर रहे हैं; ज़रूरत पड़ने पर सही सबडोमेन और पोर्ट भी शामिल करें।

ब्राउज़र के डेवलपर टूल एक और विकल्प हैं। Network पैनल खोलें, robots.txt URL लोड करें और उस अनुरोध को चुनें, ताकि उसका स्टेटस, हेडर और जवाब की सामग्री देख सकें। जब ब्राउज़र रीडायरेक्ट या फ़ॉर्मैट किया हुआ पेज दिखाए, लेकिन आखिरी डेस्टिनेशन स्पष्ट न हो, तब यह तरीका मददगार है।

अगर दोनों तरीकों के नतीजे अलग हों, तो सटीक URL, समय, स्टेटस, रीडायरेक्ट और सामग्री की तुलना करें। कमांड लाइन और ब्राउज़र के अनुरोधों में रीडायरेक्ट का व्यवहार अलग हो सकता है या उनमें से कोई अस्थायी सर्वर समस्या का सामना कर सकता है। अगर कॉर्पोरेट प्रॉक्सी, VPN या ब्राउज़र एक्सटेंशन का इस्तेमाल हो रहा है, तो उचित होने पर उसके बिना जांचें; जवाब में बदलाव किसी बीच के सिस्टम की ओर इशारा कर सकता है, न कि खुद वेबसाइट की ओर।

साइट की जांच का एक और उदाहरण है कैसे जांचें कि कोई वेबसाइटकॉपीराइट सूचना दिखाती है या नहीं। इसे robots.txt से अलग रखें: एक पाठकों के लिए साइट का बयान है, जबकि दूसरी क्रॉलर्स के लिए बनाई गई फ़ाइल है।

7. जांच का दायरा और सीमाएं दर्ज करें

robots.txt का सटीक URL, अनुरोध की तारीख और समय, HTTP स्टेटस, रीडायरेक्ट का डेस्टिनेशन और आपको दिखी सामग्री लिख लें। अगर आप किसी खास निर्देश-समूह की व्याख्या कर रहे हैं, तो क्रॉलर या यूज़र-एजेंट का संदर्भ भी जोड़ें। साइट में बदलाव होने पर इन रिकॉर्ड्स से जांच को दोहराना आसान होगा।

निष्कर्ष को सीमित रखें। सफल जवाब बताता है कि किसी एक समय पर एक ओरिजिन के लिए सर्वर ने क्या लौटाया था; इससे यह साबित नहीं होता कि कोई पेज इंडेक्स किया गया है, हर व्यक्ति के लिए खुला है या हर क्रॉलर से ब्लॉक है। फ़ाइल न मिलने का जवाब सिर्फ़ उसी URL पर लागू होता है जिसे आपने अनुरोध किया था—अपने-आप हर सबडोमेन या प्रोटोकॉल संस्करण पर नहीं।

robots.txt बिना किसी सूचना के बदल सकती है। अगर आपका फैसला मौजूदा नियमों पर निर्भर है, तो सटीक ओरिजिन को दोबारा जांचें और पुरानी कॉपी पर निर्भर रहने के बजाय नया जवाब संभालकर रखें।