Kaip tikrinti struktūrizuotus duomenis be Google įrankių

Struktūrizuotų duomenų tikrinimas tapo keistai priklausomas nuo Google skirtų įrankių. Tai suprantama: daug komandų prideda JSON-LD, nes nori išplėstinių rezultatų, o Google testavimo įrankiai yra pažįstami. Tačiau struktūrizuoti duomenys nėra Google formatas. Dažniausiai tai yra JSON-LD su Schema.org žodynu, įterptas į HTML, interpretuojamas įvairių vartotojų ir prižiūrimas jūsų pačių publikavimo procese.

Jei tikrinate tik per paieškos sistemos prizmę, galite nepastebėti esminių problemų: netinkamo JSON, duomenų, kurie dingsta po atvaizdavimo, pasenusių produktų kainų, prieštaringų kanoninių URL arba žymėjimo, kuris techniškai galioja, bet semantiškai yra nelogiškas.

Geresnė darbo eiga prasideda nuo standartų. Pirmiausia tikrinkite duomenis kaip duomenis, tada žodyną, o galiausiai puslapį tokį, koks jis egzistuoja gamybinėje aplinkoje.

Ką iš tikrųjų tikrinate?

„Struktūrizuoti duomenys“ nėra vienas dalykas. Daugumoje svetainių jie turi keturis sluoksnius:

1. JSON sintaksė — ar kodą galima išanalizuoti?
2. JSON-LD modelis — ar jis išsiskleidžia į prasmingus susietuosius duomenis?
3. Schema.org žodynas — ar tipai ir savybės yra pagrįsti?
4. Puslapio lygmens tiesa — ar žymėjimas atitinka tai, ką mato naudotojai ir tikrintuvai?

Google įrankiai daugiausia sutelkia dėmesį į ketvirtą sluoksnį ir Google specifinį tinkamumą išplėstiniams rezultatams. Naudinga — taip. Išsamus sprendimas — ne.

Pavyzdžiui, tai gali būti galiojantis JSON-LD, bet vis tiek prasti struktūrizuoti duomenys:

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

Čia niekas nėra sugadinta. Tačiau jei matomame puslapyje yra kita antraštė, nėra autoriaus priskyrimo, o paskutinio keitimo data prieštarauja žymėjimui, turite kokybės, o ne sintaksės problemą.

1 žingsnis: išanalizuokite JSON prieš galvodami apie SEO

Pradėkite nuo nuobodaus patikrinimo: ar JSON galima išanalizuoti?

HTML įterptas JSON-LD dažnai sugenda dėl mažų šablono klaidų:

• pertekliniai kableliai
• neekranuotos kabutės produktų pavadinimuose
• netinkami eilučių lūžiai tekstinėse eilutėse
• trūkstami riestiniai skliaustai po sąlyginių laukų
• pasikartojantys scenarijų blokai dėl išdėstymo paveldėjimo
• CMS papildiniai, išvedantys nepilnus objektus

Vietiniams patikrinimams SEO platformos nereikia. Naudokite įrankius, kurie jau yra jūsų kūrimo aplinkoje.

JavaScript pavyzdys:

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 aplinkoje ištraukite scenarijų turinį iš atvaizduoto HTML ir analizuokite jį kaip JSON. Tai pagauna daug problemų dar prieš joms pasiekiant gamybinę aplinką.

Svarbiausia: darykite tai prieš bet kokį Schema.org tikrinimą. Žodyno tikrintuvas negali padėti, jei duomenys nėra galiojantis JSON.

2 žingsnis: tikrinkite JSON-LD elgseną, ne tik JSON sintaksę

Galiojantis JSON automatiškai nereiškia galiojančio JSON-LD. JSON-LD naudoja tokias sąvokas kaip @context, @type, @id ir grafų ryšiai. Jei jos suformuotos netinkamai, analizatoriai gali interpretuoti jūsų duomenis kitaip, nei ketinote.

Bent jau įsitikinkite, kad:

• kiekvienas blokas turi tinkamą @context
• pirminiai subjektai turi aiškias @type reikšmes
• pasikartojantys subjektai, kai naudinga, naudoja stabilius @id
• įterpti subjektai yra logiškai susieti
• masyvai naudojami tada, kai galimos kelios reikšmės

Didesnėse svetainėse stabilūs identifikatoriai ypač naudingi. Jei jūsų organizacija pasirodo Article, Product, BreadcrumbList ir FAQPage duomenyse, tas pats @id padeda vartotojams suprasti, kad tai nuorodos į tą patį subjektą, o ne keturios nesusijusios organizacijos tuo pačiu pavadinimu.

Tipinis modelis atrodo taip:

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

Čia nesistengiate sužavėti tikrintuvo. Jūs darote savo duomenis mažiau dviprasmiškus.

3 žingsnis: tikrinkite pagal Schema.org žodyną

Kai JSON ir JSON-LD struktūra yra tvarkinga, tikrinkite žodyną.

Schema.org tikrintuvas naudingas, nes testuoja pagal Schema.org terminus, o ne pagal vienos paieškos sistemos išplėstinių rezultatų taisykles. Jis gali parodyti, ar savybės atpažįstamos, ar tipai interpretuojami taip, kaip tikitės, ir ar įterptos struktūros turi prasmę.

Čia aptiksite tokias klaidas kaip:

• publishingDate vietoje datePublished
• imageUrl, kai tikimasi image
• Product žymėjimas kategorijos sąraše, kuris nėra produktas
• AggregateRating be prasmingo vertinamo objekto
• Person, naudojamas prekės ženklo paskyrai

Atsargiai vertinkite įspėjimus. Schema.org sąmoningai yra lankstus. Tikrintuvas gali leisti savybę, kuri jūsų atvejui nėra naudinga, arba įspėti apie tai, kas neprivaloma. Tikrinimą laikykite įrodymu, o ne nuosprendžiu.

Praktinė taisyklė: jei savybė padeda mašinai tiksliau suprasti puslapį, palikite ją. Jei ji egzistuoja tik todėl, kad kažkas ją nukopijavo iš fragmentų generatoriaus, suabejokite ja.

4 žingsnis: palyginkite žymėjimą su matomu turiniu

Paieškos sistemos ir kiti duomenų vartotojai paprastai nepasitiki žymėjimu, kuris neatitinka puslapio. Dar svarbiau — naudotojai nusipelno nuoseklumo.

Kiekvienam struktūrizuotų duomenų tipui palyginkite žymėjimą su matomu puslapiu:

Article ir BlogPosting

Patikrinkite, ar antraštė, autorius, publikavimo data, keitimo data, vaizdas ir leidėjas yra matomi arba pagrįstai numanomi. Jei publikuojate dirbtinio intelekto pagalba kurtą turinį, jūsų struktūrizuoti duomenys neturėtų būti naudojami neaiškiai autorystei pridengti. Atskirai rašėme apie sąžiningą AI atskleidimą mažoje svetainėje, ir čia galioja tas pats principas: metaduomenys turi aiškinti, o ne slėpti.

Product

Patikrinkite pavadinimą, kainą, prieinamumą, valiutą, variantus, įvertinimus ir atsiliepimų skaičių. Produktų struktūrizuoti duomenys ypač linkę pasenti, nes kainos ir atsargų būsena keičiasi už CMS ribų.

LocalBusiness

Patikrinkite pavadinimą, adresą, telefono numerį, darbo laiką ir aptarnavimo teritoriją. Jei jūsų poraštė sako viena, o JSON-LD — kita, JSON-LD nėra „geresnis“. Jis prieštarauja.

BreadcrumbList

Patikrinkite, ar naršymo kelio pozicijos atitinka matomą naršymo kelią ir ar URL yra kanoniniai, tikrinami ir be reikalo neperadresuojami.

Tai nėra įspūdingas darbas. Tačiau būtent čia randama daug struktūrizuotų duomenų problemų.

5 žingsnis: tikrinkite atvaizduotą puslapį, o ne šabloną

Daugelis svetainių generuoja JSON-LD per JavaScript, žymų tvarkykles, personalizavimo sluoksnius arba komponentų hidrataciją. Tai reiškia, kad šablono failas gali neatspindėti to, ką iš tikrųjų mato tikrintuvas ar naršyklė.

Tikrinkite atvaizduotą HTML bent trijose būsenose:

• vietinės kūrimo aplinkos versijoje
• parengiamojoje arba peržiūros URL aplinkoje
• gamybinės aplinkos URL

Naudokite naršyklės DevTools, kad apžiūrėtumėte galutinį DOM. Ieškokite application/ld+json ir nukopijuokite tikslų scenarijaus turinį, esantį po atvaizdavimo. Jei serveryje atvaizduotas žymėjimas skiriasi nuo hidratuoto žymėjimo, nuspręskite, kurią versiją tikitės, kad duomenų vartotojai skaitys.

Taip pat patikrinkite, ar struktūrizuoti duomenys nedubliuojami. Pasikartojantys Article arba Product blokai dažni, kai ir CMS papildinys, ir pasirinktinis komponentas išveda schemą. Dubliavimas ne visada lemtingas, bet prieštaringas dubliavimas yra problema: dvi kainos, du autoriai, dvi publikavimo datos arba du kanoniniai URL.

Tai panašu į našumo ir diagnostikos ataskaitų skaitymą: pirmoji užduotis nėra panikuoti, o atskirti signalą nuo triukšmo. Tas pats įprotis padeda ir skaitant Lighthouse ataskaitą be panikos — nors patys struktūrizuoti duomenys neturėtų būti suvesti į vieną balą.

6 žingsnis: patikrinkite gamybinės aplinkos perdavimo detales

Struktūrizuoti duomenys gali būti tobuli šaltinyje ir vis tiek neveikti gamybinėje aplinkoje, nes puslapis nepasiekiamas taip, kaip manote.

Patikrinkite:

• galutinis būsenos kodas yra 200, o ne soft 404
• kanoninis URL atitinka puslapį, kurį tikrinate
• peradresavimai yra tyčiniai ir stabilūs
• robots direktyvos neblokuoja indeksavimo ten, kur jo tikimasi
• HTML kai kuriems naudotojo agentams nepakeičiamas klaidos puslapiu
• podėlyje laikomi puslapiai nepateikia pasenusio JSON-LD

Čia svarbi HTTP patikra. Jei produkto puslapis peradresuojamas per tris URL prieš pasiekdamas kanoninę paskirties vietą, tikrinkite galutinį puslapį, o ne pirmą iš CMS nukopijuotą URL. Praktinei mechanikai pravers mūsų gidas apie peradresavimų ir HTTP antraščių derinimą gamybinėje aplinkoje.

Struktūrizuoti duomenys neegzistuoja vakuume. Jie keliauja kartu su antraštėmis, peradresavimais, podėliu, kanoninėmis žymomis ir robots direktyvomis.

7 žingsnis: įtraukite struktūrizuotų duomenų testus į išleidimo procesą

Rankinis tikrinimas tinka vienam puslapiui. Jis nesiplečia iki šimtų ar tūkstančių URL.

Paprastas automatizuotų testų rinkinys gali pagauti brangiausias klaidas:

• paimkite reprezentatyvius URL iš kiekvieno šablono tipo
• ištraukite visus JSON-LD blokus
• analizuokite juos su JSON.parse
• patikrinkite privalomus laukus kiekvienam puslapio tipui
• patikrinkite, ar datos yra galiojančios ISO 8601 eilutės
• patikrinkite, ar URL yra absoliutūs ir kanoniniai
• patikrinkite, ar produktų puslapiuose yra kainos ir prieinamumas
• patikrinkite, ar pasikartojantys subjektai neprieštarauja vieni kitiems

Tai galite vykdyti CI aplinkoje šablonams ir pagal tvarkaraštį gamybinės aplinkos URL. Tikslas nėra įrodyti, kad kiekviena išplėstinių rezultatų funkcija pasirodys. Niekas už paieškos sistemos ribų negali to pažadėti. Tikslas — išlaikyti savo duomenis tikslius, analizuojamus ir nuoseklius.

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

💡 Išbandykite tai: Prieš tikrindami schemos logiką, paleiskite savo JSON-LD per JSON Formatter, kad aptiktumėte sintaksės klaidas, kurios priešingu atveju sugadintų kiekvieną vėlesnę patikrą.

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

Standartais pagrįsto tikrinimo kontrolinis sąrašas

Naudokite šį trumpą sąrašą prieš klausdami, ar paieškos sistemai patinka puslapis:

• Ar kiekvienas JSON-LD blokas yra galiojantis JSON?
• Ar kiekviename bloke yra teisingi @context ir @type?
• Ar Schema.org savybės parašytos teisingai?
• Ar žymėjimas atitinka matomą turinį?
• Ar datos, kainos, įvertinimai ir prieinamumas yra aktualūs?
• Ar URL yra absoliutūs, kanoniniai ir pasiekiami?
• Ar atvaizduotas gamybinės aplinkos puslapis yra tas pats puslapis, kurį testavote?
• Ar pasikartojantys subjektai yra tyčiniai ir neprieštaringi?

Jei į šiuos klausimus galite atsakyti taip, atlikote tvariąją struktūrizuotų duomenų darbo dalį. Paieškai specifinis testavimas vėliau vis dar gali būti naudingas, bet jis turėtų būti galutinis suderinamumo patikrinimas, o ne jūsų tikrinimo proceso pagrindas.