Log-urile de server arată exact ce cer boții AI, ce răspuns primesc și cât așteaptă. Fără ele, discuți despre AI Search pe baza unor presupuneri: pagini bune care nu sunt accesibile, răspunsuri 403 din firewall sau cereri abandonate după 30 de secunde. Analiza începe cu trei întrebări: intră, ce primesc, cât așteaptă.

Discuția despre AI Search s-a mutat, în bună măsură, în zona de conținut: cum scrii, cum structurezi, cum obții citări. Corect, dar incomplet. Contează și dacă textele alea ajung efectiv la bot. Iar dovada nu stă în dashboard-ul de analytics, nu stă în tracking-ul de prompturi, ci într-un fișier pe care multe echipe nu l-au deschis niciodată: log-ul de acces.

Moz a publicat pe 29.10.2026 un ghid practic despre analiza log-urilor pentru AI Search (sursa). Îl folosesc ca punct de plecare, dar ce urmează e comentariul meu operațional: ce verifici, în ce ordine, unde se sparge raționamentul și ce faci luni dimineață.

De ce log-ul spune ce nu spun celelalte surse de date

Un log de acces înregistrează o linie pentru fiecare cerere: IP-ul solicitantului, data și ora, pagina cerută și metoda, user-agent-ul declarat, codul de răspuns și câți octeți s-au trimis efectiv. Opțional, în funcție de stack, timpul de răspuns și statusul cache.

Diferența față de restul datelor din stack e simplă. Tracking-ul de prompturi arată ce a spus asistentul. Datele de referral arată când un om a dat click. Niciuna nu arată dacă asistentul a putut să îți citească pagina. Log-ul arată.

Asta schimbă natura discuției. Nu mai întrebi "apar în ChatGPT?", ci "a primit ChatGPT-User pagina mea de prețuri, în câte milisecunde și cu câți octeți". E o întrebare la care se răspunde cu date, nu cu opinii.

Șase cereri, cinci povești diferite

Exemplul din materialul Moz e didactic și merită repetat ca structură de diagnostic. Aceeași pagină, cerută de mai mulți actori, cu rezultate care arată complet diferit:

Cinci diagnostice diferite, aceeași pagină. Fără log, toate cinci ar fi invizibile și ai continua să optimizezi conținut care nu ajunge nicăieri.

Ce tipuri de boți cauți și de ce contează distincția

Prima greșeală frecventă nu e tehnică, e de categorisire. Boții care ating un site în 2026 nu sunt o masă omogenă. Sunt cel puțin patru niveluri, cu scopuri și ritmuri diferite:

  1. Training: colectează text pentru antrenarea modelelor, la frecvență mică.
  2. Indexing: construiesc lista pe care asistentul o caută ca să găsească ce poate cita.
  3. Live fetching: aduc pagina în momentul întrebării unui utilizator. Nivelul care citește pagina.
  4. Acting: un agent acționează pe site în numele utilizatorului. Nivelul care folosește site-ul.

Convenția de nume ajută, dar nu e regulă: sufixul "-User" indică de obicei o cerere live. Tratează-l ca indiciu, nu ca lege.

De aici decurge prima capcană reală: blocarea boților "cu japca". Un regulament de tipul "blochez toți boții AI" în robots.txt sau în CDN poate bloca simultan GPTBot (decizie legitimă de business, dacă nu vrei să-ți antrenezi conținutul) și OAI-SearchBot (ceea ce poate scoate conținutul din răspunsurile ChatGPT search). Două decizii complet diferite, luate accidental împreună. Când cineva îți spune că a blocat boții AI, prima întrebare e: care boți, exact?

A doua capcană: user-agent-ul nu e identitate

User-agent-ul e doar un nume pe care și-l dă solicitantul. Orice tool poate trimite "GPTBot" în header. Consecințele merg în două direcții, ambele neplăcute: scraperii umflă numerele, iar regulile de securitate gândite să blocheze boții falși pot bloca boții reali.

De aceea, la importul log-urilor în analizor, activează verificarea boților. Mecanismele de verificare diferă în funcție de operator: intervale de IP publicate, înregistrări DNS, headere semnate. Nu presupune că toți boții se verifică la fel și nu presupune că un bot nedocumentat e fake.

De aici vine o regulă de igienă analitică pe care o aplic constant: o verificare incompletă nu dovedește absența unei funcții sau a unui element. Dacă nu găsești cereri de la un bot, posibilele explicații sunt cel puțin patru: nu a cerut niciodată, cererile au fost servite din CDN și nu apar în log-ul de origin, intervalul de timp e prea scurt, sau hostname-ul e logat în altă parte. "Nu e în log" nu e echivalent cu "nu există".

Cum obții datele fără să pierzi o săptămână

Ordinea practică pe care o recomand, în trei pași:

Pasul 1: cere o mostră, nu un export. Câteva sute de linii sunt suficiente ca să verifici că fișierul se deschide, că formatul e citibil și că are câmpurile de care ai nevoie. E mult mai ieftin decât să descoperi după un export de zeci de GB că lipsește user-agent-ul.

Pasul 2: cere câmpurile pe nume. IP client, URL cerut și metodă, data și ora, user-agent, cod de răspuns, octeți trimiși. Dacă stack-ul permite, cere și timpul de răspuns și statusul cache. Astea două nu sunt în formatul implicit nginx, dar CDN-ul sau load balancer-ul le pot avea deja.

Pasul 3: alege fereastra în funcție de întrebare. Una-două săptămâni pentru un diagnostic punctual. Una-două luni pentru comportament general de crawling. Peste 90 de zile dacă te interesează boții de training, care vin rar.

Un detaliu de sursă care contează: dacă CDN-ul servește majoritatea cererilor din cache, log-urile de origin subnumără traficul. Pentru analiza de AI Search, log-urile de CDN sunt referința bună.

Ce cauți efectiv în date: trei întrebări, nu treizeci de rapoarte

Intră? Două liste sunt aur curat. Prima: paginile pe care niciun bot AI verificat nu le-a cerut. Sunt invizibile pentru AI Search, oricât de bine ar ranka în Google. Dacă paginile de bani sunt acolo, problema nu e conținutul, e accesul. A doua: URL-urile cerute doar de boți, tipic vechi, linkate cândva. Verifică dacă trebuie să returneze o pagină reală sau să redirecteze. Ceva de afară tot cere acele URL-uri.

Ce primesc? Codul de răspuns spune povestea pe categorii. 200 OK e bine, dar verifică octeții: un 200 cu o fracțiune din dimensiunea așteptată e un shell. Redirecturile multiple sau în buclă sunt o problemă. 403 înseamnă că ai respins cererea, uită-te la firewall și la regulile de bot management. 404 și 410 apar când boții cer pagini dispărute. 499 e clientul care renunță. 5xx e serverul tău. Important: uită-te la rata de eroare pe bot, nu la nivel de site. O rată mică pe un asistent cu trafic live poate însemna pierdere reală.

Cât așteaptă? Aici e partea pe care majoritatea auditurilor o sar. Compară timpul mediu de răspuns pe bot și pe secțiune de site. Două tipare te interesează: un bot care primește răspunsuri mai lente decât restul, și o secțiune a site-ului care merge mai lent decât media. Motivele diferă fundamental: un crawler de motor de căutare mai așteaptă și revine. Un asistent care răspunde unui om are un utilizator în față și poate renunța.

De ce 499 e codul care merită urmărit

499 înseamnă "client closed request". Nu e cod oficial HTTP, e o convenție nginx preluată de multe CDN-uri și load balancere. Înseamnă un singur lucru: cineva a închis conexiunea înainte să termini de trimis.

Codul nu îți spune de ce. Îți spune doar că s-a luat o decizie despre tine, în afara controlului tău. De aceea e interesant: e singurul loc din log unde vezi explicit că ai pierdut cititorul. Și e ușor de ratat, pentru că monitorizarea clasică veghează la erorile 5xx, nu la abandonurile clientului.

Ce faci cu el: corelează 499 cu statusul cache. Dacă abandonurile se concentrează pe cache miss, ai o problemă de performanță la origin, nu de acces. Corelează cu timpul de răspuns. Dacă media pe acea secțiune e de ordinul zecilor de secunde, ai răspunsul înainte să te uiți la altceva.

Ce înseamnă pentru tine, marketer sau antreprenor în România

Pentru un business mediu din România, cu un site pe Shopify sau WordPress și un CDN pus de agenție, întrebarea practică nu e "facem analiză de log-uri?". E "avem acces la cineva care ne poate da fișierele?".

Trei lucruri concrete de făcut fără să angajezi un data engineer:

  1. Întreabă ce e blocat. Deschide robots.txt și regulile de WAF/bot management. Notează exact ce boți sunt blocați. Dacă a fost o decizie "să blocăm AI-ul" luată acum doi ani, e posibil ca ea să blocheze și boții de indexing, nu doar training.
  2. Testează pagina de bani fără JavaScript. Ia URL-ul cel mai important comercial, descarcă-l fără JS și vezi ce conținut rămâne. Dacă rămâne un shell gol, boții care nu execută JS văd un shell gol. E verificabil în zece minute, fără log-uri.
  3. Cere o mostră de log și un interval de două săptămâni. Nu ai nevoie de big data ca să afli dacă boții ajung la paginile importante. Ai nevoie de un fișier citibil și de cineva care să îl citească.

Aici se leagă și discuția mai largă despre dovezi. Majoritatea marketerilor declară că AI-ul funcționează în marketing, dar puțini pot arăta mecanismul, iar analiza pe care o propun eu e exact tipul de dovadă care lipsește. Detalii în materialul despre de ce majoritatea marketerilor spun că AI funcționează, dar puțini o pot dovedi.

Un detaliu de infrastructură care nu e opțional: un 403 rapid în log poate fi o regulă de securitate care blochează trafic legitim, iar în 2026 regulile de securitate se schimbă des. Merită citit și materialul despre DDoS în 2026, atacuri scurte și vectori noi, pentru că aceleași straturi care te apără de atacuri pot filtra boți utili.

Și, dacă tot intri în zona de performanță și parametri tehnici, schimbările din analytics rămân relevante pentru cum măsori ce urmărești după ce repari accesul: vezi ce se schimbă în Google reintroduce num=100, ce se schimbă în SEO și analytics.

Ce limite are analiza de log-uri

Ca să nu transformăm un instrument bun într-o promisiune nerealistă:

FAQ

Trebuie să am acces la log-urile de CDN sau sunt suficiente cele de la server? Depinde de unde se servește traficul. Dacă CDN-ul răspunde din cache pentru majoritatea cererilor, log-urile de origin nu conțin acele cereri. Pentru o imagine corectă, cere log-urile de CDN. Dacă nu există CDN, log-urile de server sunt punctul de plecare normal.

Blochez GPTBot dacă nu vreau să-mi antreneze conținutul? E o decizie de business, nu una tehnică. Important e să o iei separat de boții de indexing și de cei de live fetching, pentru că un regulament generic "toți boții AI" le poate bloca pe toate. Întâi identifici ce boți sunt blocați, apoi decizi.

Cât de repede văd rezultatul unei corecturi? Nu pot promite termene. Depinde de frecvența cu care fiecare bot revine și de cache. Ce pot spune cu certitudine: după corectare, recitirea log-urilor în aceleași condiții îți arată dacă cererea primește acum conținutul complet.

Arc: AI, om și pasul concret

AI-ul ajută real în partea de analiză. Curăță log-uri, grupează user-agent-uri, scoate liste de URL-uri nevizitate și de cereri cu octeți incompleți, calculează medii de timp pe bot și pe folder. Fără AI, un export de câteva milioane de linii înseamnă zile de muncă manuală.

Dar AI-ul nu decide ce e important. Nu știe care pagină e pagina de bani. Nu știe dacă un 403 vine dintr-o regulă de securitate justificată sau dintr-o configurație uitată. Nu știe dacă merită să blochezi training-ul și să păstrezi indexing-ul. Aici intervine media buyer-ul sau SEO-ul senior: citește contextul, prioritizează, decide și își asumă decizia.

Iar execuția rămâne umană: cineva trebuie să vorbească cu DevOps, să ceară mostrele, să valideze formatul, să schimbe regula din firewall și să recitească log-urile după. Pasul concret îl face ALLSoft Agency.