Cum să scrii un robots.txt care chiar blochează scraperele AI

Adevărul incomod despre robots.txt

Un fișier robots.txt nu este o încuietoare. Este un semn pe ușă.

Această distincție contează când echipele întreabă dacă pot „bloca scraperele AI” cu un mic fișier text. Pentru crawlerele reputabile care respectă Robots Exclusion Protocol, da: un robots.txt scris corect le poate spune să nu acceseze paginile site-ului tău. Pentru scrapere necunoscute, imitatori, automatizări de browser și boți cărora pur și simplu nu le pasă, nu va face nimic de unul singur.

Așadar, obiectivul practic nu este „să faci scrapingul imposibil”. Este:

• Să le spui crawlerelor AI conforme să nu îți folosească site-ul.
• Să eviți blocarea accidentală a motoarelor de căutare sau a serviciilor utile.
• Să adaugi controale mai puternice pe partea serverului pentru abuz.
• Să menții politica ușor de administrat pe măsură ce numele crawlerelor se schimbă.

Aceasta este versiunea plictisitoare. Este și versiunea care funcționează.

Ce poate și ce nu poate face robots.txt

Un fișier robots.txt se află la rădăcina unui site:

https://example.com/robots.txt

Crawlerele îl solicită înainte de a accesa site-ul. Fișierul conține grupuri de reguli. Fiecare grup începe cu una sau mai multe linii User-agent, urmate de directive Allow sau Disallow.

O blocare simplă a întregului site arată astfel:

User-agent: GPTBot
Disallow: /

Asta spune: dacă ești GPTBot, nu accesa nimic de pe acest site.

Dar robots.txt are limite clare:

1. Este voluntar. Actorii rău intenționați îl pot ignora.
2. Nu împiedică solicitarea unui URL de către un browser sau un script obișnuit.
3. Nu elimină conținutul deja colectat în altă parte.
4. Nu definește, prin el însuși, drepturi de autor, licențiere sau drepturi de antrenare.
5. Poate fi configurat greșit în moduri care blochează boții nepotriviți.

Dacă ai nevoie de control real al accesului, folosește autentificare, autorizare, limitare de rată, controale pe bază de IP, administrare de boți sau controale legale. Robots.txt rămâne util, dar aparține unei strategii mai largi de protecție a conținutului.

Este similar cu alte probleme de guvernanță web: controlul vizibil este rareori controlul complet. Dacă organizația ta are deja utilizare AI negestionată intern, se aplică același principiu; un audit al AI-ului din umbră rapid este adesea mai util decât să te prefaci că un singur document de politică rezolvă problema.

Începe cu decizia de politică

Înainte de a edita fișierul, decide ce încerci de fapt să blochezi.

Există cel puțin patru lucruri diferite la care oamenii se referă prin „scraper AI”:

• Crawlere folosite pentru a colecta date de antrenare.
• Crawlere pentru căutare AI sau motoare de răspunsuri.
• Fetchere declanșate de utilizator, de exemplu când cineva cere unui produs AI să rezume un URL.
• Scrapere generice care pretind că sunt browsere obișnuite.

Poate vrei să le blochezi pe toate. Sau poate vrei descoperire în căutare, dar cu opt-out din antrenarea modelelor. Acestea nu sunt aceeași politică.

De exemplu, OpenAI documentează user agents separați pentru scopuri diferite, inclusiv GPTBot, ChatGPT-User și OAI-SearchBot. Google folosește Google-Extended ca token de control pentru unele cazuri de utilizare Gemini și Vertex AI, în timp ce crawlingul normal pentru Google Search este gestionat de alți user agents Googlebot.

Această separare este importantă. Dacă blochezi neglijent user agents largi, poți afecta vizibilitatea obișnuită în căutare în timp ce încerci să blochezi antrenarea AI.

Un șablon robots.txt rezonabil pentru blocarea AI

Iată un punct de plecare conservator pentru blocarea mai multor crawlere legate de AI documentate frecvent, lăsând în același timp crawlerele generale de căutare neafectate:

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

Aceasta nu este o listă universală magică. Este un tipar ușor de menținut.

Câteva observații:

• Disallow: / înseamnă „nu accesa nicio cale”.
• User-agent: * se aplică crawlerelor care nu se potrivesc cu un grup mai specific.
• Allow: / nu este strict necesar pentru grupul implicit, dar îți clarifică intenția.
• Păstrează comentariile scurte. Unele parsere sunt îngăduitoare, dar robots.txt ar trebui să rămână plictisitor.
• Nu include URL-uri private în robots.txt. Fișierul este public, iar listarea căilor sensibile le poate face reclamă.

Ultimul punct merită repetat. Robots.txt nu este un mecanism de secretizare. Dacă /client-contracts/ nu ar trebui să fie public, protejează-l cu autentificare. Nu îl pune doar în disallow.

Ai grijă cu Google-Extended

Google-Extended este înțeles greșit pe scară largă. Nu este același lucru cu blocarea Google Search.

Conform documentației Google, Google-Extended este un token de produs independent pe care publisherii îl pot folosi pentru a gestiona dacă un conținut de pe site poate ajuta la îmbunătățirea anumitor capabilități Gemini și Vertex AI. Blocarea lui nu ar trebui, prin ea însăși, să împiedice Googlebot să acceseze site-ul pentru Search.

Acestea fiind spuse, nu înlocui toate directivele Google cu o blocare largă ca aceasta decât dacă asta intenționezi cu adevărat:

User-agent: Googlebot
Disallow: /

Asta i-ar spune crawlerului principal Google Search să nu acceseze site-ul tău. Pentru majoritatea site-urilor publice, nu asta îți dorești.

Aceeași distincție se aplică și în alte părți. Unii furnizori separă crawlerele de antrenare de navigarea declanșată de utilizator sau de crawlerele de căutare AI. Alții nu. Trebuie să citești documentația pentru boții care te interesează și să tratezi robots.txt ca pe un fișier viu, nu ca pe o bifă unică.

Testează fișierul ca pe cod de producție

Robots.txt pare simplu, motiv pentru care este ușor de stricat.

Greșeli frecvente includ:

• Încărcarea lui în locul greșit, cum ar fi /assets/robots.txt în loc de /robots.txt.
• Folosirea ghilimelelor tipografice copiate dintr-un editor de documente.
• Blocarea tuturor crawlerelor cu User-agent: * și Disallow: / din greșeală.
• Presupunerea că fișierul unui domeniu se aplică unui alt subdomeniu.
• Uitarea faptului că gazdele http://, https://, www și non-www pot fi tratate diferit în funcție de configurația ta.

Pentru site-uri cu mai multe domenii, verifică fiecare gazdă canonică. Un fișier robots la https://www.example.com/robots.txt nu guvernează automat https://app.example.com/robots.txt.

Când depanezi, inspectează răspunsul HTTP real, nu doar ce afișează previzualizarea CMS-ului. Vrei un răspuns 200 OK, tip de conținut text/plain dacă este posibil și exact fișierul la care te aștepți. Dacă sunt implicate redirecționări, caching sau reguli CDN, inspectarea brută a headerelor ajută. Fluxul de lucru din depanarea redirecționărilor și a headerelor HTTP în producție se aplică direct aici.

Adaugă controale pe partea serverului pentru boții care ignoră regulile

Dacă un crawler este conform, robots.txt este cel mai curat semnal. Dacă un crawler este abuziv, ai nevoie de aplicare efectivă.

Controale practice includ:

Limitarea ratei

Stabilește praguri pentru tipare neobișnuite de cereri: prea multe pagini pe minut, traversare profundă a paginării, 404 repetate sau volum mare de cereri dintr-un set mic de IP-uri. Limitele de rată ar trebui să fie suficient de generoase încât să nu pedepsească utilizatorii reali și suficient de stricte încât să facă extracția în masă costisitoare.

Filtrarea User-agent

Poți bloca user agents documentați ai crawlerelor AI la nivelul serverului web, al reverse proxy-ului, al CDN-ului sau al aplicației. Aceasta este mai puternică decât robots.txt deoarece returnează un răspuns real de refuz.

De exemplu, Nginx poate bloca un tipar de user agent, deși regulile de producție ar trebui testate cu grijă:

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

Nu este infailibil. Șirurile user-agent sunt ușor de falsificat. Dar oprește traficul onest sau leneș și reduce încărcarea.

Controale IP și ASN

Unii operatori publică intervale IP, dar multe ecosisteme de scraping nu o fac. Blocarea pe bază de IP poate funcționa pentru abuzuri evidente, mai ales din intervale de cloud hosting fără trafic normal de utilizatori, dar poate crea și rezultate fals pozitive. Folosește logurile înaintea regulilor.

Autentificare și paywall-uri

Dacă un conținut nu trebuie copiat la scară, nu pune conținutul complet pe un URL public. Robots.txt nu este potrivit pentru materiale confidențiale, baze de date licențiate, comunități private sau arhive plătite.

Minimizarea conținutului

Uneori, cea mai bună protecție este arhitecturală. Nu expune API-uri inutile, payload-uri JSON mari, metadate ascunse, endpointuri de draft sau arhive complete dacă pagina publică are nevoie doar de un subset mic. Site-urile bogate în imagini ar trebui să se gândească și la metadatele pe care le publică; logica de confidențialitate din eliminarea metadatelor EXIF înainte de a partaja fotografii online se aplică și operațiunilor de conținut.

Folosește taguri meta robots pentru reguli la nivel de pagină

Robots.txt controlează crawlingul. Tagurile meta robots și headerele X-Robots-Tag controlează indexarea și comportamentul fragmentelor pentru motoarele de căutare și crawlerele conforme.

De exemplu:

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

Sau ca header HTTP:

X-Robots-Tag: noindex, noarchive

Acestea nu sunt scuturi specifice pentru AI. Sunt utile când vrei ca o pagină să fie accesibilă, dar să nu fie indexată. Totuși, dacă blochezi un crawler să preia o pagină în robots.txt, este posibil să nu vadă niciodată tagul meta de la nivelul paginii. Nu te baza pe un tag noindex pe un URL pe care crawlerului îi este interzis să îl acceseze.

Regula aproximativă:

• Folosește robots.txt pentru a reduce sau preveni crawlingul.
• Folosește meta robots sau X-Robots-Tag pentru a controla comportamentul de indexare.
• Folosește controale pe partea serverului pentru a impune accesul.

Monitorizează logurile după publicare

Publicarea fișierului este doar primul pas. După aceea, verifică logurile.

Caută:

• Cereri către /robots.txt de la user agents pe care i-ai numit.
• Crawling continuu după ce sunt servite regulile disallow.
• User agents suspecți cu volum mare.
• User agents asemănători browserelor care solicită mii de pagini în secvență.
• Acces repetat la feeduri, sitemapuri, pagini de căutare și paginare.

Dacă un bot solicită robots.txt, vede un disallow complet și apoi se oprește, robots.txt și-a făcut treaba. Dacă continuă, mută acel bot în zona de aplicare: limite de rată, blocări sau autentificare.

Revizuiește și expunerea sitemapului. Sitemapurile sunt utile pentru motoarele de căutare, dar sunt și hărți convenabile pentru scrapere. Asta nu înseamnă că ar trebui să le elimini de pe site-urile obișnuite. Înseamnă că nu ar trebui să incluzi URL-uri pe care nu vrei ca sistemele publice să le descopere.

Păstrează fișierul mic și revizuit

Robots.txt tinde să se degradeze. O echipă de marketing adaugă un microsite de campanie. Un dezvoltator adaugă o cale de staging. Un furnizor își schimbă numele crawlerului. Doi ani mai târziu, nimeni nu știe de ce există jumătate dintre reguli.

Tratează-l ca pe o configurație:

• Stochează-l în version control când este posibil.
• Adaugă un comentariu scurt pentru fiecare grup de crawlere AI.
• Revizuiește-l trimestrial.
• Verifică documentația furnizorilor înainte de a adăuga reguli largi.
• Testează după schimbări de CDN, CMS sau hosting.

Dacă site-ul tău publică conținut asistat de AI, separă și politica pentru crawlere de transparența editorială. Blocarea scraperelor AI ține de acces și reutilizare. Dezvăluirea ține de încrederea cititorilor. Se suprapun etic, dar nu sunt același control. O abordare practică a dezvăluirii este acoperită în cum arată o dezvăluire AI onestă pe un site mic.

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

💡 Încercați asta: După ce adăugați reguli pentru crawlerele AI, confirmați sintaxa cu Robots.txt Tester, ca să nu blocați din greșeală și boți legitimi.

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

Concluzia

Un fișier robots.txt bun va bloca crawlerele AI conforme. Nu va opri scrapingul determinat, șirurile user-agent copiate, browserele compromise sau oamenii care îți lipesc manual conținutul în sisteme AI.

Asta nu îl face inutil. Îl face un strat.

Scrie reguli explicite pentru crawlerele AI documentate. Evită blocările largi care afectează vizibilitatea în căutare. Testează fișierul servit, nu draftul. Urmărește logurile. Aplică reguli cu controale pe partea serverului acolo unde comportamentul trece de la nedorit la abuziv.

Webul a funcționat întotdeauna pe un amestec de protocol, norme și aplicare. Robots.txt este stratul normelor. Folosește-l, dar nu îl confunda cu un zid.