Veliko lastnikov spletnih strani se trudi z vsebino, meta opisi in hitrostjo strani – a spregleda en tehničen detajl, ki lahko odloča o tem, ali jih Google sploh razume: strukturirani podatki.
Če jih vaša stran nima, Googlu otežujete razumevanje tega, kaj ponujate. Posledično vaša vsebina morda ne izstopa v iskalniku – tudi če je kakovostna.
V tem zapisu vam bomo na praktičnem primeru, ki smo ga izvedli na seo-praktik.si, pokazali:
kaj so strukturirani podatki (schema markup),
kako jih implementirati v realnem primeru (spodaj je prikazan primer kako smo jih implementirali na našem ceniku SEO storitev),
katere tipe označevanja Google prepozna in nagrajuje,
ter kako preveriti, ali ste jih implementirali pravilno.
Če želite, da vaša vsebina ne ostane »nevidna« za iskalnike, vam bo ta vodič pokazal, kako strukturirani podatki postanejo vaša konkurenčna prednost.
Kaj so strukturirani podatki (schema markup) in zakaj jih Google sploh potrebuje
Če želimo, da Google razume, kaj pravzaprav ponujamo na svoji spletni strani, mu moramo informacije predstaviti tako, da jih zanesljivo prepozna. Klasična HTML vsebina ni vedno dovolj – iskalnik sicer vidi besedilo, a pogosto ne razume vloge posameznih elementov.
Tukaj vstopijo strukturirani podatki (ang. structured data), zapisani v obliki schema markup. Gre za poseben zapis v jeziku, ki ga razumejo iskalniki (najpogosteje v obliki JSON-LD) s katerim lahko Googlu natančno povemo:
kateri del strani je izdelek (Product),
katera informacija je cena, opis ali ocena,
katera vsebina je storitev (Service),
kateri odsek je pogosto vprašanje (FAQ),
in katera stran je npr. članek (Article) ali lokalna storitev (LocalBusiness).
Zakaj Google potrebuje strukturirane podatke
Google potrebuje strukturirane podatke, ker želi prikazati bolj bogate rezultate (rich results) in ker pri milijardah strani preprosto ne more več ugibati, kaj posamezna vsebina pomeni. Če mu pomagate s schema mark up označevanjem, vam to lahko povrne v obliki:
prikaza vaše spletne strani z dodatki (npr. cene, FAQ izpisi, ocene, slika),
večje vidnosti v rezultatih,
višjega CTR (click-through-rate),
in potencialno boljših uvrstitev (ker lažje zadovolji t.i. search intent).
Katere vrste strukturiranih podatkov so najbolj pomembne za SEO
Schema.org ponuja več sto različnih tipov strukturiranih podatkov, a v praksi jih je za SEO namenov nekaj, ki pokrivajo večino uporabnih primerov. Ključnega pomena je, da ne označujete vsega “za vsak slučaj”, ampak ciljno – glede na tip vsebine, ki jo ponujate. Spodaj so tisti tipi strukturiranih podatkov, ki jih najpogosteje uporabite na straneh, ki jih želite SEO-optimizirati:
✅ Product Uporablja se za: izdelke v spletnih trgovinah, pakete storitev s fiksnimi cenami (kot boste videli v nadaljevanju, npr. SEO paketi na seo-praktik.si), jasno definirane ponudbe. ➡ Pokaže: ime izdelka, cena, valuta, zaloga, ocena.
✅ Service Idealno za: ponudnike storitev brez fiksnih izdelkov, storitve po meri, svetovanja, mentoriranja, razpon cen in opis ponudnika. ➡ Pokaže: opis storitve, ponudnik, geografska pokritost, cene.
✅ FAQPage Odličen za: strani z pogosto zastavljenimi vprašanji, podporne strani in prodajne strani z odgovori. ➡ Lahko povzroči prikaz vprašanj/odgovorov neposredno v SERP-u.
✅ BreadcrumbList Uporabljamo, če stran vsebuje krušne drobtine (npr. Domov > SEO storitve > Cenik). ➡ Google jih uporabi za prikaz poti uporabnika v SERP.
✅ Article (ali BlogPosting) Za: vsebine z novičarsko ali blog naravo, članke, ki želijo rangirati na informativne poizvedbe. ➡ Pokaže naslov, datum objave, avtorja, sliko.
✅ LocalBusiness Pomemben za: podjetja z lokalno prisotnostjo (npr. SEO svetovalec v Ljubljani), prikaz v lokalnih rezultatih (Google Maps, 3-pack). ➡ Pokaže lokacijo, odpiralni čas, kontaktne podatke.
Kako strukturirani podatki vplivajo na prikaz v Googlu (rich results, CTR, pozicije)
Strukturirani podatki ne vplivajo neposredno na to, na katerem mestu se bo vaša stran prikazala v iskalniku – vplivajo pa na to, kako se prikazuje, in to lahko naredi ogromno razliko pri stopnji klikov (CTR).
Ko Google zazna pravilno implementirane schema oznake, lahko vašo stran prikaže z dodatki, ki takoj izstopajo v rezultatih:
zvezdice (ocene),
cena izdelka,
seznam vprašanj (FAQ),
prikaz avtorja in datuma članka,
ali navigacijska pot (breadcrumb).
Zakaj je to pomembno
Ker uporabnik ne klikne vedno najvišje uvrščene strani. Klikne tisto, ki najhitreje odgovori na njegovo vprašanje ali mu daje občutek, da je relevantna. In točno tukaj strukturirani podatki naredijo razliko.
Primer iz prakse:
Na strani seo-praktik.si smo z označevanjem naših SEO paketov kot “Product” omogočili, da Google razume, da gre za konkretno ponudbo z jasno ceno. To poveča verjetnost prikaza cene neposredno v SERP-u (več v nadaljevanju).
Primer: kako smo strukturirali SEO cenik na Seo-Praktik.si
Namesto teoretičnega opisovanja, vam v tem poglavju pokažemo dejanski primer implementacije strukturiranih podatkov, ki smo ga izvedli na naši strani cenik seo-praktik.si.
Na strani s cenikom SEO storitev smo imeli dva ključna izziva:
Ponujamo tako fiksne pakete kot tudi storitve po meri
Struktura tabele je prijazna za bralca, ne pa nujno tudi za iskalnike
Kaj smo naredili
🔹 Korak 1: Izbrali prave tipe strukturiranih podatkov
Fiksni SEO paketi → označeni z Product
Storitev po meri (npr. mentorstvo, svetovanje, sparing partnerstvo) → označene z Service
🔹 Korak 2: Pripravili strukturirano JSON-LD kodo
Za vsak posamezni paket in storitev smo ustvarili svojo Product ali Service entiteto z elementi, kot so:
name (ime storitve)
description (opis)
price in priceCurrency
availability
url (vsi vodijo na glavno cenik stran)
🔹 Korak 3: Kodo smo dodali neposredno na stran
Z uporabo HTML widgeta v WordPress urejevalniku Elementor smo celoten script type="application/ld+json" blok prilepili na dno strani.
🔹 Korak 4: Testirali smo s pomočjo Google orodij
✅ Rich Results Test – ki, je zaznal Product in Service
✅ Schema.org Validator – ki je zaznal, da je naše schema mark up označevanje bilo brez sintaktičnih napak
dobili smo sicer opozorilo za manjkajočo sliko (image) in neobvezna polja (a ti obvestili nista kritični)
JSON-LD, Microdata ali RDFa – katero obliko izbrati in zakaj
Ko se odločate za implementacijo strukturiranih podatkov, imate na voljo več zapisov. Vsi temeljijo na istem viru – Schema.org – a se razlikujejo po načinu vključitve v HTML kodo strani.
Spodaj so tri glavne oblike, ki jih podpira Google:
JSON-LD (JavaScript Object Notation for Linked Data)
Ta oblika je priporočena s strani Googla. To je tudi oblika, ki jo uporablja seo-praktik.si.
Microdata je zapis vgrajen neposredno v HTML elemente.
Slabosti:
Koda postane manj pregledna
Uporaben za zelo enostavne strani, ne za večje strukture
Primer:
htmlKopirajUredi<div itemscope itemtype="https://schema.org/Product">
<span itemprop="name">Napredni SEO paket</span>
<span itemprop="price">690</span>
</div>
RDFa (Resource Description Framework in Attributes)
Ta format je redko uporabljen v SEO svetu, bolj akademsko in tehnično orodje za semantični splet. Google sicer podpira, a ni priporočena izbira za spletne strani, ki ciljajo na prikaz v SERP.
Če ciljate na preglednost, enostavno implementacijo in skladnost z Googlovimi priporočili, potem uporabite format JSON-LD.
Kako preverite ali so strukturirani podatki pravilno implementirani
Tudi če ste natančno sledili dokumentaciji Schema.org, to še ne pomeni, da jih bo Google pravilno prebral. Zato je testiranje implementacije nujen korak pri vsaki uporabi strukturiranih podatkov.
✔️ Prikazuje, ali je vaša schema primerna za prikaz v “bogatih rezultatih” ✔️ Zazna napake, opozorila in katere entitete so prisotne ✔️ Omogoča testiranje URL-ja ali neposredno prilepljene kode
✔️ Podpira vse tipe strukturiranih podatkov, ne samo tiste, ki jih uporablja Google ✔️ Dober za sintaktično preverjanje in obširnejšo validacijo ✔️ Prikazuje lokacijo napake v kodi
Kritične in nekritične napake – kako jih razumeti – Primer iz naše implementacije na ceniku:
Google je prikazal opozorilo: Manjkajoče polje image za Product
Hkrati pa je validacija pokazala, da so ključna polja (name, price, description) pravilno vključena
To opozorilo je pomenilo, da je stran še vedno primerna za prikaz rich snippeta, a lahko z dodajanjem slike povečamo možnosti, da bo izstopala.
Pogoste napake pri uporabi strukturiranih podatkov
Strukturirani podatki so za marsikoga tehničen svet, kjer hitro pride do napak – še posebej, ko zadeve kopiramo z drugih strani ali vstavljamo po principu “nekaj bo že prijelo”.
Tudi na seo-praktik.si smo se zavedali, da lahko že majhna napaka povzroči, da Google našega schema zapisa sploh ne prepozna. Zato smo si vzeli čas in sestavili seznam najpogostejših napak, ki jih opažamo tako pri strankah kot tudi na večjih spletnih straneh.
Ena izmed najpogostejših težav je napačno uporabljen tip označevanja. Denimo, ko nekdo za storitev, kot je SEO mentorstvo, uporabi Product namesto Service. Google morda sicer razume osnovno strukturo, a jo raje ignorira, ker mu ni povsem jasno, s čim ima opravka.
Pogosto se dogaja tudi, da pri Product tipu manjkajo ključna polja – na primer priceCurrency, ki Googlu pove, v kateri valuti je podana cena. Brez tega lahko struktura izgubi pomen ali je preprosto nepopolna za prikaz v bogatem rezultatu.
Še ena pogosta težava je tehnične narave – nepravilno zapisani JSON-LD bloki. Manjkajoča vejica ali napačen narekovaj lahko pomeni, da schema sploh ne deluje, čeprav je vizualno na prvi pogled videti v redu. Zato vedno svetujemo: testirajte, preden objavite. Orodja, kot sta Schema Validator in Google Rich Results Test, so brezplačna in vam prihranijo ogromno glavobolov.
Zna biti problematično tudi, ko se na strani znajde več script blokov za strukturirane podatke, med katerimi so razlike – na primer različna cena ali opis za isto storitev. Google v takih primerih ne ve, kateri podatek naj vzame za resničnega, zato se pogosto odloči, da ne upošteva nobenega.
Pogosta in premalo naslovljena težava je tudi vsebina samega opisa (description). Če vanj napišete le marketinške puhlice, kot so “najboljša storitev v Sloveniji”, brez konkretne razlage, kaj paket vključuje, schema ne bo doprinesla k razumevanju vsebine. Opisi morajo biti vsebinski, ne prodajni.
Za konec pa še ena pogosto spregledana past: podatki v schemi se morajo ujemati z dejansko vsebino na strani. Če v JSON-LD bloku piše, da je cena 390 €, na strani pa obiskovalec tega podatka ne vidi, lahko Google vašo označbo ignorira ali celo penalizira zaradi neujemanja.
Na seo-praktik.si smo se vsega tega držali, ko smo strukturirali naš cenik SEO storitev. In zato schema ne le deluje, ampak tudi dejansko pomaga naši vsebini izstopati v iskalniku.
Kaj naredite, če struktura ni prikazana kot rich snippet
Ena izmed najbolj frustrirajočih situacij pri strukturiranju podatkov je ta: vse ste naredili pravilno. Uporabili ste pravilen @type, vnesli vse obvezne atribute, preverili v validatorju – in schema je »validna«. Pa vseeno… v iskalniku nič. Brez cene, brez FAQ-ov, brez zvezdic. Nič od obljubljenega “rich snippeta”.
Na seo-praktik.si smo se točno s tem srečali pri strukturiranju našega SEO cenika. Implementacija je bila tehnično brezhibna, kar sta potrdili tako Google Rich Results Test kot tudi Schema Validator. Pa vendar: v SERP-u (vsaj na začetku) ni bilo nobene sledi o cenah.
Zakaj se to dogaja
Pomembno je razumeti, da strukturirani podatki niso jamstvo, da bo Google dejansko prikazal bogat rezultat. So le priporočilo. Google si pridržuje pravico, da:
bogatih rezultatov ne prikaže, če presodi, da niso koristni za uporabnika,
schema ignorira, če zazna vsebinsko ali tehnično neujemanje,
ali pa prikaz aktivira šele čez čas, ko stran dobi dovolj zaupanja in signale o uporabnosti.
Včasih pa je razlog zelo enostaven – vaša stran trenutno ni dovolj obiskana ali ni dovolj avtoritativna, da bi Google vanjo »investiral« s prikazom bogatega rezultata. Če pa isto vsebino objavi znana domena, se schema pokaže že v nekaj urah.
Kaj lahko naredite
Najpomembnejše je, da strukturo vseeno implementirate pravilno – tudi če se v SERP-u še ne pokaže. S tem Googlu daste boljšo osnovo za razumevanje, ki lahko vpliva na druge SEO signale (konkretneje: na povezljivost, iskanje znotraj strani, tematsko relevantnost).
Kdaj uporabiti Product, kdaj Service – in ali ju lahko kombinirate
To vprašanje je v praksi zelo pogosto – in hkrati zelo pomembno. Še posebej za tiste, ki ne prodajajo fizičnih izdelkov, ampak storitve, pakete, svetovanja ali svetovalne ure. Google sicer omogoča rabo obeh tipov struktur – Product in Service – a njuna funkcija je različna in napačna izbira lahko zmanjša možnosti za prikaz v SERP-u.
Na seo-praktik.si smo imeli natančno tak primer. Na eni strani smo želeli predstaviti paketne SEO storitve, ki imajo fiksne cene in vključujejo točno določen obseg dela (npr. “Napredni SEO paket”). Na isti strani pa ponujamo tudi storitev po meri, ki vključuje mentorstvo, sparing pogovore ali svetovanje – pogosto brez točno določene količine in s cenami, ki se prilagajajo.
Kako smo se odločili
Za fiksne pakete smo uporabili Product, ker gre za jasno definirano ponudbo s ceno, imenom in obsegom. Tak paket lahko brez težav označimo kot “izdelek”, saj se za uporabnika vede podobno kot produkt – izbere ga, razume, koliko stane in kaj vključuje.
Za storitev po meri (npr. “SEO mentorstvo”) pa smo uporabili Service, ker tukaj ni govora o “artiklu”, ampak o kontinuirani podpori ali prilagodljivem svetovanju, kjer se cene lahko gibljejo med razponom.
Ali lahko na isti strani uporabimo Product in Service
Da – in to je pravzaprav eden najbolj logičnih pristopov. Google nima težav s kombiniranjem različnih tipov strukturiranih podatkov na eni strani, če:
so vsak tip ločeno definiran v svojem @type bloku,
imajo jasno razmejene opise (npr. ne podvajamo name ali price za različne entitete),
in če vsak od njih ustreza dejanski vidni vsebini na strani.
Tako lahko uporabimo Product za fiksne pakete in Service za svetovanje ali delo po meri – kot smo to storili tudi mi.
Če bi na silo uporabili samo Service ali samo Product, bi v najboljšem primeru izgubili bogate prikaze. V najslabšem pa bi schema sploh ne bila priznana – ker bi ne ustrezala kontekstu.
Zakaj strukturirani podatki niso več samo “tehnična SEO malenkost”
Včasih so strukturirane podatke dojemali kot nekaj, kar je namenjeno izključno razvijalcem – nekaj, kar »ni nujno«, če je vsebina že dobra. Danes pa je ta pogled popolnoma zastarel. Google se vse bolj odmika od klasičnega razumevanja besedil in vse bolj gradi iskalne rezultate na podatkovnih kontekstih.
Če to povemo bolj naravnost: če mu ne povemo, kdo smo, kaj ponujamo in zakaj smo pomembni – si bo to izmislil sam. Ali pa bo to pokazal iz vsebine nekoga drugega.
Strukturirani podatki so danes ključni del sodobne SEO strategije, ker:
pomagajo Googlu bolje razumeti namen strani,
omogočajo prikaz v bogatih rezultatih (kar poveča vidnost),
olajšajo integracijo z glasovnim iskanjem, AI odgovori in asistentom,
ter služijo kot vezno tkivo med vašo vsebino in širšim kontekstom spleta.
Na seo-praktik.si smo to spoznali skozi prakso. Ko smo implementirali strukturirane podatke na strani s SEO cenikom, smo ne le povečali možnosti za prikaz rich snippetov, ampak tudi utrdili Googlov kontekstualni okvir o tem, kaj ponujamo, komu pomagamo in kako nas naj prikazuje.
Če danes gradite spletno prisotnost brez strukturiranih podatkov, je to, kot bi gradili hišo brez temeljev – mogoče bo stala, ampak ne dolgo in ne stabilno.
Koliko spletnih strani (sploh) uporablja strukturirane podatke
Nedavna raziskava kaže, da strukturirane podatke (v različnih formatih), na svojih spletnih straneh, uporablja manj kot polovica spletnih strani:.
rdf format uporablja dobrih 42% spletnih strani
meta tag based format dobrih 23% strani
JSON-LD uporablja dobrih 21 %
microdata cca. 15% in
microformat manj kot 1% spletnih strani
Kljub temu, da strukturiranje podatkov na spletnih straneh, pomaga iskalnikom in drugim robotom, bolje razumeti (in izluščiti) podatke na posamezni strani in kljub temu, da je mogoče na vsaki strani strukturirati celo vrsto podatkov (mnenja strank, opise produktov, recepte, članke, glasbo, filme, video,….), po zgornji raziskavi več kot polovica spletnih strani, podatkov na spletnih straneh ne strukturira..
Ali strukturiranje sploh podatkov pomaga SEO.
Če se odločite za strukturiranje podatkov znotraj vsebin, ki jih imate na spletnih straneh, to (posredno), iz vidika SEO, koristi na zelo veliko načinov. Štiri, zelo enostavno razumljive, obenem pa NAJVEČKRAT SPREGLEDANE IN NEIZKORIŠČENE POTENCIALE STRUKTURIRANJA PODATKOV, pojasnjujemo spodaj:.
označevanje/strukturiranje podatkov podjetja pozitivno vpliva na branding, pri označevanju podatkov podjetja (https://schema.org/Organization) pa lahko specifično definirate ime podjetja (plus brand name izpeljanke), e naslov kontaktnih oseb, telefonsko številko, logotip, itd…. Vsi ti podatki so vidni na t.i. Knowledge Graph kartici
označevanje slik (ImageGallery Schema markup) je super priložnost, da strukturirate vse slike v galeriji. To lahko ima pozitiven učinek na recimo produktnih straneh, ki imajo ponavadi od štiri do pet slik na galerijo. Označevanje slik v galeriji pomaga Googlu prepoznati različne slike in jih prikazati bolj ustrezno, glede na vrsto iskanja.
glede na to, da raba pametnih telefonov narašča (vir: Statista) in, da ima vedno več podjetij vsaj eno mobilno aplikacijo, je strukturiranje podatkov za mobilne aplikacije (Schema MobileAplication) ena od manj izkoriščenih možnosti, še posebej, ker mobilne aplikacije ponavadi, zaradi stroška, niso izdelane samo za to, da so (češ, ker jih ima konkurenca), ampak, ker imajo zadaj zelo jasno definiran cilj in landing page.
precej spletnih strani ima svoj seznam zaposlenih (direktorji, vodje, itd…). Preko SchemaPerson Markup imate možnost, da Googlu natančno definirate ime in priimek, položaj, sliko in kratek opis vsakega zaposlenega. Postopek označevanja podatkov za osebo je podrobno opisan (v angl.) tukaj: Person markup for adding structured data – GeorgeGarsideBlog, kako pa so ti podatki vidni v Googlu, pa lahko vidite na spodnji sliki (po tem, ko v iskalnik vtipkate ime zaposlenega, vir slike: SearchEngineLand):
Za potrebe SEO (večjo, bolj izpostavljeno in bolj ciljano vidnost na iskalniku) je priporočljivo strukturirati še celo goro drugih podatkov. Npr:.
na blogih (in vseh straneh, kjer redno objavljate takšne ali drugačne vrste člankov) se priporoča strukturiranje podatkov zato, ker so tako označeni blog zapisi prikazani v obliki vrtiljaka (carousel) na vrhu iskalnika. Tu je posebej izpostavljen naslov in pa slika članka.
na kulinaričnih spletnih straneh je priporočljivo strukturirati recepte. Ti so, če so pravilno strukturirani, prikazani v iskalniku v obliki kartic, zraven pa so podatki o oceni recepta, času priprave jedi, kalorijah, itd… Slika iz Googlovega bloga Introducing Rich Cards.
.
.
.
Shopping Basket
Manage Cookie Consent
Z namenom, da bi vam olajšali uporabo naše spletne strani in jo za vas naredili prijaznejšo, uporabljamo piškotke.
Nujni
Vedno omogočeni
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistika
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
