Hogyan írjunk olyan robots.txt-t, amely valóban blokkolja az MI-scrapereket

A kényelmetlen igazság a robots.txt-ről

Egy robots.txt fájl nem zár. Csak egy tábla az ajtón.

Ez a különbség fontos, amikor csapatok azt kérdezik, hogy „blokkolhatják-e az MI-scrapereket” egyetlen kis szövegfájllal. Azoknál a megbízható crawlereknél, amelyek követik a Robots Exclusion Protocol szabályait, igen: egy helyesen megírt robots.txt jelezheti nekik, hogy ne térképezzék fel az oldalait. Ismeretlen scraperek, megszemélyesítők, böngészőautomatizálás és olyan botok esetén, amelyeket egyszerűen nem érdekel, önmagában semmit sem fog tenni.

A gyakorlati cél tehát nem az, hogy „lehetetlenné tegyük a scrapinget”. Hanem ez:

• Jelezni a szabálykövető MI-crawlereknek, hogy ne használják a webhelyét.
• Elkerülni, hogy véletlenül blokkolja a keresőmotorokat vagy hasznos szolgáltatásokat.
• Erősebb szerveroldali kontrollokat hozzáadni a visszaélések ellen.
• Karbantarthatóan tartani a szabályzatot, ahogy a crawlerek nevei változnak.

Ez az unalmas verzió. Egyben ez az a verzió is, amely működik.

Mire képes és mire nem képes a robots.txt

Egy robots.txt fájl a webhely gyökerében található:

https://example.com/robots.txt

A crawlerek ezt kérik le a feltérképezés előtt. A fájl szabálycsoportokat tartalmaz. Minden csoport egy vagy több User-agent sorral kezdődik, amelyeket Allow vagy Disallow direktívák követnek.

Egy egyszerű, teljes webhelyre vonatkozó tiltás így néz ki:

User-agent: GPTBot
Disallow: /

Ez azt jelenti: ha GPTBot vagy, ne térképezz fel semmit ezen a webhelyen.

A robots.txt-nek azonban kemény korlátai vannak:

1. Önkéntes. A rossz szereplők figyelmen kívül hagyhatják.
2. Nem akadályozza meg, hogy egy URL-t normál böngésző vagy script lekérjen.
3. Nem távolít el máshol már összegyűjtött tartalmat.
4. Önmagában nem határoz meg szerzői jogi, licencelési vagy tréningjogokat.
5. Félrekonfigurálható úgy, hogy rossz botokat blokkoljon.

Ha valódi hozzáférés-vezérlésre van szüksége, használjon hitelesítést, jogosultságkezelést, rate limitinget, IP-alapú kontrollokat, botkezelést vagy jogi eszközöket. A robots.txt továbbra is hasznos, de egy szélesebb tartalomvédelmi stratégiába tartozik.

Ez hasonló más webes irányítási problémákhoz: a látható kontroll ritkán jelenti a teljes kontrollt. Ha a szervezetén belül már most is van kezeletlen MI-használat, ugyanez az elv érvényes; egy gyors árnyék-MI audit gyakran hasznosabb, mint úgy tenni, mintha egyetlen szabályzati dokumentum megoldaná a problémát.

Kezdje a szabályzati döntéssel

Mielőtt szerkesztené a fájlt, döntse el, valójában mit próbál blokkolni.

Legalább négy különböző dolgot értenek az emberek „MI-scraper” alatt:

• Tréningadatok gyűjtésére használt crawlerek.
• MI-kereső vagy válaszmotor crawlerek.
• Felhasználó által indított lekérők, például amikor valaki arra kér egy MI-terméket, hogy foglaljon össze egy URL-t.
• Általános scraperek, amelyek hétköznapi böngészőnek adják ki magukat.

Lehet, hogy mindegyiket blokkolni szeretné. Vagy lehet, hogy szeretné a keresési felfedezhetőséget, miközben leiratkozik a modelltréningről. Ez nem ugyanaz a szabályzat.

Az OpenAI például külön user agenteket dokumentál különböző célokra, köztük a GPTBot, ChatGPT-User és OAI-SearchBot neveket. A Google a Google-Extended tokent használja kontrollként bizonyos Gemini és Vertex AI felhasználási esetekhez, miközben a normál Google Search feltérképezést más Googlebot user agentek végzik.

Ez az elkülönítés fontos. Ha gondatlanul blokkol széles user agenteket, ronthatja a szokásos keresési láthatóságot, miközben az MI-tréninget próbálja blokkolni.

Egy észszerű robots.txt sablon MI blokkolására

Íme egy konzervatív kiindulópont több, gyakran dokumentált MI-hez kapcsolódó crawler blokkolására úgy, hogy az általános keresőcrawlereket békén hagyja:

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

Ez nem varázslatos, univerzális lista. Ez egy karbantartható minta.

Néhány megjegyzés:

• A Disallow: / azt jelenti: „ne térképezz fel egyetlen elérési utat sem”.
• A User-agent: * azokra a crawlerekre vonatkozik, amelyekre nem illeszkedik specifikusabb csoport.
• Az Allow: / nem szigorúan szükséges az alapértelmezett csoportnál, de egyértelművé teszi a szándékát.
• Tartsa röviden a megjegyzéseket. Egyes parserek elnézőek, de a robots.txt maradjon unalmas.
• Ne szerepeltessen privát URL-eket a robots.txt-ben. A fájl nyilvános, és az érzékeny útvonalak felsorolása felhívhatja rájuk a figyelmet.

Az utolsó pontot érdemes megismételni. A robots.txt nem titkosítási mechanizmus. Ha a /client-contracts/ nem lehet nyilvános, védje hitelesítéssel. Ne csupán tiltsa le.

Legyen óvatos a Google-Extended használatával

A Google-Extended-et sokan félreértik. Nem ugyanaz, mint a Google Search blokkolása.

A Google dokumentációja szerint a Google-Extended egy önálló terméktoken, amelyet a kiadók arra használhatnak, hogy kezeljék, a webhely tartalma segíthet-e bizonyos Gemini és Vertex AI képességek fejlesztésében. Ennek blokkolása önmagában nem kellene, hogy megakadályozza a Googlebotot a Search célú feltérképezésben.

Ennek ellenére ne cseréljen le minden Google-direktívát ilyen széles tiltásra, hacsak nem pontosan ezt akarja:

User-agent: Googlebot
Disallow: /

Ez azt mondaná a Google Search fő crawlerének, hogy ne térképezze fel a webhelyét. A legtöbb nyilvános webhely esetében nem ezt szeretné.

Ugyanez a különbségtétel máshol is érvényes. Egyes szolgáltatók elkülönítik a tréningcrawlereket a felhasználó által indított böngészéstől vagy az MI-kereső crawlerektől. Mások nem. El kell olvasnia az Ön számára fontos botok dokumentációját, és a robots.txt-t élő fájlként kell kezelnie, nem egyszeri jelölőnégyzetként.

Tesztelje a fájlt úgy, mint éles kódot

A robots.txt egyszerűnek tűnik, ezért könnyű elrontani.

Gyakori hibák például:

• Rossz helyre töltik fel, például /robots.txt helyett /assets/robots.txt alá.
• Dokumentumszerkesztőből másolt tipográfiai idézőjeleket használnak.
• Véletlenül minden crawlert blokkolnak a User-agent: * és Disallow: / párossal.
• Feltételezik, hogy egy domain fájlja egy másik aldomainre is vonatkozik.
• Elfelejtik, hogy a http://, https://, www és nem www hosztok a beállítástól függően eltérően kezelhetők.

Többdoménes webhelyeknél ellenőrizzen minden kanonikus hosztot. A https://www.example.com/robots.txt alatt lévő robots fájl nem szabályozza automatikusan a https://app.example.com/robots.txt címet.

Hibakereséskor a tényleges HTTP-választ vizsgálja, ne csak azt, amit a CMS előnézete mutat. 200 OK választ szeretne, lehetőleg text/plain tartalomtípust, és pontosan azt a fájlt, amelyre számít. Ha átirányítások, gyorsítótárazás vagy CDN-szabályok is érintettek, a nyers headerek vizsgálata segít. Az éles környezeti átirányítások és HTTP-headerek hibakereséséről szóló munkafolyamat közvetlenül alkalmazható itt.

Adjon hozzá szerveroldali kontrollokat azokhoz a botokhoz, amelyek figyelmen kívül hagyják a szabályokat

Ha a crawler szabálykövető, a robots.txt a legtisztább jelzés. Ha a crawler visszaélésszerűen viselkedik, kikényszerítésre van szükség.

Gyakorlati kontrollok:

Rate limiting

Állítson be küszöböket szokatlan kérési mintákra: túl sok oldal percenként, mély lapozás bejárása, ismétlődő 404-ek, vagy nagy kérésmennyiség kevés IP-címről. A limitek legyenek elég megengedőek ahhoz, hogy ne büntessék a valódi felhasználókat, de elég szigorúak ahhoz, hogy a tömeges kinyerést költségessé tegyék.

User-agent szűrés

A dokumentált MI-crawlerek user agentjeit blokkolhatja a webszerveren, reverse proxyn, CDN-en vagy alkalmazásrétegen. Ez erősebb, mint a robots.txt, mert tényleges tiltó választ ad vissza.

Például az Nginx blokkolhat egy user agent mintát, bár az éles szabályokat gondosan tesztelni kell:

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

Ez nem bolondbiztos. A user-agent stringeket könnyű hamisítani. De megállítja a becsületes vagy lusta forgalmat, és csökkenti a terhelést.

IP- és ASN-kontrollok

Egyes üzemeltetők közzétesznek IP-tartományokat, de sok scraper-ökoszisztéma nem. Az IP-alapú blokkolás működhet nyilvánvaló visszaélések esetén, különösen olyan felhős tárhelytartományokból, ahonnan nincs normál felhasználói forgalom, de hamis pozitív találatokat is okozhat. Szabályok előtt használjon naplókat.

Hitelesítés és paywallok

Ha a tartalmat nem szabad nagy léptékben másolni, ne tegye ki a teljes tartalmat nyilvános URL-re. A robots.txt alkalmatlan bizalmas anyagokhoz, licencelt adatbázisokhoz, privát közösségekhez vagy fizetős archívumokhoz.

Tartalomminimalizálás

Néha a legjobb védelem architekturális. Ne tegyen ki szükségtelen API-kat, nagy JSON payloadokat, rejtett metaadatokat, draft endpointokat vagy teljes archívumokat, ha a nyilvános oldalnak csak egy kis részhalmazra van szüksége. A képekben gazdag webhelyeknek azt is át kell gondolniuk, milyen metaadatokat publikálnak; az EXIF-metaadatok eltávolítása fotók online megosztása előtt témájában leírt adatvédelmi logika a tartalomüzemeltetésre is érvényes.

Használjon robots meta tageket oldalszintű szabályokhoz

A robots.txt a feltérképezést szabályozza. A robots meta tagek és az X-Robots-Tag headerek az indexelést és a snippetek viselkedését szabályozzák a szabálykövető keresőmotorok és crawlerek számára.

Például:

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

Vagy HTTP-headerként:

X-Robots-Tag: noindex, noarchive

Ezek nem MI-specifikus pajzsok. Akkor hasznosak, amikor azt szeretné, hogy egy oldal elérhető legyen, de ne legyen indexelve. Ha azonban robots.txt-ben megtiltja egy crawlernek egy oldal lekérését, lehet, hogy az soha nem látja az oldalszintű meta taget. Ne támaszkodjon noindex tagre olyan URL-en, amelynek feltérképezése a crawler számára tilos.

Az egyszerű szabály:

• Használjon robots.txt-t a feltérképezés csökkentésére vagy megakadályozására.
• Használjon meta robots tageket vagy X-Robots-Tag headereket az indexelési viselkedés szabályozására.
• Használjon szerveroldali kontrollokat a hozzáférés kikényszerítésére.

Figyelje a naplókat publikálás után

A fájl közzététele csak az első lépés. Ezután ellenőrizze a naplókat.

Keresse ezeket:

• Kérések a /robots.txt felé azoktól a user agentektől, amelyeket megnevezett.
• Folytatódó feltérképezés azután, hogy a tiltó szabályokat kiszolgálta.
• Gyanús, nagy volumenű user agentek.
• Böngészőszerű user agentek, amelyek egymás után több ezer oldalt kérnek le.
• Ismételt hozzáférés feedekhez, sitemapekhez, keresőoldalakhoz és lapozáshoz.

Ha egy bot lekéri a robots.txt-t, látja a teljes tiltást, majd leáll, a robots.txt elvégezte a dolgát. Ha folytatja, helyezze át azt a botot kikényszerítés alá: rate limitek, blokkolások vagy hitelesítés.

Tekintse át a sitemap-kitettséget is. A sitemapek hasznosak a keresőmotoroknak, de kényelmes térképek a scrapereknek is. Ez nem jelenti azt, hogy el kellene távolítania őket a szokványos webhelyekről. Azt viszont jelenti, hogy ne tartalmazzanak olyan URL-eket, amelyeket nem szeretne nyilvános rendszerekkel felfedeztetni.

Tartsa kicsiben és felülvizsgálva a fájlt

A robots.txt hajlamos elrohadni. Egy marketingcsapat hozzáad egy kampány-mikrosite-ot. Egy fejlesztő hozzáad egy staging útvonalat. Egy vendor megváltoztatja a crawlere nevét. Két évvel később senki sem tudja, miért létezik a szabályok fele.

Kezelje konfigurációként:

• Amikor lehet, tárolja verziókezelésben.
• Adjon rövid megjegyzést minden MI-crawler csoporthoz.
• Negyedévente vizsgálja felül.
• Széles szabályok hozzáadása előtt ellenőrizze a vendor dokumentációját.
• CDN-, CMS- vagy hostingváltozások után tesztelje.

Ha a webhelye MI-vel támogatott tartalmat publikál, különítse el a crawler-szabályzatot a szerkesztői átláthatóságtól is. Az MI-scraperek blokkolása a hozzáférésről és az újrafelhasználásról szól. A disclosure az olvasói bizalomról. Etikailag átfedik egymást, de nem ugyanaz a kontroll. Gyakorlati disclosure-megközelítést mutat be az őszinte MI-disclosure egy kis webhelyen témájú cikk.

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

💡 Próbálja ki ezt: Miután szabályokat adott hozzá az AI-crawlerekhez, ellenőrizze a szintaxist a Robots.txt Tester segítségével, hogy véletlenül ne blokkoljon legitim botokat is.

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

A lényeg

Egy jó robots.txt fájl blokkolja a szabálykövető MI-crawlereket. Nem állítja meg az elszánt scrapinget, a másolt user-agent stringeket, a kompromittált böngészőket, vagy azokat az embereket, akik kézzel másolják be a tartalmát MI-rendszerekbe.

Ettől még nem haszontalan. Csak egy réteggé válik.

Írjon explicit szabályokat a dokumentált MI-crawlerekhez. Kerülje a széles blokkolásokat, amelyek rontják a keresési láthatóságot. A kiszolgált fájlt tesztelje, ne a vázlatot. Figyelje a naplókat. Ott kényszerítsen ki szerveroldali kontrollokkal, ahol a viselkedés nemkívánatosból visszaélésszerűvé válik.

A web mindig is protokollok, normák és kikényszerítés keverékén működött. A robots.txt a normák rétege. Használja, de ne tévessze össze fallal.