SEOn A/B-testaus: avain menestyvään hakukoneoptimointiin tulevaisuudessa

Jos kirjaudut melkein minkä tahansa yrityksen web-analytiikkatilille ja katsot mistä lähteistä sivusto saa suurimman osan kävijöistään, löydät yleensä aina orgaanisen hakuliikenteen joko suurimpana tai toiseksi suurimpana lähteenä.

Ja mikäs sen hienompaa, sillä orgaanisessa liikenteessä ei tarvitse maksaa mitään klikeistä tai näyttökerroista – se on kaikki ansaittua liikennettä. Näin ollen SEO-liikenne on usein yritykselle erittäin kustannustehokasta.

Mutta SEO eroaa liikenteenlähteenä merkittävästi maksullisesta mediasta siinä, että sitä ei voi testata.

Tai sanotaanko, että SEO-liikennettä ei ole voinut testata, mutta nykyaikaiset ohjelmistot ja kehittyneemmät sisällönhallintajärjestelmät tekevät tämän erittäin tärkeän kanavan testaamisen mahdolliseksi.

Tämä artikkeli pohjautuu Search Marketing Finland -tapahtumassa vetämääni alustukseen SEOn A/B-testauksesta. Näet sen esityksen materiaalit alta upotettuna:

Miksi SEOa pitäisi A/B-testata?

Meillä SEO-tekijöillä on oikeasti todella suuri vastuu, sillä yleisesti ottaen ohjaamme joko asiakkaidemme tai organisaatiomme web-kehitystä ja luomme strategiaa, miten sivustot saa löytymään mahdollisimman laajasti relevanteilla termeillä orgaanisesta hausta.

Yksi tekemisen haasteista on se, että joudumme usein nojaamaan best practiceen ja omiin testeihimme emmekä koskaan voi sanoa varmaksi mikä tietyn toimenpiteen vaikutus on juuri kyseisen sivuston kontekstissa. Asiasta tekee entistäkin kiharamman Googlen vahvasti koneoppimiseen nojaavat algoritmit, jotka säätävät hakutuloksia ja eri signaalien painoarvoja lennosta lukemattomia kertoja vuodessa.

Toisin sanoen, annamme usein suosituksia, joiden vaikutuksista emme voi olla varmoja. Koska useimmiten SEO-toimenpiteiden implementointi vaatii joko teknistä kehittämistä tai sisällön jalostamista, suosituksilla ja niiden toteuttamisella on ihan oikeita kustannuksia.

Ja välillä best practiceen nojaaminen tai oma kokemus ohjaa väärään suuntaan. Tässä esimerkki Distilled-toimiston testistä, jossa best practicen implementointi heikensi orgaanista näkyvyyttä 8%:

Distilledin SEO A/B-testi tuotti -8% kävijöitä
Sivustolle implementoitiin best practicen mukaiset suositukset – ja performanssi laski.

Näistä epävarmuustekijöistä johtuen on todella tärkeää, että SEO-tekijät pystyvät perustelemaan suosituksensa ja ihanteellisessa tapauksessa testaamaan niitä ennen kuin kaikkia suosituksia lähdetään toteuttamaan. Sen lisäksi, että tämä vaatii nöyryyttä SEO-tekijältä, hyvien SEO-tulosten saamisessa auttaa kummasti jos organisaatiolla on testaushenkinen kulttuuri ja he ovat valmiita iteroimaan sivustoaan säännölllisesti.

SEOn A/B-testauksen ja perinteisen A/B-testauksen eroavaisuudet

Yleensä kun puhutaan A/B-testauksesta esimerkiksi online-mainonnan tai konversio-optimoinnin suhteen, testausta tehdään käyttäjätasolla. Tämä tarkoittaa sitä, että jos testiin osallistuu vaikka 10000 ihmistä, tyypillisesti 5000 ihmistä näkee yhden version sivusta ja toiset 5000 ihmistä näkevät erilaisen version samasta sivusta:

A/B-testaus käyttäjätasolla
Konversio-optimoinnin A/B-testauksen periaate: samasta sivusta näytetään eri versioita käyttäjille.

SEOn A/B-testaus toimii erilaisella periaatteella, sillä siinä sivujoukko jaetaan esimerkiksi kahteen osaan, jolloin puolet sivuista jätetään alkuperäiseen muotoon ja toiseen puoleen implementoidaan muutos. Esimerkiksi verkkokaupalla voi olla 400 tuotekategoriasivua, joista vain 200 muutetaan. Tällöin siis sivustolta löytyy 2 erilaisia tuotekategoriasivuja (alkuperäisiä ja muutettuja), jotka ovat kaikille käyttäjille täsmälleen samoja.

SEOn A/B-testauksen periaate
SEOn A/B-testauksen periaate: kaikki käyttäjät näkevät samat sivut, mutta kaikki samantyyppiset sivut eivät ole keskenään samankaltaisia.

Miksi sivuja ei sitten testata sivutasolla vaan niitä testataan sivutyyppitasolla? Se johtuu yksinkertaisesti siitä, että et voi jakaa yhtä sivua kahtia ja näyttää kaikille sivun näkeville, myös roboteille, täsmälleen samaa versiota sivusta. Kaksi ei vaan voi olla yksi. Siispä saman tyyppiset sivut, esimerkiksi tuotekategoriasivut pitää jakaa kahteen tai useampaan ryhmään, joista vain osaan toteutetaan muutokset.

Tällöin sivustolle jää vielä muuttamattomat sivut kontrolliryhmäksi, johon muutettujen sivujen performanssia voidaan verrata.

On tärkeää muistaa, että hakukoneroboteille pitää tarjota samat versiot sivuista kun käyttäjille, sillä muuten mennään cloakingin puolelle. Cloaking on vahvasti esimerkiksi Googlen Webmaster Guidelinesien vastaista ja voi helposti johtaa sivuston pudottamiseen hakutuloksista.

 

Mitä SEOn A/B-testaus vaatii teknisesti

Teknisesti SEOn A/B-testausta voi tehdä muutamalla eri tavalla:

  1. Jos julkaisujärjestelmä sen sallii, voi muutokset toteuttaa suoraan sinne bulkkina. Tottakai on mahdollista tehdä muutoksia myös sivutasolla manuaalisesti, mutta se on erittäin työlästä eikä siten tehokasta resurssien käyttöä.
  2. Toinen vaihtoehto on se, että testausta tehdään oman julkaisujärjestelmän ulkopuolella toisessa ohjelmistossa, jossa julkaisujärjestelmän luomaa sisältöä muutetaan ennen kun se tarjoillaan käyttäjille ja roboteille.

Alla oleva kuva kuvaa Distilledin Optimisation Delivery Networkin (ODN) toimintaperiaatteen:

SEOn A/B-testauksen tekninen stack
Esimerkki testaus-stackista

Käytännössä ODN:ää käyttäessä prosessi menee seuraavasti:

  1. Käyttäjä tai robotti haluaa nähdä sivuston sivun ja lähettää GET-pyynnön palvelimelle. Näin tapahtuu aina kun jotain sivua yritetään ladata.
  2. Palvelin vastaanottaa kutsun ja lähettää sivun lähdekoodin pyytäjälle päin julkaisujärjestelmän ilmoittamassa muodossa.
  3. Tässä vaiheessa ODN tulee ja tekee muutoksen sivun lähdekoodiin. Eli ODN on järjestyksessä CMS:n jälkeen, mutta ennen kävijän selainta.
  4. Jos sivusto käyttää CDN:ää (Content Delivery Network, esimerkiksi Cloudflare), ODN lähettää muokatun sivun lähdekoodin CDN:n.
  5. CDN lähettää sivun eteenpäin sivua pyytäneelle taholle.

Tällöin siis sivu jota kävijä pyysi voi olla sisällöllisesti erilainen kuin miltä se näytti julkaisujärjestelmässä.

Asia kuulostaa ja näyttää monimutkaiselta ja sitä se teknisesti onkin, mutta muutokset tapahtuvat kuitenkin erittäin nopeasti ja koko prosessi toteutetaan yleensä sekunnin kymmenyksissä.

Testikohteet ja vaatimukset

Mitä sivuja sitten voi testata? Oikeastaan lähes kaikkia sivuja, joita on useampia kappaleita. Käytännössä testata voi vaikka tuotekategoriasivuja, tuotesivuja, toimipistesivuja tai vaikka blogiartikkeleita.

A/B-testauksen kohteet

Selkeä sivu, jota ei voi A/B-testata on sivuston etusivu, koska.. no, yhtä sivua ei vaan saa mitenkään jaettua kahtia.

Käytännön tasolla voidaan testata vaikkapa seuraavia asioita:

  • Sivujen meta-tietoja
  • Sivujen otsikoita
  • Sivustoelementtien lisäämisiä tai poistamisia (esimerkiksi sivupalkin linkit edellisiin blogikirjoituksiin).
  • Rikastetun datan lisäämistä sivupohjiin
  • Tuotelistaussivulla näytettävien tuotteiden lukumäärää
  • jne.

Esimerkiksi julkkiskokki Nigella voisi kokeilla reseptin tietojen ilmoittamista robotille reseptimuodossa, jolloin he voisivat saada vaikka kalorimäärät ja tähtiarvostelut hakutuloksiin kuten Jamie Oliver:

Jamie Oliver esimerkki

Tällöin Nigellan tiimin pitäisi lisätä sivulle jotain tämän tyyppistä koodia (kuvakaappauksessa oikealla):

Nigellan reseptisivun koodi

Entä minkälaisia datatarpeita testaukseen liittyen on? Tässä vaiheessa asia menee haastavaksi monelle suomalaiselle yritykselle:

  • Noin 1000 kävijää testattavaan sivutyyppiin orgaanisen liikenteen kautta päivittäin.
  • Kyky jakaa sivut kahteen yhtä suureen ryhmään liikenteen määrän mukaan.
  • Mielellään historiadataa esimerkiksi klikkausprosenteista hakutuloksista mahdollisten epäselvyyksien varalle.

Käytännössä Suomessa on vain hyppysellinen yrityksiä, joilla on riittävästi liikennettä tehokkaaseen SEOn A/B-testaukseen. Nämä ovat käytännössä kaikki joko suuria verkkokauppoja, matkailusivustoja tai muita toimialojensa jättejä.

Datahaasteiden lisäksi SEOn testaamiseen liittyy pari muutakin pähkinää.

Ensinnäkin, mistä voidaan tietää mikä on riittävän suuri impakti, jotta testin tulokseen voidaan luottaa? Tämä on periaatteessa helppoa selvittää, mutta käytännössä esimerkiksi kausivaihtelut tai meneillään olevat TV-kampanjat voivat muuttaa merkittävästi hakukäyttäytymistä ja siten sotkea testijakson datan.

Toisekseen, suurin osa IT-osastoista ei varsinaisesti hypi onnesta siinä vaiheessa jos teknologia-stackiin halutaan lisätä työkalu, jolla voidaan muokata sivuston sisältöä ja tekniikkaa lennosta. Periaatteessahan työkalulla voisi vaikka rikkoa koko sivuston vahingossa tai tehdä muutoksia, jotka vaikuttavat sivuston tietoturvallisuuteen.

Yhteenveto

SEOn testaaminen on vielä tällä hetkellä erittäin haastavaa sen vaatiman datamäärän ja teknisen monimutkaisuuden vuoksi. Uskon kuitenkin vakaasti, että tulevaisuudessa haussa pärjäävät parhaiten ne yritykset, jotka lähtevät ennakkoluulottomasti tekemään erilaisia SEO-testejä, olipa kyseessä A/B-testaus tai jokin muu tapa systemaattisesti testata miten hakukoneet reagoivat sivustolla tehtäviin muutoksiin.

Parhaassa tapauksessa sivustolla voidaan järjestelmällisesti kokeilla isoja ja pieniä muutoksia ja tietää niiden vaikutus ennen teknisen tiimin tai sisällöntuottajien vaivaamista.

Business case on hyvin helppo rakentaa, jos voit sanoa ”Jos teemme muutoksen X tuotelistaussivuille, voimme saada 9% lisää kävijöitä tähän sivutyyppiin kuukausitasolla. Vuodessa se tarkoittaa YYYYYY euroa lisää myyntiä verkkokaupan kautta.”

Vaikka meillä OIKIOlla onkin SEOn A/B-testaamisesta kokemusta en halua, että mielipiteesi näinkin tärkeään aiheeseen perustuu pelkästään yhteen blogikirjoitukseen tai esitykseen. Siispä olenkin listannut alle listan relevantteja artikkeleita ympäri webbiä. Suosittelen lämpimästi, että käyt ainakin vilkaisemassa muutamaa niistä.

Aiheesta muualla webissä:

 

Joona Tuunanen

Head of SEO

Kansainvälisellä taustalla varustettu digitaalisen markkinoinnin tekijä, joka haluaa viedä suomalaisia tuotteita ja palveluita maailmalle. Erityinen vahvuuteni on tekninen SEO. Ratkon mielelläni ongelmia mitä muut SEO-tekijät eivät osaa tai halua yrittää ratkaista.