Schema-merkinnät kertovat koneelle mitä sisältö tarkoittaa ja vähentävät virheitä tekoälyvastauksissa. Tärkeysjärjestys, virheet ja vartin tarkistus.
Strukturoitu data eli schema.org-merkinnät kertovat koneelle, mitä sivun sisältö tarkoittaa: tämä on yritys, tämä on hinta, tämä on kysymys ja tuossa on sen vastaus. Hakukoneille näitä merkintöjä on tehty vuosia tähtiarvioiden ja rikastettujen hakutulosten takia. Tekoälyhaut antoivat samalle työlle uuden merkityksen: jäsennelty tieto on kielimallille helpompaa poimia oikein — ja väärin poimittu tieto on GEO:ssa se pahin lopputulos. Käyn läpi, mitkä merkinnät kannattaa tehdä ja missä järjestyksessä.
Kielimalli pystyy lukemaan sivun ilman merkintöjäkin, mutta se joutuu silloin päättelemään: onko “alk. 590 €” asennuksen vai kuukauden hinta, viittaako osoite yritykseen vai sen asiakkaaseen, kuka sivun on kirjoittanut. Päättely menee useimmiten oikein — ja joskus ei. Schema-merkinnät poistavat arvailun kertomalla suhteet suoraan: tämä hinta kuuluu tälle palvelulle, tämä organisaatio sijaitsee täällä, tämä henkilö on kirjoittaja.
GEO:n näkökulmasta tavoite ei siis ole vain “rikastettu hakutulos” vaan tiedon oikeellisuus vastauksissa. Yritys, jonka perustiedot ovat koneluettavasti yksiselitteiset, tulee mainituksi oikein useammin kuin yritys, jonka tiedot pitää päätellä leipätekstistä.
1. Organization. Perusta kaikelle: virallinen nimi, osoite, puhelin, sähköposti, logo ja sameAs-linkit yrityksen muihin profiileihin (LinkedIn, Google Business). Tämä on se merkintä, joka sitoo hajallaan olevat maininnat samaksi entiteetiksi. Paikalliselle yritykselle LocalBusiness-alatyyppi aukioloaikoineen on vielä parempi.
2. FAQPage. GEO:n tehokkain yksittäinen merkintä, koska se paketoi sisällön täsmälleen siihen muotoon, jossa tekoälyvastaukset liikkuvat: kysymys ja vastaus pareina. Jokainen aito UKK-osio kannattaa merkitä — mutta vain aito. Keksityt kysymykset joita kukaan ei kysy ovat kohinaa sekä lukijalle että koneelle.
3. Service tai Product. Mitä myyt, mitä se maksaa, missä sitä on saatavilla. Hintatiedon merkitseminen tuntuu monesta uskaliaalta, mutta juuri hintakysymyksiin tekoälyltä haetaan vastauksia — ja vastaukseen pääsee se, jonka hinta on koneluettavissa.
4. Article. Artikkeleille julkaisupäivä, muokkauspäivä ja julkaisija. Tuoreus on hakupohjaisissa tekoälyvastauksissa valintakriteeri, ja päiväysmerkinnät ovat tapa todistaa se.
5. BreadcrumbList. Kevyt mutta hyödyllinen: kertoo sivuston rakenteen ja sivun paikan siinä.
AI-näkyvyystesti kysyy kielimallilta mitä se sinusta tietää — ja näyttää vastauksen sellaisenaan.
Merkinnät valehtelevat. Schema, joka väittää sivulla olevan sisältöä jota siellä ei näy, on riski: Google voi rankaista siitä, ja kielimallille syötetty ristiriita heikentää luottamusta kaikkeen muuhunkin dataan. Merkitse vain se, mikä sivulla oikeasti on.
Sama tieto eri arvoilla eri paikoissa. Jos Organization-merkinnän puhelinnumero eroaa footerin numerosta tai Google Business -profiilista, kone joutuu valitsemaan — ja saattaa valita väärin. Yksi totuus, kaikkialla sama.
Merkitään kaikki mahdollinen. Schema.org tuntee satoja tyyppejä, ja työkalut houkuttelevat merkitsemään jokaisen. Hyöty tulee viidestä yllä listatusta; loput ovat useimmille sivustoille ylläpitotaakkaa ilman vastinetta.
Nopea tarkistus vie vartin. Syötä etusivusi, palvelusivusi ja yksi artikkeli Googlen rikastettujen tulosten testiin tai schema.org-validaattoriin. Katso kolme asiaa: löytyykö Organization-merkintä ja ovatko sen tiedot oikein, onko UKK-osioilla FAQPage-merkintä, ja onko artikkeleilla päiväykset. Jos vastaus on kolme kertaa kyllä, perusta on kunnossa ja voit siirtyä sisältöön. Jos ei, tämä on GEO-työlistan halvin korjaus — WordPress-sivustolla useimmat merkinnät hoituvat SEO-lisäosalla tai teemalla ilman käsin koodausta.
Rakenteinen data ei muuta sitä miltä sivu näyttää. Se lisää sivun koodiin koneluettavan kerroksen, joka kertoo mitä sisältö tarkoittaa.
Ilman merkintää kone näkee tekstiä ja päättelee merkityksen. Merkinnän kanssa se lukee suoraan, että kyseessä on organisaatio jonka nimi on tämä, osoite tuo ja puhelinnumero tämä. Päättely poistuu ja sen mukana virheen mahdollisuus.
Juuri tämä on merkintöjen arvo tekoälynäkyvyydessä. Kielimalli tekee virheitä nimenomaan silloin kun se joutuu arvaamaan, ja merkintä poistaa arvauksen niistä kohdista jotka ovat yritykselle tärkeimpiä: yhteystiedot, hinnat ja palvelut.
Jos teet vain yhden merkinnän, tee tämä. Organisaatiomerkintä kertoo koneelle yrityksen viralliset perustiedot yhdessä paikassa ja yhdessä muodossa.
Siihen kuuluu nimi, verkkotunnus, logo, yhteystiedot, toimialue ja sosiaalisen median profiilit. Viimeinen on aliarvostettu: kun profiilit on lueteltu merkinnässä, kone tietää että ne kuuluvat samalle yritykselle eikä joudu päättelemään sitä nimestä.
Merkintä kannattaa laittaa kaikille sivuille, ei vain etusivulle. Silloin mikä tahansa sivustolle päätyvä botti saa perustiedot riippumatta siitä mistä se tuli.
FAQ-merkintä on tehokkain yksittäinen merkintä tekoälynäkyvyydelle, koska se tarjoaa kysymyksen ja vastauksen valmiiksi pareina. Juuri siinä muodossa malli vastauksensa rakentaa.
Yksi ehto on ehdoton: merkinnässä olevan sisällön pitää olla myös sivulla näkyvissä. Piilotettu FAQ-merkintä, jonka sisältöä ei ole itse sivulla, on ohjeiden vastainen ja voi johtaa merkintöjen huomiotta jättämiseen koko sivustolla.
Toinen yleinen virhe on merkitä kysymyksiksi asioita joita kukaan ei kysy. Merkintä ei tee kysymyksestä kysyttyä, joten kysymysten pitää olla oikeita ja mielellään peräisin myynnin tai asiakaspalvelun arjesta.
Tämä on tärkein varaus koko aiheesta. Rakenteinen data auttaa konetta ymmärtämään sisällön, mutta se ei luo sisältöä eikä paranna sitä.
Jos sivulla ei ole vastausta kysymykseen, merkintä ei tuo sitä. Jos hinta puuttuu, hintamerkintä ei auta. Merkinnät ovat viimeistely, joka kannattaa tehdä vasta kun sisältö on kunnossa, eikä oikotie sen ohi.
Käytännön järjestys on siis selkeä: ensin vastaukset kysymyksiin, sitten tekninen luettavuus, sitten merkinnät. Väärässä järjestyksessä tehtynä merkinnät kuvailevat tarkasti sisältöä jota ei kannata lainata.
Merkinnät ovat koodia, eikä virhe näy sivulla mitenkään. Siksi ne pitää tarkistaa erikseen, ja tarkistus kannattaa tehdä kolmessa vaiheessa.
Aja ensin tärkeimmät sivutyypit Googlen rakenteisen datan testityökalun läpi: etusivu, palvelusivu, artikkeli ja tuotesivu jos sellainen on. Katso sitten Search Consolen parannusraportit, jotka kertovat virheistä koko sivuston laajuudelta. Tarkista lopuksi ettei samalla sivulla ole päällekkäisiä merkintöjä samasta asiasta, mikä on yleistä kun teema ja lisäosa tuottavat molemmat omansa.
Tarkistus kannattaa toistaa aina alusta- tai teemapäivityksen jälkeen, koska merkinnät tulevat usein koodista jota päivitys muuttaa.
Kaikkia mahdollisia merkintöjä ei kannata tehdä. Osa on työläitä ja tuottaa vähän, ja ylimääräiset merkinnät vaikeuttavat ylläpitoa.
Keskity niihin, jotka kuvaavat yritystä, palveluita, hintoja ja kysymyksiä. Nämä ovat samalla ne asiat, joita tekoälyltä kysytään yrityksistä. Jätä väliin merkinnät, jotka kuvaavat sivuston teknistä rakennetta tai toistavat tietoa jota ei kysytä.
Nyrkkisääntö: jos merkintä ei liity mihinkään kysymykseen jonka asiakas voisi esittää, se ei ansaitse ylläpitotyötä.
Rakenteinen data on viimeistely, joka poistaa koneen tarpeen arvata. Organisaatiomerkintä kaikille sivuille ja FAQ-merkintä kysymyssivuille kattavat suurimman osan hyödystä pienellä työllä. Merkinnän sisällön pitää aina näkyä myös sivulla, ja rikkinäinen merkintä on huonompi kuin ei merkintää lainkaan, joten validointi kannattaa tehdä kerran huolella ja toistaa päivitysten jälkeen.
Tärkein varaus säilyy loppuun asti: merkinnät kuvaavat sisältöä, eivät korvaa sitä. Jos vastausta ei ole, merkintä ei tuo sitä.
Toteutustapoja on kolme, ja valinta riippuu siitä kuka sivustoa ylläpitää.
SEO-lisäosan kautta. Yleisimmät lisäosat tuottavat organisaatio- ja artikkelimerkinnät automaattisesti asetuksista. Tämä riittää useimmille ja on helpoin ylläpitää.
Teeman koodissa. Antaa täyden hallinnan ja välttää lisäosien päällekkäisyydet, mutta vaatii kehittäjää ja muistamista päivitysten yhteydessä.
Sivukohtaisesti sisältöön. Toimii yksittäisissä poikkeuksissa, kuten palvelusivun hintamerkinnässä, mutta hajautuu hallitsemattomaksi jos sitä käytetään laajasti.
Käytännön suositus: perusmerkinnät lisäosalla tai teemalla koko sivustolle, ja sivukohtaiset lisäykset vain siellä missä ne tuovat jotain mitä yleinen merkintä ei kata.
Rehellinen arvio: rakenteinen data on hyödyllinen mutta harvoin ratkaiseva. Se ei nosta huonoa sisältöä eikä korjaa teknistä estettä.
Suurin mitattava hyöty tulee hakutulosten esitysmuodosta: tähtiarviot, hinnat ja kysymykset näkyvissä nostavat klikkiprosenttia. Tekoälynäkyvyydessä hyöty on epäsuorempi ja liittyy siihen, että kone saa perustiedot ilman päättelyä.
Kustannus on kuitenkin pieni ja kertaluonteinen, joten suhde on hyvä. Tee perusmerkinnät kerran kunnolla, validoi ne, ja palaa asiaan vain päivitysten yhteydessä.
Rakenteinen data kertoo koneelle mitä sivun sisältö tarkoittaa, jolloin sen ei tarvitse päätellä. Organisaatiomerkintä kaikille sivuille ja FAQ-merkintä kysymyssivuille kattavat suurimman osan hyödystä. Merkinnän sisällön on näyttävä myös sivulla, ja rikkinäinen merkintä on huonompi kuin puuttuva, joten validointi kannattaa tehdä kerran huolella ja toistaa alusta- ja teemapäivitysten jälkeen.
Käytännön aloitus: tarkista mitä merkintöjä sivustollasi jo on. Useimmissa on jotain valmiina teeman tai lisäosan tuottamana, ja työ alkaa niiden korjaamisesta eikä uusien lisäämisestä.
Sivun HTML:ään upotettua koneluettavaa tietoa, joka kertoo sisällön merkityksen schema.org-sanastolla: mikä on yritys, hinta, kysymys, vastaus tai artikkeli. Yleisin toteutusmuoto on JSON-LD-koodilohko sivun head-osassa.
Se parantaa todennäköisyyttä, että mallit poimivat tietosi oikein — nimen, hinnat, yhteystiedot ja kysymys–vastaus-parit. Merkinnät eivät korvaa hyvää sisältöä, mutta vähentävät virheellisiä mainintoja ja tukevat lähteeksi pääsyä.
Organization (tai LocalBusiness), FAQPage, Service/Product hintoineen, Article päiväyksineen ja BreadcrumbList. Tässä järjestyksessä, ja vain todellista sisältöä vastaavina.
Harvoin. WordPressissä SEO-lisäosat tuottavat perusmerkinnät automaattisesti, ja UKK-osioiden FAQPage-scheman voi generoida teematasolla sisällöstä. Käsin koodausta tarvitaan lähinnä erikoistapauksiin.
Ei suoraan. Se ei ole rankingtekijä, mutta se vaikuttaa siihen miten sivu esitetään hakutuloksissa ja miten hyvin kone ymmärtää sisällön. Molemmat vaikuttavat epäsuorasti klikkiprosenttiin ja siihen, päädytäänkö sivu valitsemaan lähteeksi.
Yleensä lähtökohdaksi kyllä, mutta se kannattaa tarkistaa. Moni teema ja lisäosa tuottaa merkintöjä automaattisesti, ja niissä on usein päällekkäisyyksiä tai virheitä. Rikkinäinen merkintä on huonompi kuin ei merkintää lainkaan, joten validointi kannattaa tehdä kerran huolella.
Teimme oman sivustomme UKK-osioista automaattisesti FAQPage-scheman — sama onnistuu asiakkaidemme sivustoille osana tekoälyhakukoneoptimointia. Tekninen perusta on kuvattu myös SEO-palvelusivulla.
Useat tekoälypalvelut hakevat vastauksensa Bingin indeksistä. Jos sivustosi puuttuu sieltä, jäät vastausten ulkopuolelle. Kolmen kohdan tarkistus vie vartin.
Kun tekoälyltä kysytään parasta palvelua paikkakunnalla, vastaus kootaan Google-profiilista, arvosteluista ja listauksista. Katso neljä tekoa jotka ratkaisevat.
B2B-ostaja pyytää tekoälyltä toimittajalistan ennen yhteydenottoa. Katso millä perusteella malli valitsee listalle ja miten erikoistuminen voittaa koon.
Kerro lyhyesti tilanteestasi. Vastaamme saman arkipäivän aikana, yleensä parissa tunnissa.
