ऐसा robots.txt कैसे लिखें जो सच में AI स्क्रैपरों को रोकता है

robots.txt के बारे में असुविधाजनक सच

robots.txt फ़ाइल कोई ताला नहीं है। यह दरवाज़े पर लगा एक संकेत है।

यह फर्क तब मायने रखता है जब टीमें पूछती हैं कि क्या वे एक छोटी-सी टेक्स्ट फ़ाइल से “AI स्क्रैपरों को रोक” सकती हैं। प्रतिष्ठित क्रॉलरों के लिए, जो Robots Exclusion Protocol का पालन करते हैं, हाँ: सही ढंग से लिखा गया robots.txt उन्हें बता सकता है कि वे आपके पेज crawl न करें। अज्ञात स्क्रैपरों, impersonators, browser automation, और उन bots के लिए जिन्हें इसकी परवाह ही नहीं, यह अपने-आप कुछ नहीं करेगा।

इसलिए व्यावहारिक लक्ष्य “scraping को असंभव बनाना” नहीं है। लक्ष्य यह है:

• अनुपालन करने वाले AI क्रॉलरों को बताना कि वे आपकी साइट का उपयोग न करें।
• गलती से search engines या उपयोगी सेवाओं को ब्लॉक करने से बचना।
• दुरुपयोग के लिए अधिक मजबूत सर्वर-साइड नियंत्रण जोड़ना।
• crawler names बदलने पर policy को maintainable रखना।

यह उबाऊ संस्करण है। और यही वह संस्करण भी है जो काम करता है।

robots.txt क्या कर सकता है और क्या नहीं

robots.txt फ़ाइल किसी site के root पर रहती है:

https://example.com/robots.txt

Crawlers crawling से पहले इसे request करते हैं। फ़ाइल में rules के groups होते हैं। प्रत्येक group एक या अधिक User-agent lines से शुरू होता है, जिसके बाद Allow या Disallow directives होती हैं।

एक सरल full-site block ऐसा दिखता है:

User-agent: GPTBot
Disallow: /

इसका मतलब है: यदि आप GPTBot हैं, तो इस site पर कुछ भी crawl न करें।

लेकिन robots.txt की स्पष्ट सीमाएँ हैं:

1. यह स्वैच्छिक है। Bad actors इसे अनदेखा कर सकते हैं।
2. यह किसी URL को normal browser या script द्वारा request किए जाने से नहीं रोकता।
3. यह पहले से कहीं और collected content को हटाता नहीं है।
4. यह अपने-आप copyright, licensing, या training rights परिभाषित नहीं करता।
5. इसे इस तरह misconfigure किया जा सकता है कि गलत bots block हो जाएँ।

यदि आपको वास्तविक access control चाहिए, तो authentication, authorization, rate limiting, IP-based controls, bot management, या legal controls का उपयोग करें। Robots.txt अब भी उपयोगी है, लेकिन यह व्यापक content protection strategy का हिस्सा होना चाहिए।

यह अन्य web governance समस्याओं जैसा है: दिखने वाला control शायद ही कभी पूरा control होता है। यदि आपके संगठन के भीतर पहले से unmanaged AI use है, तो वही सिद्धांत लागू होता है; एक quick shadow AI audit अक्सर यह दिखावा करने से अधिक उपयोगी होता है कि एक policy document ही समस्या हल कर देता है।

अपनी policy decision से शुरू करें

फ़ाइल edit करने से पहले तय करें कि आप असल में क्या block करना चाहते हैं।

“AI scraper” से लोगों का मतलब कम-से-कम चार अलग-अलग चीज़ों से हो सकता है:

• Training data collect करने के लिए इस्तेमाल होने वाले crawlers।
• AI search या answer-engine crawlers।
• User-triggered fetchers, जैसे जब कोई व्यक्ति किसी AI product से URL summarize करने को कहता है।
• Ordinary browsers होने का दिखावा करने वाले generic scrapers।

आप शायद इन सभी को block करना चाहें। या आप model training से opt out करते हुए search discovery बनाए रखना चाहें। ये समान policy नहीं हैं।

उदाहरण के लिए, OpenAI अलग-अलग उद्देश्यों के लिए अलग user agents document करता है, जिनमें GPTBot, ChatGPT-User, और OAI-SearchBot शामिल हैं। Google कुछ Gemini और Vertex AI use cases के लिए control token के रूप में Google-Extended का उपयोग करता है, जबकि normal Google Search crawling अन्य Googlebot user agents द्वारा संभाली जाती है।

यह अलगाव महत्वपूर्ण है। यदि आप broad user agents को लापरवाही से block करते हैं, तो AI training रोकने की कोशिश में आप ordinary search visibility को नुकसान पहुँचा सकते हैं।

एक उचित AI-blocking robots.txt template

General search crawlers को अलग रखते हुए कई commonly documented AI-related crawlers को block करने के लिए यहाँ एक conservative starting point है:

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

यह कोई जादुई universal list नहीं है। यह एक maintainable pattern है।

कुछ notes:

• Disallow: / का अर्थ है “किसी भी path को crawl न करें।”
• User-agent: * उन crawlers पर लागू होता है जो किसी अधिक specific group से match नहीं होते।
• Default group के लिए Allow: / strictly required नहीं है, लेकिन यह आपका intent स्पष्ट करता है।
• Comments छोटे रखें। कुछ parsers forgiving होते हैं, लेकिन robots.txt को boring ही रहना चाहिए।
• robots.txt में private URLs शामिल न करें। फ़ाइल public होती है, और sensitive paths सूचीबद्ध करना उन्हें advertise कर सकता है।

आख़िरी बिंदु दोहराने लायक है। Robots.txt कोई secrecy mechanism नहीं है। यदि /client-contracts/ public नहीं होना चाहिए, तो उसे authentication से protect करें। केवल उसे disallow न करें।

Google-Extended के साथ सावधानी रखें

Google-Extended को व्यापक रूप से गलत समझा जाता है। यह Google Search को block करने जैसा नहीं है।

Google के documentation के अनुसार, Google-Extended एक standalone product token है जिसका उपयोग publishers यह manage करने के लिए कर सकते हैं कि site content कुछ Gemini और Vertex AI capabilities को improve करने में मदद कर सकता है या नहीं। इसे block करने से, अपने-आप, Googlebot को Search के लिए crawling करने से block नहीं होना चाहिए।

फिर भी, सभी Google directives को ऐसे broad block से replace न करें, जब तक कि आपका सचमुच यही मतलब न हो:

User-agent: Googlebot
Disallow: /

यह Google Search के main crawler को आपकी site crawl न करने के लिए कहेगा। अधिकांश public websites के लिए, यह वह नहीं है जो आप चाहते हैं।

यही distinction अन्य जगहों पर भी लागू होता है। कुछ vendors training crawlers को user-triggered browsing या AI search crawlers से अलग करते हैं। कुछ नहीं करते। आपको उन bots का documentation पढ़ना होगा जिनकी आपको परवाह है और अपने robots.txt को living file मानना होगा, one-time checkbox नहीं।

फ़ाइल को production code की तरह test करें

Robots.txt सरल दिखता है, इसलिए इसे तोड़ना आसान है।

Common mistakes में शामिल हैं:

• इसे गलत जगह upload करना, जैसे /robots.txt के बजाय /assets/robots.txt।
• Document editor से copied smart quotes का उपयोग करना।
• गलती से User-agent: * और Disallow: / के साथ सभी crawlers को block कर देना।
• यह मान लेना कि एक domain की file दूसरे subdomain पर लागू होती है।
• यह भूल जाना कि आपके setup के आधार पर http://, https://, www, और non-www hosts अलग-अलग handle हो सकते हैं।

Multi-domain sites के लिए, हर canonical host check करें। https://www.example.com/robots.txt पर मौजूद robots file अपने-आप https://app.example.com/robots.txt को govern नहीं करती।

Debugging करते समय, actual HTTP response inspect करें, न कि केवल वह जो आपका CMS preview दिखाता है। आपको 200 OK response, संभव हो तो text/plain content type, और वही exact file चाहिए जिसकी आप अपेक्षा करते हैं। यदि redirects, caching, या CDN rules शामिल हैं, तो raw header inspection मदद करता है। debugging redirects and HTTP headers in production वाला workflow यहाँ सीधे लागू होता है।

उन bots के लिए server-side controls जोड़ें जो rules ignore करते हैं

यदि crawler compliant है, तो robots.txt सबसे साफ signal है। यदि crawler abusive है, तो आपको enforcement चाहिए।

Practical controls में शामिल हैं:

Rate limiting

Unusual request patterns के लिए thresholds set करें: प्रति मिनट बहुत अधिक pages, deep pagination traversal, repeated 404s, या IPs के छोटे set से high request volume। Rate limits इतनी generous होनी चाहिए कि real users को punish न करें और इतनी strict कि bulk extraction महँगा हो जाए।

User-agent filtering

आप documented AI crawler user agents को web server, reverse proxy, CDN, या application layer पर block कर सकते हैं। यह robots.txt से अधिक मजबूत है क्योंकि यह actual denial response return करता है।

उदाहरण के लिए, Nginx एक user agent pattern को block कर सकता है, हालांकि production rules को सावधानी से test किया जाना चाहिए:

if ($http_user_agent ~* "GPTBot|CCBot|ClaudeBot|Bytespider") {
    return 403;
}

यह foolproof नहीं है। User-agent strings को fake करना आसान है। लेकिन यह honest या lazy traffic को रोकता है और load कम करता है।

IP and ASN controls

कुछ operators IP ranges publish करते हैं, लेकिन कई scraper ecosystems ऐसा नहीं करते। IP-based blocking obvious abuse के लिए काम कर सकता है, खासकर उन cloud hosting ranges से जहाँ normal user traffic नहीं होता, लेकिन यह false positives भी create कर सकता है। Rules से पहले logs का उपयोग करें।

Authentication and paywalls

यदि content को scale पर copy नहीं किया जाना चाहिए, तो full content को public URL पर न रखें। Robots.txt confidential material, licensed databases, private communities, या paid archives के लिए अनुपयुक्त है।

Content minimization

कभी-कभी सबसे अच्छी protection architectural होती है। Unnecessary APIs, large JSON payloads, hidden metadata, draft endpoints, या full archives expose न करें यदि public page को केवल एक small subset चाहिए। Image-heavy sites को यह भी सोचना चाहिए कि वे कौन-सा metadata publish करते हैं; stripping EXIF metadata before sharing photos online में privacy logic content operations पर भी लागू होता है।

Page-level rules के लिए robots meta tags का उपयोग करें

Robots.txt crawling को control करता है। Robots meta tags और X-Robots-Tag headers compliant search engines और crawlers के लिए indexing और snippet behavior को control करते हैं।

उदाहरण के लिए:

<meta name="robots" content="noindex, noarchive">

या HTTP header के रूप में:

X-Robots-Tag: noindex, noarchive

ये AI-specific shields नहीं हैं। ये तब उपयोगी हैं जब आप चाहते हैं कि कोई page accessible हो लेकिन indexed न हो। हालांकि, यदि आप robots.txt में किसी crawler को page fetch करने से block करते हैं, तो वह page-level meta tag शायद कभी न देखे। ऐसे URL पर noindex tag पर भरोसा न करें जिसे crawler को crawl करने से मना किया गया है।

मोटा-मोटी rule:

• Crawling को reduce या prevent करने के लिए robots.txt का उपयोग करें।
• Indexing behavior control करने के लिए meta robots या X-Robots-Tag का उपयोग करें।
• Access enforce करने के लिए server-side controls का उपयोग करें।

Publish करने के बाद logs monitor करें

फ़ाइल publish करना केवल पहला कदम है। उसके बाद, अपने logs check करें।

देखें:

• जिन user agents का आपने नाम लिया है, उनसे /robots.txt पर requests।
• Disallow rules serve होने के बाद भी continued crawling।
• High volume वाले suspicious user agents।
• Browser-like user agents जो sequence में thousands of pages request कर रहे हों।
• Feeds, sitemaps, search pages, और pagination तक repeated access।

यदि कोई bot robots.txt request करता है, full disallow देखता है, और फिर रुक जाता है, तो robots.txt ने अपना काम किया। यदि वह जारी रखता है, तो उस bot को enforcement में ले जाएँ: rate limits, blocks, या authentication।

अपने sitemap exposure की भी समीक्षा करें। Sitemaps search engines के लिए उपयोगी हैं, लेकिन वे scrapers के लिए convenient maps भी हैं। इसका मतलब यह नहीं कि आपको ordinary sites से उन्हें हटाना चाहिए। इसका मतलब यह है कि आपको वे URLs शामिल नहीं करने चाहिए जिन्हें आप नहीं चाहते कि public systems discover करें।

फ़ाइल को छोटा और reviewed रखें

Robots.txt धीरे-धीरे सड़ता है। Marketing team campaign microsite जोड़ती है। Developer staging path जोड़ता है। Vendor अपना crawler name बदलता है। दो साल बाद किसी को पता नहीं होता कि आधे rules क्यों मौजूद हैं।

इसे configuration की तरह treat करें:

• संभव हो तो इसे version control में store करें।
• प्रत्येक AI crawler group के लिए short comment जोड़ें।
• Quarterly इसकी review करें।
• Broad rules जोड़ने से पहले vendor documentation check करें।
• CDN, CMS, या hosting changes के बाद test करें।

यदि आपकी site AI-assisted content publish करती है, तो crawler policy को editorial transparency से अलग रखें। AI scrapers को block करना access और reuse के बारे में है। Disclosure reader trust के बारे में है। वे ethically overlap करते हैं, लेकिन वे same control नहीं हैं। एक practical disclosure approach what honest AI disclosure looks like on a small website में covered है।

<!-- tool-cta:start -->

💡 इसे आज़माएँ: AI क्रॉलर के लिए नियम जोड़ने के बाद, Robots.txt Tester से सिंटैक्स की पुष्टि करें ताकि आप गलती से वैध बॉट्स को भी ब्लॉक न कर दें।

<!-- tool-cta:end -->

निष्कर्ष

एक अच्छा robots.txt file compliant AI crawlers को block करेगा। यह determined scraping, copied user-agent strings, compromised browsers, या लोगों द्वारा आपके content को manually AI systems में paste करने को नहीं रोकेगा।

इससे यह बेकार नहीं हो जाता। इससे यह एक layer बनता है।

Documented AI crawlers के लिए explicit rules लिखें। Search visibility को नुकसान पहुँचाने वाले broad blocks से बचें। Served file को test करें, draft को नहीं। Logs देखें। जहाँ behavior unwanted से abusive में बदलता है, वहाँ server-side controls से enforce करें।

Web हमेशा protocol, norms, और enforcement के मिश्रण पर चला है। Robots.txt norms layer है। इसका उपयोग करें, लेकिन इसे दीवार समझने की गलती न करें।