Ce vă spun jurnalele serverului despre felul în care vă crawlează Google

Ce vă spun jurnalele serverului despre felul în care vă crawlează Google. Fiecare vizită pe care robotul Google o face pe site-ul dumneavoastră lasă o urmă exactă în jurnalele serverului, fișierele text în care găzduirea înregistrează automat orice cerere primită.

Aceste înregistrări arată exact ce pagini vizitează Google, cât de des și ce erori întâlnește pe drum. Cititorul care le înțelege descoperă probleme de indexare pe care Google Search Console nu le semnalează niciodată.

Ce vă spun jurnalele serverului despre felul în care vă crawlează Google

Majoritatea proprietarilor de site-uri se uită doar în Google Search Console când vor să știe cum se comportă Google pe site-ul lor. Search Console arată însă un rezumat prelucrat, cu întârziere de câteva zile, în timp ce jurnalele serverului arată fiecare cerere, în ordine, chiar în momentul în care s-a întâmplat.

Diferența contează mai ales pentru un site cu multe pagini sau cu probleme tehnice ascunse, unde rezumatul nu prinde detaliile care explică de ce anumite pagini nu se indexează.

Ce este de fapt un jurnal de server

Un jurnal de server, numit adesea „access log”, este un fișier text în care serverul adaugă automat câte o linie pentru fiecare cerere primită, fie că vine de la un vizitator, fie de la un robot precum Googlebot. Fiecare linie conține adresa IP a celui care a cerut pagina, data și ora exactă, pagina cerută, codul de răspuns și numele programului care a făcut cererea.

O linie tipică arată așa:

66.249.66.1 - - [03/Sep/2026:04:12:31 +0200] "GET /audit-seo/ HTTP/1.1" 200 18452 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Din această singură linie aflați cine a cerut pagina, ce pagină a cerut, la ce oră și ce răspuns a primit de la server. Pe un site găzduit prin cPanel, aceste fișiere se găsesc de obicei în secțiunea „Raw Access Logs” din panoul de control.

Formatul poate diferi puțin de la un server la altul

Un server Apache scrie jurnalele într-un format ușor diferit față de unul Nginx, iar unele găzduiri adaugă și un câmp cu pagina de la care a venit vizitatorul, numit „referrer”. Informația de bază rămâne însă aceeași: cine a cerut, ce a cerut, când și cu ce rezultat. Câmpul cu numele programului care a făcut cererea se numește „user-agent” și este exact locul unde apare eticheta „Googlebot”, alături de versiunea browserului simulat.

Cum recunoașteți robotul Google adevărat în jurnale

Numele „Googlebot” din linia de jurnal nu este o dovadă. Oricine poate trimite o cerere către server și poate declara în antet că este Googlebot, exact așa cum cineva poate scrie orice nume vrea pe o etichetă.

Verificarea reală se face prin adresa IP, folosind o căutare inversă de tip DNS, disponibilă în orice terminal Linux:

host 66.249.66.1

Dacă rezultatul se termină în „googlebot.com” sau „google.com”, iar o a doua căutare pe acel nume întoarce aceeași adresă IP de la care a pornit cererea, robotul este autentic. Semnele care indică un robot fals, deghizat în Googlebot, sunt:

• adresa IP nu aparține domeniilor Google la căutarea inversă;
• numărul de cereri pe minut este mult peste ce trimite Google în mod normal;
• robotul cere pagini de administrare sau fișiere care nu apar niciunde public;
• ignoră complet regulile din fișierul robots.txt, pe care Googlebot le respectă.

Un robot fals descoperit în jurnale poate fi blocat direct din configurarea serverului, fără să afecteze accesul vizitatorilor sau al robotului real. Pentru confirmare completă, se face și verificarea inversă, pornind de la numele găsit la primul pas:

host crawl-66-249-66-1.googlebot.com

Dacă acest al doilea pas întoarce exact adresa IP inițială, de 66.249.66.1 în exemplul de mai sus, aveți confirmarea completă că vizita a venit de la Googlebot și nu de la un program care doar copiază numele robotului pentru a trece neobservat prin restricțiile serverului.

Ce arată jurnalele despre bugetul de crawlare

Bugetul de crawlare este numărul de pagini pe care Google decide să le viziteze pe site-ul dumneavoastră într-o perioadă dată. Jurnalele arată exact cum este cheltuit acest buget, pagină cu pagină, nu doar câte pagini în total au fost accesate.

Un tipar frecvent pe site-urile mai vechi este risipa de vizite pe pagini fără valoare: rezultate de căutare internă, variante de filtrare a produselor sau pagini vechi care ar trebui redirecționate. Fiecare astfel de vizită înseamnă că robotul are mai puțin timp alocat pentru paginile care chiar contează.

Analiza jurnalelor arată și frecvența de recrawlare pentru paginile importante. O pagină de serviciu recrawlată o dată pe lună se actualizează mult mai greu în rezultatele Google decât una vizitată zilnic, iar acest decalaj explică uneori de ce o modificare recentă nu apare încă în căutări.

Pentru a compara vizitele pe două pagini, numărați liniile din jurnal care conțin adresa fiecăreia și proveniența de la Googlebot, de exemplu:

grep "Googlebot" access.log | grep "/audit-seo/" | wc -l

Comanda de mai sus numără câte cereri a trimis Googlebot spre pagina indicată, în perioada acoperită de fișierul de jurnal. Repetarea ei pentru mai multe pagini arată rapid care secțiuni ale site-ului primesc atenție din partea Google și care sunt aproape ignorate, o informație pe care niciun raport standard nu o oferă atât de direct.

Probleme frecvente descoperite în jurnale

Multe probleme tehnice ies la iveală abia atunci când urmăriți jurnalele pe o perioadă mai lungă, nu doar la o verificare izolată. Cele mai des întâlnite sunt:

• pagini cu cod 404, cerute constant de Google, deși au fost șterse de mult timp;
• redirecționări înlănțuite, unde robotul trece prin trei sau patru salturi pentru a ajunge la pagina finală;
• cod 500, semn că serverul cedează exact în momentul vizitei robotului, adesea din lipsă de resurse;
• resurse blocate din greșeală în robots.txt, precum fișiere CSS sau imagini necesare pentru randarea corectă a paginii;
• pagini identice accesate sub mai multe adrese, semn de conținut duplicat cauzat de parametri din URL.

Fiecare dintre aceste probleme poate exista luni de zile fără să apară vizibil pentru un vizitator obișnuit, în timp ce Google le întâlnește la fiecare vizită. Pagina cu 404 constant, de exemplu, consumă din bugetul de crawlare la fel ca o pagină validă, doar că nu aduce niciun beneficiu în schimb. Redirecționările înlănțuite au un efect similar, fiindcă fiecare salt suplimentar înseamnă o cerere separată în jurnal, deci timp pierdut din vizita robotului.

Codul 500 apărut chiar în timpul unei vizite Googlebot este cel mai grav dintre aceste semnale, fiindcă arată o problemă de capacitate a serverului, nu doar de configurare a site-ului. Dacă acest cod apare repetat, în special în perioadele cu trafic ridicat, verificarea resurselor serverului devine urgentă, nu doar recomandată.

Cât de des merită verificate jurnalele

Pentru un site mic, cu câteva zeci de pagini și modificări rare, o verificare lunară a jurnalelor este suficientă pentru a prinde din timp problemele descrise mai sus. Pentru un magazin online sau un site cu sute de pagini, unde conținutul se schimbă des, o verificare săptămânală ajută să observați rapid dacă o modificare recentă a afectat neașteptat comportamentul robotului.

Există și momente în care o verificare imediată este obligatorie, indiferent de programul obișnuit:

• după o migrare pe alt hosting sau o schimbare de domeniu;
• după o actualizare mare de temă sau de plugin-uri pe WordPress;
• după o scădere bruscă de trafic organic, vizibilă în statisticile site-ului;
• după modificarea fișierului robots.txt sau a regulilor de redirecționare.

Cum analizați jurnalele fără cunoștințe tehnice avansate

Nu este nevoie să scrieți programe complicate pentru a scoate informații utile dintr-un jurnal de server. Câteva instrumente accesibile fac cea mai mare parte a muncii:

• secțiunea „Raw Access Logs” din cPanel, care oferă fișierul brut, gata de descărcat;
• un instrument dedicat de analiză a jurnalelor, care separă automat cererile venite de la roboți de cele venite de la vizitatori reali;
• raportul „Crawl stats” din Google Search Console, util ca punct de plecare înainte de a intra în detaliile din jurnalul brut;
• o comandă simplă de linie, precum grep "Googlebot", care filtrează dintr-un fișier mare doar liniile care menționează robotul căutat.

Dacă nu aveți acces direct la server sau nu găsiți secțiunea potrivită în panoul de găzduire, furnizorul de hosting poate activa sau trimite aceste jurnale la cerere.

Ce faceți cu informațiile găsite

Descoperirea unei probleme în jurnale nu are valoare dacă nu este urmată de o corectare. Paginile cu 404 constant se redirecționează sau se elimină din sitemap, redirecționările înlănțuite se scurtează la un singur salt, iar resursele blocate din greșeală se scot din robots.txt.

Pentru paginile importante, recrawlate rar, ajută adăugarea unor linkuri interne noi dinspre pagini deja vizitate frecvent de robot, fiindcă Google urmează adesea linkurile pentru a decide ce mai vizitează.

Un pas util, adesea omis, este să păstrați un istoric al observațiilor din jurnale, chiar și într-un tabel simplu: data verificării, problemele găsite și ce s-a corectat. Peste câteva luni, acest istoric arată dacă anumite probleme revin constant, semn că sursa lor nu a fost eliminată complet, ci doar corectată punctual.

Concluzie

Jurnalele serverului rămân una dintre puținele surse care arată exact, fără interpretare, cum se comportă Google pe site-ul dumneavoastră. Cine le citește periodic prinde din timp probleme care altfel ar rămâne ascunse luni întregi, până la o scădere vizibilă de trafic.

Dacă nu aveți timpul sau instrumentele pentru o analiză proprie, o soluție practică este un audit SEO care include și verificarea jurnalelor de server, alături de celelalte aspecte tehnice ale site-ului. Pentru site-urile care au nevoie de verificări constante, un contract de mentenanță website include și urmărirea periodică a acestor înregistrări.

Subiecte apropiate, tratate pe larg în alte articole din blog, sunt bugetul de crawlare, fișierul robots.txt, sitemap-ul XML și paginile 404 și linkurile rupte. Pentru partea de server, articolele despre monitorizarea performanței unui server Linux și despre comenzile Linux esențiale completează informațiile din acest ghid, iar dacă pagina dumneavoastră încă nu apare deloc în Google, articolul despre motivele pentru care o pagină nu apare în Google este primul pas de verificat.