Strukturált adatok: melyekre van valóban szüksége egy céges weboldalnak
A strukturált adatok nem rangsorolási tényezők. Fordítást jelentenek: megmondják a gépeknek, mit jelent egy szövegrész, ahelyett hogy találgatniuk kellene. Egyre inkább éppen ez dönti el, hogy egy oldal egyáltalán szerepel-e a válaszokban.
A lényeg röviden
- Négy típus elég szinte minden céges oldalhoz: Organization, WebPage illetve Article, BreadcrumbList és FAQPage.
- A kiszolgálás JSON-LD formában történik a
<head>részben – nem a folyó szövegbe ágyazott jelölésként. - A leggyakoribb hiba csendes és drága: olyan adatok a strukturált adatokban, amelyek magán az oldalon nem szerepelnek.
- Három sokat tárgyalt típust egy szolgáltató cég megspórolhat – ezek csak megfelelő ajánlattal vagy valódi értékelésekkel működnek.
Egy gép, amely elolvas egy oldalt, először csak szöveget lát. Hogy az „Emma Woelk” egy ember, a „TEISENDA GmbH” egy cég, a „2026. augusztus 22.” pedig egy közzétételi dátum, azt ki kell találnia – vagy kifejezetten oda van írva.
A strukturált adatok ezt a kifejezett odaírást jelentik. Nem javítanak a helyezésen. Arról döntenek, hogy egy oldal egyáltalán szóba jöhet-e bővített megjelenítésekhez és generált válaszokhoz.
A négy, amely elég
1. Organization – egyszer, a kezdőoldalon
Hogy kik vagytok: név, cím, logó, alapítási év, profilok más hálózatokon. Ez az a bejegyzés, amely lehetővé teszi, hogy egy logó megjelenjen a találat mellett – a leggyakoribb ok, amiért hiányzik, egyszerűen ennek a bejegyzésnek a hiánya.
Fontos: A logónak raszterképként kell rendelkezésre állnia. Egy SVG-t ezen a helyen nem dolgoznak fel.
2. WebPage vagy Article – minden oldalon
Hogy mi ez az oldal: cím, leírás, nyelv, a közzététel és az utolsó átdolgozás dátuma. Bejegyzéseknél ezen felül Article illetve BlogPosting, a szerzővel önálló Person-bejegyzésként – szereppel, nem csak névvel.
Fontos: A módosítás dátumának stimmelnie kell. Egy olyan dátum, amely minden oldalbetöltésnél újra beíródik, olyan jelzés, amely önmagát értékteleníti el.
3. BreadcrumbList – minden aloldalon
Hogy hol áll ez az oldal a szerkezetben. Láthatóan útvonalként az oldal tetején, gépi olvasásra a fejrészben. A kettő összetartozik – egy olyan útvonal az adatokban, amely az oldalon nem létezik, valótlan adat.
4. FAQPage – ahol valódi kérdések vannak
A kérdésblokk egy bejegyzés végén. A válaszgépek számára a legértékesebb típus, mert a kérdést és a választ már párként adja át – pontosan abban a formában, ahogyan idézni szoktak.
Fontos: Csak az oldalon ténylegesen látható kérdésekhez. A kitalált kérdések, amelyek csak az adatokban szerepelnek, az irányelvek megsértését jelentik.
Három, amelyet meg lehet spórolni
Product és Offer. Az egyedi ajánlattal dolgozó szolgáltatásoknál nem hoznak semmit – ár és elérhetőség nélkül úgysem jelennek meg. Csak valódi webáruháznál van értelmük.
AggregateRating. A csillagok a találatban csábítóak, és szigorú feltételekhez kötöttek: az értékeléseknek valódinak, ellenőrizhetőnek és az oldalon láthatónak kell lenniük. A saját magatoknak adott értékelés irányelvsértés, valós kockázattal.
HowTo. A megjelenítésben jelentősen visszaszorult, és a legtöbb céges oldalon már nem éri meg a karbantartási ráfordítást.
Tudtad?
A strukturált adatok nem rangsorolási tényezők – ezt a Google többször is egyértelművé tette. A megjelenítésről döntenek, nem a helyezésről.
A válaszgépeknél kissé más a helyzet. Egy modell, amelynek egy oldalból választ kell építenie, előszeretettel használja azt, ami egyértelműen meg van jelölve: kérdés-válasz párokat, szerzőt szereppel, az utolsó ellenőrzés dátumát. Így nem kell találgatnia, mi tartozik össze. A haszon tehát kevésbé a rangsorban, inkább az idézhetőségben rejlik.
Hogyan épülnek be
Három szabály, amely a legtöbb bajt megelőzi.
- JSON-LD, a
<head>részben. Nem a folyó szövegben elhelyezett attribútumokként. A JSON-LD az elrendezéstől függetlenül karbantartható, és nem vész el a látványterv módosításakor. - Oldalanként egy blokk, nem öt. A több bejegyzés egy
@graphelembe való, és@idalapján kapcsolódik egymáshoz. Így a bejegyzés ugyanarra a szervezetre hivatkozik, amely a kezdőoldalon szerepel, ahelyett hogy megismételné. - Ugyanabból a forrásból állítsátok elő, mint a látható tartalmat. Ha a cím, a dátum és a szerző ugyanazokból a mezőkből jön, mint maga az oldal, akkor nem is tudnak szétcsúszni. Ez a leghatásosabb megelőzés egyáltalán.
A legdrágább hiba a leghalkabb: a strukturált adatok olyat mondanak, ami az oldalon nem szerepel. Tegnapi módosítási dátum egy 2023-as szövegnél. Szerző, aki a látható részen sehol nem tűnik fel. Kérdések az adatokban, amelyek az oldalon nincsenek.
Ez egyetlen ellenőrző eszköznek sem tűnik fel – az adatok formailag érvényesek. Kézi vizsgálatnál tűnik fel, és akkor a következmény nem csak az érintett jelölést érinti. Ezért fontosabb az „ugyanabból a forrásból állítsuk elő” szabály, mint bármilyen teljesség.
Ellenőrzés – ebben a sorrendben
| Lépés | Mivel | Mit láttok |
|---|---|---|
| 1. Szintaxis | Schema Markup Validator | Érvényes-e a JSON és helyes-e a típus |
| 2. Megjeleníthetőség | Rich Results teszt | Lehetséges lenne-e a bővített megjelenítés |
| 3. Valóság | Search Console, Fejlesztések rész | Mi lett ténylegesen felismerve, az összes oldalon |
| 4. Egyezés | Saját szemmel olvasva | Minden adat láthatóan is szerepel-e az oldalon |
A negyedik lépés az egyetlen, amelyet semmilyen eszköz nem vesz át – és az egyetlen, amelynél a komoly hibák feltűnnek.
Vizsgáld meg ennek az oldalnak a strukturált adatait teljesség és a látható tartalommal való egyezés szempontjából. Az oldal látható tartalma: [az oldal szövegének beillesztése] Az oldal JSON-LD kódja: [a blokk beillesztése] Feladatok: 1. Nevezz meg minden olyan adatot a JSON-LD-ben, amely a látható tartalomban nem fordul elő. Ez a legfontosabb pont – itt legyél alapos. 2. Nevezz meg minden látható adatot, amelyet jelölni kellene, de hiányzik (szerző szereppel, módosítási dátum, kérdések, útvonal). 3. Ellenőrizd, hogy a négy alaptípus értelmesen ki van-e töltve: Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Nevezd meg azokat a típusokat a blokkban, amelyek egy webáruház és ellenőrizhető értékelések nélküli szolgáltató cégnek semmilyen hasznot nem hoznak. 5. Jelezz minden irányelvsértést, különösen a saját magunknak adott értékeléseket és azokat a kérdéseket, amelyek az oldalon nem szerepelnek. A végén add ki teljes egészében a javított JSON-LD-t. Ne találj ki értékeket – a hiányzókat jelöld [pótlandó] módon.
Összegzés
A strukturált adatokat gyorsan túlbecsülik, és ugyanolyan gyorsan rontják el. Négy típus lefedi egy céges oldal igényét, a hasznuk pedig kevésbé a helyezésben, inkább az idézhetőségben rejlik.
Az az egy szabály, amely mindent tart: ne jelöljetek meg olyat, ami az oldalon nem szerepel. Aki az adatokat ugyanabból a forrásból állítja elő, mint a látható tartalmat, szerkezetileg oldotta meg ezt a problémát – és az utólagos ellenőrzések nagy részét megspórolhatja.
Gyakori kérdések
Milyen strukturált adatokra van szüksége egy céges weboldalnak?
Négy típus elég: Organization egyszer a kezdőoldalon, WebPage illetve Article minden oldalon, BreadcrumbList minden aloldalon, és FAQPage mindenhol, ahol valódi, látható kérdések vannak. A Product, az AggregateRating és a HowTo szolgáltató cégeknél rendszerint nem éri meg.
Javítják a strukturált adatok a rangsorolást?
Nem. Nem rangsorolási tényezők, hanem a megjelenítésről döntenek – például arról, megjelenhet-e a találatban logó, útvonal vagy lenyitható kérdés. A válaszgépeknél növelik az idézhetőséget, mert a kérdés-válasz párok, a szerző és a dátum egyértelműen meg van jelölve ahelyett, hogy ki kellene találni őket.
Miért nem jeleníti meg a Google a logónkat?
A leggyakoribb ok a kezdőoldal hiányzó vagy hiányos Organization-bejegyzése. A második leggyakoribb ok: a megadott logó csak SVG formában létezik – ezen a helyen raszterképre van szükség. Helyes jelölés esetén sincs jogosultság a megjelenítésre.
Mi a leggyakoribb hiba a strukturált adatoknál?
Olyan adatok, amelyek az adatokban szerepelnek, de a látható tartalomban nem: rossz módosítási dátum, meg nem nevezett szerző, kitalált kérdések. Az ellenőrző eszközök ezt nem jelzik, mert az adatok formailag érvényesek. Úgy kerülhető el, ha a jelölés ugyanabból a forrásból áll elő, mint a látható szöveg.
JSON-LD vagy microdata?
JSON-LD a <head> részben. Ez a Google által ajánlott forma, az elrendezéstől függetlenül karbantartható, és nem vész el a látványterv módosításakor. A microdata a folyó szövegben szórja szét a jelölést, és az oldal minden átépítésénél eltörik.
Marketing, amely magát állítja be
A Studio Engine bétája nyitva áll. Foglalj helyet, és alakítsd az elejétől fogva.
Csatlakozom a bétához →