Kako validirati strukturirane podatke bez Googleovih alata

Validacija strukturiranih podataka postala je neobično ovisna o alatima usmjerenima na Google. To je razumljivo: mnogi timovi dodaju JSON-LD zato što žele rich results, a Googleovi alati za testiranje dobro su poznati. No strukturirani podaci nisu Googleov format. Najčešće je riječ o JSON-LD-u koji koristi rječnik Schema.org, ugrađen je u HTML, tumače ga mnogi potrošači podataka i održava ga vaš vlastiti izdavački tijek rada.

Ako validirate samo kroz prizmu tražilice, možete propustiti osnovne probleme: neispravan JSON, podatke koji nestaju nakon renderiranja, zastarjele cijene proizvoda, proturječne kanonske URL-ove ili oznake koje su tehnički valjane, ali semantički besmislene.

Bolji tijek rada prvo polazi od standarda. Validirajte podatke kao podatke, zatim validirajte rječnik, a potom validirajte stranicu onakvu kakva postoji u produkciji.

Što zapravo validirate?

“Strukturirani podaci” nisu jedna stvar. Na većini web-mjesta imaju četiri sloja:

1. JSON sintaksa — može li se kod parsirati?
2. JSON-LD model — širi li se u smisleno povezane podatke?
3. Schema.org rječnik — jesu li tipovi i svojstva uvjerljivi?
4. Istinitost na razini stranice — odgovaraju li oznake onome što korisnici i crawleri mogu vidjeti?

Googleovi alati uglavnom se usredotočuju na četvrti sloj i na Googleova specifična pravila prihvatljivosti za rich results. Korisno, da. Potpuno, ne.

Na primjer, ovo može biti valjan JSON-LD, a i dalje loš strukturirani podatak:

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

Ovdje ništa nije pokvareno. No ako vidljiva stranica ima drukčiji naslov, nema navedeno autorstvo i datum zadnje izmjene proturječi oznakama, imate problem kvalitete, a ne problem sintakse.

Korak 1: Parsirajte JSON prije razmišljanja o SEO-u

Počnite s dosadnom provjerom: može li se JSON parsirati?

JSON-LD ugrađen u HTML često se pokvari zbog malih pogrešaka u predlošku:

• završni zarezi
• neescapirani navodnici u nazivima proizvoda
• neispravni prijelomi redaka unutar stringova
• nedostajuće vitičaste zagrade nakon uvjetnih polja
• duplicirani script blokovi zbog nasljeđivanja layouta
• CMS dodaci koji ispisuju djelomične objekte

Za lokalne provjere ne treba vam SEO platforma. Upotrijebite alate koje već imate u svom razvojnom stacku.

U JavaScriptu:

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);
  }
}

U CI-ju izdvojite sadržaje script elemenata iz renderiranog HTML-a i parsirajte ih kao JSON. Time se hvata mnogo problema prije nego što dođu do produkcije.

Važno je sljedeće: učinite to prije bilo kakve Schema.org validacije. Validator rječnika ne može pomoći ako podaci nisu valjan JSON.

Korak 2: Provjerite ponašanje JSON-LD-a, ne samo JSON sintaksu

Valjan JSON nije automatski valjan JSON-LD. JSON-LD koristi koncepte kao što su @context, @type, @id i odnosi u grafu. Ako su oni pogrešno oblikovani, parseri mogu protumačiti vaše podatke drukčije nego što ste namjeravali.

U najmanju ruku potvrdite:

• svaki blok ima odgovarajući @context
• primarni entiteti imaju jasne vrijednosti @type
• ponovljeni entiteti koriste stabilne vrijednosti @id gdje je to korisno
• ugniježđeni entiteti povezani su logično
• nizovi se koriste kada je moguće više vrijednosti

Za veća web-mjesta stabilni identifikatori osobito su korisni. Ako se vaša organizacija pojavljuje u podacima Article, Product, BreadcrumbList i FAQPage, korištenje istog @id pomaže potrošačima podataka razumjeti da su to reference na isti entitet, a ne četiri nepovezane organizacije istog naziva.

Tipičan obrazac izgleda ovako:

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

Ovdje ne pokušavate impresionirati validator. Činite svoje podatke manje dvosmislenima.

Korak 3: Validirajte prema rječniku Schema.org

Nakon što su JSON i JSON-LD struktura ispravni, provjerite rječnik.

Schema.org validator koristan je zato što testira prema Schema.org pojmovima, a ne prema pravilima za rich results jedne tražilice. Može pokazati prepoznaju li se svojstva, tumače li se tipovi prema očekivanjima i imaju li vaše ugniježđene strukture smisla.

Ovdje hvatate pogreške poput:

• publishingDate umjesto datePublished
• imageUrl ondje gdje se očekuje image
• Product oznake na popisu kategorije koji nije proizvod
• AggregateRating bez smislenog recenziranog predmeta
• Person korišten za račun brenda

Budite oprezni s upozorenjima. Schema.org je namjerno fleksibilan. Validator može dopustiti svojstvo koje nije korisno za vaš slučaj upotrebe ili upozoriti na nešto što je opcionalno. Validaciju tretirajte kao dokaz, ne kao presudu.

Praktično pravilo: ako svojstvo pomaže stroju da točnije razumije stranicu, zadržite ga. Ako postoji samo zato što ga je netko kopirao iz generatora isječaka, preispitajte ga.

Korak 4: Usporedite oznake s vidljivim sadržajem

Tražilice i drugi potrošači podataka skloni su ne vjerovati oznakama koje ne odgovaraju stranici. Još važnije, korisnici zaslužuju dosljednost.

Za svaki tip strukturiranih podataka usporedite oznake s vidljivom stranicom:

Article i BlogPosting

Provjerite jesu li naslov, autor, datum objave, datum izmjene, slika i izdavač vidljivi ili razumno zaključivi. Ako objavljujete sadržaj nastao uz pomoć AI-ja, strukturirani podaci ne bi se smjeli koristiti za prikrivanje nejasnog autorstva. Zasebno smo pisali o poštenom otkrivanju AI-ja na malom web-mjestu, a isto načelo vrijedi i ovdje: metapodaci trebaju razjasniti, ne zamagliti.

Product

Provjerite naziv, cijenu, dostupnost, valutu, varijante, ocjene i broj recenzija. Strukturirani podaci za proizvode osobito su skloni zastarijevanju jer se cijene i stanje zaliha mijenjaju izvan CMS-a.

LocalBusiness

Provjerite naziv, adresu, telefonski broj, radno vrijeme i područje pružanja usluge. Ako podnožje stranice govori jedno, a vaš JSON-LD drugo, JSON-LD nije „bolji”. On je proturječan.

BreadcrumbList

Provjerite odgovaraju li pozicije breadcrumb elemenata vidljivoj breadcrumb stazi te jesu li URL-ovi kanonski, dostupni crawlerima i bez nepotrebnih preusmjeravanja.

Ovo nije glamurozan posao. To je ujedno i mjesto na kojem se pronalaze mnogi problemi sa strukturiranim podacima.

Korak 5: Validirajte renderiranu stranicu, ne svoj predložak

Mnoga web-mjesta generiraju JSON-LD kroz JavaScript, tag managere, slojeve personalizacije ili hidrataciju komponenti. To znači da datoteka predloška možda ne predstavlja ono što crawler ili preglednik zapravo vidi.

Validirajte renderirani HTML u najmanje tri stanja:

• lokalni razvojni build
• staging ili preview URL
• produkcijski URL

Upotrijebite browser DevTools za pregled konačnog DOM-a. Potražite application/ld+json i kopirajte točan sadržaj script elementa koji postoji nakon renderiranja. Ako se server-rendered oznake razlikuju od hydrated oznaka, odlučite koju verziju očekujete da će potrošači podataka čitati.

Provjerite i dupliciraju li se strukturirani podaci. Duplicirani blokovi Article ili Product česti su kada CMS dodatak i prilagođena komponenta oba emitiraju schemu. Dupliciranje nije uvijek fatalno, ali proturječno dupliciranje jest problem: dvije cijene, dva autora, dva datuma objave ili dva kanonska URL-a.

To je slično čitanju izvješća o performansama i dijagnostici: prvi zadatak nije paničariti, nego odvojiti signal od šuma. Ista navika pomaže kada čitate Lighthouse izvješće bez panike — iako se sami strukturirani podaci ne bi smjeli svesti na jedan rezultat.

Korak 6: Provjerite produkcijske transportne detalje

Strukturirani podaci mogu biti savršeni u vašem izvornom kodu, a ipak zakazati u produkciji jer stranica nije dostupna na način koji pretpostavljate.

Provjerite:

• konačni statusni kod je 200, a ne soft 404
• kanonski URL odgovara stranici koju validirate
• preusmjeravanja su namjerna i stabilna
• robots direktive ne blokiraju indeksiranje ondje gdje se indeksiranje očekuje
• HTML se za neke user agente ne zamjenjuje stranicom pogreške
• cacheirane stranice ne poslužuju zastarjeli JSON-LD

Ovdje je HTTP inspekcija važna. Ako stranica proizvoda prolazi kroz tri URL-a prije nego što stigne do kanonskog odredišta, validirajte konačnu stranicu, a ne prvi URL kopiran iz CMS-a. Za sirovu mehaniku koristan je prateći materijal naš vodič za debugging redirects i HTTP headers in production.

Strukturirani podaci ne žive u vakuumu. Putuju zajedno sa zaglavljima, preusmjeravanjima, cacheiranjem, kanonskim oznakama i robots direktivama.

Korak 7: Dodajte testove strukturiranih podataka u svoj proces objave

Ručna validacija u redu je za jednu stranicu. Ne skalira se na stotine ili tisuće URL-ova.

Jednostavan automatizirani skup testova može uhvatiti najskuplje pogreške:

• dohvatiti reprezentativne URL-ove za svaku vrstu predloška
• izdvojiti sve JSON-LD blokove
• parsirati ih pomoću JSON.parse
• provjeriti obavezna polja za svaku vrstu stranice
• provjeriti jesu li datumi valjani ISO 8601 stringovi
• provjeriti jesu li URL-ovi apsolutni i kanonski
• provjeriti postoje li cijene i dostupnost za stranice proizvoda
• provjeriti da se duplicirani entiteti ne sukobljavaju

To možete pokretati u CI-ju za predloške i prema rasporedu za produkcijske URL-ove. Cilj nije dokazati da će se svaka rich-result značajka pojaviti. Nitko izvan tražilice to ne može obećati. Cilj je održati vlastite podatke točnima, parsabilnima i dosljednima.

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

💡 Isprobajte ovo: Prije provjere logike sheme, provucite svoj JSON-LD kroz JSON Formatter kako biste uhvatili sintaksne pogreške koje bi inače srušile svaku naknadnu provjeru.

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

Kontrolni popis za validaciju koja polazi od standarda

Upotrijebite ovaj kratak kontrolni popis prije nego što pitate sviđa li se stranica tražilici:

• Je li svaki JSON-LD blok valjan JSON?
• Uključuje li svaki blok ispravne @context i @type?
• Jesu li Schema.org svojstva ispravno napisana?
• Odgovaraju li oznake vidljivom sadržaju?
• Jesu li datumi, cijene, ocjene i dostupnost ažurni?
• Jesu li URL-ovi apsolutni, kanonski i dostupni?
• Je li renderirana produkcijska stranica ista stranica koju ste testirali?
• Jesu li duplicirani entiteti namjerni i bez sukoba?

Ako na ta pitanja možete odgovoriti potvrdno, obavili ste trajan dio posla sa strukturiranim podacima. Testiranje specifično za tražilice i dalje može biti korisno kasnije, ali trebalo bi biti završna provjera kompatibilnosti, a ne temelj vašeg procesa validacije.