Boții AI accesează tot mai multe website-uri pentru a descoperi, indexa sau prelua conținut. Pentru proprietarul unui website, problema nu este însă simpla apariție a unui crawler în loguri, ci numărul de request-uri generate și tipul paginilor pe care acesta le accesează.
Un crawler care citește ocazional câteva articole poate avea un impact aproape insesizabil. În schimb, mii de request-uri către pagini dinamice, căutări, filtre WooCommerce sau API-uri pot determina executarea repetată a PHP și interogarea bazei de date.
Pe un cont de găzduire care utilizează cPanel, CloudLinux și LiteSpeed Enterprise, acest trafic poate fi investigat folosind logurile de acces și informațiile despre consumul de resurse.
Cine sunt boții AI și de ce accesează website-urile?
Nu toți boții AI au același rol. Este important să facem diferența între crawlere utilizate pentru dezvoltarea modelelor, crawlere pentru servicii de căutare și request-uri generate atunci când un utilizator solicită accesarea unei pagini.
OpenAI documentează, de exemplu, mai multe tipuri de User-Agent:
- GPTBot – crawler folosit pentru conținut care poate contribui la dezvoltarea modelelor generative;
- OAI-SearchBot – utilizat pentru includerea website-urilor în funcțiile de căutare ChatGPT;
- ChatGPT-User – poate accesa o pagină în urma unei acțiuni inițiate de un utilizator ChatGPT.
Anthropic utilizează la rândul său:
- ClaudeBot – pentru colectarea de conținut care poate contribui la dezvoltarea modelelor;
- Claude-SearchBot – pentru funcțiile de căutare;
- Claude-User – pentru accesări inițiate în contextul unei solicitări a utilizatorului.
Prin urmare, blocarea unui crawler pentru antrenarea modelelor nu este neapărat același lucru cu blocarea accesului unui serviciu de căutare AI.
Google-Extended nu este un crawler separat
Google-Extended este deseori inclus în listele de „AI bots”, însă există o diferență tehnică importantă.
Google-Extended nu are propriul User-Agent HTTP. Este un token utilizat în robots.txt pentru a controla anumite utilizări ale conținutului de către produsele AI Google.
Crawling-ul propriu-zis este realizat prin User-Agent-urile Google existente.
Din acest motiv, nu are sens să cauți în access log un User-Agent numit:
Google-Extended
Google precizează și că blocarea Google-Extended nu influențează includerea website-ului în Google Search și nu reprezintă un semnal de ranking.
Cum identifici boții AI în cPanel?
Cel mai util punct de pornire este access log-ul website-ului.
În cPanel accesează:
cPanel → Metrics → Raw Access
Secțiunea Raw Access permite descărcarea logurilor domeniului în format comprimat .gz.
Un request poate arăta aproximativ astfel:
203.0.113.25 - - [14/Oct/2026:10:20:15 +0300] "GET /articol/ HTTP/1.1" 200 18432 "-" "Mozilla/5.0 ... GPTBot/1.4 ..."
Din această linie putem identifica:
- IP-ul sursă;
- data și ora;
- metoda HTTP;
- URL-ul accesat;
- codul HTTP;
- User-Agent-ul declarat.
Pentru un ghid complet despre aceste loguri poți consulta articolul Raw Access Logs și AWStats în cPanel.
Caută User-Agent-urile crawlerelor
Dacă administrezi un VPS cu acces root, pe un server cPanel poți căuta direct în logul domeniului:
grep -iE 'GPTBot|OAI-SearchBot|ClaudeBot|Claude-SearchBot' /var/log/apache2/domlogs/exemplu.ro | tail -100
Pentru a număra request-urile identificate:
grep -iE 'GPTBot|OAI-SearchBot|ClaudeBot|Claude-SearchBot' /var/log/apache2/domlogs/exemplu.ro | wc -l
Înlocuiește exemplu.ro cu domeniul analizat.
Numărul total nu este însă suficient. Trebuie verificat și ce pagini sunt accesate.
Contează foarte mult ce URL-uri accesează crawlerul
Două crawlere care generează același număr de request-uri pot produce un consum complet diferit.
Un crawler care accesează articole publice aflate în cache poate genera un impact redus.
În schimb, request-uri repetate către:
/search/ /?s=produs /wp-json/ /filtru-produse/ /api/ /checkout/
pot necesita procesare dinamică.
Pentru un website WordPress sau WooCommerce, aceasta poate însemna:
Request ↓ LiteSpeed ↓ PHP ↓ WordPress / WooCommerce ↓ MySQL / MariaDB ↓ Răspuns
Cu cât request-ul necesită mai multă procesare PHP și mai multe interogări SQL, cu atât impactul asupra resurselor poate fi mai mare.
Poți folosi și AWStats
Dacă este disponibil pentru cont, AWStats poate oferi o imagine generală asupra traficului.
Accesează:
cPanel → Metrics → Awstats
Aici poți analiza traficul zilnic și orar, codurile HTTP și alte informații despre vizitatori.
AWStats este util pentru tendințe generale, însă pentru investigarea exactă a unui bot și a request-urilor acestuia, Raw Access Logs sunt mai potrivite.
User-Agent-ul poate fi falsificat
Faptul că într-un access log apare:
GPTBot
nu demonstrează singur că request-ul provine într-adevăr de la OpenAI.
User-Agent-ul este o valoare trimisă de client și poate fi modificată foarte ușor.
Operatorii unor crawlere publică metode suplimentare de verificare. OpenAI, de exemplu, publică intervalele IP utilizate pentru GPTBot, OAI-SearchBot și ChatGPT-User.
În cazul în care identificarea exactă este importantă, IP-ul request-ului trebuie comparat cu informațiile oficiale ale operatorului.
Cu alte cuvinte:
User-Agent = indiciu IP și verificarea oficială = confirmare mai bună
Cum pot boții AI să afecteze resursele CloudLinux?
Pe infrastructura shared NameBox, CloudLinux este utilizat pentru izolarea conturilor și administrarea resurselor alocate fiecărui cont.
Traficul automatizat poate contribui la consumul mai multor resurse.
CPU
Dacă request-ul necesită executarea PHP, procesorul trebuie să ruleze codul aplicației. Un număr mare de request-uri dinamice poate crește consumul CPU.
Memorie RAM – PMEM
Procesele PHP și componentele aplicației utilizează memorie. Mai multe request-uri procesate simultan pot determina creșterea PMEM.
Entry Processes
Entry Processes reprezintă intrările simultane în LVE și sunt relevante pentru cererile dinamice procesate în același timp.
EP nu reprezintă numărul vizitatorilor website-ului.
I/O și IOPS
Request-urile pot necesita acces la fișiere, cache sau alte date de pe disc. CloudLinux poate monitoriza atât volumul I/O, cât și numărul operațiunilor IOPS.
Procese și baza de date
WordPress sau WooCommerce pot executa interogări către MySQL/MariaDB pentru generarea paginilor dinamice.
Un crawler care accesează intensiv astfel de pagini poate contribui indirect și la încărcarea bazei de date.
Pentru explicații detaliate despre aceste limite poți consulta Resurse pachet găzduire: CPU, RAM, I/O și Entry Processes și articolul despre CloudLinux.
Nu orice bot din log este cauza consumului ridicat
Aceasta este una dintre cele mai importante reguli atunci când investighezi problema.
Nu este suficient să găsești GPTBot sau ClaudeBot în access log și să concluzionezi că acesta a încetinit website-ul.
Trebuie corelate request-urile cu Resource Usage.
De exemplu:
14:00 → consum normal 14:05 → începe un volum mare de crawling 14:08 → CPU și EP cresc 14:15 → crawling-ul scade 14:18 → resursele revin la normal
O astfel de corelație oferă un indiciu mult mai bun.
Dacă CPU crește la ora 03:00, dar crawlerul a accesat website-ul la ora 15:00, cauza trebuie căutată în altă parte.
Poate fi vorba despre cron jobs, backup, importuri, pluginuri, malware sau alte procese.
Ce rol are LiteSpeed Enterprise?
LiteSpeed Enterprise poate reduce semnificativ impactul traficului repetitiv atunci când o pagină poate fi servită direct din cache.
Pentru o pagină disponibilă în LSCache:
Crawler ↓ LiteSpeed Enterprise ↓ LSCache HIT ↓ HTML livrat direct
Aplicația nu trebuie să genereze din nou pagina la fiecare accesare.
LiteSpeed documentează faptul că, pentru un cache hit complet, aplicația nu trebuie să regenereze pagina, ceea ce reduce încărcarea serverului.
Pentru WordPress poți verifica răspunsul:
X-LiteSpeed-Cache: hit
Dacă apare:
X-LiteSpeed-Cache: miss
pagina nu a fost servită dintr-un obiect cache existent pentru request-ul respectiv.
Pentru mai multe informații poți consulta articolul Ce este LiteSpeed și cum funcționează?.
LiteSpeed Cache nu elimină orice consum
Nu toate paginile pot fi tratate identic.
Zone precum checkout-ul unui magazin, pagini personalizate pentru utilizatori, API-uri, request-uri POST, căutări și diferite filtre dinamice pot necesita procesare PHP.
În această situație:
Crawler ↓ LiteSpeed ↓ Cache MISS / resursă dinamică ↓ PHP ↓ WordPress ↓ Baza de date
Acesta este motivul pentru care optimizarea cache-ului ajută, dar nu reprezintă automat o soluție pentru orice trafic generat de boți.
Cum controlezi accesul boților AI?
Există mai multe niveluri prin care accesul poate fi controlat, iar metoda trebuie aleasă în funcție de obiectiv.
robots.txt
Dacă nu dorești ca GPTBot și ClaudeBot să acceseze conținutul pentru utilizările asociate acestor crawlere, poți utiliza:
User-agent: GPTBot Disallow: / User-agent: ClaudeBot Disallow: /
OpenAI și Anthropic documentează respectarea regulilor robots.txt pentru aceste crawlere.
Important: robots.txt nu este un firewall. Este o instrucțiune pe care crawlerele conforme aleg să o respecte.
Poți permite separat crawlerele pentru căutare
De exemplu, OpenAI permite control separat pentru crawlerul utilizat în ChatGPT Search.
User-agent: OAI-SearchBot Allow: / User-agent: GPTBot Disallow: /
Astfel poți permite descoperirea conținutului pentru search și, în același timp, să restricționezi GPTBot.
OpenAI precizează că website-urile care dezactivează OAI-SearchBot nu vor fi afișate ca rezultate obișnuite în răspunsurile ChatGPT Search, deși pot exista în continuare linkuri de navigare.
Blocarea efectivă prin .htaccess
Dacă obiectivul este oprirea efectivă a request-ului și website-ul rulează pe LiteSpeed Enterprise, poate fi utilizată o regulă la nivelul website-ului.
Un exemplu pentru GPTBot și ClaudeBot este:
<IfModule LiteSpeed>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "GPTBot|ClaudeBot" [NC]
RewriteRule .* - [E=blockbot:1]
</IfModule>
LiteSpeed documentează variabila blockbot pentru blocarea conexiunilor pe baza regulilor Rewrite.
Această configurație este mult mai puternică decât robots.txt, deoarece request-ul este blocat la nivelul serverului web.
Nu copia automat liste foarte mari de User-Agent-uri. O regulă greșită poate afecta crawlere legitime, integrări, API-uri sau servicii pe care website-ul le folosește.
În plus, User-Agent-ul poate fi falsificat, deci această metodă nu trebuie privită ca un sistem perfect de identificare.
Cloudflare poate controla separat crawlerele AI
Dacă website-ul utilizează Cloudflare ca proxy, există și instrumente dedicate pentru acest tip de trafic.
Cloudflare oferă AI Crawl Control, unde pot fi vizualizați crawlerii AI identificați și poate fi configurată o acțiune pentru fiecare dintre aceștia.
Cloudflare clasifică separat, de exemplu:
GPTBot → AI Crawler OAI-SearchBot → AI Search ChatGPT-User → AI Assistant ClaudeBot → AI Crawler Claude-SearchBot → AI Search Claude-User → AI Assistant
Pentru website-urile care folosesc Cloudflare se pot utiliza și reguli WAF sau Rate Limiting atunci când obiectivul este limitarea unui volum excesiv de request-uri.
Aceste funcționalități țin de serviciul Cloudflare și nu trebuie confundate cu instrumentele cPanel sau CloudLinux.
Ce rol au Imunify360 și ModSecurity?
Pe infrastructura NameBox, Imunify360 și ModSecurity reprezintă niveluri suplimentare de protecție pentru aplicațiile web.
Un crawler AI legitim nu trebuie considerat automat un atac.
Aceste sisteme devin relevante atunci când request-urile corespund unor reguli de securitate sau prezintă comportamente considerate malițioase.
De aceea, nu recomandăm dezactivarea unor mecanisme de securitate doar pentru că un crawler primește un răspuns 403.
Pentru mai multe informații poți consulta articolul ModSecurity în cPanel și eroarea 403.
Merită să blochezi boții AI?
Nu există un răspuns universal.
Restricționarea poate avea sens dacă un crawler generează un volum mare de trafic, accesează repetitiv pagini costisitoare sau produce un consum de resurse demonstrabil.
În același timp, blocarea tuturor crawlerelor AI fără diferențiere poate reduce posibilitatea ca website-ul să fie descoperit prin serviciile de căutare și asistenții AI.
De aceea, înainte de blocare trebuie să răspunzi la trei întrebări:
- Ce crawler generează request-urile?
- Ce pagini accesează?
- Există o creștere măsurabilă a consumului în același interval?
Abordarea corectă este:
Măsoară ↓ Identifică ↓ Verifică ↓ Corelează cu resursele ↓ Limitează doar dacă este necesar
Analizează traficul înainte să aplici blocări
Boții AI reprezintă doar o parte din traficul automatizat care poate ajunge pe un website.
Pe un server cu cPanel, CloudLinux și LiteSpeed, combinația dintre Raw Access Logs, AWStats, Resource Usage și informațiile de cache permite identificarea mult mai precisă a impactului real.
O pagină servită din LSCache poate avea un cost foarte redus, în timp ce o căutare WooCommerce sau un endpoint dinamic poate executa PHP și multiple interogări SQL la fiecare request.
Din acest motiv, simpla apariție a GPTBot, ClaudeBot sau a altui crawler în loguri nu înseamnă automat că website-ul are o problemă.
Dacă observi un consum ridicat, începe cu logurile, identifică intervalul exact și compară-l cu cPanel → Resource Usage. Abia după această verificare are sens să alegi între robots.txt, blocare HTTP, rate limiting sau alte mecanisme de control.
Pentru website-urile WordPress, poți consulta și ghidul nostru despre optimizarea WordPress.
Pe pagina noastră HelpDesk găsiți multe alte tutoriale utile pentru a gestiona mai ușor contul dvs. cPanel.