Strukturoitu data: mitä yrityksen verkkosivusto oikeasti tarvitsee
Strukturoitu data ei ole sijoitustekijä. Se on käännös: se kertoo koneille, mitä tekstikappale tarkoittaa, sen sijaan että antaisi niiden arvata. Juuri se ratkaisee yhä useammin, esiintyykö sivu vastauksissa lainkaan.
Tärkeimmät kohdat
- Neljä tyyppiä riittää lähes jokaiselle yrityssivustolle: Organization, WebPage tai Article, BreadcrumbList ja FAQPage.
- Toimitusmuoto on JSON-LD
<head>-osiossa – ei merkintöinä leipätekstin sisällä. - Yleisin virhe on äänetön ja kallis: strukturoidussa datassa olevat tiedot, joita sivulla itsellään ei ole.
- Kolme paljon puhuttua tyyppiä palveluyritys voi jättää väliin – ne purevat vain sopivan tarjonnan tai aitojen arvostelujen kanssa.
Kone, joka lukee sivua, näkee aluksi vain tekstiä. Sen, että «Emma Woelk» on ihminen, «TEISENDA GmbH» yritys ja «22. elokuuta 2026» julkaisupäivä, sen täytyy arvata – tai se lukee siinä nimenomaisesti.
Strukturoitu data on juuri tätä nimenomaisuutta. Se ei paranna sijoitusta. Se ratkaisee, tuleeko sivu lainkaan kyseeseen laajennetuissa esitysmuodoissa ja tuotetuissa vastauksissa.
Ne neljä, jotka riittävät
1. Organization – kerran, etusivulla
Keitä te olette: nimi, osoite, logo, perustamisvuosi, profiilit muissa verkostoissa. Tämä on se merkintä, jonka ansiosta logo voi näkyä hakutuloksen vieressä – yleisin syy sen puuttumiseen on yksinkertaisesti tämän merkinnän puuttuminen.
Tärkeää: Logon täytyy olla rasterikuva. SVG:tä ei tässä kohdassa tulkita.
2. WebPage tai Article – jokaisella sivulla
Mikä tämä sivu on: otsikko, kuvaus, kieli, julkaisupäivä ja viimeisimmän muokkauksen päivä. Artikkeleissa lisäksi Article tai BlogPosting, jossa kirjoittaja on oma Person-merkintänsä – roolin kanssa, ei vain nimen.
Tärkeää: Muutospäivän täytyy pitää paikkansa. Päivä, joka asetetaan uudelleen jokaisella sivunlatauksella, on signaali, joka mitätöi itsensä.
3. BreadcrumbList – kaikilla alasivuilla
Missä tämä sivu sijaitsee rakenteessa. Näkyvänä polkuna sivun yläosassa, koneluettavana otsikkoalueella. Molemmat kuuluvat yhteen – polku datassa, jota sivulla ei ole, on virheellinen tieto.
4. FAQPage – siellä missä on aitoja kysymyksiä
Artikkelin lopun kysymysosio. Vastauskoneille kaikkein arvokkain tyyppi, koska se toimittaa kysymyksen ja vastauksen jo valmiiksi parina – juuri siinä muodossa, jossa lainataan.
Tärkeää: Vain sivulla todella näkyviin kysymyksiin. Keksityt kysymykset, jotka ovat vain datassa, ovat ohjeiden vastaisia.
Kolme, jotka voi jättää väliin
Product ja Offer. Palveluille, joiden tarjous tehdään pyynnöstä, ne eivät tuo mitään – ilman hintaa ja saatavuutta niitä ei kuitenkaan näytetä. Järkeviä vasta oikean verkkokaupan kanssa.
AggregateRating. Tähdet hakutuloksessa ovat houkuttelevia ja sidottu tiukkoihin ehtoihin: arvostelujen pitää olla aitoja, tarkistettavissa ja sivulla näkyvissä. Itse annetut arvostelut ovat ohjerikkomus, jolla on todellinen riski.
HowTo. Sen esittämistä on selvästi vähennetty, eikä se enää useimmilla yrityssivustoilla ole ylläpitovaivan arvoinen.
Tiesitkö?
Strukturoitu data ei ole sijoitustekijä – Google on selventänyt sen useaan kertaan. Se ratkaisee esitystavan, ei sijainnin.
Vastauskoneiden kohdalla asia on hieman toisin. Malli, jonka on rakennettava sivusta vastaus, käyttää mieluiten sitä, mikä on yksiselitteisesti merkitty: kysymys–vastaus-pareja, kirjoittajaa roolin kanssa, viimeisen tarkistuksen päivää. Sen ei silloin tarvitse arvata, mikä kuuluu yhteen. Hyöty on siis vähemmän sijoituksessa kuin lainattavuudessa.
Miten ne asennetaan
Kolme sääntöä, jotka välttävät useimmat ongelmat.
- JSON-LD,
<head>-osiossa. Ei attribuutteina leipätekstissä. JSON-LD:tä voi ylläpitää erillään ulkoasusta, eikä se katoa ulkoasumuutoksissa. - Yksi lohko sivua kohti, ei viittä. Useat merkinnät kuuluvat yhteen
@graph-rakenteeseen ja liitetään toisiinsa@id-tunnisteilla. Näin artikkeli viittaa samaan organisaatioon, joka on etusivulla, sen sijaan että toistaisi sen. - Tuota samasta lähteestä kuin näkyvä sisältö. Kun otsikko, päivä ja kirjoittaja tulevat samoista kentistä kuin sivu itse, ne eivät voi lainkaan erkaantua toisistaan. Se on kaikkein tehokkain ennaltaehkäisy.
Kallein virhe on hiljaisin: strukturoitu data sanoo jotain, mitä sivulla ei lue. Eilinen muutospäivä vuoden 2023 tekstissä. Kirjoittaja, joka ei näy näkyvällä alueella. Kysymyksiä datassa, joita sivulla ei ole.
Yksikään tarkistustyökalu ei huomaa sitä – data on muodollisesti pätevää. Se huomataan manuaalisessa tarkastuksessa, ja silloin seuraus ei koske vain kyseistä merkintää. Siksi sääntö «tuota samasta lähteestä» on tärkeämpi kuin mikään täydellisyys.
Tarkistus – tässä järjestyksessä
| Vaihe | Millä | Mitä näette |
|---|---|---|
| 1. Syntaksi | Schema Markup Validator | Onko JSON pätevää ja tyyppi oikea |
| 2. Esitettävyys | Rich Results -testi | Olisiko laajennettu esitys mahdollinen |
| 3. Todellisuus | Search Console, Parannukset-osio | Mitä on todella tunnistettu, kaikilla sivuilla |
| 4. Vastaavuus | Lue itse | Lukeeko jokainen tieto myös näkyvästi sivulla |
Vaihe neljä on ainoa, jota yksikään työkalu ei hoida – ja ainoa, jossa vakavat virheet huomataan.
Tarkista tämän sivun strukturoitu data täydellisyyden ja näkyvän sisällön kanssa vastaavuuden osalta. Sivun näkyvä sisältö: [Liitä sivun teksti] Sivun JSON-LD: [Liitä lohko] Tehtävät: 1. Nimeä jokainen JSON-LD:n tieto, jota näkyvässä sisällössä ei esiinny. Tämä on tärkein kohta – ole tässä perusteellinen. 2. Nimeä jokainen näkyvä tieto, joka pitäisi merkitä, mutta puuttuu (kirjoittaja roolin kanssa, muutospäivä, kysymykset, polku). 3. Tarkista, onko neljä perustyyppiä järkevästi täytetty: Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Nimeä lohkon tyypit, joista palveluyritykselle ilman verkkokauppaa ja ilman tarkistettavia arvosteluja ei ole hyötyä. 5. Osoita jokainen ohjeiden rikkomus, erityisesti itse annetut arvostelut ja kysymykset, joita sivulla ei ole. Tulosta korjattu JSON-LD lopuksi kokonaisuudessaan. Älä keksi arvoja – merkitse puuttuvat muodossa [täydennettävä].
Johtopäätös
Strukturoitu data yliarvioidaan nopeasti ja tehdään yhtä nopeasti väärin. Neljä tyyppiä kattaa yrityssivuston tarpeen, ja niiden hyöty on vähemmän sijainnissa kuin siinä, että sivu on lainattavissa.
Se yksi sääntö, joka kantaa kaiken: älkää merkitkö mitään, mitä sivulla ei lue. Se, joka tuottaa datan samasta lähteestä kuin näkyvän sisällön, on ratkaissut tämän ongelman rakenteellisesti – ja voi jättää jälkitarkistukset suurelta osin tekemättä.
Usein kysytyt kysymykset
Mitä strukturoitua dataa yrityksen verkkosivusto tarvitsee?
Neljä tyyppiä riittää: Organization kerran etusivulla, WebPage tai Article jokaisella sivulla, BreadcrumbList kaikilla alasivuilla ja FAQPage kaikkialla siellä, missä on aitoja, näkyviä kysymyksiä. Product, AggregateRating ja HowTo eivät palveluyritykselle yleensä kannata.
Parantaako strukturoitu data sijoitusta?
Ei. Se ei ole sijoitustekijä vaan ratkaisee esitystavan – esimerkiksi sen, voiko logo, polku tai avautuvat kysymykset näkyä hakutuloksessa. Vastauskoneille se lisää lainattavuutta, koska kysymys–vastaus-parit, kirjoittaja ja päivä on merkitty yksiselitteisesti eikä niitä tarvitse arvata.
Miksi Google ei näytä logoamme?
Yleisin syy on puuttuva tai vaillinainen Organization-merkintä etusivulla. Toiseksi yleisin syy: tallennettu logo on vain SVG-muodossa – tässä kohdassa tarvitaan rasterikuva. Myöskään oikein merkittynä ei ole oikeutta näyttämiseen.
Mikä on yleisin virhe strukturoidussa datassa?
Tiedot, jotka ovat datassa mutta eivät näkyvässä sisällössä: väärä muutospäivä, mainitsematta jäänyt kirjoittaja, keksityt kysymykset. Tarkistustyökalut eivät ilmoita siitä, koska data on muodollisesti pätevää. Sen voi välttää tuottamalla merkinnät samasta lähteestä kuin näkyvän tekstin.
JSON-LD vai mikrodata?
JSON-LD <head>-osiossa. Se on Googlen suosittelema muoto, sitä voi ylläpitää erillään ulkoasusta eikä se katoa ulkoasumuutoksissa. Mikrodata levittää merkinnät leipätekstiin ja hajoaa jokaisessa sivun uudistuksessa.
Markkinointi, joka pystyttää itsensä
Studio Enginen beta on auki. Varaa paikkasi ja ole mukana alusta asti.
Osallistu betaan →