Strukturirani podatki za SEO in GEO: praktični vodič

Pripravil: NUMEDIA. Viri in vsebina preverjeni 15. septembra 2026.

Strukturirani podatki so strojno berljiv opis informacij, ki jih spletna stran predstavlja uporabniku. Z njimi lahko pojasnite, kdo je organizacija, katero storitev ponuja, kdo je avtor članka in kako so posamezni dokumenti povezani. Ne nadomestijo vsebine in ne zagotavljajo uvrstitve ali priporočila v AI.

Za večino podjetij je najbolj uporabno vprašanje preprosto: ali javno besedilo, podatki SEO vtičnika in izpis schema.org opisujejo isto resničnost? Če na strani piše eno ime izvajalca, v kodi pa ostane drugo podjetje iz predloge, je najprej treba urediti to neskladje.

Ta vodič prikazuje praktičen način načrtovanja, preverjanja in vzdrževanja strukturiranih podatkov. Primeri z domeno example.com so izmišljene ponazoritve in niso pripravljena produkcijska koda za slepo kopiranje.

Schema.org, JSON-LD in obogateni rezultati niso ista stvar

Schema.org je besednjak tipov in lastnosti za opis stvari. Organizacijo lahko opišete s tipom Organization, storitev s Service in članek z Article. JSON-LD je eden od načinov, kako tak opis zapišete v spletni dokument. Vir: uvod v schema.org.

Obogateni rezultat je način prikaza v iskalniku. Obstoj veljavnega tipa v schema.org sam po sebi ne pomeni, da bo iskalnik zanj ponudil posebno obliko rezultata. Ločite torej tri vprašanja: ali je zapis sintaktično veljaven, ali pravilno opisuje vsebino in ali ga določen iskalnik podpira za določeno funkcijo.

Ta razlika prepreči pogost napačen sklep: »Preizkus je zelen, zato bo stran bolj vidna.« Zelen tehnični preizkus je koristen dokaz o delu izvedbe. Ni meritev prihodnjega prikaza, klikov ali prodaje. Za vsako obljubljeno korist mora biti jasno, s čim jo boste preverili.

Najprej uredite podatke, ki jih vidi človek

Google zahteva, da strukturirani podatki ustrezajo vsebini strani in ne zavajajo. Koda zato ni prostor za skrite reference, izmišljene ocene ali storitve, ki jih podjetje ne ponuja. Vir: splošna pravila strukturiranih podatkov.

Pred tehnično izvedbo pripravite kratek seznam potrjenih dejstev: ime podjetja, uradna domena, javni kontakt, dejanski naslov, področje ponudbe in odgovornost za vsebino. Pri vsaki postavki določite vir ter osebo, ki bo potrdila spremembo.

Če podjetje nima poslovalnice v določenem mestu, je ne ustvarite v shemi. Če članek ni pregledala določena oseba, ji ne pripišite pregleda. Če cena velja samo pod določenimi pogoji, ne objavite gole številke brez konteksta. Težava je v napačnem podatku, tudi kadar je zapis tehnično brezhiben.

Katere tipe najprej potrebuje storitveno podjetje?

Ni treba, da vsaka stran vsebuje vse tipe. Cenik, predstavitev podjetja in tehnični vodič imajo različne namene. Začetni nabor naj odraža spletno mesto, ki ga dejansko imate, ne čim daljšega seznama lastnosti.

Pri storitvah schema.org omogoča opis izvajalca in drugih značilnosti storitve. Uporabite le podatke, ki jih lahko podprete z vidno ponudbo. Vir: definicija Service.

Zakaj je pomemben dosleden @id?

Identifikator @id omogoča, da se več delov zapisa sklicuje na isto stvar. Namesto treh nekoliko različnih kopij podjetja lahko posamezne strani povežete z eno organizacijo. Dokument in stvar, o kateri dokument govori, pri tem nista nujno isto.

Praktična ponazoritev: spletna stran z URL-jem https://example.com/svetovanje/ opisuje storitev. Identifikator storitve je lahko isti URL z dodatkom #service, identifikator organizacije pa https://example.com/#organization. Takšne oznake niso posebna navodila za boljšo uvrstitev; pomagajo vzdrževati razumljivo povezavo med zapisi.

Izberite konvencijo, ki jo lahko ekipa ohrani. Če SEO vtičnik že uporablja določene identifikatorje, jih najprej preberite. Dodatna koda naj se poveže z obstoječim grafom, kadar je to primerno, namesto da brez razloga ustvari novo vzporedno organizacijo.

Minimalen ponazoritveni primer storitve

Naslednji skrajšani primer pokaže odnos med dokumentom, storitvijo in izvajalcem. Imena in domena so izmišljeni. Pred uporabo je treba preveriti obstoječi izpis strani, dejanske podatke in zahteve okolja, kamor bi kodo vključili.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Primer podjetja",
      "url": "https://example.com/"
    },
    {
      "@type": "Service",
      "@id": "https://example.com/svetovanje/#service",
      "name": "Svetovanje pri urejanju spletnih vsebin",
      "url": "https://example.com/svetovanje/",
      "provider": {
        "@id": "https://example.com/#organization"
      }
    }
  ]
}

V primer namenoma niso vključene ocene, cena ali obseg območja dela. Manjkajočega poslovnega podatka ne nadomestite z ugibanjem. Najprej ga potrdite in objavite tam, kjer ga uporabnik pričakuje.

Če stran že uporablja Yoast ali drug SEO vtičnik, tega primera ne prilepite kot drugega nepovezanega bloka. Najprej ugotovite, katera organizacija in kateri dokument sta že opisana. Cilj je enoten opis, ne več kode.

Avtorstvo: oseba in organizacija imata različni vlogi

Pri člankih ločite avtorja od izdajatelja. Avtor je lahko dejanska oseba ali organizacija, ki je vsebino pripravila; izdajatelj upravlja objavo. Ime blagovne znamke ne sme samodejno postati izmišljena oseba samo zato, ker je tako nastavljena predloga.

Google v dokumentaciji za Article obravnava podatke, kot so avtor, naslov, slika in datumi. Ti naj se ujemajo z dejansko objavo. Vir: dokumentacija Article.

Če vsebino pripravlja ekipa, na strani pojasnite organizacijsko odgovornost. Če uporabite AI podporo, ne ustvarjajte lažnega strokovnega pregleda. Poslovno potrjena oseba ima lahko svoj predstavitveni profil, vendar mora ta temeljiti na resnični vlogi.

Pri prenovi ohranite prvotni datum objave. Datum posodobitve uporabite za dejansko spremembo in ga uskladite z vidnim stanjem. Samodejno spreminjanje datuma brez vsebinskega razloga obiskovalcu ne pove, kaj je bilo izboljšano.

WordPress in Elementor: najprej pregled obstoječega izpisa

Na WordPress strani lahko podatke ustvarja več komponent: SEO vtičnik, tema, urejevalnik, namenski vtičnik in ročno vstavljena koda. Preden dodate novo rešitev, preverite javni HTML reprezentativne strani.

1. Poiščite obstoječe bloke application/ld+json.
2. Zabeležite tipe, identifikatorje in glavne povezave med njimi.
3. Preverite, katera komponenta ustvarja vsak blok.
4. Primerjajte vrednosti z vidnim naslovom, avtorjem in ponudbo.
5. Odpravite napačen vir podatka, ne samo njegovega trenutnega izpisa.
6. Po spremembi preverite javno stran brez prijave.

Yoast ponuja Schema API za dopolnjevanje posameznih delov ali grafa. Pri prilagoditvi je smiselno uporabiti podprt mehanizem in ohraniti obstoječe povezave. Vir: Yoast Schema API.

Elementorjevo postavitev urejajte ločeno od podatkov SEO, kadar je mogoče. Splošna menjava besedil v bazi lahko poškoduje serializirane vrednosti ali nenamerno spremeni predlogo. Več o varnem pregledu je v vodiču za SEO in GEO na WordPressu.

Trije nivoji preverjanja

Prvi nivo je sintaksa. Ali se JSON pravilno razčleni? Ali so narekovaji, vejice in tipi pravilni? Tak test odkrije tehnične napake, ne more pa potrditi, da podjetje res ponuja zapisano storitev.

Drugi nivo je pomen. Ali je organizacija prava, ali identifikatorji kažejo na iste entitete in ali datum ustreza objavi? Preverite tudi napačne domene, ostanke testnega okolja in reference na neobstoječe elemente.

Tretji nivo je podpora konkretne funkcije. Uporabite preverjevalnik za funkcijo, ki jo želite preveriti. Orodje za obogatene rezultate ne ocenjuje celotne poslovne kakovosti strani in ne podpira nujno vsakega tipa schema.org.

V zapisniku ločite napako od priporočila. Kritična napaka lahko prepreči obdelavo, priporočilo pa opozori na možnost dopolnitve. Če podatka nimate ali ni relevanten, ga ne izmišljajte zgolj zato, da bi odstranili opozorilo.

Kako so strukturirani podatki povezani z GEO in LLM-ji?

Usklajen zapis lahko pomaga pojasniti, o čem stran govori in kako so podatki povezani. Vendar posamezni AI sistemi uporabljajo različne načine pridobivanja in obdelave virov. Ni upravičeno trditi, da določena schema zagotavlja citat v vseh LLM-jih.

Google za svoje AI funkcije ne zahteva posebne AI sheme. Običajne tehnične in vsebinske osnove ostajajo pomembne. Vir: Google o AI funkcijah in spletnih mestih.

Praktičen vrstni red je zato: resnični podatki, uporabna vsebina, dostopen dokument, skladen strojni opis in merjenje. Če obiskovalec ne more razumeti vaše storitve, dodatno označevanje ne odpravi glavne težave. Širši kontekst pojasni vodič za optimizacijo spletnih virov za LLM-je.

Kako podatke ohraniti pravilne po objavi

Največ napak pogosto ne nastane ob prvi uvedbi, temveč pozneje: podjetje spremeni naslov, urednik preimenuje storitev ali se zamenja SEO vtičnik. Zato določite dogodke, ki sprožijo ponovni pregled.

• Sprememba imena, kontakta ali uradne domene podjetja.
• Nova storitev ali pomembna sprememba njenega obsega.
• Menjava teme, SEO vtičnika ali predloge članka.
• Združitev, preusmeritev ali umik strani.
• Sprememba avtorstva in uredniške odgovornosti.
• Posodobitev cen ali pogojev, kadar so vključeni v podatke.

Za vsako vrsto strani shranite en reprezentativen primer in seznam pričakovanih lastnosti. Pri naslednji spremembi ne pregledujete nujno vsakega dokumenta ročno, ampak najprej preverite predlogo ter nato dejanske izjeme. Vseeno preverite javni rezultat: predpomnilnik lahko začasno vrača stare podatke.

Najpogostejše napake pri uvedbi

Podvojeni bloki niso vedno napačni, vendar postanejo težava, ko isti članek ali organizacijo opisujejo različno. Odkrijte izvor podvajanja in ga uredite. Ne izklapljajte celotne sheme, če je dovolj ciljna odprava ročnega ostanka.

Druga napaka je zamenjava širine nabora za kakovost. Več tipov, področij dela ali ključnih besed ne pomeni bolj pravilnega opisa. Tretja je prikaz navideznih ocen ali priznanj. Četrta je označevanje vsega kot izdelka, čeprav stran opisuje storitev, vodič ali podjetje.

Uporaben prevzem dela vsebuje izpis pred spremembo, opis popravka, preverjanje po objavi in znane omejitve. Izvajalec naj zna pojasniti vsak dodani podatek z običajnim jezikom. Če se utemeljitev konča pri »to imajo radi roboti«, zahtevajte konkretnejši razlog.

Pogosta vprašanja

Ali vsaka stran potrebuje ročno JSON-LD kodo?

Ne. Pogosto je ustrezna osnova že v SEO vtičniku. Najprej preverite obstoječi izpis in dodajte samo manjkajoče, smiselne podatke.

Ali veljavna schema zagotavlja obogaten rezultat?

Ne. Veljavnost je del pogojev za razumevanje zapisa, prikaz pa je odvisen od podpore funkcije, vsebine in odločitve iskalnika.

Ali lahko organizacija nastopa kot avtor?

Da, kadar to ustreza dejanski odgovornosti za vsebino. Vidna oznaka in strojni zapis naj bosta dosledna; organizacijskega imena ne predstavljajte kot izmišljene osebe.

Kje začeti, če je izpis neurejen?

Izberite domačo stran, eno storitev in en članek. Popišite vire kode, potrdite poslovna dejstva in odpravite neskladja. Nato preverite še druge strani iste vrste.