Mis on Schema markup ja kuidas seda kasutada

Valid lehele sobiva schema tüübi, lood JSON-LD-koodi ja lisad selle veebilehele.

Kui ootad, et schema lisaks su enda ettevõtte nime juurde arvustustärnid, tasub kohe pidurit tõmmata. LocalBusiness-märgistus ei anna ettevõtte enda lehel avaldatud arvustustele sellist kuva.

Selles juhendis käin läbi kümme sammu vajaduse kaardistamisest kuni märgistuse hooldamiseni. Alustame sellest, mis schema üldse on.

Juhendi kümme sammu:

1. Kaardista märgistuse vajadus
2. Vali schema tüüp
3. Kaardista omadused sisule
4. Koosta JSON-LD kood
5. Kontrolli JSON-LD koodi ja lehe sisu
6. Lisa märgistus veebilehele
7. Testi avaldatud lehte
8. Paranda schema vead
9. Jälgi otsingutulemusi
10. Hoolda märgistust

Schema markup ja JSON-LD

Schema markup on siltide kogum, mille lisad oma veebilehe koodi. Sildid ütlevad Google'ile, mis asi lehel on mis: see number on hind, see tekst on arvustus, see aadress on su töökoja asukoht.

CMS-is ei pea sa tavaliselt JSON-LD-d igale lehele käsitsi koodi sisse kirjutama. Osa märgistusest tuleb platvormi, teema või SEO-plugina kaudu automaatselt.

• WordPress: Yoast SEO, Rank Math ja teised SEO-pluginad lisavad põhimärgistuse automaatselt. Täpsema JSON-LD saad lisada plugina, koodiploki või teema kaudu.
• Squarespace: platvorm lisab osa struktureeritud andmetest ise. Kohandatud JSON-LD saad paigutada lehe või saidi koodiväljale.
• Wix: põhimärgistus luuakse automaatselt ning lehe SEO seadetes saad schema väärtusi muuta või uue märgistuse lisada.
• Shopify: teema või rakendus lisab tavaliselt toote hinna ja laoseisu märgistuse. Kohandatud JSON-LD saab lisada teemakoodi.
• Webflow: JSON-LD lisatakse lehe või kogu saidi kohandatud koodi väljale.

Kontrolli enne uue koodi lisamist, mida CMS juba väljastab. Kaks sama toodet või ettevõtet erinevate andmetega kirjeldavat schema plokki võivad Google'ile vastuolulist infot anda.

JSON-LD on nende siltide vorming ja Google soovitab just seda. Kood läheb lehele eraldi plokina, nii et olemasolevat sisu ümber tõstma ei pea ja hiljem on seda lihtne parandada.

Rich result ehk rikastatud otsingutulemus on Google'i enda otsus. Korrektne märgistus ei taga selle kuvamist ega paremat positsiooni, kuid aitab Google'il lehe andmeid tõlgendada.

Mida Google 2025–2026 schema osas muutis?

Google ei lõpetanud Schema.org märgistuse arvestamist tervikuna. Ta eemaldas otsingust (Google Searchist) valitud vähe kasutatud rikastatud otsingukuvad.

2025. aasta juuni teade nimetas esimese rühma. Novembri jätkuteatele järgnesid 2026. aasta alguses järgmised tööriistamuudatused:

• Google Otsingust ja Rikastatud Tulemuste testist (Rich Results Test) eemaldati: Course Info, Claim Review, Estimated Salary, Learning Video, Special Announcement ja Vehicle Listing.
• 2026. aasta jaanuaris eemaldati: Practice Problem; Dataset jäi kasutusse andmekogumi otsingus (Dataset Search), mitte tavalises Google Otsingus.
• 2026. aasta mais lõpetati: FAQ rich result. Täpne ajalugu on Google'i dokumentatsiooni muudatuste logis.

See ei tähenda, et korrektne märgistus teeks lehele paha. Google kinnitas, et muudatus ei mõjuta positsioone ning nende tüüpide kasutus väljaspool Google Searchi jäi alles.

AI-otsingu mõju kohta pole Google nende eemalduste põhjal avaldanud mõõdetud järeldust. Schema võib endiselt anda masinale korrastatud konteksti, kuid rohkem nähtavust ei saa selle põhjal lubada.

Rich Results Test kontrollib ainult Google'i toetatud otsingukuvade kõlblikkust. Kui tahad kontrollida kõiki Schema.org tüüpe ja koodi ennast, kasuta Schema Markup Validatorit.

Kaardista märgistuse vajadus

Alusta Google Search Gallery'st, mis loetleb Google'i toetatud otsingukuvad. Schema.org on laiem sõnavara; kõik selle tüübid ei anna Google'is rich result'i.

Google'i dokumentatsioon näitab toetatud tüüpe. Vaata see üle enne, kui koodi kirjutama hakkad.

Nüüd vaatame, mis lehel juba olemas on. Kaardistamise saad ära teha neljas käigus:

1. Kontrolli Google'i tuge. Märgi üles ainult sinu sisuga sobivad Google'i Search Gallerys loetletud tüübid, näiteks Product tootelehel.
2. Vaata üle olemasolev märgistus. Otsi lähtekoodist ld+json, Microdata ja RDFa ning kontrolli ka renderdatud DOM-i. Testi live-URL-i Rich Results Testi ja Schema Markup Validatoriga.
3. Otsi varasemat märgistust (legacy markup). Varasem märgistuse kood võib viidata näiteks tootele, mida lehel enam ei müüda.
4. Kontrolli migratsioonijärgset seisu. Kontrolli pärast veebilehe uuendust või CMS-i vahetust, et märgistus jõudis uuele lehele.

Lõpuks peab sul olema kaks nimekirja: URL-id ja sisutüübid, mis vajavad uut märgistust, ning eraldi lehed, kus olemasolev schema vajab parandamist või eemaldamist.

Vali schema tüüp

Vali esmalt lehe põhisisule vastav schema tüüp Google’i dokumenteeritud kasutusjuhtude seast, seejärel erista Google’i rich result’ide jaoks toetatud tüübid muust schema.org sõnavarast.

Kasuta Google'i Search Galleryt, et leida lehe sisule vastav tüüp, ja kontrolli märgistust Schema Markup Validatoris.

Mõned levinud paarid:

• Tooteleht. Vali Product ning kontrolli eraldi Product snippets'i või Merchant listings'i nõudeid; hind ja laoseis ei ole igas kasutusjuhus sama väljakomplekt.
• Kohaliku teenuse leht. Kasuta sageli LocalBusiness-tüüpi; aadress ja lahtiolekuajad lisa siis, kui leht neid näitab ning valitud Google'i funktsioon neid vajab.
• Blogiartikkel. Kasuta tavaliselt Article-tüüpi ning kontrolli Google'i dokumentatsioonist autori, kuupäevade, pealkirja ja pildi soovitusi.
• Leivapuru (Breadcrumbs). Kasuta BreadcrumbListi, kui leht on osa selgest lehehierarhiast ja leivapuru on külastajale nähtav.

Koht, kus paljud eksivad: aetakse segamini kaks eri eesmärki.

Rich result Google'is

Google otsustab ise, kas kuvada toote hinda või leivapuru. Sa ei saa seda muuta, aga saad teha nii, et selleks tekiks võimalus. FAQ rich result pole enam toetatud ning enda ettevõtte arvustused ei tekita selle enda lehel LocalBusiness- või Organization-tärne.

Masinloetav selgus

Muud schema.org tüübid võivad kirjeldada lehe sisu masinloetavalt, kuid Google'i otsingukuva jaoks tasub lähtuda Search Galleryst. Ära luba kliendile erikuvamist tüübi põhjal, mida Google seal ei nimeta.

Kas sais Schema tüübi valitud? Järgmine küsimus on, millised omadused sellele tüübile lehe sisust kaasa panna.

Kaardista omadused sisule

Seo iga valitud schema omadus lehel nähtava sisuelemendiga, kontrolli et väärtus oleks ajakohane, ja jäta välja omadused, millele lehel selget vastet ei ole.

Tootelehel seo Product-tüübi offers.price lehel nähtava hinnaga ning lisa priceCurrency. Kohaliku teenuse lehel peab LocalBusiness-tüübi aadress vastama avalikul lehel näidatule.

Article (artikli schema) puhul seo esmalt artikli pealkiri lehel nähtava pealkirjaga. Enne koodi loomist võrdle lehe ja JSON-LD väärtusi näiteks nii:

• Hind: Kui tootelehel on 35 €, aga JSON-LD offers.price väärtus on 30, kasuta märgistuses lehel nähtavat hinda ja lisa valuutaks EUR.
• Lahtiolekuajad: Kui lehel muudetakse tööaega, uuenda sama info ka openingHoursSpecification väärtustes.

Kontrolli eraldi ettevõtte aadressi ja telefoninumbrit. Mõlemas kohas peab olema sama ajakohane väärtus.

Ära täida schema’t väljadega ainult selleks, et kood paistaks pikem. Jäta omadus välja, kui selle kohta pole lehel nähtavat ja ajakohast infot.

Iga märgistuse väide peab vastama lehel nähtavale infole. Google peab saama sama väidet lehelt kontrollida.

Koosta JSON-LD kood

Ära alusta tühjast koodiplokist. Kasuta tehisintellekti abi, et schema kood luua. Ütle lihtsalt, et vajad Schema koodi näiteks tootele, teenusele või oma ärile. Anna AI-le valitud schema tüüp ja lehel nähtavad andmed, seejärel kontrolli mustandit Google Rich Results Testiga.

Kogu enne genereerimist ainult valitud schema tüübi ja lehe jaoks vajalikud andmed. Kõik allolevad väljad ei ole igale tüübile kohustuslikud:

• nimi, kirjeldus ja kanooniline URL
• lehel kasutatavad pildid
• hind, saadavus või hinnakiri
• aadress ja lahtiolekuajad
• autor, kuupäev või nähtavad arvustused

Product ei vaja autori välja ja Article ei vaja laoseisu. Väiksem, täpne sisend annab puhtama mustandi kui pikk nimekiri tühjadest omadustest.

AI võib teha esmase JSON-LD mustandi. Valitud rich result'i nõutud ja soovituslikud omadused määrab siiski Google'i vastava funktsiooni dokumentatsioon.

Töö käib kolmes sammus:

1. Ütle, millist schema tüüpi vajad ja millise lehe jaoks.
2. Anna oma kasutatavale AI-le lehel nähtavad andmed ning palu puuduv info enne genereerimist üle küsida.
3. Palu väljundiks üks JSON-LD plokk, ilma väljamõeldud väärtusteta.

Hea sisend ütleb otse, et tühjad või lehel kinnitamata omadused tuleb välja jätta. Näiteks peab Producti name olema sama nimi, mis tootelehel.

Kopeeritav AI-sisend

Loo Article-tüüpi JSON-LD ainult allpool antud avalikul lehel nähtavate andmete põhjal. Ära mõtle väärtusi välja. Küsi enne puuduv nõutud info üle ja jäta kinnitamata soovituslikud omadused välja. Väljasta üks <script type="application/ld+json"> plokk. Kontrolli välju Google'i Article dokumentatsiooni järgi.

Lehe URL: [URL]
Pealkiri:
Autor: [nimi ja autori URL]
Avaldamise kuupäev: [YYYY-MM-DD]
Muutmise kuupäev: [YYYY-MM-DD]
Pildi URL: [avalik pildi URL]

Täielik Article-näide näeb välja nii:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "ASENDA: artikli nähtav pealkiri",
  "image": [
    "https://example.ee/ASENDA-pilt.jpg"
  ],
  "datePublished": "2026-01-15",
  "dateModified": "2026-01-15",
  "author": {
    "@type": "Person",
    "name": "ASENDA: autori nimi",
    "url": "https://example.ee/autor/ASENDA"
  },
  "mainEntityOfPage": "https://example.ee/ASENDA"
}
</script>

Asenda kõik näidisväärtused lehel nähtava infoga. Pildi ja autori URL-id peavad olema avalikult ligipääsetavad.

AI loodud JSON-LD on mustand. See võib olla süntaktiliselt korrektne, kuid kasutada vale tüüpi, lisada lehel puuduva omaduse või jätta Google'i nõutud välja märkamata.

Võrdle tulemust Google Search Centrali valitud rich result’i dokumentatsiooniga. Seejärel sisesta kood Google Rich Results Testi ja paranda vead enne veebilehele lisamist.

Kontrolli JSON-LD koodi ja lehe sisu

Enne paigaldamist kontrolli JSON-i süntaksit, valitud Google’i rich result’i jaoks nõutud välju ning seda, kas kõik schema väited on avalikul lehel nähtavad ja ajakohased.

Alusta süntaksist. Katkine jutumärk, koma või sulg võib muuta terve JSON-LD ploki loetamatuks.

Google Search Centrali dokumentatsioonis erista kahte asja:

• Nõutud väljad valitud rich result’i jaoks
• Soovituslikud väljad, mis annavad lisateavet, kuid mille puudumine ei ole viga

Kasuta Rich Results Testi Google'i toetatud otsingukuvade kontrolliks ja Schema Markup Validatorit kogu schema.org märgistuse kontrolliks. Veendu ka, et lehte ei blokeeri robots.txt, noindex ega sisselogimine.

Tehniliselt korrektne kood võib siiski kirjeldada valet infot. Võrdle märgistuse hinda, aadressi, saadavust, kuupäevi ja pildi URL-e avaliku lehega; pildid peavad olema Google'ile ligipääsetavad.

Näiteks 30 €/h võib validaatoris veatult läbi minna, kuigi hinnakirjas on teenuse hind juba 35 €/h. Selline vastuolu vajab parandamist ka siis, kui tööriist rohelist tulemust näitab.

Enne paigaldamist kontrolli neid kolme veatüüpi:

• vigane JSON-i süntaks
• puuduv valitud rich result’i jaoks nõutud väli
• aegunud või lehel nähtamatu väärtus

Paranda vead selles järjekorras. Esmalt peab tööriist koodi lugema, seejärel saad kontrollida välju ja nende vastavust sisule.

Lisa märgistus veebilehele

Lisa valideeritud JSON-LD HTML-i <head>- või <body>-ossa või CMS-i koodiväljale. <head> on sageli puhtam valik, kuid Google saab korrektset JSON-LD-d lugeda mõlemast.

Lihtne paigutus näeb välja nii:

<head>
  <!-- lehe muu kood -->
  <script type="application/ld+json">
    { ... }
  </script>
</head>

Asenda kolm punkti päris JSON-LD objektiga. Kui CMS lisab script-ploki <body>-ossa, on see samuti sobiv.

Vali paigaldusviis selle järgi, mida saad ise muuta ja kui tihti leheandmeid uuendad:

• Käsitsi lisamine sobib üksikule stabiilsele lehele, kui saad HTML-i või mallifaili muuta.
• CMS-i väli või plugin sobib siis, kui platvorm pakub vajalikku schema tüüpi ja seadistus on sulle kättesaadav.
• Automaatne ühendus andmeallikaga aruta veebiarendajaga läbi siis, kui e-poe hind või saadavus tuleb andmebaasist.

Käsitsi lisamine võib vältida tasulise plugina kulu. Näiteks tuleb LocalBusiness märgistuses aadressi või lahtiolekuaegade muutmisel muuta ka JSON-LD-d.

Kontrolli CMS-i koodivälja, plugina või rakenduse seadistust. Mitu schema plokki on lubatud, kuid sama toodet või ettevõtet erineva hinna, aadressi või saadavusega kirjeldavad plokid lähevad vastuollu.

Arendajat vajad siis, kui JSON-LD peab tulema mallist, andmebaasist või serveris loodud koodist. Sama kehtib siis, kui sul puudub ligipääs lähtekoodile või pluginate seadetele.

Kui arendaja seob JSON-LD ja lehesisud sama andmeallikaga, võivad väärtused püsida ühtsed. Kontrolli märgistust ka pärast leheandmete muutmist.

Käsitsi lisatud koodi puhul lisa schema uuendamine samasse kontrollnimekirja, kus muudad lehe sisu. Hinna või aadressi parandamine on lõpetatud alles siis, kui mõlemad kohad näitavad sama väärtust.

7. Testi avaldatud lehte

Testi pärast avaldamist Google'i toetatud otsingukuva Rich Results Testis. Kõigi Schema.org tüüpide koodi kontrolli Schema Markup Validatoris; seejärel paranda leitud vead.

Kood on lehel. Aga see, mis paistab sinu koodiredaktoris, ei ole veel see, mida Google avaldatud lehelt päriselt kätte saab.

Seepärast kontrolli live-URL-i eraldi. Tee seda enne võimalikku indekseerimise taotlust, sest taotlus ei paranda vigast märgistust ega taga kiiret töötlemist.

Tee seda alati selles järjekorras:

1. Vali tööriist eesmärgi järgi. Rich Results Test kontrollib Google'i toetatud otsingukuvade kõlblikkust. Schema Markup Validator kontrollib kõiki Schema.org tüüpe; sisesta avaldatud URL, et testida renderdatud lehte.
2. Kontrolli, et märgistus tuvastatakse. Tööriist peab näitama sama schema tüüpi ja needsamu omadusi, mille sa lehele lisasid.
3. Loe probleemid üle. Kriitiline viga takistab rich result'i kõlblikkust; mittekriitiline probleem võib vähendada märgistuse täielikkust ning vajab valitud tüübi dokumentatsioonist kontrollimist.
4. Paranda ja testi uuesti. Korda kontrolli, kuni kriitilisi vigu pole ning mittekriitilised probleemid on läbi vaadatud.
5. Vali sobiv uuesti töötlemise viis. Olulise äsja parandatud URL-i puhul võid kasutada URL Inspectionit. Paljude lehtede korral hoia sitemap ajakohane.

Kehtiv märgistus on nagu korrektselt täidetud taotlus: see annab sulle õiguse järjekorda seista, otsuse teeb ametnik. Lisaks kehtib reegel, et märgistada tohib ainult sisu, mis on lehel kasutajale reaalselt nähtav.

8. Paranda schema vead

Paranda schema vead tähtsuse järjekorras ja testi avaldatud URL-i pärast iga muudatust.

Alusta vigadest, mis peatavad töötluse:

• JSON-i süntaks: jutumärgid, komad ja sulud.
• Nõutud omadused: rich result'i dokumentatsiooni järgi.
• Nähtamatu sisu: väited, mida avalikul lehel pole.
• Aegunud väärtused: hind, kuupäev, saadavus või toode.
• Vastuolulised plokid: sama üksuse erinevad andmed.
• Renderdus: renderdatud HTML-ist puuduv märgistus.

Raskema vea leidmiseks liigu nii:

1. Võrdle lähtekoodi ja renderdatud HTML-i.
2. Tee kontroll (crawl), et leida URL-i- või malliviga.
3. Kontrolli käsitsi teenus- ja tootelehti.
4. Erista ligipääsu, indekseerimise ja serveerimise probleemid.

Korduva mallivea korral kontrolli malli, pluginaid ja avaldatud HTML-i SEO auditi juhendi järgi või võta minuga ühendust. Vaatame koos, kust parandamist alustada.

Klaasiprofide tulemus tuli laiemast SEO-uuendusest, kuhu kuulus rohkem kui schema parandamine. Pärast parandusi mõõda Search Console'is, kas kehtivate üksuste arv, näitamised ja klikid liiguvad.

9. Jälgi otsingutulemusi

Jälgi Google Search Console'is rich result'i näitamisi, klikke ja kehtivusolekut. Vaata muutust kogu kodulehe optimeerimise kontekstis, mitte schema eraldiseisva tulemusena.

Ava Google Search Console'is Performance > Search results ning vaata näitamisi, klikke ja CTR-i. Tootetulemuste jaoks kasuta Search Appearance’i filtreid Product snippets ja vajaduse korral Merchant listings. Need filtrid ilmuvad alles siis, kui saidil on vastava otsingukuva näitamisi.

Kontrolli ka rich result'i aruandeid. Need rühmitavad üksused põhiolekutesse Valid ja Invalid; üksikute probleemide juures eristatakse kriitilisi ning mittekriitilisi puudusi.

Pärast parandusi jälgi, kas Valid üksuste arv kasvab ja Invalid üksuste arv väheneb. Muutuse kiirus sõltub sellest, millal Google lehed uuesti roomab ja andmed töötleb.

Liikluse muutust vaata laiemas SEO kontekstis. Samal ajal muudetud sisu, siselingid, pealkirjad ja indekseerimine võivad mõjutada näitamisi ning klikke rohkem kui schema üksinda.

• Invalid: vähemalt üks kriitiline probleem takistab rich result'i kõlblikkust.
• Valid: kriitilisi probleeme pole, kuid üksusel võib olla mittekriitilisi puudusi.

10. Hoia Schema märgistus ajakohane

Uuenda JSON-LD-d alati koos nähtava sisuga. Märgistus vajab eraldi ülevaatust ka pärast redesigni, CMS-i vahetust, mallimuudatust või plugina uuendust.

Hoia samas töövoos ajakohasena:

• hinnad ja saadavus
• aadress, telefon ning lahtiolekuajad
• sündmuste kuupäevad
• toote staatus ja lehe URL

Käsitsi lisatud kood ei saa sisumuudatusest ise teada. Kui uuendad ainult lehte, jääb Google’ile antav struktureeritud info vanaks.

Redesigni või tehnilise uuenduse järel veendu, et märgistus pole kadunud, dubleeritud ega renderdatud lehest välja jäänud.

Sama hooldusreegel muutub eriti tähtsaks e-poes, kus hinnad, laoseis ja variandid võivad muutuda iga päev.

E-poe struktureeritud andmed

E-poes tasub Product- ja Offer-märgistus siduda sama andmeallikaga, kust tulevad lehel nähtav hind ja laoseis. Nii ei jää JSON-LD pärast muudatust vanaks.

Product kirjeldab toodet ja selle sees olev Offer müügitingimusi, näiteks hinda, valuutat ning saadavust. Variantide puhul koondab ProductGroup seotud tooted üheks grupiks.

Kontrolli iga toote ja variandi puhul vähemalt SKU-d, hinda ning saadavust. Kui automaatset seost pole, lisa schema kontroll kohe hinna või laoseisu muutmise töövoogu.

Google'i jaoks kontrolli eraldi Product snippets'i ja Merchant listings'i nõudeid. Toote põhiandmed jagunevad nii:

• Product: toote nimi, kirjeldus, pilt ja SKU.
• Offer: Product-objekti sees olev hind, valuuta, saadavus ja pakkumise URL.
• ProductGroup: variantide grupp ja neid eristavad omadused.
• Review või AggregateRating: ainult tootelehel päriselt kuvatavad arvustused ja hinnangud.

Lühike Product- ja Offer-seos näeb välja nii:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "ASENDA: toote nimi",
  "image": "https://example.ee/ASENDA-pilt.jpg",
  "sku": "ASENDA-SKU",
  "offers": {
    "@type": "Offer",
    "url": "https://example.ee/ASENDA-toode",
    "priceCurrency": "EUR",
    "price": "35.00",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Asenda näidisväärtused sama toote andmetega, mida ostja lehel näeb.

Otse ostetaval tootelehel peab märgistus kirjeldama sama toodet, hinda ja saadavust, mida ostja ekraanil näeb. Variatsioonide puhul kontrolli iga variandi väärtusi eraldi.