Verkkokaupan ylläpitäjä huomaa myynnin notkahtaneen, mutta Google Analytics ei kerro miksi – silloin katse kannattaa kääntää palvelimen omiin lokitiedostoihin. Sivuston lokitiedostot tallentavat jokaisen palvelimelle tulevan pyynnön, ja niistä löytyy tietoa, jota mikään analytiikkatyökalu ei näytä: miten Googlebot todella liikkuu sivustolla, mitkä sivut kaatuvat virheisiin ja kuka yrittää murtautua sisään kello kolme yöllä.
Moni suomalainen pienyrittäjä on kuullut lokitiedostoista vain silloin, kun hosting-palveluntarjoaja on pyytänyt niitä vianselvitystä varten. Todellisuudessa niistä saa irti paljon enemmän – kunhan tietää mistä katsoa.
Mitä lokitiedosto oikeastaan sisältää
Palvelimen lokitiedosto on tekstitiedosto, johon kirjautuu rivi jokaisesta HTTP-pyynnöstä. Tyypillinen Apache- tai Nginx-lokirivi näyttää tältä: IP-osoite, aikaleima, pyydetty osoite, HTTP-statuskoodi, tiedoston koko ja user agent -tunniste.
Yhdellä rivillä voi lukea esimerkiksi, että 66.249.66.1 – tunnettu Googlebotin IP-alue – haki sivua /tuotteet/talvitakit/ 14.8.2026 kello 03:14 ja sai vastauksena statuskoodin 200. Toisella rivillä sama botti törmää statuskoodiin 404, koska tuote on poistettu myynnistä ilman uudelleenohjausta.
Tämä ero on kriittinen. Google Analytics ja GA4 näyttävät vain ihmiskäyttäjien toimintaa JavaScript-pohjaisen seurannan kautta, kun taas lokitiedosto tallentaa myös botit, API-kutsut ja kaiken liikenteen ennen kuin sivu edes latautuu selaimeen.
Hakukonebottien käyttäytyminen – crawl budget näkyväksi
Suurin syy, miksi SEO-asiantuntijat kaivavat lokitiedostoja esiin, liittyy crawl budgetiin eli siihen, kuinka paljon aikaa ja resursseja Google käyttää sivuston indeksointiin. 5000 sivun verkkokaupassa Googlebot ei välttämättä käy läpi kaikkia sivuja joka päivä – ja lokitiedostosta näkee tarkalleen, mihin se aikansa käyttää.
Tyypillinen löydös: botti käy 40 kertaa päivässä suodatinparametreilla varustetuissa URL-osoitteissa (esimerkiksi ?vari=musta&koko=m), jotka eivät tuota mitään SEO-arvoa, mutta jättää tuotesivut vähemmälle huomiolle. Tämä on suoraan korjattavissa robots.txt-tiedostolla tai kanonisilla tageilla, ja aihe kannattaa lukea tarkemmin artikkelista robots.txt:stä ja sen vaikutuksesta hakukoneisiin.
Käytännön esimerkki: kun tamperelainen rakennustarvikeliike analysoi lokinsa Screaming Frog Log File Analyserilla (ilmainen versio käsittelee 1000 riviä), selvisi että Googlebot vieraili sivustolla keskimäärin 1200 kertaa vuorokaudessa, mutta 30 % käynneistä kohdistui vanhoihin kampanjasivuihin vuodelta 2023. Kampanjasivujen poistaminen indeksistä ja crawl-budjetin ohjaaminen tuotesivuille nosti uusien tuotteiden indeksoitumisnopeuden kahdesta viikosta kolmeen päivään.
Virhekoodit paljastavat rikkinäisen sivuston
Lokitiedosto listaa jokaisen 404-, 500- ja 503-virheen, ja tässä piilee usein enemmän ongelmia kuin kukaan huomaa manuaalisesti selaamalla. Verkkokaupoissa yleisin löydös on poistettujen tuotteiden jättämät 404-sivut, jotka keräävät edelleen ulkoisia linkkejä ja hakukoneliikennettä.
Oikea ratkaisu ei ole aina uudelleenohjaus etusivulle – se hukkaa linkkiarvon ja turhauttaa käyttäjän. Tilanteesta riippuen kannattaa ohjata samankaltaiseen tuotteeseen tai kategoriasivulle, ja 301- ja 302-koodien ero on syytä ymmärtää ennen toteutusta, ks. 301- ja 302-uudelleenohjausten ero ja oikea käyttö.
500-sarjan virheet ovat vakavampia: ne kertovat palvelimen kaatuneen kesken pyynnön. Jos lokista löytyy 500-virheitä tiettyyn kellonaikaan toistuvasti, esimerkiksi joka yö klo 02:00–02:15, syy on usein ajastettu varmuuskopiointi tai päivitysskripti, joka kuormittaa palvelinta liikaa samaan aikaan kuin kävijöitä.
Tietoturva – ensimmäinen hälytysjärjestelmä
Lokitiedosto on usein ensimmäinen paikka, josta murtoyritys näkyy ennen kuin mikään muu järjestelmä hälyttää. Toistuvat kirjautumisyritykset osoitteeseen /wp-admin/ samasta IP-lohkosta, epätavalliset POST-pyynnöt lomakekenttiin tai äkillinen piikki pyynnöissä yhdestä maasta ovat kaikki merkkejä, jotka näkyvät ensin lokissa.
WordPress-sivustolla yleinen tilanne on brute force -hyökkäys kirjautumissivulle: sama IP-osoite yrittää satoja kirjautumisia tunnissa. Tämä näkyy lokissa selvästi toistuvina POST /wp-login.php -riveinä ennen kuin mikään suojaustyökalu ehtii reagoida. Aiheesta laajemmin artikkelissa tietoturva kotisivuilla – miten estät hakkeroinnit.
Työkalut lokien lukemiseen
Raakaa lokitiedostoa ei kannata avata tekstieditorissa, jos sivustolla on enemmän kuin muutama sata kävijää päivässä – tiedosto voi olla helposti satoja megatavuja kuukaudessa. Käytännössä analyysiin sopivat:
GoAccess – ilmainen, komentorivipohjainen, toimii reaaliaikaisesti ja tuottaa selkeän HTML-raportin. Screaming Frog Log File Analyser – ilmainen 1000 riviin asti, maksullinen versio 179 £/vuosi, erikoistunut juuri SEO-näkökulmaan ja Googlebot-käyttäytymiseen. AWStats – vanha mutta yhä toimiva, usein valmiiksi asennettuna webhotellin hallintapaneeliin, esimerkiksi cPanelissa.
Moni webhotelli, kuten Louhi tai Zoner, tarjoaa lokitiedostot valmiiksi hallintapaneelin kautta ilman erillistä palvelinyhteyttä. Jos sivusto pyörii Cloudflaren takana, kannattaa muistaa että näkyvä IP-osoite lokissa voi olla Cloudflaren oma – todellinen kävijän IP löytyy vasta CF-Connecting-IP-otsikosta.
Yleisimmät virheet lokianalyysissä
Ensimmäinen virhe on sekoittaa botit ihmisiin. Jos lokista lasketaan ”kävijämäärä” suoraan rivien perusteella, luku on usein 3–5-kertainen todelliseen ihmisliikenteeseen verrattuna, koska mukana on hakukonebotteja, seurantapalveluita ja skräppereitä.
Toinen virhe on jättää lokit tarkastelematta kokonaan siihen asti, kun jotain menee pieleen. Lokitiedostot kannattaa käydä läpi säännöllisesti, esimerkiksi kerran kuukaudessa, eikä vasta silloin kun myynti on jo pudonnut tai sivusto hidastunut. Kolmas yleinen virhe on lokien säilytysajan unohtaminen – moni webhotelli poistaa lokit automaattisesti 7–30 päivän jälkeen, jolloin pidemmän aikavälin trendit katoavat, jos niitä ei ole arkistoitu erikseen.
Yleinen väärinkäsitys: ”Google Analytics riittää”
Yleinen myytti on, että jos sivustolla on GA4 asennettuna, lokitiedostoja ei tarvitse enää katsoa. Tämä ei pidä paikkaansa. GA4 näkee vain sen liikenteen, joka lataa JavaScriptin ja suostuu evästeisiin – botit, API-kutsut ja moni tietoturvatapahtuma jäävät kokonaan näkymättömiin.
Palvelinpuolen data ja selainpohjainen analytiikka vastaavat eri kysymyksiin: toinen kertoo mitä käyttäjät tekevät, toinen mitä palvelimelle todella tapahtuu. Tästä syystä myös server-side-seuranta on yleistynyt, ks. evästeetön seuranta ja server-side analytics.
Usein kysytyt kysymykset
Kuinka usein lokitiedostoja pitäisi tarkastella?
Pienelle yritys- tai esittelysivustolle riittää kerran kuukaudessa tehtävä tarkistus. Verkkokaupoille ja sivustoille, joilla on aktiivista SEO-työtä tai aiempia tietoturvahuolia, kannattaa asettaa viikoittainen tarkastus tai automaattinen hälytys epätavallisista piikeistä.
Tarvitaanko lokianalyysiin ohjelmointitaitoa?
Ei välttämättä. Työkalut kuten GoAccess ja Screaming Frog Log File Analyser tuottavat valmiit graafiset raportit ilman komentorivin syvällistä tuntemusta. Peruskäyttöön riittää, että ymmärtää HTTP-statuskoodit ja osaa tunnistaa hakukonebottien user agentit.
Voiko lokitiedostoista nähdä yksittäisen käyttäjän henkilötiedot?
IP-osoite lasketaan GDPR:n alaisuudessa henkilötiedoksi, joten lokitiedostojen säilytykselle ja käsittelylle pätevät samat periaatteet kuin muullekin kävijädatalle. Lokeja ei kannata säilyttää loputtomiin ilman perusteltua syytä, ja säilytysajasta kannattaa mainita tietosuojaselosteessa.
Lokitiedostot eivät korvaa Google Analyticsia tai Search Consolea, mutta ne täydentävät kuvaa juuri siinä kohtaa, missä muut työkalut ovat sokeita. Kannattaa varata kalenteriin toistuva 30 minuutin tarkistushetki – se riittää usein paljastamaan ongelman viikkoja ennen kuin se näkyy myynnissä tai hakusijoituksissa.