AI স্ক্র্যাপার সত্যিই ব্লক করে—এমন robots.txt কীভাবে লিখবেন

robots.txt সম্পর্কে অস্বস্তিকর সত্য

একটি robots.txt ফাইল তালা নয়। এটি দরজায় লাগানো একটি নোটিশ।

এই পার্থক্যটি গুরুত্বপূর্ণ, যখন টিমগুলো জানতে চায় একটি ছোট text file দিয়ে তারা “AI scraper ব্লক” করতে পারবে কি না। Robots Exclusion Protocol অনুসরণ করে এমন স্বনামধন্য crawler-এর ক্ষেত্রে, হ্যাঁ: ঠিকভাবে লেখা একটি robots.txt তাদের বলতে পারে আপনার page crawl না করতে। অজানা scraper, ছদ্মবেশী bot, browser automation, এবং যে bot-রা সহজভাবে পাত্তাই দেয় না—তাদের ক্ষেত্রে এটি নিজে থেকে কিছুই করবে না।

তাই ব্যবহারিক লক্ষ্য “scraping অসম্ভব করে তোলা” নয়। লক্ষ্য হলো:

• নিয়ম মানে এমন AI crawler-দের জানানো যে তারা যেন আপনার site ব্যবহার না করে।
• ভুল করে search engine বা দরকারি service ব্লক করা এড়ানো।
• অপব্যবহারের জন্য আরও শক্তিশালী server-side নিয়ন্ত্রণ যোগ করা।
• crawler-এর নাম বদলালে policy যেন রক্ষণাবেক্ষণযোগ্য থাকে।

এটাই বিরক্তিকর সংস্করণ। এবং এটিই কাজ করে।

robots.txt কী করতে পারে এবং কী পারে না

একটি robots.txt ফাইল কোনো site-এর root-এ থাকে:

https://example.com/robots.txt

Crawler-রা crawl করার আগে এটি request করে। ফাইলটিতে rule-এর group থাকে। প্রতিটি group এক বা একাধিক User-agent line দিয়ে শুরু হয়, এরপর থাকে Allow বা Disallow directive।

সম্পূর্ণ site ব্লক করার একটি সহজ উদাহরণ:

User-agent: GPTBot
Disallow: /

এর মানে: আপনি যদি GPTBot হন, এই site-এর কিছুই crawl করবেন না।

কিন্তু robots.txt-এর কঠোর সীমাবদ্ধতা আছে:

1. এটি স্বেচ্ছাসেবী। খারাপ actor এটি উপেক্ষা করতে পারে।
2. এটি কোনো URL-কে সাধারণ browser বা script দিয়ে request করা ঠেকায় না।
3. এটি অন্য কোথাও আগে থেকেই সংগ্রহ করা content মুছে দেয় না।
4. এটি নিজে থেকে copyright, licensing, বা training rights নির্ধারণ করে না।
5. ভুল configuration হলে এটি ভুল bot ব্লক করতে পারে।

আপনার যদি প্রকৃত access control দরকার হয়, authentication, authorization, rate limiting, IP-based controls, bot management, বা legal controls ব্যবহার করুন। Robots.txt এখনও দরকারি, কিন্তু এটি বৃহত্তর content protection strategy-এর অংশ।

এটি web governance-এর অন্যান্য সমস্যার মতো: দৃশ্যমান নিয়ন্ত্রণ খুব কমই পুরো নিয়ন্ত্রণ। আপনার organization-এর ভেতরেই যদি ইতিমধ্যে unmanaged AI use থাকে, একই নীতি প্রযোজ্য; একটি মাত্র policy document সমস্যার সমাধান করে—এমন ভান করার চেয়ে দ্রুত একটি shadow AI audit অনেক সময় বেশি কার্যকর।

আপনার policy decision দিয়ে শুরু করুন

ফাইল edit করার আগে ঠিক করুন আপনি আসলে কী ব্লক করতে চাইছেন।

“AI scraper” বলতে মানুষ অন্তত চারটি ভিন্ন জিনিস বোঝায়:

• training data সংগ্রহে ব্যবহৃত crawler।
• AI search বা answer-engine crawler।
• user-triggered fetcher, যেমন কেউ কোনো AI product-কে একটি URL summarize করতে বললে।
• সাধারণ browser সেজে থাকা generic scraper।

আপনি হয়তো সবগুলোই ব্লক করতে চাইবেন। অথবা model training থেকে opt out করে search discovery রাখতে চাইবেন। এগুলো একই policy নয়।

উদাহরণ হিসেবে, OpenAI বিভিন্ন উদ্দেশ্যের জন্য আলাদা user agent document করে, যার মধ্যে GPTBot, ChatGPT-User, এবং OAI-SearchBot রয়েছে। Google কিছু Gemini এবং Vertex AI use case-এর control token হিসেবে Google-Extended ব্যবহার করে, আর সাধারণ Google Search crawling অন্য Googlebot user agent দিয়ে পরিচালিত হয়।

এই পৃথকীকরণ গুরুত্বপূর্ণ। আপনি যদি অসতর্কভাবে broad user agent ব্লক করেন, AI training ব্লক করতে গিয়ে সাধারণ search visibility ক্ষতিগ্রস্ত করতে পারেন।

AI ব্লক করার জন্য একটি যুক্তিসঙ্গত robots.txt template

সাধারণ search crawler চালু রেখে কয়েকটি প্রচলিতভাবে documented AI-related crawler ব্লক করার জন্য এখানে একটি সতর্ক 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 নয়। এটি একটি রক্ষণাবেক্ষণযোগ্য pattern।

কয়েকটি নোট:

• Disallow: / মানে “কোনো path crawl করবেন না।”
• User-agent: * সেই crawler-দের ক্ষেত্রে প্রযোজ্য, যাদের সঙ্গে বেশি specific group match করে না।
• default group-এর জন্য Allow: / কঠোরভাবে প্রয়োজনীয় নয়, কিন্তু এটি আপনার উদ্দেশ্য পরিষ্কার করে।
• comment ছোট রাখুন। কিছু parser সহনশীল, কিন্তু robots.txt boring থাকাই ভালো।
• robots.txt-এ private URL রাখবেন না। ফাইলটি public, এবং sensitive path list করলে সেগুলো advertise হয়ে যেতে পারে।

শেষ পয়েন্টটি আবার বলা দরকার। Robots.txt গোপনীয়তার mechanism নয়। যদি /client-contracts/ public হওয়া উচিত না হয়, authentication দিয়ে protect করুন। শুধু disallow করে থেমে যাবেন না।

Google-Extended নিয়ে সতর্ক থাকুন

Google-Extended ব্যাপকভাবে ভুল বোঝা হয়। এটি Google Search ব্লক করার সমান নয়।

Google-এর documentation অনুযায়ী, Google-Extended একটি standalone product token, যা publisher-রা কিছু Gemini এবং Vertex AI capability উন্নত করতে site content ব্যবহার করা যাবে কি না—তা manage করতে ব্যবহার করতে পারেন। এটি ব্লক করলে নিজে থেকে Search-এর জন্য Googlebot crawling ব্লক হওয়ার কথা নয়।

তবে, আপনি সত্যিই তা বোঝাতে না চাইলে সব Google directive বদলে এমন broad block দেবেন না:

User-agent: Googlebot
Disallow: /

এটি Google Search-এর main crawler-কে আপনার site crawl না করতে বলবে। বেশিরভাগ public website-এর জন্য এটি কাঙ্ক্ষিত নয়।

একই পার্থক্য অন্য জায়গাতেও প্রযোজ্য। কিছু vendor training crawler-কে user-triggered browsing বা AI search crawler থেকে আলাদা করে। অন্যরা করে না। আপনার জন্য গুরুত্বপূর্ণ bot-গুলোর documentation পড়তে হবে এবং আপনার robots.txt-কে একবারের checkbox নয়, একটি living file হিসেবে দেখতে হবে।

production code-এর মতো ফাইলটি test করুন

Robots.txt দেখতে সহজ, তাই এটি ভাঙাও সহজ।

সাধারণ ভুলগুলোর মধ্যে রয়েছে:

• এটিকে ভুল জায়গায় upload করা, যেমন /robots.txt-এর বদলে /assets/robots.txt।
• document editor থেকে copy করা smart quote ব্যবহার করা।
• ভুল করে User-agent: * এবং Disallow: / দিয়ে সব crawler ব্লক করে ফেলা।
• ধরে নেওয়া যে এক domain-এর ফাইল অন্য subdomain-এও প্রযোজ্য।
• ভুলে যাওয়া যে আপনার setup অনুযায়ী http://, https://, www, এবং non-www host আলাদাভাবে handled হতে পারে।

Multi-domain site-এর জন্য প্রতিটি canonical host পরীক্ষা করুন। https://www.example.com/robots.txt-এ থাকা robots file স্বয়ংক্রিয়ভাবে https://app.example.com/robots.txt নিয়ন্ত্রণ করে না।

Debug করার সময় আপনার CMS preview যা দেখাচ্ছে শুধু তা নয়, প্রকৃত HTTP response inspect করুন। আপনি চাইবেন 200 OK response, সম্ভব হলে text/plain content type, এবং আপনার প্রত্যাশিত exact file। Redirect, caching, বা CDN rule জড়িত থাকলে raw header inspection সাহায্য করে। production-এ redirect এবং HTTP header debug করার workflow সরাসরি এখানে প্রযোজ্য।

যে bot নিয়ম মানে না, তার জন্য server-side control যোগ করুন

Crawler যদি compliant হয়, robots.txt সবচেয়ে পরিষ্কার signal। Crawler যদি abusive হয়, enforcement দরকার।

ব্যবহারিক control-এর মধ্যে রয়েছে:

Rate limiting

অস্বাভাবিক request pattern-এর জন্য threshold নির্ধারণ করুন: প্রতি মিনিটে অতিরিক্ত page, deep pagination traversal, repeated 404, বা অল্প কিছু IP থেকে high request volume। Rate limit যথেষ্ট উদার হওয়া উচিত যাতে real user শাস্তি না পায়, আবার যথেষ্ট কঠোর হওয়া উচিত যাতে bulk extraction ব্যয়বহুল হয়।

User-agent filtering

আপনি documented AI crawler user agent-কে web server, reverse proxy, CDN, বা application layer-এ ব্লক করতে পারেন। এটি robots.txt-এর চেয়ে শক্তিশালী, কারণ এটি প্রকৃত denial response return করে।

উদাহরণ হিসেবে, Nginx user agent pattern ব্লক করতে পারে, যদিও production rule সতর্কভাবে test করা উচিত:

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

এটি foolproof নয়। User-agent string সহজেই fake করা যায়। তবে এটি honest বা lazy traffic থামায় এবং load কমায়।

IP এবং ASN controls

কিছু operator IP range publish করে, কিন্তু অনেক scraper ecosystem তা করে না। স্পষ্ট abuse-এর ক্ষেত্রে IP-based blocking কাজ করতে পারে, বিশেষ করে এমন cloud hosting range থেকে, যেখানে normal user traffic নেই; তবে false positive-ও তৈরি হতে পারে। Rule দেওয়ার আগে log ব্যবহার করুন।

Authentication এবং paywall

যদি content scale-এ copy হওয়া চলবে না, তাহলে full content public URL-এ রাখবেন না। Confidential material, licensed database, private community, বা paid archive-এর জন্য robots.txt অনুপযুক্ত।

Content minimization

কখনও কখনও সেরা protection architectural। public page-এর যদি শুধু ছোট subset দরকার হয়, তাহলে অপ্রয়োজনীয় API, বড় JSON payload, hidden metadata, draft endpoint, বা full archive expose করবেন না। Image-heavy site-এরও ভাবা উচিত তারা কী metadata publish করছে; online-এ photo share করার আগে EXIF metadata strip করার privacy logic content operation-এও প্রযোজ্য।

page-level rule-এর জন্য robots meta tag ব্যবহার করুন

Robots.txt crawling control করে। Robots meta tag এবং X-Robots-Tag header compliant search engine এবং crawler-এর indexing ও snippet behavior control করে।

উদাহরণ:

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

অথবা HTTP header হিসেবে:

X-Robots-Tag: noindex, noarchive

এগুলো AI-specific shield নয়। আপনি যখন কোনো page accessible রাখতে চান কিন্তু indexed করতে চান না, তখন এগুলো দরকারি। তবে, আপনি যদি robots.txt-এ কোনো crawler-কে page fetch করা থেকে block করেন, সেটি হয়তো কখনো page-level meta tag দেখবেই না। যে URL crawler-কে crawl করতে নিষেধ করা হয়েছে, সেখানে থাকা noindex tag-এর ওপর নির্ভর করবেন না।

মোটামুটি নিয়ম:

• crawling কমাতে বা ঠেকাতে robots.txt ব্যবহার করুন।
• indexing behavior control করতে meta robots বা X-Robots-Tag ব্যবহার করুন।
• access enforce করতে server-side control ব্যবহার করুন।

publish করার পর log monitor করুন

ফাইল publish করা মাত্র প্রথম ধাপ। এরপর আপনার log পরীক্ষা করুন।

খেয়াল করুন:

• আপনি যে user agent-এর নাম দিয়েছেন তাদের থেকে /robots.txt-এ request।
• disallow rule serve হওয়ার পরও crawling চলতে থাকা।
• high volume সহ suspicious user agent।
• ধারাবাহিকভাবে হাজার হাজার page request করা browser-like user agent।
• feed, sitemap, search page, এবং pagination-এ repeated access।

যদি কোনো bot robots.txt request করে, full disallow দেখে, তারপর থেমে যায়—robots.txt তার কাজ করেছে। যদি চালিয়ে যায়, সেই bot-কে enforcement-এ নিন: rate limit, block, বা authentication।

আপনার sitemap exposure-ও review করুন। Sitemap search engine-এর জন্য দরকারি, কিন্তু scraper-এর জন্যও সুবিধাজনক map। এর মানে এই নয় যে সাধারণ site থেকে এগুলো সরিয়ে ফেলতে হবে। এর মানে হলো, public system যেন discover না করে—এমন URL অন্তর্ভুক্ত করা উচিত নয়।

ফাইলটি ছোট রাখুন এবং review করুন

Robots.txt ধীরে ধীরে নষ্ট হয়। Marketing team একটি campaign microsite যোগ করে। Developer একটি staging path যোগ করে। Vendor তার crawler name বদলায়। দুই বছর পরে কেউ জানে না অর্ধেক rule কেন আছে।

এটিকে configuration হিসেবে দেখুন:

• সম্ভব হলে version control-এ রাখুন।
• প্রতিটি AI crawler group-এর জন্য ছোট comment যোগ করুন।
• quarterly review করুন।
• broad rule যোগ করার আগে vendor documentation পরীক্ষা করুন।
• CDN, CMS, বা hosting change-এর পরে test করুন।

আপনার site যদি AI-assisted content publish করে, crawler policy-কে editorial transparency থেকে আলাদা রাখুন। AI scraper ব্লক করা access এবং reuse সম্পর্কিত। Disclosure হলো reader trust সম্পর্কিত। নৈতিকভাবে এগুলো overlap করে, কিন্তু এগুলো একই control নয়। একটি ব্যবহারিক disclosure approach আলোচনা করা হয়েছে একটি ছোট website-এ honest AI disclosure কেমন হওয়া উচিত প্রবন্ধে।

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

💡 এটি চেষ্টা করুন: AI ক্রলারদের জন্য নিয়ম যোগ করার পরে, Robots.txt Tester দিয়ে সিনট্যাক্স নিশ্চিত করুন, যাতে ভুলবশত বৈধ বটগুলোকেও ব্লক না করে ফেলেন।

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

শেষ কথা

ভালো robots.txt ফাইল compliant AI crawler ব্লক করবে। এটি determined scraping, copy করা user-agent string, compromised browser, বা মানুষ নিজে আপনার content AI system-এ paste করা থামাবে না।

তাতে এটি useless হয়ে যায় না। বরং এটি এক স্তর।

Documented AI crawler-এর জন্য explicit rule লিখুন। Search visibility ক্ষতিগ্রস্ত করে এমন broad block এড়িয়ে চলুন। Draft নয়, served file test করুন। Log দেখুন। আচরণ unwanted থেকে abusive পর্যায়ে গেলে server-side control দিয়ে enforce করুন।

Web সবসময় protocol, norm, এবং enforcement-এর মিশ্রণে চলে এসেছে। Robots.txt হলো norms layer। এটি ব্যবহার করুন, কিন্তু এটিকে দেয়াল ভেবে ভুল করবেন না।