Log files analysis: cum citești crawl log-urile pentru a înțelege ce face Googlebot pe site-ul tău

Dacă ai ajuns aici, probabil te-ai săturat de rapoartele din Search Console care îți arată „Discovered – currently not indexed” fără să-ți spună de ce. Sau ai un site mare și suspectezi că Googlebot pierde timpul prin colțuri inutile, în timp ce paginile importante stau neaccesate săptămâni întregi.

Analiza log-urilor e singura metodă prin care vezi exact ce face Googlebot pe site-ul tău. Nu ce zice Google că face. Nu ce simulează crawlerele third-party. Ce face efectiv, la nivel de request server.

Pe scurt: ce găsești în log files

• Ce pagini accesează Googlebot și cât de des
• Ce coduri HTTP returnezi (200, 301, 404, 500) și în ce proporție
• Cât crawl budget pierzi pe URL-uri inutile (filtre, parametri, paginări vechi)
• Dacă Googlebot ajunge la paginile noi sau le ratează
• Dacă site-ul tău e crawl-uit de boți falși care se dau drept Google

Asta nu vezi în Search Console. Vezi un raport agregat, frumos. Logurile îți dau realitatea brută.

Ce sunt, concret, log-urile de server

Fiecare request către serverul tău – de la un user real, de la Googlebot, de la Bingbot sau de la un scraper random – lasă o linie în log. Arată cam așa:

66.249.66.1 – – [12/Nov/2024:08:23:11 +0000] „GET /produs/pantofi-sport HTTP/1.1” 200 14523 „-” „Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

Ai IP-ul, data, URL-ul cerut, codul HTTP returnat, dimensiunea răspunsului și user-agentul. Pentru analiza SEO, te interesează doar request-urile de la boții de motoare de căutare – mai ales Googlebot.

De unde iei log-urile

Depinde de hosting:

• Server propriu / VPS: găsești fișierele în /var/log/nginx/ sau /var/log/apache2/. Acces SSH și gata.
• Hosting partajat (cPanel, Plesk): ai secțiune dedicată „Raw Access Logs”. Le descarci compresate.
• Cloudflare: prin Logpush sau Log Retention (necesită plan Enterprise pentru complet, dar și pe planurile mici ai date utile).
• CDN-uri tip Fastly, Akamai: au propriile sisteme de export.

Realist: pe shared hosting ieftin, log-urile sunt rotite agresiv (uneori zilnic) și pierzi date. Dacă vrei analiză serioasă, configurează un sistem de arhivare. Minim 30 de zile, ideal 90.

Cum verifici că Googlebot e chiar Googlebot

Aici greșesc mulți. Un user-agent „Googlebot” poate fi orice scraper care minte. Trebuie să faci reverse DNS lookup pe IP.

Pași simpli:

1. Iei IP-ul din log
2. Faci reverse DNS – trebuie să returneze un hostname care se termină în googlebot.com sau google.com
3. Faci forward DNS pe hostnameul respectiv – trebuie să returneze același IP

Dacă nu se verifică, e bot fals. În practică, 5-15% din traficul „Googlebot” pe un site mediu e fake. Tool-uri ca Screaming Frog Log File Analyser, Botify sau Oncrawl fac asta automat. Pentru analize ad-hoc, un script Python de 20 de linii rezolvă problema.

Ce te interesează când deschizi log-urile

1. Distribuția crawl-ului pe tipuri de pagini

Grupează URL-urile pe șabloane: /produs/*, /categorie/*, /blog/*, /tag/*, etc. Apoi vezi câte requesturi primește fiecare grup. Dacă Googlebot face 60% din requesturi pe paginile de tag-uri și 5% pe produse, ai o problemă serioasă de prioritizare.

2. Frecvența de crawl pe paginile importante

Homepage-ul ar trebui crawl-uit zilnic, dacă nu de mai multe ori pe zi. Categoriile principale – la fel. Produse / articole noi – în 1-3 zile de la publicare. Dacă o pagină importantă nu e accesată de 30+ zile, fie ai probleme de internal linking, fie autoritatea site-ului e prea mică.

3. Codurile HTTP

Aici găsești surprize neplăcute:

• 404 multe pe URL-uri vechi: Googlebot încă încearcă să acceseze pagini șterse de luni de zile. Înseamnă că ai backlinks vechi spre ele – oportunitate pentru redirect 301.
• 301 în lanț (chains): dacă Googlebot e plimbat prin 2-3 redirecturi, pierzi crawl budget și PageRank.
• 500/503: dacă apar des, serverul cedează exact când Googlebot vine. Verifică log-urile la ore de trafic mare.
• 200 pe URL-uri care n-ar trebui indexate: filtre de produs, rezultate de search intern, parametri UTM ajunși în sitemap.

4. Crawl budget pierdut

Pentru site-uri sub 10.000 de URL-uri, crawl budget-ul rar e o problemă. Pentru e-commerce cu 100.000+ de produse, devine critic. Verifică ce procent din requesturile Googlebot merg spre URL-uri cu valoare zero: filtre combinate (?color=red&size=42&sort=price), paginări adânci (page 87 din blog), URL-uri canonicalizate dar tot crawl-uite.

Pe un site mare prost configurat, am văzut 70-80% din crawl pierdut pe astfel de URL-uri. După cleanup cu robots.txt și canonical corect, paginile importante au început să fie crawl-uite de 5-10 ori mai des.

Tool-uri pentru analiză

Nu ai nevoie de software scump pentru început:

• Screaming Frog Log File Analyser: 99 GBP/an, perfect pentru site-uri mici și medii. Interfață familiară dacă folosești deja Screaming Frog.
• Excel / Google Sheets: pentru log-uri sub 1 milion de linii, parsezi cu formule sau Power Query. Lent, dar gratuit.
• Python + pandas: dacă ai 10+ milioane de linii, e singura opțiune sănătoasă. O zi de învățat, ani de utilizat.
• Oncrawl, Botify, JetOctopus: enterprise, 200-2.000 EUR/lună. Merită doar pentru site-uri foarte mari sau agenții cu multe proiecte.
• ELK Stack (Elasticsearch + Logstash + Kibana): dacă ai resurse tehnice, e gratuit și extrem de puternic.

Greșeli frecvente în analiza log-urilor

• Te uiți doar la o săptămână de date: Googlebot are pattern-uri care se văd pe 30-60 de zile. O săptămână nu îți spune dacă o pagină e ignorată sau doar accesată mai rar.
• Nu separi Googlebot Desktop de Googlebot Smartphone: mobile-first indexing înseamnă că versiunea smartphone e cea care contează. Dacă Googlebot Desktop crawlează mult mai des decât Smartphone, ceva e setat greșit.
• Ignori boții fake: dacă 15% din requesturile „Googlebot” sunt scrapers, statisticile tale de crawl frequency sunt false.
• Te focusezi pe 404-uri în loc de URL-uri irelevante crawl-uite cu 200: 404 nu fură crawl budget semnificativ. URL-urile cu 200 care n-ar trebui să existe – da.
• Nu corelezi cu Search Console: log-urile îți spun ce crawlează Google. Search Console îți spune ce indexează. Diferența dintre cele două e zona în care găsești problemele.

Cum acționezi pe baza datelor

Logurile fără acțiune sunt doar date. Câteva intervenții tipice după o analiză:

• Blochezi în robots.txt tipurile de URL-uri inutile (search intern, filtre combinate, sortări)
• Adaugi noindex pe paginile cu valoare scăzută dar care trebuie să rămână accesibile userilor
• Cureți redirect chains – toate 301-urile vechi să meargă direct la destinația finală
• Recuperezi 404-uri cu trafic prin redirecturi 301 către pagini relevante
• Îmbunătățești internal linking spre paginile importante care primesc puține crawl-uri
• Optimizezi viteza serverului dacă vezi 503 sau timpi mari de răspuns la Googlebot

Pentru site-urile noi sau cu autoritate scăzută, problema reală nu e crawl budget-ul. E lipsa semnalelor de autoritate care să facă Google să vină mai des. Acolo intervine partea de off-page – advertoriale contextuale și menționări în publicații relevante care cresc crawl rate-ul pe tot site-ul, nu doar pe pagina linkuită.

Cât de des faci analiza

Pentru site-uri mici (sub 1.000 de pagini): la 3-6 luni sau când faci modificări structurale mari.

Pentru site-uri medii (1.000-50.000): lunar, cu rapoarte agregate săptămânale dacă ai resurse.

Pentru site-uri mari (50.000+): monitorizare continuă, alerte automate pe schimbări bruște de pattern.

Pe scurt, dacă ai sărit până aici: log-urile sunt singura sursă obiectivă despre ce face Googlebot pe site-ul tău. Search Console e util, dar îți dă o versiune filtrată. Pentru orice site care depinde de SEO și are peste câteva mii de pagini, analiza log-urilor nu mai e opțională – e diferența dintre a ghici și a ști.