Kuinka validoida strukturoitua dataa ilman Google-työkaluja

Strukturoidun datan validoinnista on tullut erikoisen riippuvaista Googleen suunnatuista työkaluista. Se on ymmärrettävää: monet tiimit lisäävät JSON-LD:tä, koska he haluavat laajennettuja hakutuloksia, ja Googlen testaustyökalut ovat tuttuja. Strukturoitu data ei kuitenkaan ole Googlen formaatti. Se on yleensä Schema.org-sanastoa käyttävää JSON-LD:tä, joka on upotettu HTML:ään, jota monet kuluttajat tulkitsevat ja jota oma julkaisutyönkulkusi ylläpitää.

Jos validoit vain hakukonenäkökulmasta, voit ohittaa perustavanlaatuisia ongelmia: virheellinen JSON, renderöinnin jälkeen katoava data, vanhentuneet tuotehinnat, ristiriitaiset kanoniset URL-osoitteet tai merkintä, joka on teknisesti validia mutta semanttisesti järjetöntä.

Parempi työnkulku lähtee standardeista. Validoi data datana, validoi sitten sanasto ja lopuksi sivu sellaisena kuin se on tuotannossa.

Mitä oikeastaan validoit?

“Strukturoitu data” ei ole yksi asia. Useimmilla verkkosivustoilla siinä on neljä kerrosta:

1. JSON-syntaksi — onko koodi jäsennettävissä?
2. JSON-LD-malli — laajeneeko se merkitykselliseksi linkitetyksi dataksi?
3. Schema.org-sanasto — ovatko tyypit ja ominaisuudet uskottavia?
4. Sivutason totuus — vastaako merkintä sitä, mitä käyttäjät ja indeksoijat näkevät?

Googlen työkalut keskittyvät enimmäkseen neljänteen kerrokseen sekä Googlen omiin laajennettujen hakutulosten kelpoisuusehtoihin. Hyödyllistä, kyllä. Kattavaa, ei.

Esimerkiksi tämä voi olla validia JSON-LD:tä ja silti heikkoa strukturoitua dataa:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

Tässä ei ole mitään rikki. Mutta jos näkyvällä sivulla on eri otsikko, ei tekijämerkintää ja viimeksi muokattu -päiväys, joka on ristiriidassa merkinnän kanssa, kyse on laatuongelmasta eikä syntaksiongelmasta.

Vaihe 1: Jäsennä JSON ennen kuin ajattelet SEO:a

Aloita tylsästä tarkistuksesta: voidaanko JSON jäsentää?

HTML:ään upotettu JSON-LD rikkoutuu usein pienten mallipohjavirheiden vuoksi:

• ylimääräiset pilkut lopussa
• escape-käsittelemättömät lainausmerkit tuotenimissä
• virheelliset rivinvaihdot merkkijonoissa
• puuttuvat aaltosulkeet ehdollisten kenttien jälkeen
• kahdentuneet script-lohkot layout-periytymisen vuoksi
• CMS-lisäosat, jotka tuottavat osittaisia objekteja

Paikallisiin tarkistuksiin et tarvitse SEO-alustaa. Käytä työkaluja, jotka ovat jo kehityspinossasi.

JavaScriptissä:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

CI:ssä pura script-sisällöt renderöidystä HTML:stä ja jäsennä ne JSON:ina. Tämä havaitsee monet ongelmat ennen kuin ne päätyvät tuotantoon.

Tärkeä pointti: tee tämä ennen mitään Schema.org-validointia. Sanastovalidaattori ei voi auttaa, jos data ei ole validia JSON:ia.

Vaihe 2: Tarkista JSON-LD:n käyttäytyminen, ei vain JSON-syntaksia

Validi JSON ei ole automaattisesti validia JSON-LD:tä. JSON-LD käyttää käsitteitä kuten @context, @type, @id ja graafisuhteet. Jos ne ovat virheellisesti muodostettuja, jäsentäjät voivat tulkita datasi eri tavalla kuin tarkoitit.

Varmista vähintään:

• jokaisessa lohkossa on asianmukainen @context
• ensisijaisilla entiteeteillä on selkeät @type-arvot
• toistuvat entiteetit käyttävät vakaita @id-arvoja siellä, missä siitä on hyötyä
• sisäkkäiset entiteetit liittyvät toisiinsa loogisesti
• taulukoita käytetään, kun useat arvot ovat mahdollisia

Suuremmilla sivustoilla vakaat tunnisteet ovat erityisen hyödyllisiä. Jos organisaatiosi esiintyy Article-, Product-, BreadcrumbList- ja FAQPage-datassa, saman @id-arvon käyttö auttaa kuluttajia ymmärtämään, että nämä viittaavat samaan entiteettiin eivätkä neljään toisiinsa liittymättömään organisaatioon, joilla on sama nimi.

Tyypillinen malli näyttää tältä:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

Tässä ei yritetä tehdä vaikutusta validaattoriin. Teet datastasi vähemmän monitulkintaista.

Vaihe 3: Validoi Schema.org-sanastoa vasten

Kun JSON ja JSON-LD-rakenne ovat kunnossa, tarkista sanasto.

Schema.org-validaattori on hyödyllinen, koska se testaa Schema.org-termejä vasten eikä yhden hakukoneen laajennettujen hakutulosten sääntöjä vasten. Se voi näyttää, tunnistetaanko ominaisuudet, tulkitaanko tyypit odotetusti ja ovatko sisäkkäiset rakenteet järkeviä.

Tässä vaiheessa löydät esimerkiksi tällaisia virheitä:

• publishingDate eikä datePublished
• imageUrl, kun odotetaan image-ominaisuutta
• Product-merkintä kategoriasivulla, joka ei ole tuote
• AggregateRating ilman merkityksellistä arvioitua kohdetta
• Person käytettynä bränditilille

Ole varovainen varoitusten kanssa. Schema.org on tarkoituksella joustava. Validaattori voi sallia ominaisuuden, josta ei ole hyötyä käyttötapauksessasi, tai varoittaa asiasta, joka on valinnainen. Käsittele validointia todisteena, älä tuomiona.

Käytännöllinen sääntö: jos ominaisuus auttaa konetta ymmärtämään sivua tarkemmin, pidä se. Jos se on olemassa vain siksi, että joku kopioi sen snippet-generaattorista, kyseenalaista se.

Vaihe 4: Vertaa merkintää näkyvään sisältöön

Hakukoneet ja muut datan kuluttajat suhtautuvat yleensä epäluuloisesti merkintään, joka ei vastaa sivua. Vielä tärkeämpää on, että käyttäjät ansaitsevat johdonmukaisuutta.

Vertaa kunkin strukturoidun datan tyypin kohdalla merkintää näkyvään sivuun:

Article ja BlogPosting

Tarkista, että otsikko, tekijä, julkaisupäivä, muokkauspäivä, kuva ja julkaisija ovat näkyvissä tai kohtuullisesti pääteltävissä. Jos julkaiset tekoälyavusteista sisältöä, strukturoitua dataa ei pidä käyttää epäselvän tekijyyden puhdistamiseen. Olemme kirjoittaneet erikseen siitä, miltä rehellinen tekoälystä kertominen pienellä verkkosivustolla näyttää, ja sama periaate pätee tässä: metadatan pitäisi selkeyttää, ei hämärtää.

Product

Tarkista nimi, hinta, saatavuus, valuutta, variantit, arviot ja arvostelumäärät. Tuotteiden strukturoitu data vanhenee erityisen helposti, koska hinnat ja varastotilanne muuttuvat CMS:n ulkopuolella.

LocalBusiness

Tarkista nimi, osoite, puhelinnumero, aukioloajat ja palvelualue. Jos alatunnisteesi kertoo yhtä ja JSON-LD toista, JSON-LD ei ole “parempi”. Se on ristiriitainen.

BreadcrumbList

Tarkista, että murupolun sijainnit vastaavat näkyvää murupolkua ja että URL-osoitteet ovat kanonisia, indeksoitavissa ja ilman tarpeettomia uudelleenohjauksia.

Tämä ei ole hohdokasta työtä. Se on myös se kohta, jossa monet strukturoidun datan ongelmat löytyvät.

Vaihe 5: Validoi renderöity sivu, älä mallipohjaasi

Monet sivustot luovat JSON-LD:tä JavaScriptin, tag managerien, personointikerrosten tai komponenttien hydraation kautta. Se tarkoittaa, että mallipohjatiedosto ei välttämättä edusta sitä, mitä indeksoija tai selain todella näkee.

Validoi renderöity HTML vähintään kolmessa tilassa:

• paikallinen kehityskoontiversio
• staging- tai esikatselu-URL
• tuotanto-URL

Käytä selaimen DevTools-työkaluja lopullisen DOM:n tarkastamiseen. Etsi application/ld+json ja kopioi täsmälleen se script-sisältö, joka on olemassa renderöinnin jälkeen. Jos palvelinrenderöity merkintä eroaa hydraation jälkeisestä merkinnästä, päätä, kumman version odotat kuluttajien lukevan.

Tarkista myös, kahdentuuko strukturoitu data. Kahdentuneet Article- tai Product-lohkot ovat yleisiä, kun sekä CMS-lisäosa että mukautettu komponentti tuottavat schemaa. Kahdentuminen ei aina ole kohtalokasta, mutta ristiriitainen kahdentuminen on ongelma: kaksi hintaa, kaksi tekijää, kaksi julkaisupäivää tai kaksi kanonista URL-osoitetta.

Tämä muistuttaa suorituskyky- ja diagnostiikkaraporttien lukemista: ensimmäinen tehtävä ei ole panikoida, vaan erottaa signaali kohinasta. Sama tapa auttaa, kun luet Lighthouse-raporttia panikoimatta — vaikka strukturoitua dataa itsessään ei pidä pelkistää yhdeksi pistemääräksi.

Vaihe 6: Tarkista tuotannon siirtotiedot

Strukturoitu data voi olla täydellistä lähdekoodissasi ja silti epäonnistua tuotannossa, koska sivu ei ole saavutettavissa sillä tavalla kuin oletat.

Tarkista:

• lopullinen tilakoodi on 200, ei soft 404
• kanoninen URL vastaa validoitavaa sivua
• uudelleenohjaukset ovat tarkoituksellisia ja vakaita
• robots-direktiivit eivät estä indeksointia siellä, missä indeksointia odotetaan
• HTML:ää ei korvata virhesivulla joillekin user agent -tunnisteille
• välimuistissa olevat sivut eivät tarjoile vanhentunutta JSON-LD:tä

Tässä HTTP-tarkastuksella on merkitystä. Jos tuotesivu ohjautuu kolmen URL-osoitteen kautta ennen kanoniseen kohteeseen päätymistä, validoi lopullinen sivu, älä ensimmäistä CMS:stä kopioitua URL-osoitetta. Raakamekaniikkaa varten oppaamme uudelleenohjausten ja HTTP-otsakkeiden virheenkorjauksesta tuotannossa on hyödyllinen kumppani.

Strukturoitu data ei elä tyhjiössä. Se kulkee otsakkeiden, uudelleenohjausten, välimuistin, kanonisten tagien ja robots-direktiivien mukana.

Vaihe 7: Lisää strukturoidun datan testit julkaisuprosessiisi

Manuaalinen validointi sopii yhdelle sivulle. Se ei skaalaudu satoihin tai tuhansiin URL-osoitteisiin.

Yksinkertainen automatisoitu testisarja voi havaita kalleimmat virheet:

• hae edustavia URL-osoitteita kustakin mallipohjatyypistä
• pura kaikki JSON-LD-lohkot
• jäsennä ne JSON.parse-metodilla
• varmista pakolliset kentät kullekin sivutyypille
• tarkista, että päivämäärät ovat valideja ISO 8601 -merkkijonoja
• tarkista, että URL-osoitteet ovat absoluuttisia ja kanonisia
• tarkista, että hinnat ja saatavuus ovat olemassa tuotesivuilla
• tarkista, etteivät kahdentuneet entiteetit ole ristiriidassa

Voit ajaa tämän CI:ssä mallipohjille ja aikataulutetusti tuotanto-URL-osoitteille. Tavoite ei ole todistaa, että jokainen laajennettujen hakutulosten ominaisuus tulee näkyviin. Kukaan hakukoneen ulkopuolella ei voi luvata sitä. Tavoite on pitää oma datasi tarkkana, jäsennettävänä ja johdonmukaisena.

<!-- tool-cta:start -->

💡 Kokeile tätä: Ennen kuin validoit skeeman logiikan, aja JSON-LD:si JSON Formatter -työkalun läpi, jotta löydät syntaksivirheet, jotka muuten rikkoisivat jokaisen myöhemmän tarkistuksen.

<!-- tool-cta:end -->

Standardit edellä -validoinnin tarkistuslista

Käytä tätä lyhyttä tarkistuslistaa ennen kuin kysyt, pitääkö hakukone sivusta:

• Onko jokainen JSON-LD-lohko validia JSON:ia?
• Sisältääkö jokainen lohko oikean @context- ja @type-arvon?
• Onko Schema.org-ominaisuudet kirjoitettu oikein?
• Vastaako merkintä näkyvää sisältöä?
• Ovatko päivämäärät, hinnat, arviot ja saatavuus ajan tasalla?
• Ovatko URL-osoitteet absoluuttisia, kanonisia ja saavutettavissa?
• Onko renderöity tuotantosivu sama sivu, jonka testasit?
• Ovatko kahdentuneet entiteetit tarkoituksellisia ja ristiriidattomia?

Jos voit vastata kyllä näihin kysymyksiin, olet tehnyt strukturoidun datan työn kestävän osan. Hakukohtaisesta testauksesta voi silti olla hyötyä myöhemmin, mutta sen pitäisi olla viimeinen yhteensopivuustarkistus, ei validointiprosessisi perusta.