Analiza serverskih log (dnevničkih) datoteka za praćenje botova pretraživača najpouzdaniji je način da vidite koje URL-ove, koliko često, s kojim statusnim kodovima i uz kakvu potrošnju resursa posjećuju Googlebot, Bingbot i drugi crawleri na vašoj web stranici. Dok SEO alati nude procjene, serverski logovi prikazuju stvarne zahtjeve koje je vaš server zabilježio; na taj način možete precizno izmjeriti rasipanje crawl budžeta, 404/500 greške, lance preusmjeravanja, nepotrebno indeksiranje parametarskih URL-ova i da li botovi dovoljno posjećuju vaše ključne stranice.
Tehnički SEO radovi često se fokusiraju na vidljiva područja poput on-page optimizacije, brzine, strukturiranih podataka i backlinkova. Međutim, da biste razumjeli kako pretraživač vidi vašu stranicu, potrebno je analizirati ponašanje botova. Najsiroviji i najpouzdaniji izvor ponašanja botova su pristupni logovi (access log). Log analiza igra ključnu ulogu u rješavanju problema s indeksiranjem, posebno za velike e-commerce stranice, news portale, SaaS projekte, višejezične web stranice i blogove koji često objavljuju sadržaj.
U ovom vodiču ćemo za Hostragons blog, korak po korak, uz praktičan i primjenjiv pristup, obraditi gdje se nalaze serverske log datoteke, koja polja treba čitati, kako razlikovati prave botove pretraživača od lažnih, koje metrike pratiti sa SEO aspekta i kako rezultate analize pretvoriti u konkretne akcije. Ako vam je za redovnu log analizu na vlastitoj stranici potrebna pouzdana hosting infrastruktura, možete razmotriti Hostragons web hosting i za projekte s intenzivnim prometom Hostragons VPS Server opcije.
Šta je serverska log datoteka i zašto je važna za SEO?
Serverska log datoteka je dnevnička datoteka u koju se bilježi svaki zahtjev upućen vašem web serveru. Kada korisnik otvori vašu početnu stranicu, kada Googlebot indeksira stranicu kategorije ili kada sigurnosni skener pošalje zahtjev vašoj stranici, ovaj događaj se zapisuje u log datoteku. Obično sadrži informacije poput datuma, vremena, IP adrese, traženog URL-a, HTTP metode, statusnog koda, veličine odgovora, user-agenta i ponekad vremena odgovora.
Sa SEO tačke gledišta, log datoteke su važne jer direktno pokazuju kako pretraživači indeksiraju vašu stranicu. Google Search Console vam nudi statistiku indeksiranja, ali ne daje uvijek detaljno svaki zahtjev na nivou URL-a, sve botove i trenutne greške na vašem serveru. Uz log analizu možete, na primjer, vidjeti da je u posljednjih 7 dana Googlebot uputio 12.400 zahtjeva, da je 18 posto tih zahtjeva otišlo na 301 preusmjeravanje, 6 posto na 404 grešku, 2 posto na 500 grešku i da su vaše važne stranice proizvoda indeksirane samo 9 posto.
Ovi podaci su posebno vrijedni za upravljanje crawl budžetom. Crawl budžet se može posmatrati kao broj URL-ova koje botovi pretraživača mogu indeksirati na vašoj stranici u određenom vremenskom periodu. Ako postoji previše nepotrebnih filtera, paginacije, rezultata pretrage, parametarskih URL-ova ili pogrešnih preusmjeravanja, botovi mogu posvetiti manje vremena vašim vrijednim stranicama. Log datoteke otkrivaju ovo rasipanje s dokazima.
Na koja pitanja tražimo odgovor prilikom praćenja botova pretraživača?
Uspješna log analiza nije samo otvaranje datoteke i čitanje redova. Prvo treba postaviti prava pitanja. Timovi za tehnički SEO obično traže odgovore na sljedeća pitanja:
- Koje grupe URL-ova Googlebot najviše indeksira?
- Da li se važne stranice dovoljno posjećuju?
- Koliki dio zahtjeva za indeksiranje dobija statusne kodove 200, 301, 302, 404, 410 ili 5xx?
- Da li botovi i dalje šalju zahtjeve na područja blokirana robots.txt datotekom?
- Da li parametarski, duplirani ili URL-ovi niske vrijednosti troše crawl budžet?
- Postoji li razlika između ponašanja mobilnog Googlebota i desktop Googlebota?
- Da li vrijeme odgovora servera usporava indeksiranje botova?
- Da li lažni botovi troše resurse predstavljajući se kao Googlebot?
Svako od ovih pitanja može se direktno pretvoriti u akciju. Na primjer, ako vidite da Googlebot indeksira veliki broj starih kampanjskih URL-ova kao 404, možete te URL-ove preusmjeriti 301 na relevantnu kategoriju ili, ako su trajno uklonjeni, koristiti statusni kod 410. Ako 30 posto botova odlazi na rezultate interne pretrage, možda ćete morati redizajnirati robots.txt, canonical, noindex oznake ili upravljanje URL parametrima.
Gdje se nalaze log datoteke?
Lokacija log datoteka varira ovisno o vrsti hostinga koju koristite, kontrolnom panelu i web serveru. Na stranicama koje koriste dijeljeni hosting, pristupnim zapisima se obično pristupa putem cPanel-a, Plesk-a ili odjeljaka za statistiku i sirove pristupne logove (raw access logs) na hosting panelu. Na projektima koji koriste VPS ili dedicated server, logovima se pristupa putem SSH-a.
Uobičajene lokacije Apache i Nginx logova
Na Linux serverima, uobičajena putanja za Apache pristupni log je /var/log/apache2/access.log ili /var/log/httpd/access_log. Na serverima koji koriste Nginx, datoteka /var/log/nginx/access.log je uobičajena. U konfiguracijama virtualnog hosta specifičnim za domenu, za svaku stranicu se može voditi zasebna log datoteka. Ovo povećava tačnost analize u strukturama s više stranica.
Primjer log linije može sadržavati sljedeće informacije: 66.249.66.1 - - [12/Mar/2026:10:15:22 +0300] GET /blog/tehnicki-seo HTTP/2.0 200 18432 Googlebot/2.1. Iz ove linije možete pročitati IP adresu, vrijeme zahtjeva, URL, statusni kod, veličinu odgovora i informaciju o user-agentu. Ako vaš log format uključuje i vrijeme odgovora, imate još snažniji set podataka za analizu performansi.
Preuzimanje logova sa hosting panela
Za korisnike s ograničenim tehničkim znanjem, preuzimanje logova sa hosting panela je najpraktičniji metod. Na panelu možete potražiti odjeljke poput access logs, raw logs, visitors ili web statistics. Na velikim stranicama, dnevne log datoteke mogu sadržavati stotine hiljada linija; stoga je efikasnije preuzeti datoteke u komprimiranom obliku i analizirati ih. Za redovan pristup, sigurno backupiranje i praćenje performansi, rješenja kojima se lako upravlja poput Hostragons cPanel hosting mogu vam ubrzati posao.
Važna polja u log liniji za SEO
Nije svaka log linija jednako vrijedna. Za SEO se prvenstveno treba fokusirati na neka polja. IP adresa se koristi za provjeru da li je bot stvaran. Datum i vrijeme vam omogućavaju mjerenje intenziteta indeksiranja po danu i satu. HTTP metoda bi obično trebala biti GET; neuobičajeni POST zahtjevi mogu se ispitati sa sigurnosnog aspekta. Traženi URL pokazuje koja se stranica indeksira. Statusni kod označava dostupnost stranice. User-agent vam pomaže da shvatite identitet bota koji upućuje zahtjev. Ako postoji polje za vrijeme odgovora (time taken), ono je vrlo vrijedno za iskustvo bota i opterećenje servera.
Na primjer, pretpostavimo da u logu za posljednjih 30 dana ima 50.000 Googlebot zahtjeva. Ako je od ovih zahtjeva 38.000 sa statusom 200, 7.500 sa 301, 2.000 sa 404, 1.200 sa 304, 800 sa 5xx i 500 sa 302, problem je jasan: stope preusmjeravanja i grešaka su ukupno preko 20 posto. Cilj tehničkog SEO-a je približiti 5xx greške nuli, smanjiti 404 greške na razuman nivo i reducirati nepotrebna preusmjeravanja.
Kako razlikovati pravi Googlebot od lažnog bota?
User-agent sam po sebi nije pouzdan. Zlonamjerni crawleri se mogu predstaviti kao Googlebot. Stoga je za verifikaciju pravih botova pretraživača potrebno izvršiti obrnutu DNS (reverse DNS) i direktnu DNS (forward DNS) provjeru. Metoda koju preporučuje Google je da se IP adresa prevede u ime hosta putem obrnutog DNS-a, zatim provjeri da li dobijeno ime hosta završava na googlebot.com ili google.com i da se to ime hosta ponovo razriješi na istu IP adresu.
Primjer procesa je sljedeći: Uzmite IP adresu koja dolazi s Googlebot user-agent informacijom u logu. U terminalu izvršite upit obrnutog DNS-a komandom host 66.249.66.1 ili nslookup 66.249.66.1. Ako dobijeni naziv domene pripada pouzdanoj Google domeni poput crawl-66-249-66-1.googlebot.com, pređite na drugi korak. Razriješite ovaj naziv domene ponovo na IP adresu. Ako se rezultat podudara s prvobitnom IP adresom, velika je vjerovatnoća da je bot stvaran. Ako se ne podudara ili se pojavi nepovezani naziv domene, treba ga smatrati lažnim botom.
Ova verifikacija je posebno važna za izdvajanje botova koji intenzivno troše resurse. Lažni Googlebotovi mogu iscrpiti serverske resurse, skenirati sigurnosne propuste ili imati za cilj kopiranje sadržaja. Kada otkrijete ovakav promet, mogu se aktivirati WAF, ograničenje brzine (rate limit), blokiranje IP adrese ili pravila firewall-a. Za HTTPS i sigurnu konfiguraciju veze možete pogledati stranicu Hostragons SSL Certifikati.
Alati koji se mogu koristiti za log analizu
Ne postoji jedan ispravan alat za log analizu. Mogu se preferirati različite metode ovisno o veličini stranice, iskustvu tehničkog tima i budžetu. Za male stranice, Excel, Google Sheets ili jednostavni filteri komandne linije mogu biti dovoljni. Za stranice srednje veličine, Screaming Frog Log File Analyser, GoAccess ili Python skripte su efikasniji. U korporativnim strukturama mogu se koristiti Elasticsearch, Logstash, Kibana, BigQuery ili SIEM rješenja.
| Metoda | Najpogodnija upotreba | Prednost | Ograničenje |
|---|---|---|---|
| Excel ili Sheets | Mali blogovi, nizak promet | Lako se uči, omogućava brzo filtriranje | Usporava se kod velikih datoteka i nailazi na ograničenje redova |
| Komandna linija | Tehnički korisnici, VPS serveri | Brza, besplatna, pogodna za automatizaciju | Zahtijeva poznavanje Linux komandi |
| SEO alati za log analizu | Srednje i velike stranice | Gotovi izvještaji o botovima, URL-ovima i statusnim kodovima | Može imati troškove licence |
| ELK ili BigQuery | Korporativne stranice i stranice s visokim prometom | U realnom vremenu, skalabilno i detaljno | Instalacija i održavanje zahtijevaju stručnost |
Za praktičan početak dovoljno je preuzeti logove za posljednjih 7 ili 14 dana i filtrirati samo Googlebot, Bingbot, YandexBot i druge važne user-agente botova. Zatim možete kreirati pivot tabele prema poljima URL-a, statusnog koda i datuma. Cilj u prvoj analizi nije izgraditi savršeno skladište podataka, već brzo uočiti najveće SEO gubitke.
Korak po korak analiza serverskih log datoteka
1. Definišite cilj analize
Prvo razjasnite šta želite saznati. Da li se novi objavljeni sadržaji ne indeksiraju? Da li se stranice kategorija ne indeksiraju dovoljno? Da li serverske greške utiču na organsku vidljivost? Ako je vaš cilj jasan, signali koje ćete tražiti u log datoteci također će biti jasni. Na primjer, za problem s indeksiranjem gleda se koliko su puta važne URL-ove Googlebot indeksirao u posljednjih nekoliko dana; za problem s performansama ispituju se 5xx kodovi i vremena odgovora.
2. Odaberite pravi vremenski interval
Prekratki intervali mogu biti obmanjujući; predugi intervali nepotrebno povećavaju veličinu datoteke. Za male i srednje stranice, 14 do 30 dana je dobar početak. Za strukture koje se brzo ažuriraju, poput news portala, čak i periodi od 3 do 7 dana mogu biti smisleni. Na velikim e-commerce stranicama, sezona, kampanje i ažuriranja kategorija trebaju biti dodatno označeni.
3. Filtrirajte promet botova
U polju user-agent izdvojite botove kao što su Googlebot, Googlebot-Image, Googlebot-News, Bingbot, YandexBot, DuckDuckBot, Applebot. Međutim, ne zaboravite izvršiti verifikaciju pravih botova u kritičnim izvještajima. Zbog indeksiranja s prioritetom na mobilne uređaje (mobile-first indexing), Googlebot Smartphone zahtjevi trebaju se posebno pratiti. Ako se čini da je desktop bot vrlo aktivan, a mobilni bot pasivan, mogu postojati problemi s konfiguracijom ili pristupom.
4. Kreirajte grupe URL-ova
Pojedinačna analiza URL-ova je neefikasna na velikim stranicama. Razdvojite URL-ove u šablone: početna stranica, kategorija, proizvod, blog, tag, filter, pretraga, paginacija, slika, API, statična datoteka. Na taj način možete vidjeti kojim dijelovima stranice botovi daju prioritet. Na primjer, ako na e-commerce stranici 42 posto Googlebot zahtjeva odlazi na filtrirane URL-ove, a 18 posto na stranice proizvoda, možda postoji problem s prioritizacijom.
5. Procijenite statusne kodove
Statusni kodovi su jedan od glavnih indikatora u SEO log analizi. Kod 200 označava uspješan pristup, 301 trajno preusmjeravanje, 302 privremeno preusmjeravanje, 304 odgovor "nije izmijenjeno", 404 grešku "nije pronađeno", 410 trajno uklanjanje, 429 status "previše zahtjeva" i 5xx serverske greške. Cilj je da važne stranice vraćaju direktno 200 što je više moguće i da botovi ne gube vrijeme na greške ili nepotrebne lance preusmjeravanja.
6. Izmjerite vrijeme odgovora i opterećenje servera
Ako vaš log format uključuje vrijeme odgovora, ispitajte prosječno vrijeme i vrijeme u 95. percentilu za zahtjeve botova. Prosjek od 180 ms može izgledati dobro; međutim, ako je vrijednost 95. percentila 2.800 ms, neki tipovi URL-ova možda usporavaju botove. Posebno treba pažljivo ispitati filtrirane kategorije, internu pretragu, dinamičke izvještaje i stranice koje pokreću teške upite baze podataka. Ako imate problema s performansama, mogu se razmotriti opcije za jače resurse poput Hostragons Cloud Server.
Najkritičniji nalazi log analize sa SEO aspekta
Rasipanje crawl budžeta
Rasipanje crawl budžeta je kada botovi troše previše vremena na nevažne URL-ove. Parametarski URL-ovi, filteri za sortiranje, ID-jevi sesija, stranice za štampanje, beskonačne arhive kalendara i rezultati interne pretrage su najčešći izvori. Ako u log analizi vidite da ovi URL-ovi čine visok udio, zajedno procijenite opcije canonical, robots.txt, noindex, pojednostavljenje parametara i uređivanje internih linkova.
Nedovoljno indeksiranje važnih stranica
Ponekad problem nije u tome što botovi previše indeksiraju, već što indeksiraju pogrešna mjesta. Nove stranice proizvoda, landing stranice s visokim potencijalom konverzije ili ažurirani vodiči možda se ne posjećuju dovoljno. Razlog tome može biti slabo interno linkanje, neažurnost sitemapa, mala brzina stranice ili to što je URL preduboko u arhitekturi. U tom slučaju ažurirajte XML sitemap, dodajte interne linkove sa glavne kategorije i relevantnih sadržaja, otkrijte "siročad" stranice (orphan pages) i smanjite dubinu URL-a. Ako ste u fazi planiranja domene i strukture projekta, možete napraviti početak usklađen s brendom putem Provjera Domene.
Lanci preusmjeravanja
U logovima je uobičajeno vidjeti da se botovi sa /stari-url preusmjeravaju na /medju-url, a odatle na /novi-url. Ovi lanci smanjuju korisničko iskustvo i efikasnost botova. Idealna struktura je da stari URL direktno vrati 301 na konačni URL. U velikim projektima migracije stranica, stara pravila preusmjeravanja mogu se nagomilati i stvoriti lance. Mjesečna kontrola logova rano hvata ove lance.
5xx greške i oscilirajuća dostupnost
Ako botovi pretraživača često vide greške 500, 502, 503 ili 504 na vašoj stranici, mogu smanjiti učestalost indeksiranja. Ovo može posebno uticati na organski učinak tokom kampanjskih perioda. U logovima ispitajte vrijeme, tip URL-a i vrstu bota za 5xx greške. Na primjer, ako se 503 povećava svake noći u 02:00 tokom backupa, treba urediti prozor održavanja, planiranje resursa ili strategiju keširanja.
Zajedničko čitanje robots.txt, sitemapa i log podataka
Log analiza je moćna sama po sebi, ali postaje mnogo smislenija kada se čita zajedno s robots.txt, XML sitemapom i podacima iz Google Search Console. Uporedite da li su URL-ovi koji se nalaze u sitemapu indeksirani od strane bota. Pronađite URL-ove koji nisu u sitemapu, ali se često indeksiraju. Provjerite da li zahtjevi botova dolaze na područja koja ste blokirali robots.txt datotekom. Ako se blokirani URL-ovi i dalje pojavljuju u rezultatima pretrage, sam robots.txt možda nije dovoljan; možda će biti potrebna strategija noindex ili uklanjanja.
Dobra praksa je svakog mjeseca kreirati tri liste: Važni URL-ovi koji su u sitemapu, ali se ne indeksiraju, URL-ovi niske vrijednosti koji nisu u sitemapu, ali se često indeksiraju i zahtjevi botova koji vraćaju kod greške. Ove tri liste čine osnovu vaše mape puta za tehnički SEO.
Koje metrike treba uključiti u izvještaj log analize?
Za upravljiv izvještaj, umjesto da se utopite u previše metrika, treba odabrati indikatore koji pokreću akciju. Sljedeće metrike su dovoljan početni set za većinu stranica:
- Ukupni zahtjevi botova i distribucija po botovima
- Odnos Googlebot Smartphone i Desktop
- Distribucija statusnih kodova: 200, 3xx, 4xx, 5xx
- Stopa indeksiranja prema tipu URL-a
- Prvih 100 najčešće indeksiranih URL-ova
- Važni URL-ovi koji se nikada ili rijetko indeksiraju
- Prosječno vrijeme odgovora i vrijeme u 95. percentilu
- URL-ovi koji najčešće vraćaju 404 i 5xx
- Stopa zahtjeva s parametarskim URL-ovima
- Lista lažnih botova ili sumnjivih user-agenta
Pripremite izvještaj uporedno na sedmičnoj ili mjesečnoj bazi. Na primjer, ako je stopa 5xx u januaru bila 1,8 posto, a u februaru je pala na 0,2 posto, dokazali ste učinak izvršenog poboljšanja infrastrukture. Isto tako, ako su se zahtjevi Googlebota prema sadržaju bloga povećali za 35 posto nakon novog internog linkanja, vaša odluka o arhitekturi sadržaja je potkrijepljena podacima.
Primjenjiv primjer: Scenarij 30-dnevne log analize
Zamislimo da je analiziran pristupni log (access log) za posljednjih 30 dana na jednom tehnološkom blogu. Unutar ukupno 320.000 zahtjeva otkriveno je 48.000 zahtjeva botova pretraživača. Googlebot zahtjeva bilo je 39.500, Bingbot zahtjeva 5.200, ostalih botova 3.300. U distribuciji statusnih kodova, stopa odgovora 200 bila je 78 posto, 301 11 posto, 404 7 posto, 5xx 1,5 posto i ostali odgovori 2,5 posto.
Kada je izvršeno grupisanje URL-ova, vidjelo se da 28 posto Googlebot zahtjeva odlazi na stranice s tagovima, 22 posto na stare arhive, 19 posto na blog postove, 8 posto na stranice kategorija, a ostatak na slike i statične datoteke. Međutim, cilj organskog prometa stranice bili su aktuelni vodiči i klasteri kategorija. Kao akcija, stranice s tagovima niske vrijednosti su označene noindex oznakom, smanjeni su interni linkovi prema arhivskim stranicama, aktuelni vodiči su linkani sa početne stranice i relevantnih kategorija, a sitemap je pojednostavljen samo na URL-ove koje treba indeksirati.
U sljedećih 30 dana, udio zahtjeva koje je Googlebot posvetio blog postovima porastao je sa 19 posto na 34 posto, a udio posvećen stranicama kategorija sa 8 posto na 14 posto. Stopa 404 je pala sa 7 posto na 2,1 posto preusmjeravanjem starih URL-ova. Ovaj primjer pokazuje da log analiza nije samo tehnički izvještaj, već mehanizam odlučivanja koji direktno podržava strategiju organskog rasta.
Česte greške
Najčešća greška u log analizi je slijepo povjerenje u informaciju o user-agentu. Ako se lažni botovi ne uzmu u obzir, izvještaji postaju obmanjujući. Druga greška je vrednovanje svih URL-ova jednako. Rijetko indeksiranje stranice s politikom privatnosti nema isti učinak kao rijetko indeksiranje glavne stranice kategorije. Treća greška je izvlačenje velikih zaključaka iz jednodnevnih podataka. Ponašanje botova može varirati po danima; stoga treba birati smislene vremenske periode.
Četvrta greška je mišljenje da će robots.txt riješiti svaki problem. Robots.txt može ograničiti indeksiranje, ali nije uvijek dovoljan za upravljanje indeksom. Peta greška je nepretakanje nalaza u akciju. Ako se kao rezultat log analize ne donose odluke o preusmjeravanju, internom linkanju, sitemapu, canonical oznakama, performansama i sigurnosti, izvještaj ostaje samo pregled datoteke.
Na šta treba obratiti pažnju u pogledu sigurnosti i privatnosti
Budući da log datoteke sadrže IP adresu i informacije o zahtjevima, treba ih pažljivo čuvati. Ne smiju se dijeliti s neovlaštenim osobama, datoteke preuzete za analizu ne treba nepotrebno dugo držati na ličnim računarima i, ako je moguće, treba primijeniti maskiranje. U korporativnim projektima, period čuvanja logova mora biti usklađen sa zakonima o zaštiti podataka i politikama kompanije. Osim toga, ako se unutar log datoteka vide tokeni, parametri sesije ili osjetljive informacije u query stringu, treba revidirati politiku zapisivanja na strani aplikacije.
Sa sigurnosne strane, logovi su vrijedni ne samo za SEO već i za otkrivanje napada. Iznenadni porast 404 pokušaja, skeniranje admin panela, neuobičajeni POST zahtjevi ili intenzivan promet s određenih IP blokova mogu biti sigurnosni alarm. Stoga je korisno da SEO i timovi za sistemsku administraciju zajedno procjenjuju log podatke.
Zaključak: Log analiza je sloj stvarnih podataka SEO-a
Analiza serverskih log datoteka za praćenje botova pretraživača smanjuje odluke zasnovane na pretpostavkama u tehničkom SEO-u i čini stvarno ponašanje pri indeksiranju vidljivim. Zahvaljujući logovima možete izmjeriti koji URL-ovi dobijaju na vrijednosti, koje greške zamaraju botove, kada se server muči i gdje se crawl budžet bespotrebno troši. Redovna analiza je moćna navika za očuvanje kvaliteta indeksiranja i organske vidljivosti, posebno na rastućim stranicama.
Za brzi početak, preuzmite svoju access log datoteku za posljednjih 14 dana, filtrirajte stvarne Googlebot zahtjeve, izdvojite statusne kodove i grupe URL-ova. Ako vaši nalazi ukazuju na potrebu za performansama, sigurnošću ili resursima, revidiranje vaše infrastrukture može biti dobar korak. Možete ojačati tehničku osnovu vaše stranice uz Hostragonsova rješenja za hosting, VPS, cloud servere, domene i SSL te primijeniti poboljšanja proizašla iz log analize u zdravijem okruženju.
Često postavljana pitanja
Zašto se serverska log datoteka za SEO razlikuje od Google Search Console?
Google Search Console nudi sažete podatke fokusirane na Google; serverska log datoteka, s druge strane, prikazuje stvarne zahtjeve koji dolaze na vaš server na nivou URL-a, vremena, IP adrese, user-agenta i statusnog koda. Stoga je log analiza siroviji, detaljniji i provjerljiviji izvor podataka.
Koliko dana podataka je dovoljno za log analizu?
Za većinu web stranica, 14 do 30 dana log podataka je dobar početak. Za news portale ili projekte koji se vrlo često ažuriraju, analiza od 3 do 7 dana također može biti smislena. Za stranice sa sezonskim prometom, periodi kampanja trebaju se posebno ispitati.
Kako da shvatim da li je Googlebot stvaran?
Nemojte se oslanjati samo na informaciju o user-agentu. Izvršite provjeru obrnutog DNS-a za IP adresu, potvrdite da dobijeni naziv domene završava na googlebot.com ili google.com i ponovo razriješite taj naziv domene na istu IP adresu. Ako postoji podudaranje, bot je najvjerovatnije stvaran.
Da li su 404 greške uvijek SEO problem?
Nije svaka 404 greška problem; može biti prirodna za uklonjene ili nikad postojeće stranice. Međutim, 404 URL-ovi koji dolaze iz važnih internih linkova, primaju backlinkove ili ih Googlebot često indeksira mogu bespotrebno trošiti crawl budžet. Za ove URL-ove treba razmotriti odgovarajuću strategiju preusmjeravanja ili 410.
Koliko često treba raditi log analizu?
Za male stranice, mjesečna analiza može biti dovoljna. Za velike e-commerce, news i projekte s visokim prometom preporučuje se sedmično, čak i dnevno praćenje u kritičnim periodima. Nakon migracije stranice, promjene infrastrukture ili velikih ažuriranja sadržaja, obavezno treba izvršiti kontrolu logova.