Mitä on rakenteellinen data (Schema.org)?

Mitä on strukturoitu data?

Rakenteellinen data on koodi, joka selittää sivun sisällön merkityksen hakukoneille koneellisesti luettavassa muodossa Schema.org-sanakirjaa käyttäen. Yleisin käyttötapa on JSON-LD-muoto, joka lisätään sivulle erillisenä <script type="application/ld+json"> lisätty JSON-LD-muoto; tämä lohko ei muuta sivun näkyvää sisältöä, vaan lisää siihen vain ylimääräisen ”tunnistekerroksen”. Saatavilla on useita tyyppejä, kuten Organization, Article, Product ja BreadcrumbList, ja kukin niistä on suunniteltu määrittelemään eri sisältötyyppiä.

Rakenteellista dataa voidaan verrata kirjaston luettelokorttiin: itse kirja (sivun sisältö) ei muutu, mutta kortti (rakenteellinen data) esittää kirjan tekijän, tyypin ja julkaisupäivän standardoidussa muodossa ja helpottaa hakua ja luokittelua.

JSON-LD:n lisäksi on olemassa vanhempia sovellusmuotoja, kuten Microdata ja RDFa; ne upottavat tiedot suoraan näkyviin HTML-tunnisteisiin. JSON-LD on helpompi ylläpitää, koska se on erillinen ja riippumaton sivun sisällöstä, ja se on nykyään myös Googlen suosittelema menetelmä.

Miksi se on tärkeää?

Oikein toteutettu strukturoitu data auttaa Googlea ymmärtämään sivun sisältöä selkeämmin ja voi mahdollistaa tiettyjen sisältötyyppien osalta rikastettujen tulosten (rich result) näyttämisen hakutulossivulla (SERP) – esim. navigointipolku, tuotteen hinta, artikkelin julkaisupäivä. Nämä visuaaliset lisäykset voivat nostaa sivusi esiin samassa hakutuloksessa olevien tulosten joukosta ja lisätä klikkausprosenttia.

Strukturoidun datan lisääminen ei kuitenkaan takaa rikastettuja tuloksia; Google päättää omalla algoritmillaan, mitä rikastettuja tuloksia se näyttää, ja tämä päätös voi muuttua ajan myötä. Siksi on oikeampaa ajatella strukturoitua dataa ”sisällön tekemisenä selkeämmäksi koneille luettavaksi” eikä ”varmana SERP-ominaisuuden ostona”.

Konkreettisin esimerkki tästä ovat FAQPage- ja HowTo-skeemat: vaikka niitä suositeltiin laajalti vuosien ajan, Google on kaventanut näiden rikastettujen tulosten laajuutta ja poistanut ne lähes kaikilta sivustoilta. Tämä on hyvä esimerkki siitä, kuinka ”aikanaan hyödyllinen sovellus” voi menettää arvonsa, kun hakukoneen käytäntö muuttuu.

Miten tilanne korjataan?

• Käytä sivustosi identiteetin osalta Organization-skeemaa ja blogi- tai uutissisällön osalta Article-skeemaa.
• Lisää navigointipolku BreadcrumbList ; tämä voi auttaa näyttämään hakutulossivulla (SERP) URL-osoitteen sijaan luettavan navigointipolun.
• Merkitse rakenteellisessa datassa vain sivulla todella näkyvä tieto; sivulla olemattoman datan lisääminen skeemaan rikkoo Googlen sääntöjä ja voi johtaa manuaalisiin toimenpiteisiin.
• Tarkista JSON-LD:n kelpoisuus (valid) validointityökalulla; syntaksivirheitä sisältävä lohko saatetaan jättää kokonaan huomiotta.
• Älä lisää FAQPage- ja HowTo-skeemoja: Google poisti nämä rikastetut tulokset suurelta osin vuonna 2023 ja on kaventanut niiden soveltamisalaa ajan myötä entisestään; ne eivät enää tarjoa tavallisille sivustoille käytännön hyötyä hakutulossivuilla (SERP), vaan aiheuttavat vain tarpeetonta koodikuormitusta ja ylläpitokustannuksia.

Esimerkki

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO-ystaevaellinen URL-rakenne",
  "datePublished": "2026-07-01",
  "author": {"@type": "Organization", "name": "SeoRaporu"}
}
</script>

Huono esimerkki: vaikka sivulla ei näy lainkaan julkaisupäivämäärää, JSON-LD:ssä on keksitty satunnainen datePublished arvoa; tämä on Googlen strukturoitujen tietojen ohjeiden vastaista ja voi jopa johtaa manuaalisiin toimenpiteisiin, jos se havaitaan.

Yleisiä virheitä

• Sivulla näkymättömän tiedon merkitseminen strukturoituun dataan (Google-sääntöjen vastaista).
• Virheellisen tai puutteellisen JSON-koodin kirjoittaminen; yksikin puuttuva pilkku voi mitätöidä koko lohkon.
• Ajan tuhlaaminen FAQPage/HowTo-skeemaan, joka ei enää tuota rikastettuja tuloksia.
• Strukturoidun datan synkronoinnin laiminlyönti ajantasaisen sisällön kanssa (esim. vanhan hinnan jättäminen skeemaan, vaikka sivun hinta on päivitetty).
• Kun Seoraporu.co-raportissa ei löydy strukturoituja tietoja, sitä ei merkitä virheeksi, vaan mahdollisuudeksi — se voidaan täyttää lisäämällä perustyyppejä, kuten Organization ja Article.
• Schema-tyyppien valitseminen sattumanvaraisesti ilman, että niitä sovitetaan sivun todelliseen sisältötyyppiin; esim. Product-scheman lisääminen blogikirjoitukseen aiheuttaa merkityssekaannusta ja voi heikentää Googlen luottamusta.
• Useamman ristiriitaisen skeemalohkon lisääminen samalle sivulle (esim. kaksi erilaista Organization-määritelmää); tällöin Google joutuu päättämään itse, kumpi on oikea.