Schema-merkinnän opas

Pelkkiä sinisiä linkkejä pidemmälle: Miksi strukturoitu tieto on tehokkain SEO-valttisi

Avaa kaksi välilehteä. Hae ensimmäisessä paikallista ravintolaa. Näet tavallisen sinisen linkin ja metakuvauksen, joka katkeaa kesken lauseen. Hae toisessa välilehdessä reseptiä. Näet todennäköisesti tähtiarvosteluja, valmistusajan, kalorimäärän ja pikkukuvan – kaikki suoraan hakutuloksissa ennen kuin kukaan on klikannut mitään.

Sama hakukone. Sama algoritmi. Täysin erilainen visuaalinen näkyvyys. Eron tekee strukturoitu tieto.

Strukturoitu tieto, joka toteutetaan schema-merkinnän avulla, kertoo Googlelle, mitä sisältösi tarkoittaa, ei vain sitä, mitä siinä lukee. Kun Google ymmärtää, että sivullasi oleva numero on hinta, että tietty kappale on vastaus kysymykseen, tai että osoite kuuluu fyysiselle toimipisteelle, se voi esittää tämän tiedon rikastettuna hakutuloksena (rich result). Rikastetut hakutulokset ovat niitä paranneltuja hakukonenäkymiä, jotka sisältävät tähtiarvosteluja, UKK-haitareita, hintahaarukoita, tapahtumien päivämääriä, tuotteiden saatavuustietoja ja paljon muuta.

Visuaalinen hyöty on todellinen ja mitattavissa. Tutkimukset osoittavat toistuvasti, että rikastetut hakutulokset parantavat klikkausprosentteja (CTR) 20–30 prosenttia verrattuna tavallisiin sinisiin linkkeihin. Joillakin toimialoilla kasvu on jopa suurempi. Tuotelistaukset, joissa näkyy hinta, saatavuus ja arvostelutähdet, yksinkertaisesti kiinnittävät enemmän huomiota kuin sellaiset, joissa niitä ei ole. Katse hakeutuu sinne, missä tiedon tiheys on suurin.

Kun toteutat scheman oikein, tapahtuu kolme asiaa:

Tässä on kuitenkin realiteettitarkistus, joka jokaisen rehellisen schema-oppaan on sisällettävä: strukturoitu tieto ei suoraan paranna sijoituksiasi. Google on todennut tämän yksiselitteisesti. Schema-merkintä ei ole perinteisessä mielessä sijoitustekijä. Se tekee kuitenkin jotain muuta: se parantaa huomattavasti näkyvyyttäsi ja klikkausprosenttiasi siinä sijoituksessa, joka sinulla jo on. Sijalla 4 oleva sivu, jolla on rikastettuja hakutuloksia, voi helposti voittaa sijalla 2 olevan pelkän sinisen linkin. Tämä CTR-parannus lähettää Googlelle ajan myötä positiivisia sitoutumissignaaleja, jotka voivat epäsuorasti tukea sijoitusten nousua. Mutta ensisijainen mekanismi on näkyvyys, ei auktoriteetti.

Kaikesta tästä huolimatta suurin osa verkkosivustoista ei edelleenkään toteuta schemaa oikein. Tai ollenkaan. Kilpailtujen hakutulosten tarkastelu paljastaa usein, että alle puolet tuloksista käyttää strukturoitua tietoa enemmän kuin mitä heidän julkaisujärjestelmänsä (CMS) automaattisesti tuottaa. Tämä aukko on sinun mahdollisuutesi. Kilpailijasi jättävät rikastetut hakutulokset hyödyntämättä, koska he pitävät schemaa liian teknisenä, liian riskialttiina tai liian aikaavievänä. Se ei ole mitään näistä, kunhan ymmärrät perusteet.

Teknisen jargonin purkaminen: Schema.org vs. JSON-LD vs. Microdata

Tässä kohtaa useimmat menevät sekaisin, ja ymmärrettävästä syystä. Lähes jokaisessa internetin schema-oppaassa heitellään kolmea termiä ristiin, eivätkä ne tarkoita samaa asiaa. Korjataan asia saman tien.

Schema.org on sanasto. Ajattele sitä sanakirjana. Se määrittelee sanat, joita voit käyttää: "Product", "LocalBusiness", "FAQPage", "Review", "Event" ja noin 800 muuta tyyppiä. Google, Bing, Yahoo ja Yandex loivat Schema.orgin yhdessä vuonna 2011 yhteiseksi kieleksi verkkosisällön kuvaamiseen. Se kertoo, mitä voit kuvata. Se ei kerro, miten koodi kirjoitetaan.

JSON-LD, Microdata ja RDFa ovat syntakseja. Ne ovat muotoja, joita käytät kyseisen sanaston kirjoittamiseen verkkosivustosi koodiin. Ne ovat kilpailevia menetelmiä samaan työhön, eivätkä ne ole samanarvoisia.

Suhde on yksinkertainen: Schema.org on sanakirja, ja JSON-LD on kieli, jolla sitä kirjoitetaan. Schema.org määrittelee, että "Product"-tyypillä on ominaisuuksia, kuten "name", "price" ja "availability". JSON-LD on syntaksi, jonka avulla voit ilmaista nämä ominaisuudet siistissä koodilohkossa, joka on erillään HTML:stä.

Tässä on toimituksellinen tuomio, eikä tässä ole syytä olla diplomaattinen: käytä JSON-LD:tä. Piste.

Google suosittelee yksiselitteisesti JSON-LD:tä Search Central -dokumentaatiossaan. Syy on käytännöllinen. JSON-LD elää omassa skriptilohkossaan, täysin erillään sivusi näkyvästä HTML:stä. Voit lisätä, muokata tai poistaa sitä ilman riskiä, että se rikkoo asettelusi, CSS:si tai front-end-kehittäjäsi mielenterveyden. Microdata puolestaan vaatii, että kudot attribuutit suoraan HTML-tunnisteisiisi. Aina kun suunnittelija muuttaa sivupohjaa, on vaarana, että schema rikkoutuu äänettömästi. Kukaan ei huomaa mitään, ennen kuin rikastetut hakutulokset katoavat viikkoja myöhemmin.

JSON-LD on myös ainoa muoto, jonka voit syöttää Google Tag Managerin kautta. Tämä on elintärkeää, kun sinun on skaalattava schema sadoille sivuille ilman, että joudut tekemään kehityspyynnön (dev ticket) jokaisesta erikseen. Palaamme tähän työnkulkuun myöhemmin tässä oppaassa.

Jos kohtaat sivustollasi olemassa olevaa Microdataa, sinun ei tarvitse repiä sitä irti. Google lukee sitä edelleen. Mutta jokaisen uuden toteutuksen tästä eteenpäin pitäisi olla JSON-LD:tä. Vuonna 2026 ei ole olemassa sellaista teknistä skenaariota, jossa Microdata tai RDFa olisi parempi valinta uuteen asennukseen.

Googlen hierarkia: Mitkä schema-tyypit oikeasti tuottavat rikastettuja hakutuloksia?

Schema.org listaa yli 800 tyyppiä. Voit kuvata kaikkea lääketieteellisestä tilasta keilahalliin ja tulivuorenpurkaukseen. Sanasto on valtava, koska se on suunniteltu koko verkolle, ei vain Googlen hakutuloksille.

Tätä kukaan ei kerro sinulle tarpeeksi selvästi: Google palkitsee vain noin 32 näistä tyypeistä näkyvillä rikastetuilla hakutuloksilla. Entä loput? Google voi lukea niitä. Google saattaa käyttää niitä ymmärtääkseen sisältöäsi hieman paremmin. Mutta ne eivät tuota minkäänlaista näkyvää parannusta hakukoneiden tulossivuille (SERP). Ei tähtiä. Ei haitareita. Ei erityiskohtelua.

Tällä on merkitystä, koska toteutus vie aikaa. Jos vietät kaksi viikkoa merkitsemällä sivustosi "Organization"-schemalla odottaen jotain dramaattista SERP-muutosta, joudut pettymään. Organization-schemalla on semanttista arvoa, eli se auttaa Googlea ymmärtämään entiteettien välisiä suhteita, mutta se ei tuota yksinään näkyvää rikastettua hakutulosta.

Joten selvitetään tämä selkeän priorisointikehyksen avulla.

Taso 1: Vaikuttavimmat schema-tyypit (Näkyvät rikastetut hakutulokset)

Nämä ovat niitä tyyppejä, jotka laukaisevat suoraan paranneltuja SERP-ominaisuuksia. Jos luet tätä schema-opasta saadaksesi konkreettisia tuloksia, aloita tästä äläkä lopeta ennen kuin nämä on toteutettu jokaisella soveltuvalla sivulla.

Taso 2: Semanttisen arvon schema-tyypit (Ei näkyvää SERP-ominaisuutta)

Nämä tyypit auttavat Googlea ymmärtämään sivustosi rakennetta ja entiteettisuhteita. Ne kannattaa toteuttaa jossain vaiheessa, mutta ne eivät aiheuta visuaalisia muutoksia hakutuloksissasi.

Hyödyllinen nyrkkisääntö: toteuta jokainen 1. tason tyyppi, joka vastaa sisältöäsi, ennen kuin kosket mihinkään 2. tason tyyppiin. Paikallinen putkimies, jolla on täydellinen LocalBusiness-, FAQ- ja Review-schema, päihittää kilpailijan, joka käytti viikkoja Organization- ja WebPage-merkintöihin saamatta aikaan mitään näkyvää.

Vielä yksi asia on syytä sanoa suoraan. Tukemattomien tai 2. tason schema-tyyppien toteuttaminen ei vahingoita sinua. Google ei rankaise sinua sellaisen sisällön merkitsemisestä tyypeillä, joita se ei visuaalisesti palkitse. Mutta se ei myöskään auta SERP-näkyvyyttäsi, ja maailmassa, jossa toteutusaika on rajallinen, vaihtoehtoiskustannuksella on väliä. Keskity sinne, missä hyöty on todellinen.

Näin toteutat schema-merkinnän: Vaiheittainen tekninen työnkulku

On eri asia tietää, mitkä schema-tyypit ovat tärkeitä, kuin saada ne verkkosivustollesi rikkomatta mitään. Toteutusprosessilla on tietty järjestys, ja vaiheiden ohittaminen on syy siihen, miksi päädytään merkintöihin, jotka näyttävät hyvältä koodieditorissa, mutta eivät koskaan tuota yhtäkään rikastettua hakutulosta.

Tässä on kuusivaiheinen työnkulku, jota ammattimaiset teknisen SEO:n tiimit noudattavat. Se toimii riippumatta siitä, oletko merkitsemässä viisisivuista esitesivustoa vai 50 000 sivun verkkokauppakatalogia.

Vaihe 1: Auditoi olemassa oleva merkintäsi. Ennen kuin kirjoitat riviäkään JSON-LD:tä, tarkista, mitä sivustollasi on jo. Monet julkaisujärjestelmät ja teemat luovat schemaa automaattisesti taustalla. Esimerkiksi WordPress yhdessä Yoastin kanssa tuottaa oletuksena Article- ja BreadcrumbList-schemaa. Shopify syöttää Product-schemaa tuotesivuille. Jos lisäät oman merkintäsi olemassa olevan, automaattisesti luodun scheman päälle, luot samalle sivulle päällekkäisiä tyyppejä, ja Google joko jättää molemmat huomiotta tai antaa validointivirheitä. Aja tärkeimmät sivusi ensin Rich Results Test -työkalun läpi. Tiedä, mitä sieltä jo löytyy.

Vaihe 2: Tunnista kohdesivut ja yhdistä ne schema-tyyppeihin. Jokainen sivustosi sivu ei tarvitse schemaa, eikä jokainen sivu täytä saman tyypin vaatimuksia. Kartoita sivustosi sivupohjat aiemman osion 1. tason tyyppeihin. Tuotesivut saavat Product-scheman. Toimipaikkasivut saavat LocalBusiness-scheman. Blogikirjoitukset saavat Article-scheman. UKK-osiot saavat FAQPage-scheman. Palvelusivut, joilla on vaiheittaisia prosesseja, voivat saada HowTo-scheman. Ole tarkka. Tarvitset vain laskentataulukon, jossa on kolme saraketta (URL-malli, sivupohja, schema-tyyppi).

Vaihe 3: Valitse asennustapa. Tämä päätös määrittää, kuinka paljon jatkuvaa ylläpitoa otat harteillesi. Todellisia vaihtoehtoja on kolme, ja oikea valinta riippuu teknisistä resursseistasi ja skaalasta.

Jos käytät WordPressiä ja hallinnoit alle muutamaa sataa sivua, lisäosa hoitaa suurimman osan raskaasta työstä. Jos sinun täytyy puskea schemaa tuhansille tuote- tai toimipaikkasivuille ja kehitystiimilläsi on kuuden viikon jono, Google Tag Manager on ratkaisu. Jos sinulla on yksi etusivu ja yksi kriittinen laskeutumissivu, joiden on oltava ehdottoman täydellisiä, koodaa ne käsin ja siirry eteenpäin.

Vaihe 4: Kirjoita tai luo JSON-LD. Tässä varsinainen koodi luodaan. Voit kirjoittaa sen käsin, käyttää schema-generaattoria tai mukauttaa tämän oppaan seuraavassa osiossa olevia malleja. Valitsitpa minkä reitin tahansa, varmista, että jokainen valitsemasi tyypin pakollinen ominaisuus on mukana. Googlen dokumentaatio listaa pakolliset ja suositellut ominaisuudet jokaiselle tuetulle tyypille. Pakollisen kentän puuttuminen tarkoittaa, ettei rikastettua hakutulosta tule. Suositellun kentän puuttuminen tarkoittaa vähemmän kilpailukykyistä hakutulosta.

Vaihe 5: Validoi ennen julkaisua. Tästä vaiheesta ei voi joustaa. Älä koskaan työnnä testaamatonta schemaa tuotantosivustolle. Liitä JSON-LD-koodisi Rich Results Test -työkaluun koodinpätkänä. Korjaa jokainen virhe. Käsittele mahdollisimman monta varoitusta. Julkaise se sitten testiympäristöön (staging) ja testaa live-URL. Kooditason validointi ja URL-tason validointi saavat kiinni erilaisia ongelmia, erityisesti silloin, kun mukana on JavaScript-renderöintiä.

Vaihe 6: Julkaise ja seuraa. Vie schema livenä sivuille ja tarkkaile Google Search Consolen Parannukset-raportteja (Enhancements) seuraavien kahden tai neljän viikon ajan. Googlen täytyy ryömiä sivusi uudelleen ennen kuin uusi schema näkyy sen järjestelmissä. Jos tänä aikana ilmenee virheitä, Search Console ilmoittaa niistä. Käymme seurantaprosessin yksityiskohtaisesti läpi myöhemmin tässä oppaassa.

Välttämättömät JSON-LD-mallit: Local Business, Tuotteet ja UKK

Alla on kolme käyttövalmista JSON-LD-mallia. Kopioi ne, korvaa paikkamerkit omilla tiedoillasi, validoi ja julkaise. Jokainen malli sisältää koodin sisäisiä kommentteja, jotka merkitsevät pakolliset kentät ja varoittavat yleisimmistä validointivirheitä aiheuttavista virheistä.

LocalBusiness-schema

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "LocalBusiness", "name": "Yrityksesi Nimi", // Pakollinen "image": "https://example.com/photo.jpg", // Suositeltu "address": { // Pakollinen "@type": "PostalAddress", "streetAddress": "Esimerkkikatu 123", "addressLocality": "Helsinki", "addressRegion": "Uusimaa", "postalCode": "00100", "addressCountry": "FI" }, "geo": { // Suositeltu "@type": "GeoCoordinates", "latitude": 60.1699, "longitude": 24.9384 }, "telephone": "+358-9-123-4567", // Suositeltu "openingHoursSpecification": [ // Suositeltu { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"], "opens": "09:00", "closes": "17:00" } ], "url": "https://example.com", "priceRange": "$$" } </script>

Pakolliset kentät: name, address.
Yleinen virhe: Käytetään yleistä "@type"-arvoa "Organization" tietyn alatyypin, kuten "Restaurant", "Dentist" tai "LegalService", sijaan. Google suosii tarkinta mahdollista tyyppiä, joka kuvaa yritystäsi. Tarkista Schema.orgin LocalBusiness-alatyypit ja valitse sopivin.

Product-schema

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Product", "name": "Tuotteen Nimi Tähän", // Pakollinen "image": "https://example.com/product.jpg", // Pakollinen "description": "Lyhyt tuotekuvaus.", // Suositeltu "brand": { "@type": "Brand", "name": "Brändin Nimi" }, "offers": { // Pakollinen "@type": "Offer", "price": "49.99", // Pakollinen "priceCurrency": "EUR", // Pakollinen "availability": "https://schema.org/InStock", // Pakollinen "priceValidUntil": "2026-12-31", // Suositeltu "url": "https://example.com/product-page" }, "aggregateRating": { // Suositeltu "@type": "AggregateRating", "ratingValue": "4.5", "reviewCount": "87" } } </script>

Pakolliset kentät: name, image, offers (joka sisältää kentät price, priceCurrency ja availability).
Yleinen virhe: priceValidUntil -kentän poisjättäminen. Google Search Console antaa varoituksen jokaisesta tuotesivusta, josta tämä kenttä puuttuu. Varoitus ei estä rikastetun hakutuloksen näkymistä, mutta se tukkii Parannukset-raporttisi ja vaikeuttaa todellisten virheiden huomaamista. Aseta siihen nykyisen hintajakson päättymispäivä ja päivitä se, kun hinnat muuttuvat.

FAQPage-schema

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Mikä on palautuskäytäntönne?", // Pakollinen "acceptedAnswer": { // Pakollinen "@type": "Answer", "text": "Tarjoamme 30 päivän palautusoikeuden kaikille käyttämättömille tuotteille. Ota yhteyttä support@example.com aloittaaksesi palautuksen." } }, { "@type": "Question", "name": "Kuinka kauan toimitus kestää?", "acceptedAnswer": { "@type": "Answer", "text": "Vakiotoimitus kestää 3-5 arkipäivää Suomen sisällä. Pikatoimitus on saatavilla seuraavan päivän toimitusta varten." } } ] } </script>

Pakolliset kentät: Vähintään yksi Question, jolla on vastaava acceptedAnswer.
Yleinen virhe: FAQPage-scheman lisääminen sivulle, jossa ei ole näkyvää UKK-sisältöä. Tämä on suora reitti Googlen antamaan manuaaliseen rangaistukseen (manual action). Jokaisen schemassasi olevan kysymyksen ja vastauksen on näyttävä sanasta sanaan sivun näkyvässä sisällössä. Jos käyttäjät eivät näe UKK:ta, schema on harhaanjohtava, ja Google kohtelee sitä sen mukaisesti.

Yksi syntaksia koskeva huomio, joka pätee kaikkiin kolmeen malliin: yleisin JSON-LD-virhe on puuttuva pilkku ominaisuuden arvon jälkeen. JSON on tässä armoton. Yksittäinen puuttuva pilkku rikkoo hiljaisesti koko koodilohkon, ja sivusi latautuu selaimessa aivan normaalisti, mutta Google ei näe strukturoitua tietoa lainkaan. Validoi aina.

Toteutuksen skaalaus: Google Tag Managerin käyttö isojen sivustojen schemassa (Enterprise Schema)

CMS-lisäosat toimivat hyvin, kun sinulla on kourallinen sivupohjia ja hallittavissa oleva sivusto. Siinä vaiheessa, kun käsittelet satoja toimipaikkasivuja, tuhansia tuote-SKU:ita tai alustaa, jossa kehitystiimi käsittelee jokaista koodimuutosta kahden sprintin projektina, tarvitset erilaisen lähestymistavan.

Google Tag Manager (GTM) antaa sinun syöttää JSON-LD:tä mille tahansa sivustosi sivulle lähdekoodiin koskematta. Hallitset kaikkea GTM:n käyttöliittymästä: schema-mallia, dynaamisia arvoja ja sivuja, joilla se laukaistaan. Kun sinun on päivitettävä ominaisuus tai lisättävä uusi schema-tyyppi, julkaiset GTM-version sen sijaan, että tekisit kehityspyynnön.

Ennen kuin käymme asennuksen läpi, puututaan huolenaiheeseen, joka estää useimpia kokeilemasta tätä: näkeekö Google todella GTM:n kautta syötetyn scheman? Kyllä. Google on vahvistanut, että Googlebot renderöi JavaScriptiä, mukaan lukien Google Tag Managerin kautta syötetyt skriptit. GTM:llä julkaistu JSON-LD on ryömittävissä ja kelvollinen rikastettuihin hakutuloksiin. Tämä ei ole harmaa alue.

Tässä on vaiheittainen GTM-asennus:

1. Luo mukautettu HTML-tunniste (Custom HTML tag). Siirry GTM:ssä kohtaan Tunnisteet > Uusi > Mukautettu HTML. Tämä tunniste sisältää JSON-LD-mallisi.

2. Liitä JSON-LD-mallisi GTM-muuttujien paikkamerkeillä. Sen sijaan, että koodaisit kiinteästi arvoja, kuten tuotteen nimen tai hinnan, korvaa ne kaksinkertaisissa aaltosulkeissa olevilla GTM-muuttujilla. Esimerkiksi: "name": "{{DL - Product Name}}", jossa DL - Product Name on Data Layer -muuttuja, jonka määrität seuraavassa vaiheessa.

3. Luo Data Layer -muuttujat dynaamisille arvoille. Siirry kohtaan Muuttujat > Käyttäjän määrittelemät muuttujat > Uusi > Data Layer -muuttuja. Jokainen muuttuja hakee tietyn arvon sivustosi Data Layeristä (tietokerroksesta). Kehitystiimisi on puskettava nämä arvot Data Layeriin sivun latautuessa. Verkkokauppa-alustoilla monet näistä arvoista (tuotteen nimi, hinta, SKU, saatavuus) ovat jo Data Layerissä, jos Enhanced Ecommerce -seuranta on määritettynä.

4. Aseta laukaisin (trigger). Määritä, millä sivuilla tämän tunnisteen tulisi laueta. Käytä Page Path- tai Page URL -laukaisimia kohdentaaksesi tiettyihin sivupohjiin. Tuote-scheman kohdalla voit laukaista sen kaikissa URL-osoitteissa, jotka vastaavat muotoa /products/*. LocalBusiness-scheman tapauksessa muoto voi olla /locations/*. Ole tarkka. Scheman laukaiseminen väärällä sivutyypillä aiheuttaa validointivirheitä.

5. Esikatsele ja validoi. Käytä GTM:n esikatselutilaa (Preview) varmistaaksesi, että tunniste laukeaa oikein kohdesivuillasi. Ota sitten live-esikatselun URL-osoite ja liitä se Googlen Rich Results Test -työkaluun. Käytä URL-tarkistusmenetelmää, älä koodinpätkämenetelmää. Koska GTM syöttää scheman JavaScriptin kautta renderöintivaiheessa, koodinpätkätesti ei näe sitä. URL-testi näkee sen, koska se renderöi sivun samalla tavalla kuin Googlebot.

6. Julkaise. Kun validointi menee läpi puhtaasti, julkaise GTM-säilön versio. Seuraa Search Consolea seuraavien viikkojen ajan uusien parannusraporttien tai kohdistamiisi sivuihin liittyvien virheilmoitusten varalta.

GTM on järkevin ratkaisu monitoimipaikkaisille yrityksille, jotka tarvitsevat LocalBusiness-scheman 50 tai 500 sijaintisivulle, verkkokaupoille, joilla on suuret katalogit ja joiden tuotetiedot kulkevat jo Data Layerin kautta, sekä markkinointitiimeille, joiden on iteroitava schemaa odottamatta insinööriresursseja. Yksittäisille kriittisille sivuille, kuten etusivulle tai tärkeimmälle laskeutumissivulle, käsin koodaaminen antaa enemmän hallintaa ja poistaa JavaScript-renderöinnin riippuvuuden. Käytä molempia menetelmiä siellä, minne ne parhaiten sopivat.

Yksi asia, jota on syytä seurata tarkasti: GTM:llä syötetty schema on näkyvissä vasta JavaScriptin suorittamisen jälkeen. Jos Googlebot kohtaa renderöinnin aikakatkaisun tai GTM-säilösi latautuu hitaasti, schemaa ei välttämättä käsitellä. Varmista asennuksen jälkeen asia aina Rich Results Test -työkalun URL-tarkistuksella ja tarkista säännöllisesti Search Consolen Parannukset-raportit varmistaaksesi, että Google lukee asiat niin kuin oli tarkoitus.

Validointiprotokolla: Rich Results Test- ja Schema Validator -työkalujen käyttö

Olet kirjoittanut JSON-LD:n, valinnut julkaisutavan ja puskenut sen livenä sivuille. Nyt vuorossa on osa, joka erottaa rikastettuja hakutuloksia aidosti tuottavan scheman siitä schemasta, joka lojuu sivustollasi tekemättä mitään: validointi.

On olemassa kaksi virallista testaustyökalua, ja ne tekevät eri asioita. Niiden sekoittaminen, tai vain toisen käyttäminen, on syy siihen, miksi merkintävirheet voivat säilyä kuukausia kenenkään huomaamatta.

Google Rich Results Test (search.google.com/test/rich-results) tarkistaa, voiko Google lukea strukturoidun tietosi ja onko se kelvollinen rikastettuun hakutulokseen. Se arvioi vain niitä noin 32 schema-tyyppiä, joita Google aktiivisesti tukee. Jos syötät siihen Organization- tai WebPage-tyypin, se ilmoittaa merkinnän olevan kelvollinen, mutta "ei oikeutettu rikastettuihin hakutuloksiin" (not eligible for rich results). Se ei ole virhe; se tarkoittaa, että työkalu tekee juuri sen, mihin se on suunniteltu. Rich Results Test näyttää myös esikatselun siitä, miltä paranneltu listauksesi voisi näyttää, mikä on hyödyllistä sidosryhmien hyväksynnän saamiseksi.

Schema Markup Validator (validator.schema.org) tarkistaa merkintäsi koko Schema.org-spesifikaatiota vasten. Jokainen tyyppi, jokainen ominaisuus, jokainen sisäkkäisyyssääntö. Sitä ei kiinnosta, palkitseeko Google tyypin rikastetulla hakutuloksella. Sitä kiinnostaa, onko koodisi rakenteellisesti oikein sanastostandardin mukaan. Tämä työkalu huomaa ongelmat, jotka Rich Results Test sivuuttaa, kuten sellaisen ominaisuuden käytön, joka on olemassa Schema.orgissa, mutta jota Googlen alajoukko ei tunnista.

Käytä molempia. Aja ensin Rich Results Test varmistaaksesi, että Google palkitsee merkintäsi. Aja sitten Schema Markup Validator saadaksesi kiinni kaiken sen, minkä ensimmäinen työkalu sivuutti.

Tässä on testauksen tarkistuslista, joka toimii käytännössä:

Testaa aina live-URL, älä vain koodinpätkää. Tämä yksittäinen tapa pelastaa sinut yleisimmältä julkaisuvirheeltä: schemalta, joka validoituu täydellisesti koodinpätkänä, mutta ei koskaan renderöidy todellisella sivulla GTM-laukaisimen virheellisen määrityksen tai JavaScriptin latauskonfliktin vuoksi.

Suorituskyvyn seuranta ja virheiden korjaaminen Google Search Consolessa

Kun Google on ryöminyt sivusi uudelleen (mikä kestää yleensä muutamasta päivästä muutamaan viikkoon riippuen sivustosi ryömintätiheydestä), strukturoitu tieto alkaa näkyä Search Consolen vasemman sivupalkin Parannukset (Enhancements) -osiossa. Jokainen tuettu schema-tyyppi saa oman raporttinsa: Tuotteet, UKK, Murupolut, Näin teet -ohjeet ja niin edelleen. Jos Google löysi merkintäsi ja käsitteli sen, tyyppi näkyy täällä. Jos se ei löytänyt sitä, tyyppiä ei näy lainkaan, mikä on itsessään diagnostinen signaali.

Jokainen Parannukset-raportti jakaa sivusi kolmeen kategoriaan: Kelvollinen (Valid), Kelvollinen, sisältää varoituksia (Valid with warnings) ja Virhe (Error). Kelvolliset sivut tuottavat tai ovat oikeutettuja tuottamaan rikastettuja hakutuloksia. Sivut, joilla on varoituksia, ovat edelleen oikeutettuja, mutta niiltä puuttuu suositeltuja kenttiä. Virheitä sisältävät sivut on estetty rikastetuista hakutuloksista kokonaan, kunnes korjaat ongelman.

Tässä ovat virheet, joita kohtaat useimmin, sekä se, mikä ne oikeasti korjaa:

"Puuttuva kenttä: 'image'" (Missing field 'image') Product- tai Recipe-schemassa. Google vaatii kuvaominaisuuden näille tyypeille. Lisää suora URL-osoite korkealaatuiseen kuvaan. Älä käytä suhteellista polkua; käytä koko absoluuttista URL-osoitetta, joka alkaa https://.

"Puuttuva kenttä: 'priceValidUntil'" (Missing field 'priceValidUntil') Product-schemassa. Tämä näkyy varoituksena, ei virheenä. Lisää ISO 8601 -muodossa oleva päivämäärä (VVVV-KK-PP), joka edustaa nykyisen hinnan voimassaoloajan päättymistä. Jos hinnoittelullasi ei ole nimenomaista päättymispäivää, aseta se kuluvan kalenterivuoden loppuun ja päivitä vuosittain.

"Virheellinen enum-arvo kentälle 'availability'" (Invalid enum value for field 'availability') Product-schemassa. Saatavuusominaisuuden on oltava täydellinen Schema.org URL, kuten https://schema.org/InStock, ei tavallinen tekstimerkkijono, kuten "In Stock" tai "saatavilla". Tämä on muotoiluongelma, ei sisältöongelma.

"mainEntity-kenttä puuttuu tai on tyhjä" (mainEntity field is missing or empty) FAQPage-schemassa. UKK-merkinnässäsi on FAQPage-kääre, mutta ei Question-kohteita sen sisällä. Tämä tapahtuu yleensä silloin, kun CMS-lisäosa luo ulkorakenteen, mutta ei pysty täyttämään kysymyksiä dynaamisesti. Tarkista sivun renderöity lähdekoodi, älä vain lisäosan asetuksia.

Kun Search Console ilmoittaa virheestä, korjaa se, julkaise uudelleen ja käytä sitten Parannukset-raportin "Vahvista korjaus" (Validate Fix) -painiketta. Tämä käskee Googlea ryömimään kyseiset sivut uudelleen ja tarkistamaan merkinnän. Google käsittelee validointipyynnön muutaman päivän kuluessa ja päivittää raportin. Älä klikkaile painiketta toistuvasti; yksi pyyntö riittää. Kärsivällisyys on osa prosessia.

Tee näiden Parannukset-raporttien tarkistamisesta kuukausittainen tapa. Schema voi rikkoutua äänettömästi. Teemapäivitys, CMS-lisäosan päivitys, kehittäjä uudelleenjärjestelemässä sivupohjaa (refactoring): mikä tahansa näistä voi pyyhkiä pois tai korruptoida strukturoidun tietosi ilman, että kukaan sitä tarkoitti. Sivut latautuvat selaimessa hyvin. Rikastetut hakutulokset vain katoavat hausta. Tiedät asian vain, jos seuraat raportteja.

Manuaalisen rangaistuksen välttäminen: Ohjeet eettiseen ja turvalliseen scheman julkaisuun

Googlen dokumentaatio strukturoidusta tiedosta sisältää osion, jonka useimmat sivuuttavat nopeasti: Yleiset ohjeet strukturoidulle tiedolle (Structured Data General Guidelines). Tälle sivulle on haudattu säännöt, joiden rikkominen laukaisee manuaaliset rangaistukset (manual actions). Manuaalinen rangaistus ei ole hellä varoitus. Se tarkoittaa, että ihmistarkastaja Googlella päättää, että schemasi on harhaanjohtava, ja rangaistuksena on kaikkien rikastettujen hakutulosten poistaminen koko sivustoltasi. Ei vain rikkovalta sivulta. Koko verkkotunnukselta.

Itse säännöt ovat suoraviivaisia. Niiden noudattaminen vaatii enemmän kurinalaisuutta kuin teknistä osaamista.

Jokaisen strukturoidun tiedon osan on vastattava sivulla olevaa näkyvää sisältöä. Jos FAQPage-schemasi sisältää viisi kysymystä ja vastausta, näiden samojen viiden kysymyksen ja vastauksen on oltava sivulla vierailevan ihmisen luettavissa. Jos Product-schemasi kertoo hinnan olevan 49,99 €, tuon hinnan on näyttävä sivulla. Schema on kuvaus siitä, mitä on olemassa, ei toivelista siitä, mitä haluaisit Googlen näyttävän.

Älä merkitse sisältöä, joka on piilotettu käyttäjiltä. UKK-sisällön laittaminen display: none -CSS-lohkoon ja sen jälkeen FAQPage-scheman lisääminen sille on juuri sellaista toimintaa, joka laukaisee manuaalisen tarkistuksen. Sisällön on oltava saavutettavissa. Haitarityyliset UKK-osiot, jotka käyttäjät voivat laajentaa napsautuksella, ovat ok. Sisältö, joka on pysyvästi näkymätöntä, ei ole.

Älä käytä Review- tai AggregateRating-schemaa itsetehtyihin arvosteluihin. Googlen ohjeet kieltävät nimenomaisesti arvostelu-scheman silloin, kun arvosteltava entiteetti on sama entiteetti, joka hallitsee sivua. Et voi laittaa AggregateRating-schemaa omalle etusivullesi näyttääksesi viittä tähteä itsellesi. Arvostelujen on koskettava tiettyä tuotetta, palvelua tai sisältöä, ja niiden on oltava peräisin aidoista kolmannen osapuolen lähteistä. Keksityt arviot ovat nopein reitti manuaaliseen rangaistukseen.

Älä luo useita ristiriitaisia schema-lohkoja samalle entiteetille samalla sivulla. Jos CMS-lisäosasi tuottaa Product-schemaa ja koodaat lisäksi erillisen Product-lohkon eri arvoilla käsin, Google saa ristiriitaista tietoa. Parhaimmillaan se sivuuttaa molemmat. Pahimmillaan se merkitsee epäjohdonmukaisuuden virheeksi. Toteutustyönkulun alussa oleva auditointivaihe on olemassa nimenomaan tämän estämiseksi.

Pidä schemasi ajan tasalla. Product-schema, jossa on vuoden 2023 hinta ja saatavuustilana "InStock" (varastossa) tuotteelle, jonka valmistuksen lopetit viime vuonna, on harhaanjohtava. Tapahtuma-schema (Event), joka mainostaa jo mennyttä päivämäärää, on harhaanjohtava. Vanhentunut schema heikentää sekä Googlen että niiden ihmisten luottamusta, jotka klikkaavat rikastettuja hakutuloksiasi odottaen tarkkaa tietoa. Jos tuote loppuu varastosta, päivitä saatavuusominaisuus. Jos tapahtuma päättyy, poista Event-schema tai päivitä se seuraavaan ajankohtaan.

Kaikkien näiden sääntöjen taustalla oleva periaate on yksinkertainen: strukturoitu tieto on lupaus. Kerrot Googlelle: "Tämä on täsmälleen se, mitä käyttäjä löytää, kun hän päätyy tälle sivulle." Kun tuo lupaus pitää, Google palkitsee sinut parannetulla näkyvyydellä. Kun se ei pidä, Google poistaa tuon etuoikeuden.

Käsittele schema-merkintääsi samalla toimituksellisella tarkkuudella kuin itse sisältöäkin. Auditoi se neljännesvuosittain. Validoi se jokaisen sivustopäivityksen jälkeen. Seuraa sitä Search Consolessa kuukausittain. Palkinto – rikkaammat hakulistaukset, korkeammat klikkausprosentit ja kilpailuetu, jota suurin osa kilpailijoistasi ei ole vielä saavuttanut – on ylläpidon arvoinen. Ja jos olet epävarma siitä, onko nykyinen toteutuksesi puhdas, aja kymmenen tärkeintä laskeutumissivuasi Rich Results Test -työkalun läpi tänään. Tulokset kertovat sinulle täsmälleen, missä seisot.