robots.txt के बारे में मैं कहाँ गलत था

• robots.txt सेटिंग के ज़रिए वेबसाइट के सभी क्रॉलर को ब्लॉक करने की कोशिश के बाद अनपेक्षित दुष्प्रभाव देखने को मिले
• LinkedIn पोस्ट प्रीव्यू गायब हो गया, और पोस्ट की reach भी कम होती दिखी
• वजह यह थी कि robots.txt ने LinkedInBot की पेज एक्सेस रोक दी, जिससे meta tag इकट्ठा नहीं हो सके
• अब समझ आया कि Open Graph Protocol सोशल मीडिया पर प्रीव्यू बनाने में केंद्रीय भूमिका निभाता है
• robots.txt को आंशिक अनुमति वाले तरीके से बदलकर समस्या हल की, और आगे फीचर बदलते समय पर्याप्त testing की ज़रूरत समझी

---

परिचय: robots.txt सेटिंग और अनचाही समस्या का अनुभव

• हाल में ब्लॉग पर robots.txt सेटिंग सीखते हुए मैंने अपने कंटेंट के data rights के बारे में सोचना शुरू किया
• वेबसाइट पर सभी क्रॉलर को ब्लॉक करने के लिए robots.txt बदला
• लेकिन अनपेक्षित रूप से वेबसाइट पर अवांछित नतीजे सामने आए

LinkedIn पोस्ट प्रीव्यू की समस्या

• robots.txt बदलने के बाद, जब मैंने LinkedIn पर अपने ब्लॉग का लिंक डाला तो प्रीव्यू (thumbnail, summary) दिखाई नहीं दिया
• पहले तक प्रीव्यू सामान्य रूप से दिखता था, लेकिन बदलाव के बाद visibility और engagement तेज़ी से घट गए
• शुरू में लगा कि यह अस्थायी समस्या है, लेकिन 2 हफ्ते से ज़्यादा समय तक यह जारी रही
• LinkedIn Post Inspector से जाँच करने पर पता चला कि robots.txt, LinkedInBot की access सीमित कर रहा था, इसलिए meta information इकट्ठा नहीं हो पा रही थी
• सोशल मीडिया प्लेटफ़ॉर्म पर link preview बनाने के लिए पेज request और meta tag इकट्ठा करना ज़रूरी होता है

Open Graph Protocol का परिचय

• Open Graph Protocol(OGP) Facebook द्वारा बनाया गया एक standard protocol है, जो वेबपेज को social graph object में बदल देता है
• OGP कुछ न्यूनतम अनिवार्य meta tag परिभाषित करता है
  • og:title: पोस्ट का शीर्षक
  • og:type: ऑब्जेक्ट का प्रकार, उदाहरण के लिए "video.movie"
  • og:image: thumbnail image URL
  • og:url: उस ऑब्जेक्ट का canonical URL
• इस protocol की वजह से अलग-अलग सोशल प्लेटफ़ॉर्म पर कंटेंट प्रभावी ढंग से सारांशित होकर आकर्षक रूप में दिखाया जा सकता है

robots.txt में आंशिक अनुमति देकर समाधान

• समस्या हल करने के लिए robots.txt को इस तरह बदला कि सिर्फ LinkedInBot को अनुमति मिले
• अगर दूसरे सोशल प्लेटफ़ॉर्म के प्रीव्यू भी चाहिए हों, तो उनके बॉट्स को भी अलग-अलग अनुमति देनी होगी
• अभी इस्तेमाल की जा रही सेटिंग का उदाहरण:

  User-agent: LinkedInBot
  Allow: /
  
  User-agent: *
  Disallow: /
  

पुनरावलोकन और सीखी गई बातें

• सभी क्रॉलर को बिना सोचे-समझे ब्लॉक करने से कंटेंट visibility और presentation में समस्या आ सकती है
• बिना पर्याप्त testing के बदलाव लागू करना मेरी गलती थी
• इस अनुभव से Open Graph Protocol, LinkedIn Post Inspector जैसे उपयोगी tools और web standards के बारे में ज़्यादा जानने को मिला
• फीचर जोड़ते या बदलते समय पूरे impact area को अच्छी तरह समझना और verify करना ज़रूरी है
• शुरुआत में मैं OGP और robots.txt ब्लॉकिंग के संबंध को जोड़ नहीं पाया था, लेकिन इस अनुभव से इसकी अहमियत समझ आई

[GN⁺]

Hacker News राय

• पहले robots.txt का मुख्य उद्देश्य search engine में duplicate content penalty को रोकना था। जब कोई मुश्किल dynamic site चलाते हुए query parameters वगैरह के कारण एक ही page कई URL पर दिखने लगता था, तो search engine penalty दे देते थे। robots.txt का काम यह बताना था कि "यही canonical URL है, बाकी को ignore करो"। इसके अलावा यह ‘अच्छे’ crawlers को infinite link crawling में भटकने से भी बचाता था। बेशक ‘बुरे’ crawlers ने इसकी कभी परवाह नहीं की, और ऐसे bots को IP block जैसी चीज़ों से रोका जाता था। User-Agent आधारित block का कोई खास मतलब नहीं था। यह मान लेना कि malicious bot शांति से नियम मानेंगे, एक भोली सोच है। DNT(Do Not Track) header भी कुछ ऐसा ही था, जैसे tracking से कमाई करने वाली कंपनियों से कहना, "कृपया track मत कीजिए"। या फिर RFC के Evil Bit वाले विचार जैसा, जिसमें उम्मीद की जाए कि malicious packets खुद header में लिख दें कि "मैं malicious हूँ"

  • यह याद रखना चाहिए कि Evil Bit प्रस्ताव April Fools RFC था RFC 3514 देखें

  • आखिरकार यह सोच भी आती है कि robots.txt की भूमिका sitemap जैसी है या नहीं, लेकिन असल में यह बिल्कुल उलटा है। robots.txt बताता है कि crawler कहाँ न जाए, जबकि sitemap बताता है कि किन चीज़ों को index किया जाए। duplicate content penalty प्रबंधन वाला इसका मूल उद्देश्य मुझे पता नहीं था, इसलिए SEO control के नज़रिए में इससे एक नया context जुड़ता है

  • मूल बात यह है कि जब किसी व्यवहार को ‘निषिद्ध’ घोषित किया जाता है, तो उसका असर सिर्फ कुछ ईमानदार agents या उन मामलों में दिखता है जहाँ user agent नाम ठीक से छिपाया नहीं गया हो। उससे आगे यह ज़्यादा काम नहीं करता, इसलिए अंततः यह कुछ हद तक प्रतीकात्मक कदम ही है

  • DNT header की तरह, जो चीज़ें व्यवहार में लागू करना मुश्किल लगती हैं वे अक्सर आलोचना झेलती हैं, लेकिन DNT का विचार दरअसल कानूनी व्यवस्था के साथ लागू करने की कोशिश था। भले ही पूरी तरह तकनीकी रोक मुश्किल हो, बड़े पैमाने पर गैरकानूनी काम करते रहना अंततः whistleblower के ज़रिए उजागर हो सकता है, यह ध्यान में रखना चाहिए

  • कुछ लोग मानते हैं कि नियम बना दो तो सब मानेंगे, और कभी-कभी यह सोचकर हैरानी होती है कि क्या यह विश्वास सांस्कृतिक अंतर से आता है

• मैंने 2003 में खुद एक search engine बनाया था और web crawl किया था। User-Agent में contact email डाल दी थी, और उसके बाद मुझे बहुत सारे protest emails मिले। मैंने crawler को जितना हो सके उतना ईमानदारी और शिष्टता से बनाया था, फिर भी लोगों को Google के अलावा कोई और मंजूर नहीं था। ऐसी सोच ही Google के खिलाफ competitors के उभरने को रोकती है। यह सिर्फ LinkedIn preview की समस्या नहीं है, बल्कि यह भी सोचना चाहिए कि web विभिन्न bots और users के लिए खुला होना चाहिए। बेशक बुरे crawlers को रोकना चाहिए, लेकिन हर bot को default रूप से malicious मानना ठीक नहीं है

  • एक bot को ईमानदारी से चलाने वाले के रूप में मेरा सबसे झुंझलाने वाला अनुभव यह था कि किसी ने मेरे bot के user agent का नाम लेकर malicious bot बनाया, हमला किया, और शिकायतें मेरे पास आईं

  • कोई भी अपने bot की रक्षा करना चाहेगा, लेकिन असली समस्या सिर्फ एक bot की नहीं है, बल्कि वही जैसे 9000 bots घूमते रहते हैं और server resources का ज़्यादा इस्तेमाल करते हैं। ऐसे bots वास्तव में referral traffic भी नहीं लाते

  • मैंने भी शुरुआत में सब कुछ block करने वाला रुख अपनाया था, लेकिन बाद में web की interconnectivity और complexity समझ आई। मुझे लगता है कि अपने resources पर control होना ज़रूरी है। लेकिन जब आप तय करते हैं कि किस traffic को allow या block करना है, तो खुद से ‘क्यों’ पूछना चाहिए और यह समझना चाहिए कि हर bot क्या कर रहा है। इस प्रक्रिया में समय और मेहनत लगती है। AI कंपनियों की training data के लिए अंधाधुंध crawling की आदत के कारण ही मेरी robots.txt में रुचि शुरू हुई। मैं allow/block का फैसला खुद करना चाहता हूँ। सभी bots robots.txt का पालन नहीं करते, लेकिन काफ़ी करते हैं। इसे सीधे test करने का एक तरीका है किसी browsing-enabled model से किसी खास link को scrape करने के लिए कहना। मूल रूप से यह ज़्यादा अहम है कि bot malicious है या नहीं, यह कंपनी data का उपयोग कैसे करती है और मुझे उसके बारे में कैसा लगता है

  • “सभी bots malicious नहीं होते, इसलिए सबको अंधाधुंध block मत करो” इस दावे पर मेरा मानना है कि भरोसे के आधार के बिना access देना एक जोखिमभरी strategy है

  • अज्ञात crawlers पर शक करना स्वाभाविक है। ज़्यादातर crawlers malicious होते हैं, और पहले से यह जानना संभव नहीं कि कौन अच्छा है कौन बुरा, इसलिए default रूप से unknown bots को अस्थायी तौर पर malicious मानना तर्कसंगत है

• मैं आलोचनात्मक राय देने से बचने की कोशिश करता हूँ, लेकिन इस लेख को पढ़कर हैरानी हुई कि लेखक अपनी हरकतों के नतीजों को मानो बहुत गहराई से समझ लेने जैसा पेश कर रहा है। personal growth की कहानी अपनी जगह ठीक है, लेकिन यह लेख insight से ज़्यादा ignorance की confession जैसा लगता है। अंत में यह ध्यान खींचने के लिए लिखा गया पोस्ट ज़्यादा लगता है

  • लेखक page preview fetcher को crawler के रूप में पहचान नहीं पाया था, और उसे robots.txt से block करने का सोच भी नहीं रहा था। भले यह कोई चौंकाने वाली बात न हो, लेकिन कम से कम उसके लिए यह सीखने जैसा था। मुझे लगता है कि असली इंसान द्वारा लिखे गए blog posts web की औसत quality बढ़ा सकते हैं

  • Google में न दिखने की वजह से ही इसने यहाँ(Hacker News) पोस्ट किया है

  • मेरे लिए भी इसमें कुछ बातें सचमुच नई थीं। Open Graph Protocol और Robots Exclusion Protocol के बारे में और सीखने का मौका मिला। मैं आमतौर पर जो चीज़ें खुद सीखता हूँ या दिलचस्प लगती हैं, उन्हें दर्ज करके साझा करता हूँ। लगा कि यह दूसरों को भी रोचक लग सकता है, इसलिए शेयर किया

  • समझ नहीं आता यह पोस्ट front page तक कैसे पहुँच गई। लगता है बस “रास्ता बंद करो तो अच्छे लोग बचकर निकल जाते हैं और बुरे लोग अनदेखा कर देते हैं” जैसी बहुत obvious बात को लंबा खींचा गया है। आखिर robots.txt एक विनम्र “कृपया ऐसा न करें” भर है, firewall नहीं, यह तो साफ़ है

• robots.txt की समस्या यह है कि यह crawler के उद्देश्य पर नहीं, बल्कि उसकी ‘पहचान’ पर filtering करता है। लेखक ने भी AI scraping रोकने के लिए सब bots block किए, लेकिन OpenGraph preview crawlers(जैसे LinkedIn) को फिर allow किया। लेकिन फिर सवाल उठता है कि अगर कोई link Twitter या Mastodon जैसे किसी और platform पर share हो तो क्या होगा? आपको हर social media का UA अलग-अलग allow करना पड़ेगा, और इससे फायदा अंततः कुछ बड़े platforms को ही मिलेगा। असल में ऐसा तरीका चाहिए जो “AI training रोको, लेकिन search indexing, preview, archive वगैरह allow करो” जैसी granular control दे सके। इसे व्यावहारिक रूप से enforce करने के लिए कानूनी framework भी चाहिए होगा, हालांकि वह भी आसान नहीं है

  • robots.txt के मूल उपयोग पर हमेशा चर्चा रही है। मेरे विचार में यह मूलतः (और अब भी) ज़्यादातर crawlers के लिए है, यानी वे systems जो links follow करते हुए नई चीज़ें खोजते हैं। search engines इसका प्रमुख उदाहरण हैं। लेकिन अगर user खुद किसी खास URL की request करता है, जैसे browser या iCal subscription, तो robots.txt का पालन करना ज़रूरी नहीं होना चाहिए। वास्तव में Google Calendar जैसी services का robots.txt block के कारण subscription न कर पाना मुझे गलत behavior लगता है। URL preview के मामले में, अगर user केवल एक link request करता है, तो वह crawling से ज़्यादा targeted request है। लेकिन अगर किसी लंबे message में कई links हों, तो वह एक तरह की crawling जैसा भी हो जाता है। कुल मिलाकर social media के URL preview feature को robots.txt मानना चाहिए या नहीं, यह अब भी अस्पष्ट है

  • Common Crawl जैसे data का उपयोग search engines में भी हो सकता है, और AI training वगैरह में भी। उपयोग के आधार पर साफ़ विभाजन करना आसान नहीं है

  • information sharing को in-band की जगह out-of-band में बाँटकर इस समस्या को हल किया जा सकता है। यदि Open Graph metadata अलग path/header से दिया जाए, तो उस path(जिसमें उपयोगी content न हो) को allow किया जा सकता है, और मुख्य content को मज़बूती से deny किया जा सकता है। इसके लिए कानूनी framework अनिवार्य नहीं है

  • function/purpose के हिसाब से classify करके allow/block करने वाला standard बनाने का विचार मुझे पसंद है। लेकिन function verification और spoofing से सुरक्षा बड़ी चुनौती होगी, और बात आखिर कानूनी मुद्दों से भी जुड़ती है। वास्तव में social media preview जैसे विभिन्न platforms को फिर से allow करना पड़ सकता है, और किसे allow/block करना है यह बहुत सोच-समझकर तय करना पड़ता है। अलग-अलग राय सुनना इस प्रक्रिया में बहुत मददगार रहा है

• OP के लिए, 1) आपने सिर्फ LinkedIn के बारे में सोचा, लेकिन वास्तव में मेरे links Facebook, Bluesky जैसे दूसरे social media पर भी share हो सकते हैं। मैंने Facebook के ai.robots.txt में यह भी देखा कि FB preview crawler तक साथ में block हो सकता है (ai.robots.txt उदाहरण).

2. Google ranking और robots.txt block के मामले में, भले robots.txt से search visibility पर अप्रत्यक्ष links जैसे दूसरे factors भी असर डालते हों, लेकिन सीधे crawling allow करना Naver/Google SEO के लिए मूल रूप से कहीं बेहतर है। block करने पर search results में thumbnail/description नहीं दिखते, जिससे quality गिरती है। अगर search engine traffic महत्वपूर्ण है, तो robots.txt से पूरी तरह block करने पर दोबारा सोचना चाहिए

• feedback के लिए धन्यवाद! 1) मैंने भी सिर्फ LinkedIn और HN के बारे में सोचा था। यह बात ध्यान ही नहीं आई कि दूसरे लोग मेरे blog links अलग-अलग platforms पर share कर सकते हैं। हो सकता है मुझे कई platforms के access पर फिर से विचार करना पड़े। 2) search engine trends को AI summaries की तरफ जाते देख मुझे लगता है कि आगे चलकर site पर आने वाला organic traffic घटेगा। इसलिए Google search traffic कम होना मुझे अभी उतना दुखद नहीं लगता। आगे मेरी राय बदल सकती है, लेकिन फिलहाल मुझे लगता है कि HN और social sharing से होने वाला word-of-mouth मेरे blog के लिए ज़्यादा meaningful traffic लाएगा। मैं यह और जाँचूँगा कि कहीं मेरा फैसला मेरे ही खिलाफ न चला जाए। अलग-अलग राय decision-making में बहुत मदद कर रही है

• robots.txt में ‘crawling’ और ‘indexing’ को गड़बड़ करने से एक और side effect होता है।
  नई page को Google index में शुरुआत से रोकना हो, तो robots.txt block असरदार है।
  लेकिन जो page पहले से indexed है उसे हटाने के लिए सिर्फ robots.txt में जोड़ देना गलती है। Google crawl नहीं कर पाएगा, इसलिए metadata के बिना भी वह उसे search results में दिखाता रह सकता है, और noindex meta tag भी नहीं देख पाएगा, इसलिए page लंबे समय तक search में रह सकता है। Google बाद में जाकर उस page को पूरी तरह हटाता है, लेकिन यह प्रक्रिया बहुत frustrating हो सकती है

  • Google उन URLs के बारे में external links वगैरह से जान सकता है जो robots.txt द्वारा blocked हैं, और ऐसे मामलों में crawl न कर पाने पर भी indexed record results में बना रह सकता है (warning देखें: Google official docs). search results से पूरी तरह हटाने के लिए code में noindex tag ज़रूर डालना चाहिए, और robots.txt block होने पर Google इसे पढ़ नहीं पाएगा, इसलिए सावधानी ज़रूरी है

  • मेरे मामले में मैं यह ज़रूरी नहीं मानता कि Google index से हटा दे। indexing से मुझे फर्क नहीं पड़ता, मेरी चिंता सिर्फ crawling-scraping है। यह मानता हूँ कि मैंने terminology कभी-कभी गड़बड़ इस्तेमाल की थी

• यह लेख ऐसी बात को बहुत खींचता है जिसे असल में एक-दो पंक्तियों में कहा जा सकता था। जैसे स्कूल के दिनों में word count बढ़ाने के लिए लिखा जाता है

  • समस्या को एक paragraph में समझाया जा सकता था। मेरे लेख का उद्देश्य अपने अनुभव, समस्या, research, और उसके समाधान तक की यात्रा को दर्ज करना था। मैंने यह सब इसलिए विस्तार से लिखा ताकि non-technical readers भी साथ चल सकें

• robots.txt की बुनियादी सीमा यही है कि असली समस्या वे bots हैं जो robots.txt मानते नहीं, न कि वे जो मानते हैं। आज जिन bots से traffic की समस्या होती है, उनमें से ज़्यादातर पर robots.txt का कोई नियंत्रण नहीं चलता। जो bots server को वास्तव में नुकसान पहुँचाते हैं, वे robots.txt की बिल्कुल परवाह नहीं करते

  • ऐसे bots को पकड़ने के लिए ‘honeypot’ उपयोगी हो सकता है। robots.txt में /honeypot path को साफ़ तौर पर disallow कर दें, और index.html में display:none वाला <a href="/honeypot">ban me</a> link जोड़ दें। जो IP इस path पर पहुँचे, उसे तुरंत block किया जा सकता है

  • समझ नहीं आता इसे downvote क्यों मिला। OpenAI, Anthropic जैसी बड़ी कंपनियाँ robots.txt का कितना पालन करती हैं, इस पर भरोसा करने का कोई ठोस आधार नहीं है। ये कंपनियाँ residential ISP IPs के ज़रिए traffic घुमाती हैं, जिससे detection मुश्किल हो जाता है, और ‘third-party ads’ जैसी रणनीतियों से direct tracking से बचकर जिम्मेदारी भी बाँट देती हैं

• सबसे चौंकाने वाली बात यह है कि robots.txt और meta robots tags को साथ में समझना हो और conflict होने पर किसे precedence मिले, इसके लिए ठीक-ठाक parser libraries लगभग हैं ही नहीं। Google का official reference parser C++11 पर आधारित है, जो एक rare case है, और लोकप्रिय Python या JS libraries में developers को अक्सर अलग से implementation करनी पड़ती है। meta robots जैसी चीज़ें तो robots.txt file में भी नहीं होतीं, बल्कि index.html के भीतर छिपी रहती हैं। समस्या यह है कि अगर कोई bot author नैतिक रूप से सही काम करना भी चाहे, तो implementation की कठिनाई के कारण ऐसा करना मुश्किल हो जाता है

  • Python standard library में urllib.robotparser (official docs) है। दूसरी तरफ rel=nofollow का उद्देश्य robots.txt से बिल्कुल अलग है। यह attribute search engines से कहता है कि इस link पर ‘trust/link juice’ न दें, इसका मतलब “इस link को follow मत करो” नहीं है(विस्तार से). इसका मूल उद्देश्य spam communities में अंधाधुंध self-promotion links छोड़ने से रोकना था

  • जिन ‘अच्छे’ bot developers के resources सीमित होते हैं, वे servers पर अंधाधुंध bombardment नहीं करते, इसलिए सिर्फ library की कमी के कारण वास्तविक परेशानी बहुत बड़ी नहीं होती

  • अगर कोई सचमुच अच्छी नीयत से एक सही bot बनाना चाहता है, तो parser library को किसी दूसरी language में open source करके जारी करना भी पूरी तरह संभव है। इसमें कुछ मुश्किल नहीं है

• दिलचस्प बात यह है कि Apple इस समस्या को अलग तरह से handle करता है। iMessage में link share करने पर preview ‘भेजने वाले’ client की तरफ से सीधे fetch करके बनाया जाता है। LinkedIn जैसी services server side पर link data fetch करने के अपने कारण रखती हैं, जैसे spam या phishing रोकना, लेकिन यह वाकई एक अलग तरीका है

  • मुझे भी यह तर्कसंगत लगा था कि message के भीतर link मिलने के बाद client खुद preview बनाए। और यह उम्मीद भी थी कि कोई और पहले ही यह बात उठाएगा। लेकिन server द्वारा खुद scrape करने के कई कारण समझ आते हैं। 1) भविष्य में हर page को fetch कर उपयोग करने की तैयारी; 2) page बदल जाए, 404 हो जाए, या client database खो जाए, तब भी server पहले से निकाली गई preview info दे सके; 3) client side पर preview बनाए बिना भी message के साथ जल्दी preview दिखाया जा सके। आखिर iMessage की तरह अगर ‘भेजने वाला’ preview बनाए, तो इनमें से सिर्फ ‘1’ और ‘2’ का कुछ हिस्सा ही बचता है, और reliability के लिहाज़ से server का retry करते रहना बेहतर विकल्प हो सकता है