Rakenteinen data ei nosta sijoituksia, mutta se poistaa epäselvyyden siitä, mikä sivu, yritys ja kirjoittaja ovat. Yleisin virhe ei ole se, että schema puuttuu. Yleisin virhe on, että aikaa käytetään erikoismerkintöihin samalla kun peruskerros on vajaa. Pienelle yritykselle riittää viisi tyyppiä, ja neljä niistä tekee suurimman osan työstä.
Mitä rakenteinen data tekee?
Rakenteinen data on koneluettava kuvaus sivusta: onko se artikkeli, yritysprofiili, palvelusivu vai navigaatiopolku, kuka sen julkaisi ja milloin. Se kirjoitetaan yleensä JSON-LD-muodossa sivun koodiin, ja sen sanasto tulee schema.org-standardista.
Hyöty tulee kolmesta suunnasta. Hakukone ymmärtää sivun entiteetit ja niiden suhteet nopeammin. Osa sisällöstä voi saada rikkaamman hakutuloksen. Ja sama selkeys auttaa tekoälyhakua, joka joutuu muuten päättelemään kirjoittajan ja julkaisijan tekstistä. Kolmas kohta on käytännön SEO-työstä tehty päätelmä, ei Googlen lupaus. Google sanoo, että rakenteinen data auttaa sitä ymmärtämään sisältöä ja näyttämään sitä rikkaammissa muodoissa, ei että se nostaisi sivun AI-vastauksiin.
Mitkä tyypit ovat tärkeimmät?
Kaikkea ei tarvitse toteuttaa. Useimmille suomalaisille pk-yrityksille järjestys on tämä.
| Järjestys | Tyyppi | Missä | Miksi |
|---|---|---|---|
| 1 | Organization | koko sivustolla, yhtenä solmuna | Yhdistää nimen, logon, osoitteen, Y-tunnuksen ja profiilit yhdeksi entiteetiksi. |
| 2 | WebSite | etusivulla | Määrittää sivuston kokonaisuuden ja julkaisijan. |
| 3 | BreadcrumbList | sisältö- ja palvelusivuilla | Tekee sivuhierarkian näkyväksi. |
| 4 | Article tai BlogPosting | artikkeleissa | Kertoo kirjoittajan, julkaisijan ja päivämäärät. |
| 5 | Service | tärkeimmillä palvelusivuilla | Kuvaa, mitä oikeasti myydään ja kenelle. |
| 6 | LocalBusiness | vain jos toimipiste on osa ostotilannetta | Tukee paikallista hakua. Etänä toimiva konsultti ei tarvitse sitä. |
Jos sivusto on pieni, neljä ensimmäistä riittää pitkälle. Se on parempi kuin neljätoista puoliksi rikkinäistä merkintää, jotka lisäosa tuotti kerran eikä kukaan ole tarkistanut sen jälkeen.
Miksi FAQPage ei enää kannata?
Schema.org-sanasto kertoo, mitä voi kuvata. Google Search Central kertoo, mitä Google-haku oikeasti tukee. Ne ovat eri listoja, ja ero näkyy selvimmin FAQPage-tyypissä. Merkintä on edelleen validi, mutta Google rajaa FAQ-laajennuksen hakutuloksissa pääasiassa tunnettuihin terveys- ja viranomaissivustoihin. Tavallisen yrityksen sivulle se ei enää tuo näkyvää laajennusta.
FAQ-osio sivulla on silti hyvä ajatus, koska kysymys ja suora vastaus on helpoin rakenne poimia tekoälyvastaukseen. Ero on tämä: tee FAQ lukijaa ja konetta varten, älä rich resultin toivossa.
Miksi Organization korjataan ensin?
Organization on sivuston identiteettikerros. Jos yrityksen nimi on footerissa eri muodossa kuin markupissa, logo on vanha ja sosiaaliset profiilit puuttuvat, ongelma ei ole merkinnässä vaan entiteetissä: kone ei ole varma, että kyse on samasta yrityksestä. Tyypilliset virheet ovat eri nimi eri paikoissa, vanha logo, väärä kanoninen osoite ja puuttuvat sameAs-viittaukset.
Artikkeleissa Google painottaa kirjoittajamerkinnän laatua. Jos sivulla on näkyvä kirjoittaja, saman tiedon pitää olla markupissa. Hyvä artikkelimerkintä sisältää otsikon, kuvauksen, julkaisu- ja päivityspäivän, kirjoittajan, julkaisijan, pääkuvan ja kanonisen osoitteen.
Miten oma entiteettigraafimme on rakennettu?
Jokaisen sivumme rakenteinen data viittaa samaan pieneen joukkoon pysyviä tunnisteita. Yritys on yksi solmu, #organization, jossa ovat osoite, Y-tunnus, profiilit ja hinnat. Anssi on #anssi, sivusto on #website, ja jokaisella sivulla on oma #webpage, jonka päivityspäivä on sama kuin sitemapissa. Artikkelin author ja publisher ovat aina viittaus yrityssolmuun, eivät uusi kopio nimestä.
Tämä ei syntynyt kerralla. Elokuussa 2026 huomasimme, että useat sivut kantoivat omaa pientä Organization-kopiotaan. Koneelle se näytti kolmelta samannimiseltä yritykseltä. Kopiot poistettiin 22.8.2026, ja sen jälkeen graafissa on yksi yritys.
Rehellisyyden nimissä: samana päivänä ajettu SEO Intel -auditti antoi schema-kattavuudelle 49 pistettä sadasta ja entiteettiauktoriteetille 8. Graafi on siis ehjä, mutta sivut eivät vielä nimeä riittävän näkyvästi, kuka puhuu. Se on tämän luvun seuraava työ meillä itsellämme.
Mitä tehdä seuraavan 30 päivän aikana?
- Listaa kaikki sivuston nykyiset schema-tyypit. Lisäosan tuottamat mukaan lukien.
- Poista merkinnät, joita et pysty ylläpitämään luotettavasti.
- Korjaa Organization ja WebSite ensin: yksi nimi, yksi logo, yksi osoite, sameAs-profiilit.
- Lisää tai korjaa BreadcrumbList sivuille, joilla polku on oikeasti olemassa.
- Vie kaikki artikkelit saman Article- tai BlogPosting-mallin alle.
- Validoi Googlen Rich Results Testillä ja Schema Markup Validatorilla.
- Seuraa Search Consolesta, ettei validien kohteiden määrä romahda sivupohjan muutoksen jälkeen.
Tärkein sääntö on tämä: vähemmän, mutta oikein. Jos näkyvä sisältö sanoo yhtä, meta toista ja JSON-LD kolmatta, koneelle ei synny luotettavaa kuvaa, ja silloin merkintää on parempi olla vähemmän.
Usein kysyttyä
Vaikuttaako rakenteinen data suoraan sijoituksiin?
Ei samalla tavalla kuin sisällön laatu, linkit tai indeksoitavuus. Sen arvo tulee ymmärrettävyydestä, mahdollisista rikkaista hakutuloksista ja siitä, että kone pystyy mallintamaan sivun tarkemmin.
Pitääkö schema lisätä joka sivulle?
Ei automaattisesti. Pieni, hyvin ylläpidetty pino on parempi kuin laaja ja ristiriitainen toteutus.
JSON-LD vai microdata?
JSON-LD. Syy on ylläpidettävyys: kun merkintä on yhdessä lohkossa, sen tarkistus ja sivupohjan muutokset ovat selkeämpiä kuin HTML-elementtien sisään ripotellussa microdatassa.