Hogyan validáljuk a strukturált adatokat Google-eszközök nélkül

A strukturált adatok validálása furcsa módon Google-központú eszközöktől vált függővé. Ez érthető: sok csapat azért ad hozzá JSON-LD-t, mert rich resultokat szeretne, a Google tesztelőeszközei pedig ismerősek. De a strukturált adat nem Google-formátum. Általában Schema.org-szókincset használó JSON-LD, HTML-be ágyazva, amelyet sokféle fogyasztó értelmez, és amelyet a saját publikálási munkafolyamatunk tart karban.

Ha csak keresőmotoros szemüvegen keresztül validál, könnyen elsiklhat alapvető problémák felett: érvénytelen JSON, renderelés után eltűnő adatok, elavult termékárak, egymásnak ellentmondó canonical URL-ek, vagy technikailag érvényes, de szemantikailag értelmetlen jelölés.

Jobb munkafolyamat a szabványközpontú megközelítés. Először validálja az adatot adatként, majd a szókincset, végül pedig az oldalt úgy, ahogy az éles környezetben létezik.

Mit validál valójában?

A „strukturált adat” nem egyetlen dolog. A legtöbb webhelyen négy rétege van:

1. JSON-szintaxis — értelmezhető a kód?
2. JSON-LD-modell — értelmes linked datává bontható ki?
3. Schema.org-szókincs — hihetőek a típusok és tulajdonságok?
4. Oldalszintű igazság — a jelölés megfelel annak, amit a felhasználók és a crawlerek látnak?

A Google-eszközök többnyire a negyedik rétegre, valamint a Google-specifikus rich-result jogosultságra összpontosítanak. Hasznosak, igen. Teljesek, nem.

Például ez lehet érvényes JSON-LD, és közben mégis gyenge strukturált adat:

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

Itt semmi sincs elromolva. De ha a látható oldalon más a címsor, nincs szerzői feltüntetés, és az utolsó módosítás dátuma ellentmond a jelölésnek, akkor minőségi problémája van, nem szintaktikai.

1. lépés: Elemezze a JSON-t, mielőtt SEO-ra gondolna

Kezdje az unalmas ellenőrzéssel: értelmezhető a JSON?

A HTML-be ágyazott JSON-LD gyakran apró sablonhibák miatt romlik el:

• záró vesszők
• nem escape-elt idézőjelek terméknevekben
• érvénytelen sortörések stringeken belül
• hiányzó kapcsos zárójelek feltételes mezők után
• elrendezés-öröklésből származó duplikált scriptblokkok
• részleges objektumokat kibocsátó CMS-bővítmények

Helyi ellenőrzésekhez nincs szüksége SEO-platformra. Használja azokat az eszközöket, amelyek már eleve részei a fejlesztési stacknek.

JavaScriptben:

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-ben nyerje ki a script tartalmát a renderelt HTML-ből, és elemezze JSON-ként. Ez sok problémát elkap, mielőtt azok éles környezetbe kerülnének.

A lényeg: ezt bármilyen Schema.org-validálás előtt tegye meg. Egy szókincsvalidátor nem tud segíteni, ha az adat nem érvényes JSON.

2. lépés: A JSON-LD viselkedését ellenőrizze, ne csak a JSON-szintaxist

Az érvényes JSON nem automatikusan érvényes JSON-LD. A JSON-LD olyan fogalmakat használ, mint az @context, @type, @id és a gráfkapcsolatok. Ha ezek hibásan vannak megadva, a parsolók máshogy értelmezhetik az adatot, mint ahogy Ön szánta.

Legalább ellenőrizze, hogy:

• minden blokk megfelelő @context értékkel rendelkezik
• az elsődleges entitásoknak egyértelmű @type értékeik vannak
• az ismétlődő entitások ott, ahol hasznos, stabil @id értékeket használnak
• a beágyazott entitások logikusan kapcsolódnak egymáshoz
• tömböket használ, ha több érték is lehetséges

Nagyobb webhelyeknél a stabil azonosítók különösen hasznosak. Ha a szervezete megjelenik Article, Product, BreadcrumbList és FAQPage adatokban is, ugyanannak az @id értéknek a használata segít a fogyasztóknak megérteni, hogy ezek ugyanarra az entitásra mutató hivatkozások, nem pedig négy, azonos nevű, egymástól független szervezet.

Egy tipikus minta így néz ki:

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

Itt nem az a cél, hogy lenyűgözzön egy validátort. Az adatát teszi kevésbé kétértelművé.

3. lépés: Validáljon a Schema.org-szókincs alapján

Ha a JSON és a JSON-LD struktúrája már rendben van, ellenőrizze a szókincset.

A Schema.org validator azért hasznos, mert Schema.org-kifejezések alapján tesztel, nem egyetlen keresőmotor rich-result szabályai szerint. Megmutathatja, hogy a tulajdonságok felismerhetők-e, a típusokat a várakozásnak megfelelően értelmezi-e, és a beágyazott struktúrák értelmesek-e.

Itt derülnek ki az olyan hibák, mint:

• publishingDate a datePublished helyett
• imageUrl ott, ahol image lenne elvárt
• Product jelölés egy kategórialista oldalon, amely nem termék
• AggregateRating értelmes értékelt elem nélkül
• Person használata márkafiókhoz

Legyen óvatos a figyelmeztetésekkel. A Schema.org szándékosan rugalmas. Egy validátor engedélyezhet olyan tulajdonságot, amely az Ön esetében nem hasznos, vagy figyelmeztethet valamire, ami opcionális. A validálást bizonyítékként kezelje, ne ítéletként.

Gyakorlati szabály: ha egy tulajdonság segít a gépnek pontosabban megérteni az oldalt, tartsa meg. Ha csak azért létezik, mert valaki kimásolta egy snippet-generátorból, kérdőjelezze meg.

4. lépés: Hasonlítsa össze a jelölést a látható tartalommal

A keresőmotorok és más adatfogyasztók általában bizalmatlanok az olyan jelöléssel szemben, amely nem egyezik az oldallal. Ennél is fontosabb, hogy a felhasználók következetességet érdemelnek.

Minden strukturáltadattípusnál hasonlítsa össze a jelölést a látható oldallal:

Article és BlogPosting

Ellenőrizze, hogy a címsor, a szerző, a közzétételi dátum, a módosítás dátuma, a kép és a kiadó látható vagy ésszerűen kikövetkeztethető-e. Ha AI által támogatott tartalmat publikál, a strukturált adatot nem szabad homályos szerzőség tisztára mosására használni. Külön írtunk már arról, hogyan néz ki a őszinte AI-közzététel egy kis webhelyen, és ugyanez az elv itt is érvényes: a metaadatnak tisztáznia kell, nem elhomályosítania.

Product

Ellenőrizze a nevet, árat, elérhetőséget, pénznemet, változatokat, értékeléseket és véleményszámokat. A termékek strukturált adatai különösen hajlamosak elavulni, mert az árak és a készletállapot a CMS-en kívül változik.

LocalBusiness

Ellenőrizze a nevet, címet, telefonszámot, nyitvatartási időt és szolgáltatási területet. Ha a lábléc mást mond, mint a JSON-LD, akkor a JSON-LD nem „jobb”. Ellentmondásos.

BreadcrumbList

Ellenőrizze, hogy a morzsamenü pozíciói megfelelnek-e a látható morzsamenü-útvonalnak, és hogy az URL-ek canonical, crawlolható URL-ek-e, szükségtelen átirányítások nélkül.

Ez nem látványos munka. Ugyanakkor sok strukturáltadat-probléma éppen itt derül ki.

5. lépés: A renderelt oldalt validálja, ne a sablont

Sok webhely JavaScripten, tag managereken, személyre szabási rétegeken vagy komponenshidratáción keresztül állít elő JSON-LD-t. Ez azt jelenti, hogy a sablonfájl nem feltétlenül azt képviseli, amit egy crawler vagy böngésző ténylegesen lát.

Legalább három állapotban validálja a renderelt HTML-t:

• helyi fejlesztői build
• staging vagy preview URL
• éles URL

Használja a böngésző DevTools eszközeit a végső DOM vizsgálatához. Keressen rá az application/ld+json kifejezésre, és másolja ki pontosan azt a script tartalmat, amely a renderelés után létezik. Ha a szerveroldalon renderelt jelölés eltér a hidratált jelöléstől, döntse el, melyik verziót várja el az adatfogyasztóktól.

Ellenőrizze azt is, hogy a strukturált adat nem duplikálódik-e. A duplikált Article vagy Product blokkok gyakoriak, amikor egy CMS-bővítmény és egy egyedi komponens is kibocsát sémát. A duplikáció nem mindig végzetes, de az egymásnak ellentmondó duplikáció probléma: két ár, két szerző, két közzétételi dátum vagy két canonical URL.

Ez hasonlít a teljesítmény- és diagnosztikai jelentések olvasásához: az első feladat nem a pánik, hanem a jel és a zaj szétválasztása. Ugyanez a szokás segít akkor is, amikor pánik nélkül olvas egy Lighthouse-jelentést — bár magát a strukturált adatot nem szabad egyetlen pontszámra redukálni.

6. lépés: Ellenőrizze az éles szállítási részleteket

A strukturált adat tökéletes lehet a forrásban, és mégis elbukhat éles környezetben, mert az oldal nem úgy hozzáférhető, ahogy Ön feltételezi.

Ellenőrizze:

• a végső státuszkód 200, nem soft 404
• a canonical URL megegyezik a validált oldallal
• az átirányítások szándékosak és stabilak
• a robots direktívák nem blokkolják az indexelést ott, ahol indexelés várható
• a HTML-t nem cseréli le hibaoldal bizonyos user agentek esetén
• a gyorsítótárazott oldalak nem szolgálnak ki elavult JSON-LD-t

Itt számít a HTTP-vizsgálat. Ha egy termékoldal három URL-en keresztül irányít át, mielőtt eléri a canonical céloldalt, a végső oldalt validálja, ne az első URL-t, amelyet a CMS-ből kimásolt. A nyers mechanikához hasznos kísérő az átirányítások és HTTP-fejlécek éles környezeti hibakereséséről szóló útmutatónk.

A strukturált adat nem vákuumban létezik. Fejlécekkel, átirányításokkal, gyorsítótárazással, canonical tagekkel és robots direktívákkal együtt utazik.

7. lépés: Adjon strukturáltadat-teszteket a kiadási folyamathoz

A manuális validálás egy oldalnál rendben van. Több száz vagy több ezer URL esetén nem skálázódik.

Egy egyszerű automatizált tesztkészlet el tudja kapni a legdrágább hibákat:

• reprezentatív URL-ek lekérése minden sablontípusból
• az összes JSON-LD blokk kinyerése
• elemzésük JSON.parse segítségével
• kötelező mezők ellenőrzése minden oldaltípusnál
• annak ellenőrzése, hogy a dátumok érvényes ISO 8601 stringek
• annak ellenőrzése, hogy az URL-ek abszolútak és canonical URL-ek
• annak ellenőrzése, hogy termékoldalaknál létezik ár és elérhetőség
• annak ellenőrzése, hogy a duplikált entitások nem mondanak ellent egymásnak

Ezt futtathatja CI-ben sablonokra, és ütemezetten éles URL-ekre. A cél nem annak bizonyítása, hogy minden rich-result funkció meg fog jelenni. Ezt a keresőmotoron kívül senki sem ígérheti meg. A cél az, hogy a saját adatai pontosak, értelmezhetők és következetesek maradjanak.

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

💡 Próbálja ki ezt: A séma logikájának validálása előtt futtassa át a JSON-LD-t a JSON Formatter eszközön, hogy elkapja azokat a szintaktikai hibákat, amelyek különben minden további ellenőrzést megszakítanának.

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

Szabványközpontú validálási ellenőrzőlista

Használja ezt a rövid ellenőrzőlistát, mielőtt megkérdezné, tetszik-e az oldal egy keresőmotornak:

• Minden JSON-LD blokk érvényes JSON?
• Minden blokk tartalmazza a megfelelő @context és @type értéket?
• A Schema.org-tulajdonságok helyesen vannak írva?
• A jelölés megfelel a látható tartalomnak?
• A dátumok, árak, értékelések és elérhetőségi adatok aktuálisak?
• Az URL-ek abszolútak, canonical URL-ek és elérhetők?
• A renderelt éles oldal ugyanaz az oldal, amelyet tesztelt?
• A duplikált entitások szándékosak, és nem mondanak ellent egymásnak?

Ha ezekre a kérdésekre igennel tud válaszolni, elvégezte a strukturáltadat-munka tartós részét. A keresésspecifikus tesztelés később továbbra is hasznos lehet, de annak a végső kompatibilitási ellenőrzésnek kell lennie, nem a validálási folyamat alapjának.