Paano magsulat ng robots.txt na talagang humaharang sa mga AI scraper

Ang hindi komportableng katotohanan tungkol sa robots.txt

Ang robots.txt file ay hindi kandado. Isa itong karatula sa pinto.

Mahalaga ang pagkakaibang iyon kapag nagtatanong ang mga team kung kaya ba nilang “harangin ang mga AI scraper” gamit ang isang maliit na text file. Para sa mga mapagkakatiwalaang crawler na sumusunod sa Robots Exclusion Protocol, oo: maaaring sabihin ng wastong naisulat na robots.txt na huwag nilang i-crawl ang iyong mga page. Para sa mga hindi kilalang scraper, nagpapanggap, browser automation, at mga bot na sadyang walang pakialam, wala itong magagawa nang mag-isa.

Kaya ang praktikal na layunin ay hindi “gawing imposible ang scraping.” Ito ay:

• Sabihin sa mga sumusunod na AI crawler na huwag gamitin ang iyong site.
• Iwasang aksidenteng harangin ang mga search engine o kapaki-pakinabang na serbisyo.
• Magdagdag ng mas matibay na server-side controls para sa abuse.
• Panatilihing madaling i-maintain ang patakaran habang nagbabago ang mga pangalan ng crawler.

Iyan ang boring na bersyon. Iyan din ang bersyong gumagana.

Ano ang kaya at hindi kaya ng robots.txt

Ang robots.txt file ay nasa root ng isang site:

https://example.com/robots.txt

Hinihiling ito ng mga crawler bago mag-crawl. Naglalaman ang file ng mga grupo ng rule. Nagsisimula ang bawat grupo sa isa o higit pang User-agent line, na sinusundan ng mga Allow o Disallow directive.

Ganito ang isang simpleng full-site block:

User-agent: GPTBot
Disallow: /

Ibig sabihin nito: kung ikaw ay GPTBot, huwag mag-crawl ng kahit ano sa site na ito.

Ngunit may mahihigpit na limitasyon ang robots.txt:

1. Boluntaryo ito. Maaaring balewalain ito ng masasamang aktor.
2. Hindi nito napipigilan ang isang URL na hilingin ng normal na browser o script.
3. Hindi nito inaalis ang content na nakolekta na sa ibang lugar.
4. Hindi nito mag-isang tinutukoy ang copyright, licensing, o training rights.
5. Maaari itong ma-misconfigure sa mga paraang naghaharang sa maling mga bot.

Kung kailangan mo ng tunay na access control, gumamit ng authentication, authorization, rate limiting, IP-based controls, bot management, o legal controls. Kapaki-pakinabang pa rin ang robots.txt, ngunit bahagi ito ng mas malawak na content protection strategy.

Katulad ito ng ibang problema sa web governance: bihirang ang nakikitang control ang buong control. Kung mayroon nang unmanaged AI use sa loob ng iyong organisasyon, pareho ang prinsipyo; kadalasang mas kapaki-pakinabang ang mabilis na shadow AI audit kaysa magkunwaring nalulutas ng isang policy document ang isyu.

Magsimula sa iyong pasya sa patakaran

Bago i-edit ang file, magpasya kung ano talaga ang sinusubukan mong harangin.

May hindi bababa sa apat na magkakaibang bagay na tinutukoy ng mga tao kapag sinasabi nilang “AI scraper”:

• Mga crawler na ginagamit para mangolekta ng training data.
• Mga AI search o answer-engine crawler.
• Mga user-triggered fetcher, gaya kapag may humiling sa isang AI product na ibuod ang isang URL.
• Mga generic scraper na nagpapanggap na ordinaryong browser.

Maaaring gusto mong harangin silang lahat. O baka gusto mo ng search discovery habang nag-o-opt out sa model training. Hindi iisa ang mga patakarang ito.

Halimbawa, nagdodokumento ang OpenAI ng magkakahiwalay na user agent para sa iba’t ibang layunin, kabilang ang GPTBot, ChatGPT-User, at OAI-SearchBot. Ginagamit ng Google ang Google-Extended bilang control token para sa ilang use case ng Gemini at Vertex AI, habang ang normal na Google Search crawling ay pinangangasiwaan ng ibang Googlebot user agent.

Mahalaga ang paghihiwalay na iyon. Kung pabaya mong haharangin ang malalawak na user agent, maaari mong mapinsala ang karaniwang search visibility habang sinusubukan mong harangin ang AI training.

Isang makatwirang robots.txt template para sa pagharang sa AI

Narito ang isang konserbatibong panimulang punto para harangin ang ilang karaniwang dokumentadong AI-related crawler habang hinahayaang gumana ang general search crawlers:

# 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: /

Hindi ito isang magic universal list. Isa itong pattern na madaling i-maintain.

Ilang tala:

• Ang Disallow: / ay nangangahulugang “huwag mag-crawl ng anumang path.”
• Nalalapat ang User-agent: * sa mga crawler na hindi tumutugma sa mas espesipikong grupo.
• Hindi mahigpit na kailangan ang Allow: / para sa default group, ngunit nililinaw nito ang iyong intensyon.
• Panatilihing maikli ang mga comment. Mapagpatawad ang ilang parser, ngunit dapat manatiling boring ang robots.txt.
• Huwag maglagay ng mga pribadong URL sa robots.txt. Pampubliko ang file, at maaaring i-advertise ng paglista ng sensitive paths ang mga ito.

Mahalagang ulitin ang huling punto. Hindi mekanismo ng pagtatago ang robots.txt. Kung hindi dapat pampubliko ang /client-contracts/, protektahan ito gamit ang authentication. Huwag lamang itong i-disallow.

Mag-ingat sa Google-Extended

Madalas mali ang pagkakaunawa sa Google-Extended. Hindi ito kapareho ng pagharang sa Google Search.

Ayon sa dokumentasyon ng Google, ang Google-Extended ay isang standalone product token na magagamit ng mga publisher para pamahalaan kung maaaring makatulong ang site content sa pagpapahusay ng ilang kakayahan ng Gemini at Vertex AI. Ang pagharang dito ay hindi dapat, sa sarili nito, humarang sa Googlebot sa pag-crawl para sa Search.

Gayunpaman, huwag palitan ang lahat ng Google directive ng isang malawak na block na ganito maliban kung iyon talaga ang ibig mong sabihin:

User-agent: Googlebot
Disallow: /

Sasabihin niyan sa pangunahing crawler ng Google Search na huwag i-crawl ang iyong site. Para sa karamihan ng pampublikong website, hindi iyon ang gusto mo.

Nalalapat din ang parehong pagkakaiba sa iba pang lugar. Pinaghihiwalay ng ilang vendor ang training crawlers mula sa user-triggered browsing o AI search crawlers. Ang iba ay hindi. Kailangan mong basahin ang dokumentasyon para sa mga bot na mahalaga sa iyo at ituring ang iyong robots.txt bilang buhay na file, hindi one-time checkbox.

Subukan ang file na parang production code

Mukhang simple ang robots.txt, kaya madali rin itong masira.

Kabilang sa karaniwang pagkakamali ang:

• Pag-upload nito sa maling lugar, gaya ng /assets/robots.txt sa halip na /robots.txt.
• Paggamit ng smart quotes na kinopya mula sa document editor.
• Aksidenteng pagharang sa lahat ng crawler gamit ang User-agent: * at Disallow: /.
• Pag-aakalang nalalapat ang file ng isang domain sa ibang subdomain.
• Pagkalimot na maaaring magkaiba ang paghawak sa http://, https://, www, at non-www hosts depende sa iyong setup.

Para sa mga multi-domain site, suriin ang bawat canonical host. Ang robots file sa https://www.example.com/robots.txt ay hindi awtomatikong namamahala sa https://app.example.com/robots.txt.

Kapag nagde-debug, siyasatin ang aktuwal na HTTP response, hindi lang ang ipinapakita ng CMS preview. Gusto mo ng 200 OK response, text/plain content type kung maaari, at ang eksaktong file na inaasahan mo. Kung may kasamang redirects, caching, o CDN rules, nakatutulong ang raw header inspection. Direktang nalalapat dito ang workflow sa debugging redirects and HTTP headers in production.

Magdagdag ng server-side controls para sa mga bot na binabalewala ang rules

Kung sumusunod ang crawler, robots.txt ang pinakamalinis na signal. Kung abusive ang crawler, kailangan mo ng enforcement.

Kabilang sa praktikal na controls ang:

Rate limiting

Magtakda ng thresholds para sa hindi karaniwang request patterns: sobrang daming page kada minuto, malalim na pagination traversal, paulit-ulit na 404, o mataas na request volume mula sa maliit na set ng IP. Dapat sapat na mapagbigay ang rate limits para hindi maparusahan ang totoong users at sapat na istrikto para gawing magastos ang bulk extraction.

User-agent filtering

Maaari mong harangin ang dokumentadong AI crawler user agents sa web server, reverse proxy, CDN, o application layer. Mas malakas ito kaysa robots.txt dahil nagbabalik ito ng aktuwal na denial response.

Halimbawa, maaaring harangin ng Nginx ang isang user agent pattern, bagama’t dapat masusing subukan ang production rules:

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

Hindi ito foolproof. Madaling pekein ang user-agent strings. Ngunit pinipigilan nito ang honest o lazy traffic at binabawasan ang load.

IP at ASN controls

Naglalathala ang ilang operator ng IP ranges, ngunit marami sa scraper ecosystems ang hindi. Maaaring gumana ang IP-based blocking para sa halatang abuse, lalo na mula sa cloud hosting ranges na walang normal user traffic, ngunit maaari rin itong lumikha ng false positives. Gumamit ng logs bago gumawa ng rules.

Authentication at paywalls

Kung hindi dapat makopya nang maramihan ang content, huwag ilagay ang buong content sa isang pampublikong URL. Hindi angkop ang robots.txt para sa confidential material, licensed databases, private communities, o paid archives.

Content minimization

Minsan arkitektural ang pinakamainam na proteksyon. Huwag ilantad ang hindi kinakailangang APIs, malalaking JSON payload, hidden metadata, draft endpoints, o buong archives kung maliit na subset lang ang kailangan ng public page. Dapat ding isipin ng image-heavy sites kung anong metadata ang inilalathala nila; nalalapat din sa content operations ang privacy logic sa stripping EXIF metadata before sharing photos online.

Gumamit ng robots meta tags para sa page-level rules

Kinokontrol ng robots.txt ang crawling. Kinokontrol ng robots meta tags at X-Robots-Tag headers ang indexing at snippet behavior para sa sumusunod na search engines at crawlers.

Halimbawa:

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

O bilang HTTP header:

X-Robots-Tag: noindex, noarchive

Hindi AI-specific shields ang mga ito. Kapaki-pakinabang ang mga ito kapag gusto mong accessible ang isang page ngunit hindi indexed. Gayunpaman, kung hinaharang mo ang crawler mula sa pag-fetch ng page sa robots.txt, maaaring hindi nito kailanman makita ang page-level meta tag. Huwag umasa sa isang noindex tag sa URL na ipinagbabawal i-crawl ng crawler.

Ang magaspang na tuntunin:

• Gamitin ang robots.txt para bawasan o pigilan ang crawling.
• Gamitin ang meta robots o X-Robots-Tag para kontrolin ang indexing behavior.
• Gamitin ang server-side controls para ipatupad ang access.

I-monitor ang logs pagkatapos mag-publish

Ang pag-publish ng file ay unang hakbang pa lang. Pagkatapos nito, suriin ang iyong logs.

Hanapin ang:

• Mga request sa /robots.txt mula sa user agents na pinangalanan mo.
• Patuloy na crawling matapos ma-serve ang disallow rules.
• Kahina-hinalang user agents na may mataas na volume.
• Browser-like user agents na humihiling ng libo-libong page nang magkakasunod.
• Paulit-ulit na access sa feeds, sitemaps, search pages, at pagination.

Kung humiling ang isang bot ng robots.txt, nakakita ng full disallow, at pagkatapos ay tumigil, nagawa ng robots.txt ang trabaho nito. Kung nagpapatuloy ito, ilipat ang bot na iyon sa enforcement: rate limits, blocks, o authentication.

Suriin din ang iyong sitemap exposure. Kapaki-pakinabang ang sitemaps para sa search engines, ngunit maginhawa rin silang mapa para sa scrapers. Hindi ibig sabihin nito na dapat mong alisin ang mga ito sa ordinaryong sites. Ibig sabihin nito, hindi ka dapat magsama ng mga URL na ayaw mong matuklasan ng public systems.

Panatilihing maliit at nire-review ang file

May tendensiyang mabulok ang robots.txt. Nagdaragdag ang marketing team ng campaign microsite. Nagdaragdag ang developer ng staging path. Binabago ng vendor ang pangalan ng crawler nito. Pagkalipas ng dalawang taon, wala nang nakaaalam kung bakit umiiral ang kalahati ng rules.

Ituring ito bilang configuration:

• I-store ito sa version control kung maaari.
• Magdagdag ng maikling comment para sa bawat AI crawler group.
• I-review ito kada quarter.
• Suriin ang vendor documentation bago magdagdag ng broad rules.
• Subukan pagkatapos ng CDN, CMS, o hosting changes.

Kung naglalathala ang iyong site ng AI-assisted content, ihiwalay din ang crawler policy mula sa editorial transparency. Ang pagharang sa AI scrapers ay tungkol sa access at reuse. Ang disclosure ay tungkol sa tiwala ng mambabasa. Nag-o-overlap ang mga ito sa etikal na pananaw, ngunit hindi sila iisang control. Tinalakay ang praktikal na disclosure approach sa what honest AI disclosure looks like on a small website.

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

💡 Subukan ito: Pagkatapos magdagdag ng mga panuntunan para sa mga AI crawler, kumpirmahin ang syntax gamit ang Robots.txt Tester para hindi mo rin aksidenteng ma-block ang mga lehitimong bot.

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

Ang pinakabuod

Haharangin ng isang mahusay na robots.txt file ang mga sumusunod na AI crawler. Hindi nito mapipigilan ang determinadong scraping, kinopyang user-agent strings, compromised browsers, o mga taong manu-manong nagpe-paste ng iyong content sa AI systems.

Hindi ibig sabihin nito na wala itong silbi. Ibig sabihin, isa itong layer.

Sumulat ng explicit rules para sa dokumentadong AI crawlers. Iwasan ang broad blocks na nakakasira sa search visibility. Subukan ang served file, hindi ang draft. Bantayan ang logs. Magpatupad gamit ang server-side controls kung saan ang behavior ay lumalagpas mula sa hindi kanais-nais tungo sa abusive.

Matagal nang tumatakbo ang web sa halo ng protocol, norms, at enforcement. Ang robots.txt ang norms layer. Gamitin ito, ngunit huwag itong ipagkamaling pader.