Analiza jurnalelor de server: ce vă spun despre felul în care Google vă crawlează

Analiza jurnalelor de server: ce vă spun despre felul în care Google vă crawlează. Fiecare cerere pe care Googlebot o trimite către site-ul dumneavoastră rămâne înregistrată, cu oră exactă, cod de răspuns și adresă IP, în jurnalele serverului.

Majoritatea administratorilor se uită doar în Search Console, care arată date eșantionate și întârziate cu câteva zile. Jurnalele brute arată exact ce a cerut crawlerul, fără nicio filtrare între el și dumneavoastră.

Analiza jurnalelor de server: ce vă spun despre felul în care Google vă crawlează

Pe un cont de hosting cu cPanel, jurnalele de acces există deja, fără niciun plugin instalat și fără cod suplimentar pe site. Problema nu e lipsa datelor, ci faptul că nimeni nu le citește înainte să fie comprimate și șterse de rotația automată.

Unde găsiți jurnalele brute în cPanel

În cPanel, secțiunea Metrics > Raw Access permite descărcarea jurnalelor zilei curente și a arhivelor din zilele anterioare, de obicei comprimate cu gzip. Pe server, fișierele stau de regulă în /home/utilizator/access-logs/domeniu.ro, un fișier text sau un link simbolic către jurnalul activ al Apache sau LiteSpeed.

Fiecare linie respectă formatul combinat de jurnalizare: adresa IP, data și ora cererii, metoda și calea cerută, codul de stare, numărul de octeți transferați, referrer-ul și șirul user-agent. Din acest șir aflați dacă vizitatorul pretinde că este Googlebot, însă pretenția singură nu e o dovadă, așa cum explicăm în secțiunea despre verificare.

Retenția implicită diferă de la un pachet de hosting la altul. Pe un cont shared obișnuit, WHM păstrează de regulă arhivele câteva săptămâni înainte să le șteargă definitiv, nu doar să le comprime. Pe un VPS administrat de dumneavoastră, intervalul se setează manual în configurarea serviciului de jurnalizare al Apache sau LiteSpeed, iar un interval prea scurt înseamnă că orice analiză de tendință pe trimestru devine imposibilă, nu doar incomodă.

Diferența dintre Apache și LiteSpeed contează mai ales la volum mare de trafic: LiteSpeed scrie jurnalele într-un format ușor diferit, cu un câmp suplimentar pentru timpul de procesare al cererii, util tocmai când investigați dacă un cod 503 a apărut din lipsă de resurse, nu dintr-o eroare de configurare.

De ce jurnalele spun mai mult decât Search Console

Raportul de statistici de crawlare din Search Console agregă datele pe zile, le întârzie și limitează numărul de exemple afișate pentru fiecare categorie de probleme. E util pentru o privire de ansamblu, dar inutil când trebuie să găsiți exact ce cale a generat un cod 500 ieri la ora trei dimineața.

Jurnalele brute nu agregă nimic. Fiecare cerere a fiecărui crawler apare separat, cu timestamp exact, ceea ce permite corelarea directă cu alte evenimente: un deploy, o modificare de configurare sau o campanie de linkuri care a atras brusc mai mulți roboți pe site.

Search Console raportează și doar roboții pe care Google îi recunoaște drept proprii. În jurnale apar, în aceeași listă, Googlebot, Bingbot, roboții de la furnizorii de unelte SEO și scraperele necunoscute care pretind user-agenți de browser obișnuiți. Separarea reală a traficului de crawlere de traficul uman sau de boții falși nu se poate face decât la nivelul jurnalelor, pentru că rapoartele agregate din panouri amestecă toate aceste categorii fără să le distingă clar.

Cum verificați că un vizitator este chiar robotul Google

Șirul user-agent se falsifică în câteva secunde, așa că nu e o dovadă de identitate. Verificarea reală se face prin căutare DNS inversă pe adresa IP din jurnal, urmată de o confirmare în sens direct a numelui obținut.

host 66.249.66.1
# răspuns așteptat: ceva-66-249-66-1.googlebot.com

dig +short ceva-66-249-66-1.googlebot.com
# trebuie să întoarcă exact 66.249.66.1

Dacă numele de gazdă obținut nu se termină în .googlebot.com sau .google.com, sau dacă a doua interogare nu confirmă adresa IP inițială, cererea nu vine de la Google, indiferent ce scrie în user-agent. Astfel de cereri false merită izolate separat în statistici, ca să nu vă umfle artificial cifrele de crawlare.

Google publică și liste oficiale cu intervalele de adrese IP folosite de Googlebot, actualizate periodic, pe care le puteți descărca automat într-un script de verificare în loc să faceți interogarea DNS la fiecare linie din jurnal. Pentru un site cu trafic mare, varianta cu lista de IP-uri e mult mai rapidă decât mii de interogări DNS repetate, și la fel de sigură, cât timp lista se reîmprospătează periodic, nu o dată la un an.

Merită separate și cele două tipuri principale de Googlebot: crawlerul pentru desktop și crawlerul pentru mobil, acesta din urmă dominant astăzi, de vreme ce Google indexează aproape toate site-urile după varianta mobilă a paginilor. Dacă în jurnalele dumneavoastră crawlerul pentru desktop are o pondere neobișnuit de mare, verificați dacă site-ul servește conținut diferit pe cele două variante, o cauză frecventă de discrepanțe la indexare.

Ce căutați în jurnalele brute

Odată confirmate cererile reale ale Googlebot, trei lucruri contează mai mult decât restul.

• Distribuția codurilor de stare: un procent mare de 301 și 302 înseamnă lanțuri de redirecționare pe care crawlerul le parcurge în loc să ajungă direct la pagina finală.
• Adresele 404 cerute repetat: Google încă ține minte adrese vechi și revine la ele, consumând vizite care ar putea merge spre pagini active.
• Codurile 500 și 503 apărute chiar în timpul crawlării: un semn că serverul nu a făcut față exact când Googlebot a venit, nu o coincidență de ignorat.

Comparați apoi frecvența de accesare pe secțiuni cu importanța lor reală. Dacă paginile de filtrare dintr-un magazin online sunt crawlate de zeci de ori mai des decât paginile de produs, crawlerul își consumă timpul pe combinații fără valoare, în loc să descopere conținut nou. Tema e aceeași discutată și la bugetul de crawlare, dar aici vedeți dovada concretă, linie cu linie.

Urmăriți și ora din zi la care vine crawlerul. Un site găzduit în România, dar crawlat masiv între orele de vârf ale traficului local, concurează pentru aceleași resurse de server cu vizitatorii reali, iar un timp de răspuns care crește exact atunci explică adesea fluctuații de poziționare pe care altfel le-ați căuta degeaba în conținut sau în linkuri.

Instrumente pentru extragerea și analiza datelor

Pentru un site mic, câteva comenzi de linie de comandă rezolvă cea mai mare parte a analizei, direct pe server, fără să descărcați fișiere de zeci de megaocteți.

zcat access-log.*.gz | grep -i "googlebot" | awk '{print $9}' | sort | uniq -c | sort -rn

Comanda de mai sus numără câte cereri cu user-agent Googlebot au primit fiecare cod de stare, din toate arhivele comprimate ale lunii. Puteți adapta ușor comanda ca să extrageți doar căile cerute, prin schimbarea coloanei selectate de awk, ceea ce arată imediat care secțiuni atrag cel mai mult crawlerul într-o perioadă dată. Pentru volume mari, pe site-uri cu zeci de mii de pagini, merită un instrument dedicat, care face și corelarea automată cu sitemap-ul și cu rezultatul crawlării proprii, nu doar numărătoarea brută.

• Screaming Frog Log File Analyser, gratuit până la un volum mic de linii, cu interfață grafică și filtrare pe tip de bot.
• GoAccess, instrument open-source de linie de comandă, potrivit pentru rapoarte rapide direct pe server.
• Un script propriu în Python, dacă aveți deja o bază de date unde vreți să păstrați istoricul, nu doar o privire de moment.

Probleme frecvente descoperite în jurnale

Aceleași tipare apar, cu mici variații, pe majoritatea site-urilor pe care le analizăm.

• Capcane de crawlare: pagini de calendar generate dinamic, cu link către luna următoare la nesfârșit, pe care Googlebot le parcurge ca pe un labirint fără ieșire.
• Parametri de urmărire sau de sortare lăsați necanonicalizați, care produc mii de adrese tehnic diferite pentru același conținut, discutate pe larg și la conținutul duplicat.
• Pagini excluse explicit prin fișierul robots.txt, dar crawlate oricum pentru verificarea periodică a directivei, ceea ce e normal și nu un motiv de panică.
• Adrese din sitemap-ul XML pe care Googlebot nu le-a cerut niciodată, semn că sitemap-ul conține intrări ignorate sau de calitate slabă.

Arhivarea jurnalelor înainte de rotația automată

Pe majoritatea conturilor cPanel, rotația implicită comprimă jurnalul zilnic și păstrează doar câteva zile sau săptămâni de istoric, în funcție de configurarea din WHM. Pentru o analiză de tendință pe luni întregi, acel interval nu ajunge.

Soluția e o sarcină cron simplă, care copiază zilnic arhiva nouă într-un spațiu de stocare extern, înainte ca rotația să o șteargă definitiv.

0 2 * * * gzip -c /home/utilizator/access-logs/domeniu.ro > /mnt/arhiva-externa/jurnale/domeniu-$(date +\%Y\%m\%d).log.gz

Principiul e identic cu cel descris la backup-urile automate pe cPanel: datele locale dispar la un moment dat, iar singura copie care contează e cea păstrată în afara serverului de producție.

Cât de des merită repetată analiza

O verificare punctuală, făcută o singură dată, arată o fotografie, nu o tendință. Tiparele de crawlare utile apar abia când comparați mai multe luni la rând: a crescut frecvența de accesare după ce ați publicat un articol nou, a scăzut după o migrare de domeniu sau a rămas constantă deși ați adăugat zeci de pagini noi.

Pentru majoritatea site-urilor, o trecere lunară prin jurnalele arhivate e suficientă. După o schimbare majoră, precum o migrare, o restructurare de categorii sau o actualizare mare de conținut, verificarea merită făcută săptămânal timp de o lună, exact perioada în care Googlebot își recalibrează frecvența de accesare pe baza noii structuri.

Analiza jurnalelor de server nu înlocuiește Search Console, dar arată exact ce vede crawlerul, fără aproximări. Dacă descoperiți tipare pe care nu știți cum să le corectați, un audit SEO complet pornește adesea tocmai de la aceste date brute, iar o discuție de consultanță SEO ajută la transformarea observațiilor în priorități concrete de lucru, mai ales când site-ul trece printr-o lucrare de SEO tehnic mai amplă.