Robots.txt a fost inventat in 1994. Un fisier de text simplu, pus in radacina site-ului, prin care ii spuneai unui crawler ce sa nu acceseze. Pagini de admin. Fisiere de test. Directoare interne. Functiona pentru ca existau putini crawlere si toate jucau dupa aceleasi reguli.
Treizeci de ani mai tarziu, acelasi fisier este rugat sa faca ceva complet diferit: sa controleze ce modele AI au voie sa citeasca, sa antreneze si sa redistribuie din continutul tau. Si nu, nu e echipat pentru asta.
La difrnt., am inceput sa primim intrebari despre robots.txt si AI cam din 2024. Initial erau simple: "Putem bloca ChatGPT?". Acum sunt mult mai nuantate. Si raspunsul e aproape niciodata un simplu da sau nu.
Cand un fisier din 1994 devine politie de trafic AI
Robots.txt a fost proiectat cu o premisa clara: crawlerele vor respecta regulile voluntar. Nu exista enforcement. E un gentleman's agreement, nu un firewall. Googlebot a respectat robots.txt de 25 de ani, pentru ca avea interes sa fie un bun cetatean al web-ului. La fel Yahoo, Bing, si ceilalti.
Dar universul crawlerelor s-a extins dramatic. Conform datelor din industrie, traficul de boti AI pe site-uri a crescut cu peste 300% in ultimul an. GPTBot (OpenAI), ClaudeBot (Anthropic), Google-Extended, CCBot, Bytespider, Amazonbot, fiecare vine cu propriul user-agent si propriile reguli de interpretare.
Problema? Fiecare companie AI a decis independent cum sa-si numeasca crawlerul. Nu exista un standard. Daca vrei sa blochezi antrenarea AI pe continutul tau, trebuie sa mentii o lista de user-agents care creste lunar. In momentul de fata, un robots.txt complet care acopera principalii crawleri AI are peste 30 de randuri dedicate exclusiv acestui scop.
Am vazut asta direct in auditurile tehnice pe care le facem. Un client din e-commerce avea 14 crawlere AI distincte in log-urile de server, dintre care doar 3 erau mentionate in robots.txt. Restul accesau site-ul complet nestingheriti. Nu pentru ca proprietarul nu voia sa le blocheze, ci pentru ca pur si simplu nu stia ca exista.
Blocarea AI nu inseamna ce crezi ca inseamna
Cea mai frecventa confuzie pe care o intalnim la clienti: "Am blocat GPTBot, deci ChatGPT nu mai stie nimic de noi." Fals. Si pe mai multe niveluri.
Primo, robots.txt controleaza crawlarea, nu antrenarea. Daca un model AI a fost antrenat pe date din Common Crawl sau alte seturi publice de date care au inclus site-ul tau inainte sa blochezi crawlerul, acel continut este deja in model. Blocarea e prospectiva, nu retroactiva. Un raport din 2025 estima ca peste 60% din web-ul public a fost inclus in seturile de antrenare ale principalelor modele lingvistice. Probabilitatea ca site-ul tau sa fie deja acolo e mare.
Secundo, exista o diferenta critica intre antrenare si grounding (sau retrieval). Cand blochezi Google-Extended, blochezi antrenarea modelului Gemini pe continutul tau. Dar nu blochezi neaparat ca Gemini sa citeze sau sa rezume continutul tau in AI Overviews, pentru ca acolo Google foloseste indexul de cautare, nu crawlerul de antrenare. Acelasi continut, doua utilizari complet diferite, un singur mecanism de control.
Asta creeaza un paradox interesant. Multi proprietari de site-uri vor sa-si protejeze continutul de "furtul" AI, dar in acelasi timp vor sa apara in raspunsurile AI. E ca si cum ai vrea sa blochezi un restaurant din a-ti copia reteta, dar in acelasi timp sa le ceri sa te recomande clientilor. Cele doua obiective pot fi contradictorii, iar robots.txt nu are granularitatea necesara sa le separe curat.
Tertio, unele companii folosesc mai multi user-agents pentru scopuri diferite. Anthropic, de exemplu, are ClaudeBot pentru antrenare, Claude-User pentru interactiuni directe si Claude-SearchBot pentru cautare. OpenAI are GPTBot pentru antrenare si OAI-SearchBot pentru cautare. Daca blochezi GPTBot dar nu OAI-SearchBot, continutul tau poate fi inca accesat si utilizat in anumite contexte. Configuratia corecta depinde de ce exact vrei sa controlezi.
Standardizarea vine, dar lent
Vestea buna: industria incepe sa recunoasca problema. Google, Microsoft si OpenAI lucreaza la un mecanism comun de opt-out care ar permite unui singur rand in robots.txt sa comunice preferinta de antrenare catre mai multi furnizori simultan. Anthropic e si ea in discutii. Ideea e sa nu mai fie nevoie de 30 de reguli separate, ci de una singura, universala.
Vestea mai putin buna: implementarea completa e estimata pentru 2027. Pana atunci, fiecare furnizor va continua sa interpreteze regulile diferit. Microsoft planuieste sa inlocuiasca directivele NoArchive si NoCache cu noul sistem abia din martie 2027. Google va trata noua optiune "ca si cum" ai fi blocat Google-Extended, ceea ce creeaza ambiguitati pentru site-urile care vor sa permita grounding-ul dar nu antrenarea.
In practica, asta inseamna ca robots.txt pentru AI va fi complicat inca cel putin un an. Si chiar dupa standardizare, va trebui sa verifici ca fiecare furnizor onoreaza aceleasi reguli in acelasi mod. Nici macar un standard universal nu elimina nevoia de monitorizare.
Ce recomandam clientilor la difrnt.
Am dezvoltat un checklist pe care il aplicam in toate auditurile tehnice. Nu e spectaculos, dar functioneaza. Cateva puncte esentiale:
1. Inventariaza inainte sa blochezi. Inainte sa adaugi reguli in robots.txt, verifica log-urile de server. Cati boti AI acceseaza efectiv site-ul? Cu ce frecventa? Cat bandwidth consuma? Multi clienti vor sa blocheze crawlere care nici macar nu le viziteaza site-ul. Alteori, descoperim crawlere care genereaza 40-50% din traficul total, consumand resurse fara niciun beneficiu.
2. Decide ce vrei sa controlezi. Vrei sa blochezi antrenarea? Citarea in raspunsuri AI? Ambele? Raspunsul determina configuratia. Pentru majoritatea business-urilor, vizibilitatea in raspunsuri AI este un avantaj, nu o amenintare. Blocarea totala inseamna sa dispari din AI Search, si asta e o decizie de business, nu una tehnica.
3. Monitorizeaza dupa implementare. Robots.txt nu are confirmare de primire. Nu stii daca un crawler respecta regulile decat daca verifici log-urile. Noi verificam la 30 de zile dupa orice modificare si am gasit cazuri in care crawlere mai mici ignorau complet directivele. Fara monitorizare, robots.txt e doar un act de speranta.
4. Nu uita de sitemap.xml. Un robots.txt restrictiv combinat cu un sitemap.xml permisiv trimite semnale contradictorii. Daca blochezi un crawler din robots.txt dar il inviți prin sitemap, comportamentul variaza de la furnizor la furnizor. Unii il ignora, altii il interpreteaza ca pe o invitatie explicita care suprasrie restrictia.
5. Revizuieste trimestrial. Lista crawlerelor AI se schimba constant. Apar user-agents noi, unele se redenumesc, altele sunt inlocuite. Un robots.txt care era complet in ianuarie poate fi depasit in aprilie. Am adaugat actualizarea robots.txt ca punct fix in review-urile tehnice trimestriale pe care le facem clientilor.
Robotul tau de text din 1994 nu va disparea curand. Dar rolul lui se schimba fundamental. Nu mai e vorba doar de "nu intra aici". E vorba de "cine are voie sa faca ce cu continutul meu". Si pentru asta, un fisier static de text e un instrument nepotrivit folosit din lipsa a ceva mai bun.
Cand brandurile mari isi optimizeaza prezenta in AI Search, cele mici trebuie macar sa inteleaga ce controale au la dispozitie. Chiar daca sunt imperfecte.
