Tekoälyoptimointi: Näin saat verkkosivusi vastaukseen

Tekoälyoptimointi tarkoittaa sitä, että verkkosivu tehdään sellaiseksi, että hakukoneet ja generatiiviset tekoälypalvelut voivat löytää sen, ymmärtää sen sisällön ja mahdollisesti käyttää sitä vastauksissaan. Moni olettaa, että tähän tarvitaan jokin uusi tiedosto tai erillinen merkintä. Google kertoo kuitenkin, että sen AI Overviews- ja AI Mode -näkymiin voi päästä samoilla teknisillä perusvaatimuksilla kuin tavalliseen hakuun, eikä erillistä tekoälytiedostoa, uutta metatagia tai erityistä Schema.org-tietotyyppiä tarvita [1].

Lyhyt vastaus on siis tämä: tekoälyoptimointi on teknisesti luettava sivusto ja selkeästi jäsennelty, lähteisiin perustuva sisältö. Omissa projekteissani se on onnistunut helpoimmin silloin, kun se on suunniteltu mukaan heti verkkosivuprojektin alussa eikä lisätty valmiiseen sivustoon jälkikäteen.

Perusta

Ensimmäinen tarkistus on se, saako hakukone sivun ylipäätään luettavakseen. Sivun pitää vastata palvelimelta onnistuneesti. Rikkinäinen linkki palauttaa usein tilan 404.

Google Search Consolen URL-tarkastus näyttää, tunteeko Google yksittäisen osoitteen ja miten se on sen käsitellyt.

Kaksi asetusta voi estää sivun näkymisen Googlen hakutuloksissa, vaikka sivu näyttää kävijälle normaalilta:

• Robots.txt on sivuston juuressa oleva tiedosto, joka kertoo indeksoijille, mihin osoitteisiin ne saavat mennä.
• Noindex on sivukohtainen merkintä, joka pyytää jättämään sivun pois hakutuloksista.

Olen huomannut, että uudistuksen jälkeen noindex jää usein päälle kehitysvaiheesta, ja silloin sivu ei näy Googlessa. En tiedä varmasti, miten kukin tekoälypalvelu tällaisen sivun käsittelee, koska palvelujen toiminta vaihtelee.

JavaScript vaikuttaa siihen, näkeekö indeksoija saman tekstin kuin kävijä. Jos teksti syntyy vasta selaimessa skriptin ajamisen jälkeen, indeksoija ei välttämättä näe sitä heti tai kokonaan. SK Infran sivustossa Astro tuottaa valmiit sivut ja sisältöä hallitaan Sanity CMS:ssä, joten tekstit ovat HTML:ssä jo silloin, kun sivu saapuu selaimeen.

Viimeinen kerros on rakenne. Jokaisella sivulla on yksi pääotsikko eli h1-elementti, ja sen alla väliotsikot, kappaleet ja luettelot jakavat sisällön osiin. Sisäiset linkit kertovat, miten sivut liittyvät toisiinsa.

Sivustokartta on XML-tiedosto, jossa luetellaan indeksoitaviksi tarkoitetut osoitteet ja joka lähetetään Search Consoleen. Shopify-alustalle tekemissäni TopStoren ja Taigalyhdyn kaupoissa tuoteryhmät, tuotesivut ja asiakasryhmien sivut löytyvät selkeän linkkipolun kautta.

Teknisen perustan kerrokset

1. 1Pääsy sivullePalvelin vastaa ja linkit toimivat ilman virhekoodeja.
2. 2IndeksointiasetuksetRobots.txt ja noindex sallivat sivun käsittelyn.
3. 3HTML-tekstiSisältö tarjotaan suoraan HTML-muodossa ilman skriptejä.
4. 4SivurakenneOtsikot, sisäiset linkit ja sivustokartta opastavat lukijaa.

Sisältörakenne

Kirjoitan jokaisen sivun ensimmäiseen kappaleeseen lyhyen vastauksen pääkysymykseen: mitä tarjotaan, kenelle ja millä ehdoilla. Perustelut ja tausta tulevat vasta sen jälkeen. Jos vastaus on pitkän markkinointitekstin keskellä, kuvassa tai avattavassa välilehdessä, sen löytää huonommin sekä lukija että kone.

Aloitusvastauksen jälkeen sivulle kuuluvat luvut, ehdot ja rajaukset näkyvänä tekstinä. Lause “palvelu on nopea ja edullinen” ei kerro mitään tarkistettavaa. Lause “toimitus kestää 2–4 arkipäivää Suomessa, ei koske ennakkotilauksia” kertoo.

Merkitsen hintoihin, sisältävätkö ne arvonlisäveron, ja kirjoitan näkyviin, koskeeko tieto vain Suomea vai myös Ahvenanmaata tai muita maita. Kun samaa termiä käytetään koko sivulla samassa merkityksessä, yksittäisen kappaleen voi lainata ilman, että sen merkitys muuttuu.

Usein kysytyt kysymykset toimivat, kun jokainen vastaa todelliseen asiakkaan kysymykseen ja vastaus on konkreettinen. Kymmenen lähes samanlaista, avainsanaa toistavaa kysymystä heikentää sivua. Lisään sivun loppuun näkyvän päivityspäivän, josta lukija näkee, milloin hinta- tai saatavuustieto on viimeksi tarkistettu.

TopStoren kaupassa yritysasiakkaille tein oman alennusmallin isompia tilauksia varten. Sekä kuluttajien että yritysasiakkaiden ehdot on siksi kirjoitettu sivulle auki eikä jätetty ostoskorin logiikkaan.

Taigalyhdyn kauppa siirrettiin WooCommercesta Shopifyhin, jotta yrittäjä voi hallita kauppaansa itse. Kun tuotteen tärkeimmät faktat ovat aina samoissa kentissä ja samassa järjestyksessä, uuden tuotteen lisääjä täyttää kentät eikä joudu miettimään sivun rakennetta.

Sisältöviestinnän täsmällisyys

Toimii

• Vastaus pääkysymykseen aloituskappaleessa
• Tarkat toimitusajat ja alv-merkinnät
• Aitoihin kysymyksiin vastaava UKK

Ei toimi

• Vastauksen piilottaminen välilehtiin
• Ympäripyöreät myyntilauseet
• Avainsanoja toistavat tekokysymykset

Lähteet ja merkinnät

Lähdekelpoinen sivu kertoo, kuka tiedon on kirjoittanut ja kuka tarkistanut. Merkitsen artikkeliin kirjoittajan nimen ja roolin, julkaisupäivän ja viimeisimmän päivityspäivän. Jos tekstin on tarkistanut esimerkiksi tilintarkastaja tai rakennesuunnittelija, hänen nimensä ja pätevyytensä näkyvät samassa kohdassa.

Luvun lähde on sen alkuperäinen julkaisija: viranomaispäätös, tilasto, standardi tai tutkimus, ei toisen sivuston tiivistelmä. Kun luku on itse laskettu, sivulla kerrotaan aineisto, ajanjakso ja yksikkö: “palvelu nopeutui” ei kerro mitään, mutta “mediaanivasteaika oli 1,8 sekuntia 500 pyynnön aineistossa” kertoo, mitä mitattiin ja kuinka laajasti. Samaan kohtaan kuuluvat epävarmuudet, kuten se, koskeeko tieto vain Suomea vai voiko sääntö muuttua.

Rakenteinen data on sivun koodiin lisättävä koneluettava kuvaus sisällöstä. Se käyttää Schema.org-sanastoa ja kertoo esimerkiksi, että sivu on artikkeli, tuote tai yrityksen esittely. Googlen mukaan rakenteisen datan on vastattava sitä, mitä käyttäjä näkee sivulla [1], joten merkintään ei lisätä hintaa, arvostelua tai väitettä, jota sivulla ei ole.

Käytän yleensä viittä tyyppiä:

• Article kuvaa artikkelin otsikon, kirjoittajan ja päivämäärät.
• Product tuotteen nimen, hinnan ja saatavuuden.
• Organization yrityksen nimen ja yhteystiedot.
• FAQPage merkitsee usein kysytyt kysymykset, mutta se ei takaa, että kysymykset näkyvät hakutuloksissa.
• BreadcrumbList kuvaa sivun paikan sivuston rakenteessa.

Product-merkinnän hinnan ja saatavuuden on vastattava kaupan senhetkistä tilannetta. TopStorelle ja Taigalyhdylle rakensin merkinnät Shopifyn omista tuotetiedoista enkä kirjoittanut niitä käsin.

SK Infran sivustolla merkinnät syntyvät samoista Sanityn kentistä kuin näkyvä sivu, joten kun asiakas päivittää tekstin Sanityssa, merkintä päivittyy samalla.

Merkintöjen virheet näkee Googlen Rich Results Testillä ja Schema Markup Validatorilla. Testit kertovat, onko merkintä teknisesti kunnossa, mutta eivät sitä, vastaako se näkyvää sivua, joten sen tarkistan itse. Rakenteinen data ei yksinään nosta sivua tekoälyvastaukseen, ja jos merkinnässä on vanha hinta tai poistettu kysymys, se johtaa harhaan.

Toteutus ja seuranta

Kun sivupohjat, otsikkotasot ja sisältökentät päätetään ennen ensimmäistä tekstiä, jokainen myöhemmin lisätty sivu noudattaa samaa rakennetta ilman korjauskierrosta. Siksi en tee optimointia omaksi projektikseen julkaisun jälkeen, vaan kirjaan sen samoihin työvaiheisiin kuin suunnittelun ja toteutuksen. Omassa työssäni SK Infran kaltainen malli, jossa Astro ja Sanity ovat erikseen, vie enemmän työtä kuin valmis sivupohja. En suosittele sitä, jos sivustolla on vain muutama harvoin muuttuva sivu.

Julkaisun jälkeen lähetän sivustokartan Search Consoleen, katson URL-tarkastuksella, että tärkeät sivut on indeksoitu, ja seuraan näyttökertoja, klikkauksia ja hakukyselyjä. Search Console kertoo vain Google-haun luvut, joten katson palvelinlokista myös, mitkä indeksoijat sivustolla käyvät ja estääkö robots.txt jonkin niistä. Vaikka indeksoija pääsee sivulle, se ei vielä tarkoita, että sivu mainitaan yhdessäkään vastauksessa.

Lähdemainintoja ei saa yhdestä raportista, joten testaan niitä toistuvasti. Kokoan 20–50 kysymystä, joita alan asiakas voisi esittää, ja kysyn ne muutaman viikon välein useammasta tekoälypalvelusta. Joka kerralta kirjaan päivämäärän, palvelun, mainittiinko oma sivu, mitä sivun kohtaa käytettiin ja oliko vastaus oikein. Vastaukset vaihtelevat käyttäjän, sijainnin, kirjautumisen ja ajankohdan mukaan, joten yksittäinen testi ei todista paljon, mutta usean kierroksen kirjanpidosta näkee, mitkä sivut kaipaavat korjausta.

Lopuksi

Tekoälyoptimoinnissa ei ole erillistä temppua, joten se toimii parhaiten toimintatapana eikä kertaprojektina. Tavoitteeksi voi ottaa, että ensimmäisen kuukauden aikana lähtötilanne on kirjattu, tärkeimmät sivut korjattu ja seuranta käynnissä.

Aluksi valitaan 10–20 sivua, joilta yhteydenotot tai ostot oikeasti tulevat. Työ etenee seuraavasti:

1. Tarkistetaan indeksointi, robots.txt, noindex-asetukset, canonical-osoitteet ja sivustokartta.
2. Kirjataan näyttökerrat, klikkaukset, klikkausprosentti ja tärkeimmät hakukyselyt talteen vertailukohdaksi.
3. Kirjoitetaan sivuille suora aloitusvastaus sekä näkyvät hinnat, toimitusajat ja ehdot päivityspäivineen.
4. Linkitetään luvut alkuperäisiin asiakirjoihin ja verrataan rakenteinen data näkyvään tekstiin [1].
5. Sovitaan, kuka päivittää mitäkin ja kuinka usein, esimerkiksi hinnat aina muutoksen yhteydessä ja muut tärkeät sivut neljännesvuosittain.

Jos päivittäminen vaatii joka kerta kehittäjää, tiedot vanhenevat.

Samalla kannattaa kirjata, kuka on tarkistanut tekoälyllä tuotetun tekstin ja milloin. EU:n tekoälysäädöksen artiklan 50 avoimuusvelvoitteiden soveltaminen alkaa lähteiden mukaan 2.8.2026 [2][3], ja vaatimukset riippuvat sisällön tyypistä ja omasta roolista, joten epäselvät tapaukset on syytä tarkistaa ajantasaisesta viranomaisohjeesta.

Jos teet vain yhden asian, sovi kalenteriin kuukausitarkistus, jossa käyt läpi samat testikysymykset, Search Consolen luvut ja kuukauden yhteydenotot tai ostot. Vasta niiden rinnakkainen vertailu kertoo, tuoko näkyvyys asiakkaita.

Lähteet

1. AI Features and Your Website | Google Search Central
2. Transparency obligations under Article 50 of the AI Act
3. AI Act Service Desk - Frequently Asked Questions