seoscore
LT / EN Prisijungti Nemokamas skenas
LT / EN Prisijungti
Nemokamas skenas →

Kokie struktūriniai duomenys realiai naudojami ir kur klystama?

Praktikoje matom du kraštutinumus: arba struktūrinių duomenų nėra visai, arba yra šablono įdėtas Organization ir daugiau nieko. Dažniausios klaidos vienodos: duomenys neatitinka to, kas matoma puslapyje, Article be autoriaus ir datų, Product be kainos ar prieinamumo, ir FAQPage ten, kur DUK puslapyje nėra.

SeoScore

Struktūriniai duomenys yra vienas iš nedaugelio dalykų, kuriuos galima sudėti per vieną dieną ir kurie veikia iš karto. Todėl įdomu, kad praktikoje jų būklė beveik visada ta pati.

Skaičiai remiasi maždaug 500 auditų, atliktų ankstesne mūsų platforma, ir tuo, ką matom šiandien. Tų auditų duomenų eksportų nebeturim, todėl čia — intervalai, ne tiksli statistika.

Ką matom dažniausiai

Organization, įdėtas šablono. Yra pavadinimas, kartais logotipas. Be sameAs, be kontaktų, dažnai su neteisingu url. Tai geriau nei nieko, bet sustoja ties pirmu žingsniu.

Article be nieko. Straipsniai pažymėti kaip Article, bet be author, datePublished ir dateModified. Tai dažniausia klaida iš visų, nes tie trys laukai kaip tik ir sprendžia, ar tekstu galima pasitikėti.

Product be kainos. E. parduotuvėse Product būna, bet offers viduje trūksta price, priceCurrency arba availability — t. y. kaip tik to, dėl ko tas mazgas įdedamas.

FAQPage be DUK. Rečiau, bet skaudžiau: schema deklaruoja klausimus, kurių puslapyje nėra. Tai jau ne trūkumas, o neteisingas teiginys.

Kodėl neatitikimas yra rimčiau nei trūkumas

Google gairės čia aiškios: struktūriniai duomenys turi aprašyti tai, kas puslapyje matoma žmogui. Mazgas, sakantis ne tą, ką rodo puslapis, yra priežastis prarasti rezultatų papuošimus visai — ne tik tam puslapiui.

Todėl tvarka yra tokia: pirma tekstas, tada schema. Ne atvirkščiai.

Ko realiai reikia įprastai svetainei

Trumpas sąrašas, kuris uždaro didžiąją dalį naudos:

  • Organization — vieną kartą, pradiniame puslapyje, su sameAs į realius profilius;
  • WebSite — jei turi vidinę paiešką;
  • BreadcrumbList — visuose gilesniuose puslapiuose, ir etiketė privalo sutapti su matomu trupiniu;
  • Article — straipsniams, būtinai su autoriumi ir abiem datomis;
  • Product su offers — jei parduodi;
  • FAQPage — tik ten, kur DUK realiai yra.

Visa kita yra papildoma ir dažniausiai neduoda nieko, ko neduoda šitas sąrašas.

Kaip pasitikrinti

Greičiausias būdas — Google Rich Results testas vienam puslapiui ir Search Console ataskaita visai svetainei. Skenas tą patį padaro per visus puslapius iš karto ir parodo, kur mazgas yra, bet nepilnas.

Platesnis kontekstas apie tai, kurie tipai realiai reikalingi: struktūriniai duomenys.

Susiję straipsniai

Kas tikrinama, surašyta ties ką tikriname.

Šaltiniai

Tai, kuo remiasi šis tekstas — pirminiai šaltiniai, ne perpasakojimai:

Šablonas įdėjo, žmogus nepratęsė — Dažniausiai yra tik Organization iš šablono; Article be autoriaus ir datų — dažniausia klaida; Duomenys turi sutapti su matomu tekstu; Tuščia schema blogiau nei jokios.

Dažni klausimai

Ar struktūriniai duomenys kelia pozicijas?

Tiesiogiai ne. Jie keičia tai, kaip rezultatas atrodo, ir padeda mašinai suprasti, kas puslapyje yra. Paspaudimų dalis nuo to dažnai pakyla, bet pati pozicija skaičiuojama kitais dalykais.

Ar galima turėti kelis mazgus viename puslapyje?

Taip, ir taip dažnai teisinga: `BreadcrumbList` plius `Article` plius `FAQPage` tame pačiame puslapyje yra normalu, jei visi trys atitinka turinį.

Kas blogiau — jokios schemos ar klaidinga?

Klaidinga. Jokios schemos reiškia praleistą galimybę; klaidinga reiškia neteisingą teiginį mašinai, ir už jį atlyginama praradimu.

Ar JSON-LD geriau nei microdata?

Praktiškai taip. Google rekomenduoja JSON-LD, jį lengviau prižiūrėti, nes jis gyvena vienoje vietoje, o ne išbarstytas po visą HTML.

SEO →

Pasitikrink

Nemokamas skenas parodo, ką iš to, kas aprašyta, tavo svetainė jau daro, o ko — ne.

Skenuoti svetainę →