Strukturált adatok vállalati weboldalon

Kiinduló helyzet és döntési feladat

Egy vállalati webhelyen több bővítmény ír ki szervezetadatokat eltérő névvel és logóval. A cél nem a lehető legtöbb schema típus hozzáadása, hanem egy következetes, valós tartalomra épülő leírás létrehozása.

Szereplők

Azonosítsd a szervezetet, webhelyet, szerzőt és oldalt külön összekapcsolható szereplőként. Az összevont objektum zavaros kapcsolatokat eredményezhet.

Fogalmazd meg egyszerűen, ki mit készített. Az ellenőrzés fő kérdése: A gépi leírás ugyanezt adja vissza?

Megfelelő típus

A tényleges tartalomhoz válassz típust és támogatott mezőket. A jelölés nem teremti meg a hiányzó tartalmi jogosultságot.

Olvasd az adott keresőfunkció aktuális követelményeit. Az ellenőrzés fő kérdése: Miért ezt a típust használod?

Látható egyezés

A cím, szerző, dátum és cégadat egyezzen a nyilvános oldallal. A rejtett vagy kitalált értékelés félrevezető.

Vesd össze a JSON-LD mezőit a tartalommal. Az ellenőrzés fő kérdése: Ellenőrizhető minden állítás?

Kimeneti felelősség

Egyeztesd a sablon és SEO-bővítmény adatgenerálási szerepét. A párhuzamos kimenet ellentmondó azonosítókat hagyhat.

Nézd át az összes strukturáltadat-blokkot. Az ellenőrzés fő kérdése: Világos minden entitás felelőse?

Validálás

Teszteld a szintaxist és a konkrét megjelenési típus követelményeit. Az érvényes schema nem jelent garantált kiemelt megjelenést.

Használd a megfelelő validátort. Az ellenőrzés fő kérdése: Technikai vagy tartalmi hiányt javítasz?

Frissítés

Szerző- és cégesadat-változáskor a gépi leírás is frissüljön. A régi adat idővel pontatlanná válhat.

Tartalommódosítás után ellenőrizd a kimenetet. Az ellenőrzés fő kérdése: Melyik folyamat biztosít tartós egyezést?

Részletes megvalósítás és szakmai döntések

A strukturált adatok tervezését egyszerű mondatokkal kezdd. Ki a webhely tulajdonosa? Ki készítette a cikket? Melyik URL mutatja be a szervezetet? Mi az adott oldal témája? Ha ezekre emberi nyelven nincs következetes válasz, a JSON-LD sem fogja magától rendezni a helyzetet. A gépi leírás a már tisztázott kapcsolatok kifejezése, nem a hiányzó vállalkozási információ pótlása. Egy pontos névvel és elérhetőséggel bemutatott szervezet jobb kiindulópont, mint sok részletes, de egymásnak ellentmondó technikai mező.

Készíts entitástérképet a legfontosabb szereplőkkel. A szervezet, webhely, cikk és szerző külön objektum lehet, amelyeket világos hivatkozás kapcsol össze. A szerző nem feltétlenül azonos a WordPress technikai felhasználójával, és a webhely nem ugyanaz a fogalom, mint az üzemeltető vállalkozás. E különbségeket a választott adatmodellben is tartsd meg. Nem szükséges minden lehetséges szereplőt felvenni; azok jelenjenek meg, amelyek a tényleges tartalom megértéséhez szükségesek, és amelyekhez hiteles, karbantartható információ áll rendelkezésre a szerkesztőségben.

Az oldaltípus megválasztása tartalmi döntés. Egy blogcikket cikként leírni érthető, de egy puszta szolgáltatásbemutatót nem kell más műfajnak álcázni egy remélt megjelenés kedvéért. Az adott keresőfunkcióhoz tartozó hivatalos követelmények külön vizsgálatot igényelnek. A schema.org szintjén értelmes adat és egy adott kiemelt keresőmegjelenés jogosultsága nem teljesen azonos kérdés. A validálásnál ezért nevezd meg, mit ellenőrzöl: JSON-szintaxist, adatmodellbeli összefüggést vagy konkrét keresőfunkció követelményét. E különbség megakadályozza a félrevezető minden rendben állapotjelentést.

A látható egyezés alapkövetelmény a saját minőségbiztosításban. Ha a cikk szerzője a felületen KOCI szerkesztőség, a gépi leírás ne kitalált személyként mutassa be. A módosítási dátum egyezzen a valós frissítéssel. A szervezet logója és neve a nyilvános márkát tükrözze. Az értékeléseknél különösen szigorúan kerüld a nem igazolt állítást. A technikai mező nem kevésbé nyilvános állítás attól, hogy az átlagos látogató nem olvassa közvetlenül. Ugyanaz a pontosság és szerkesztői felelősség tartozik hozzá, mint a cikk főszövegéhez.

A WordPress-környezetben gyakran több kiegészítő is generál adatot. A sablon adhat szervezetet, a SEO-bővítmény cikket, egy másik kiegészítő pedig morzsamenüt. Ez nem feltétlenül gond, ha a kimenetek következetesen kapcsolódnak egymáshoz. Probléma akkor lesz, ha eltérő név, azonosító vagy dátum jelenik meg. A megoldás nem újabb generátor hozzáadása. Készíts kimeneti felelősségtáblát: melyik komponens milyen adatért felel, honnan olvassa és hol szerkeszthető. A felesleges párhuzamosságot ennek alapján szüntesd meg, majd több oldaltípuson vizsgáld újra.

A tesztelést három lépcsőben végezheted. Először ellenőrizd, hogy a JSON egyáltalán értelmezhető-e. Másodszor nézd meg a mezők jelentését és a szereplők kapcsolatait. Harmadszor vizsgáld az adott keresőmegjelenés hivatalos eszközében a támogatott típust. A figyelmeztetések értelmezést kívánnak: egy opcionális mező hiánya nem ugyanaz, mint a hibás kötelező adat. Ne tölts ki bizonytalan információt pusztán azért, hogy minden figyelmeztetés eltűnjön. A pontosan hiányzó adat jobb, mint a valósággal ellentétes, de technikailag elfogadhatónak látszó érték.

A strukturált adatok karbantartása a publikációs folyamat része legyen. Amikor egy szerző neve, profilja vagy a vállalkozás elérhetősége változik, a kapcsolódó kimenetnek is frissülnie kell. Ha az adat több helyen másolatként szerepel, nő az eltérés veszélye. Érdemes közös, megbízható forrást használni a visszatérő szervezeti információhoz. A cikk saját címe és dátuma viszont a konkrét tartalom állapotából származzon. A szerkesztőnek értenie kell, mely mező látható és gépi felhasználást is táplál, hogy ne csak a felületi megjelenésre figyeljen.

A speciális megjelenést reálisan kommunikáld. Az érvényes megjelölés önmagában nem garancia arra, hogy a kereső látványosabb találatot mutat. A vállalható fejlesztői eredmény a helyes, következetes és tesztelt adatleírás. A riportban ezt nevezd meg, és ha később megfigyelhető megjelenésváltozás történik, azt külön eredményként dokumentáld. Ugyanez igaz az AI-láthatóságra: ne tulajdoníts biztos idézési előnyt egy schema típusnak, ha erre nincs megfelelő elsődleges bizonyíték. A gépi érthetőség és a garantált ajánlás egészen eltérő állítás.

Az átadási csomag tartalmazzon néhány kész oldalmintát, a használt típusokat és az adatforrások felelősét. Egy későbbi sablonváltásnál ebből gyorsan kiderül, mit kell újra ellenőrizni. A szervezetoldal, cikk, szolgáltatás és kapcsolatoldal külön mintát érdemelhet. A dokumentáció legyen elég rövid ahhoz, hogy tényleg használják, de konkrét ahhoz, hogy az eltérés felismerhető legyen. A cél nem a lehető legsűrűbb technikai jelölés, hanem a valós tartalmat pontosan tükröző, hosszú távon is rendezett adatkapcsolat a webhelyen.

Gyakori kérdések