SEO & Discoverability

Kurie schema.org tipai iš tikrųjų daro įtaką paieškos rezultatams

Praktinis struktūrinių duomenų vadovas: kas gali pakeisti jūsų puslapių išvaizdą paieškoje ir kuris žymėjimas daugiausia padeda mašinoms jus suprasti.

The Wux Webtools Team The Wux Webtools Team 12 min skaityti Pagal AI, peržiūrėta žmogaus
Structured data blocks connected to enhanced search result cards.
Turinys
  1. Trumpas atsakymas
  2. Pirma: struktūriniai duomenys suteikia tinkamumą, o ne garantiją
  3. Tipai, turintys aiškiausią poveikį
  4. Product, Offer, AggregateRating ir Review
  5. BreadcrumbList
  6. Article, NewsArticle ir BlogPosting
  7. LocalBusiness ir jo potipiai
  8. Event
  9. JobPosting
  10. Recipe
  11. VideoObject
  12. Organization, Logo ir WebSite
  13. FAQPage: techniškai palaikomas, bet daugumai svetainių retai matomas
  14. DiscussionForumPosting ir ProfilePage
  15. Tipai, kurie naudingi, bet dažnai pervertinami
  16. JSON-LD paprastai yra geriausias įgyvendinimo formatas
  17. Praktinis prioritetų nustatymo modelis
  18. Dažnos klaidos, mažinančios poveikį
  19. Netinkamo puslapio tipo žymėjimas
  20. Savybių, kurios nėra matomos, pridėjimas
  21. Validavimo laikymas sėkme
  22. Schema įgyvendinimas vieną kartą ir pamiršimas
  23. Rami rekomendacija

Trumpas atsakymas

Schema.org žymėjimas automatiškai nepagerina pozicijų. Tačiau jis gali suteikti puslapiui teisę būti rodomam išplėstais paieškos formatais: rich results, produktų skydeliuose, breadcrumbs, renginių sąrašuose, darbo skelbimų moduliuose, vaizdo įrašų peržiūrose ir panašiose funkcijose.

Šis skirtumas svarbus. Schema.org yra platus žodynas, skirtas aprašyti dalykus internete. Paieškos sistemos palaiko tik jo dalį, o kiekviena paieškos funkcija turi savas taisykles. Galite tobulai pažymėti puslapį naudodami Thing, CreativeWork arba Service ir nematyti jokio matomo pokyčio paieškos rezultatuose, nes su tuo tipu gali būti nesusieta jokia paieškos funkcija.

Todėl naudingas klausimas nėra „Kokie schema tipai egzistuoja?“ Jis yra toks: „Kokius schema tipus paieškos sistemos naudoja matomoms ar operacinėms paieškos funkcijoms sukurti?“

Toliau pateikiamas praktinis atsakymas.

Pirma: struktūriniai duomenys suteikia tinkamumą, o ne garantiją

Struktūriniai duomenys suteikia paieškos sistemoms aiškių užuominų. Jie nepriverčia jų nieko rodyti.

Paprastai puslapiui reikia visų šių dalykų, kad struktūriniai duomenys turėtų kokį nors matomą poveikį:

  • Žymėjimas turi atitikti matomą puslapio turinį.
  • Turi būti pateiktos privalomos ir rekomenduojamos savybės.
  • Puslapis turi būti indeksuojamas ir neužblokuotas robots taisyklėmis.
  • Turinys turi atitikti kokybės ir šlamšto politiką.
  • Paieškos sistema turi nuspręsti, kad išplėstas rezultatas padeda naudotojui.

Štai kodėl du techniškai validūs puslapiai paieškoje gali elgtis skirtingai. Vienas gali gauti produkto rich result; kitas gali būti rodomas kaip paprasta mėlyna nuoroda. Žymėjimas yra tik vienas įvesties signalas.

Dėl tos pačios priežasties vaikytis neaiškių schema tipų paprastai yra prastas laiko panaudojimas. Jei su tipu nesusieta palaikoma paieškos funkcija, nauda dažniausiai yra semantinė, o ne vizualinė.

Tipai, turintys aiškiausią poveikį

Product, Offer, AggregateRating ir Review

Elektroninės prekybos ir programinės įrangos puslapiams produkto žymėjimas yra viena matomiausiai naudingų struktūrinių duomenų šeimų.

Product puslapis gali tapti tinkamas kainos, prieinamumo, įvertinimo, pristatymo, grąžinimo ir prekybininko sąrašų funkcijoms. Svarbiausi pagalbiniai tipai paprastai yra:

  • Offer kainai, valiutai, prieinamumui ir pardavėjo informacijai
  • AggregateRating apibendrintiems įvertinimams
  • Review atskiriems atsiliepimams, kai tai tinkama
  • Brand arba Organization gamintojo ar pardavėjo kontekstui

Šis žymėjimas naudingiausias tada, kai puslapis iš tiesų yra apie konkretų produktą, o ne apie kategoriją ar neapibrėžtą paslaugų puslapį. Paieškos sistemos vis griežčiau žiūri į atsiliepimų ir įvertinimų piktnaudžiavimą, ypač į savanaudiškus atsiliepimus. Jei įvertinimas puslapyje naudotojams nematomas, jo nežymėkite.

Produkto schema gali paveikti ir klasikinius organinius snippets, ir prekybininko tipo paviršius. Mažmenininkams tai dažnai yra viena didžiausios grąžos struktūrinių duomenų įgyvendinimo sričių.

BreadcrumbList nėra įspūdingas, bet praktiškas. Jis gali paveikti URL / kelio rodymą paieškos rezultatuose, pakeisdamas netvarkingą URL švaresne hierarchija.

Breadcrumb žymėjimas naudingas:

  • Elektroninės prekybos kategorijų ir produktų puslapiams
  • Dokumentacijos svetainėms
  • Dideliems tinklaraščiams ir leidiniams
  • SaaS pagalbos centrams

Jis retai sukuria dramatišką rich result, bet gali pagerinti suprantamumą. Naudotojai prieš spustelėdami gali matyti, kur puslapis yra svetainėje. Paieškos sistemos taip pat gauna aiškesnį svetainės struktūros vaizdą.

Jei jūsų svetainės navigacija yra gili, breadcrumb žymėjimą verta įgyvendinti anksti.

Article, NewsArticle ir BlogPosting

Article, NewsArticle ir BlogPosting gali padėti paieškos sistemoms suprasti antraštę, autorių, datą, vaizdą ir leidėjo informaciją. Leidėjams tai gali paveikti tinkamumą į straipsnius orientuotoms funkcijoms, ypač kartu su geru nuskaitymu, šviežumu ir turinio kokybe.

Nesitikėkite, kad article schema paprastą tinklaraščio įrašą pavers naujienų rezultatu. Ji nekompensuos silpnos žurnalistikos, trūkstamos autoriaus informacijos ar paviršutiniško turinio.

Vis dėlto editorialinėms svetainėms straipsnių žymėjimas yra prasmingas. Naudokite jį, kad pagrindiniai faktai būtų nedviprasmiški:

  • Antraštė
  • Autorius arba organizacija
  • Publikavimo data ir keitimo data
  • Pagrindinis vaizdas
  • Leidėjas
  • Kanoninis URL

Jei jūsų komanda naudoja AI padedamą publikavimą, struktūriniai duomenys nėra atskleidimo ar redakcinės atsakomybės pakaitalas. Žmogiškąją to pusę aptarėme straipsnyje kaip atrodo sąžiningas AI atskleidimas mažoje svetainėje. Paieškos sistemos gali analizuoti jūsų žymėjimą, bet skaitytojai vertina patį puslapį.

LocalBusiness ir jo potipiai

Vietinėms organizacijoms LocalBusiness ir jo potipiai — tokie kaip Restaurant, Dentist, Store arba ProfessionalService — gali padėti susieti svetainę su verslo faktais: pavadinimu, adresu, telefono numeriu, darbo valandomis, geografinėmis koordinatėmis ir same-as profiliais.

Matomas poveikis mažiau nuspėjamas nei produkto ar recepto žymėjimo, nes vietinė paieška labai priklauso nuo verslo įrašų, atstumo, žinomumo, atsiliepimų ir naudotojo ketinimo. Vis dėlto nuoseklus vietinio verslo žymėjimas yra naudinga higiena.

Naudokite jį puslapyje, kuris reprezentuoja verslo vietą, o ne atsitiktinai kiekviename tinklaraščio įraše. Jei turite kelias vietas, kiekvieną vietos puslapį pažymėkite jo pačio adresu ir darbo valandomis.

Event

Event žymėjimas gali padaryti puslapius tinkamus būti rodomus su datomis, vietomis ir bilietų informacija su renginiais susijusiose paieškos funkcijose.

Tai gerai tinka:

  • Koncertams
  • Konferencijoms
  • Webinarams
  • Užsiėmimams
  • Festivaliams
  • Bendruomenės renginiams

Svarbiausia — konkretumas. Puslapis apie „mūsų kasmetinę mokymų programą“ nėra tas pats, kas puslapis apie konkrečios datos renginį su pradžios laiku, vieta, organizatoriumi ir dalyvavimo būdu.

Internetiniams renginiams įtraukite virtualaus dalyvavimo informaciją. Fizinėms renginių vietoms įtraukite venue informaciją. Atšauktus, atidėtus ir perkeltus renginius atnaujinkite; pasenęs renginio žymėjimas yra blogiau nei jokio žymėjimo.

JobPosting

JobPosting yra vienas aiškiausių pavyzdžių, kai struktūriniai duomenys maitina konkrečią paieškos patirtį. Tinkamai pažymėti darbo skelbimų puslapiai gali tapti tinkami darbo paieškos funkcijoms, įskaitant pareigas, vietą, atlyginimą, užimtumo tipą ir paskelbimo datą.

Šis žymėjimas naudingas tik tikruose darbo skelbimų puslapiuose. Netaikykite jo bendriesiems karjeros puslapiams, kuriuose išvardijamos kelios pareigos be atskirų išsamių puslapių.

Svarbūs laukai:

  • Pareigų pavadinimas
  • Samdanti organizacija
  • Vieta arba nuotolinio darbo būsena
  • Paskelbimo data
  • Galiojimo pabaigos data
  • Užimtumo tipas
  • Atlygis, kai prieinamas

Pasibaigę darbo skelbimai turėtų būti pašalinti, tinkamai nukreipti arba pažymėti kaip nebegaliojantys. Paieškos sistemoms nepatinka siųsti naudotojų į nebeaktyvias pozicijas.

Recipe

Recipe žymėjimas išlieka vienu klasikinių rich-result atvejų. Jis gali paveikti vaizdų miniatiūras, įvertinimus, gaminimo laiką, ingredientus, maistingumą ir vedamas receptų patirtis.

Tai taip pat viena labiausiai piktnaudžiaujamų struktūrinių duomenų sričių. Jei puslapis daugiausia yra asmeninis esė, o receptas paslėptas apačioje, žymėjimas vis tiek turi tiksliai aprašyti matomą receptą. Struktūriniai duomenys neturėtų teigti, kad paruošimas trunka penkias minutes, jei instrukcijos sako kitaip.

Receptų puslapiuose daug vaizdų, todėl struktūriniai duomenys yra tik dalis darbo. Geri vaizdai, protingas glaudinimas ir naudingas alt tekstas taip pat svarbūs. Jei tvarkote maisto, produktų ar editorialinius vaizdus, pragmatiškas vaizdų alt teksto vadovas 2026 m. yra naudingas schema darbų palydovas.

VideoObject

VideoObject žymėjimas gali paveikti vaizdo įrašų peržiūras, pagrindinius momentus, miniatiūras, trukmę, įkėlimo datą ir vaizdo įrašų indeksavimą. Jis naudingas, kai vaizdo įrašas yra reikšminga puslapio dalis, o ne atsitiktinis embed apačioje.

Mažiausiai pateikite:

  • Pavadinimą
  • Aprašymą
  • Miniatiūros URL
  • Įkėlimo datą
  • Trukmę
  • Embed arba turinio URL

Instrukciniams ar ilgos formos vaizdo įrašams pagrindiniai momentai gali padėti paieškos sistemoms suprasti vaizdo įrašo dalis. Tai gali pagerinti, kaip vaizdo įrašas atrodo paieškoje, nors, vėlgi, negarantuoja vietos.

Organization, Logo ir WebSite

Organization žymėjimas padeda apibrėžti už svetainės esančią esybę. WebSite gali palaikyti svetainės lygio supratimą ir kai kuriais atvejais tokias funkcijas kaip sitelinks search box, kai paieškos sistema pasirenka ją rodyti.

Šis žymėjimas yra pamatinis, o ne efektingas. Jis gali padėti paaiškinti:

  • Oficialią svetainės tapatybę
  • Logotipą
  • Socialinius profilius
  • Kontaktinę informaciją
  • Patronuojančios ar dukterinės įmonės ryšius

Kiekvienas rimtas verslas, leidinys, ne pelno organizacija ir produktų įmonė turėtų turėti tvarkingą organization žymėjimą stabilioje vietoje, paprastai pagrindiniame puslapyje arba puslapyje apie mus.

Neprikimškite į jį visų įmanomų savybių. Tikslas yra esybės aiškumas, o ne duomenų bazės išpylimas.

FAQPage: techniškai palaikomas, bet daugumai svetainių retai matomas

FAQPage nusipelno atskiros pastabos, nes anksčiau tai buvo lengvas laimėjimas. Daugelį metų FAQ žymėjimas galėjo išplėsti snippets klausimų ir atsakymų akordeonais. Dėl to jis tapo patrauklus ir, nuspėjamai, pernaudojamas.

Vėliau Google smarkiai apribojo FAQ rich results, paprastai rodydama juos tik gerai žinomoms autoritetingoms valdžios ir sveikatos svetainėms. Kitos paieškos sistemos vis dar gali naudoti FAQ žymėjimą kitaip, o žymėjimas vis dar gali padėti mašinoms suprasti turinio struktūrą, tačiau dauguma komercinių ir editorialinių svetainių neturėtų tikėtis matomų FAQ rich results.

Naudokite FAQ žymėjimą tik tada, kai puslapyje iš tiesų yra FAQ. Nepridėkite netikrų Q&A blokų vien tam, kad vaikytumėtės paieškos ploto.

DiscussionForumPosting ir ProfilePage

Bendruomenių turinys paieškos rezultatuose tapo ryškesnis, o struktūriniai duomenys gali padėti identifikuoti forumų gijas ir profilių puslapius.

DiscussionForumPosting gali būti naudingas forumams, Q&A bendruomenėms ir diskusijų platformoms, kuriose pagrindinis turinys yra naudotojų kuriama diskusija. ProfilePage gali padėti identifikuoti puslapius apie žmones ar bendraautorius, ypač kai svarbi ekspertizė, autorystė ar bendruomenės tapatybė.

Tai netinka įprastiems rinkodaros atsiliepimams ar tinklaraščio komentarams. Puslapio tipas turi atitikti tikrąją patirtį.

Tipai, kurie naudingi, bet dažnai pervertinami

Kai kurie schema.org tipai yra semantiškai pagrįsti, bet patys savaime retai sukuria matomus paieškos patobulinimus.

Pavyzdžiai:

  • Service
  • Thing
  • CreativeWork
  • Person
  • Place
  • ImageObject
  • WebPage
  • AboutPage
  • ContactPage

Tai nėra „blogi“ tipai. Jie gali padėti tiksliau aprašyti puslapį ir gali būti naudingi platesniuose žinių grafų kontekstuose. Tačiau jei jūsų tikslas yra matomas pokytis paieškos rezultatuose, jie paprastai yra antriniai.

Pavyzdžiui, konsultacijų puslapio pažymėjimas kaip Service patikimai nesukurs specialaus paslaugos rich result. Gerai struktūruotas puslapis su aiškiu tekstu, vidinėmis nuorodomis, greitu atvaizdavimu ir patikimais įrodymais paieškos rezultatams padarys daugiau nei sudėtingas, bet nepalaikomas žymėjimas.

Panašiai ImageObject gali aprašyti vaizdus, bet vaizdų paieškos rezultatai taip pat priklauso nuo aplinkinio teksto, failų pavadinimų, antraščių, vaizdo kokybės, indeksavimo ir prieinamumo. Schema nėra pagrindų pakaitalas.

JSON-LD paprastai yra geriausias įgyvendinimo formatas

Paieškos sistemos gali skaityti kelis struktūrinių duomenų formatus, įskaitant Microdata ir RDFa, tačiau JSON-LD paprastai yra švariausias pasirinkimas.

Jis laiko žymėjimą atskirai nuo HTML pateikimo, jį lengviau testuoti ir mažiau tikėtina, kad jis suges dizaineriams keičiant šablonus. Daugumai komandų JSON-LD puslapio head arba body dalyje yra praktinis numatytasis pasirinkimas.

Paprastas produkto pavyzdys atrodo taip:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Acme Carbon Tripod",
  "image": "https://example.com/images/tripod.jpg",
  "description": "A lightweight carbon tripod for travel photography.",
  "brand": {
    "@type": "Brand",
    "name": "Acme"
  },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "149.00",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/products/carbon-tripod"
  }
}

Pavyzdys sąmoningai paprastas. Dauguma struktūrinių duomenų turėtų būti nuobodūs. Tikslumas pranoksta gudrumą.

Praktinis prioritetų nustatymo modelis

Jei sprendžiate, ką įgyvendinti pirmiausia, naudokite šią tvarką:

  1. Pradėkite nuo puslapių tipų, kurie susiejami su palaikomomis paieškos funkcijomis. Product, recipe, event, job, video, breadcrumb, article ir local business žymėjimas paprastai nusipelno dėmesio prieš neaiškius tipus.
  2. Žymėkite tik tai, ką naudotojai gali matyti. Paslėpti teiginiai yra dažna priežastis, kodėl struktūriniai duomenys tampa netinkami arba rizikingi.
  3. Taisykite šablonus, o ne atskirus puslapius. Struktūrinius duomenis lengviausia prižiūrėti, kai jie generuojami iš jūsų CMS arba produktų duomenų bazės.
  4. Validuokite, tada stebėkite. Naudokite oficialius rich result ir schema validavimo įrankius, tada stebėkite Search Console patobulinimų ataskaitas, kai jos prieinamos.
  5. Neignoruokite puslapio patirties. Rich results gali padėti pateikimui, bet naudotojai vis tiek patenka į puslapį. Jei našumo ataskaitos kelia jūsų komandai nerimą, skaitykite Lighthouse ataskaitas nepanikuodami prieš paversdami schema dar vienu dėmesio blaškymu.

Dažnos klaidos, mažinančios poveikį

Netinkamo puslapio tipo žymėjimas

Kategorijos puslapis nėra produkto puslapis. Karjeros įvadinis puslapis nėra darbo skelbimas. Būsimų webinarų sąrašas nebūtinai yra vienas renginys.

Paieškos funkcijos paprastai kuriamos konkretiems puslapių ketinimams. Suderinkite žymėjimą su dominuojančiu puslapio tikslu.

Savybių, kurios nėra matomos, pridėjimas

Jei puslapis nerodo įvertinimo, neįtraukite aggregateRating. Jei darbo skelbimo puslapyje neminimas atlyginimas, atsargiai vertinkite kompensacijos žymėjimo išgalvojimą. Jei produkto nėra sandėlyje, nežymėkite jo kaip esančio sandėlyje.

Struktūriniai duomenys turėtų palengvinti matomų faktų analizę, o ne sukurti paralelinę puslapio versiją.

Validavimo laikymas sėkme

Validatoriaus patvirtinimas reiškia tik tai, kad sintaksė priimtina ir privalomi laukai gali būti pateikti. Tai nereiškia, kad puslapis gaus rich result.

Galvokite apie validavimą kaip apie pagrindą, o ne rezultatą.

Schema įgyvendinimas vieną kartą ir pamiršimas

Kainos keičiasi. Darbo skelbimai pasibaigia. Renginiai atidedami. Autoriai išeina. Logotipai perdizainuojami.

Struktūriniai duomenys, generuojami iš pasenusių laukų, gali tyliai tapti netikslūs. Peržiūrėkite juos kaskart keisdami šablonus, CMS laukus ar verslo duomenų šaltinius.

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

💡 Išbandykite tai: Prieš aiškindamiesi, kurie schemų tipai iš tikrųjų svarbūs, sutvarkykite savo JSON-LD naudodami JSON Formatter, kad struktūrą būtų lengva audituoti.

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

Rami rekomendacija

Daugumai svetainių schema strategija turėtų būti kukli ir apgalvota.

Įgyvendinkite tipus, kurie atitinka jūsų tikrą turinį ir susiejami su palaikomomis paieškos funkcijomis. Laikykite duomenis tikslius. Generuokite juos iš patikimų šaltinių. Validuokite. Stebėkite rezultatus. Tada sustokite.

Jums nereikia žymėti kiekvieno daiktavardžio puslapyje. Jums nereikia dvylikos įdėtų schema tipų vien todėl, kad taip nurodė kontrolinis sąrašas. Ir jums tikrai nereikia struktūrinių duomenų, kurie pasako daugiau nei pats puslapis.

Schema.org naudingiausia tada, kai pašalina dviprasmiškumą. Paieškos rezultatai gerėja, kai tas aiškumas sutampa su funkcija, kurią paieškos sistemos iš tikrųjų palaiko.

Dažnai užduodami klausimai

Ar schema.org žymėjimas pagerina pozicijas?
Ne tiesiogiai. Struktūriniai duomenys padeda paieškos sistemoms suprasti puslapio turinį ir gali padaryti puslapius tinkamus rich results. Tokia išplėsta išvaizda gali pagerinti paspaudimų rodiklį, bet vien žymėjimas nėra trumpas kelias į aukštesnes pozicijas.
Kurį schema tipą dauguma svetainių turėtų įgyvendinti pirmiausia?
Pradėkite nuo žymėjimo, kuris atitinka jūsų pagrindinius puslapių tipus. Elektroninės prekybos svetainės turėtų teikti pirmenybę Product ir BreadcrumbList. Leidėjai turėtų naudoti Article arba BlogPosting. Vietiniai verslai turėtų naudoti LocalBusiness. Svetainės su vaizdo įrašais, renginiais, darbo skelbimais ar receptais turėtų teikti pirmenybę tiems konkretiems tipams.
Ar FAQ schema vis dar verta naudoti?
Tik tada, kai puslapyje iš tiesų yra FAQ. FAQ rich results matomi daug rečiau nei anksčiau, ypač įprastoms komercinėms svetainėms. Nepridėkite dirbtinių FAQ skyrių vien tam, kad vaikytumėtės paieškos funkcijų.
Ar turėčiau naudoti JSON-LD, Microdata ar RDFa?
JSON-LD paprastai yra geriausias pasirinkimas šiuolaikinėms svetainėms. Jį lengviau prižiūrėti, jis mažiau susipynęs su šablonais ir paieškos sistemos plačiai rekomenduoja jį palaikomiems struktūriniams duomenims.
Ar galiu pridėti schema turiniui, kurio naudotojai nemato?
Paprastai ne. Struktūriniai duomenys turėtų aprašyti turinį, kuris puslapyje yra matomas ir tikslus. Paslėpti įvertinimai, išgalvotos kainos, netikras prieinamumas ar klaidinantys renginio duomenys gali padaryti puslapius netinkamus rich results arba pažeisti paieškos politiką.

Šaltiniai ir tolesnis skaitymas

  1. Google Search Central: Structured data markup that Google Search supports
  2. Google Search Central: Intro to structured data markup in Google Search
  3. Schema.org Documentation
  4. Google Search Central Blog: Changes to HowTo and FAQ rich results
Apie autorių
The Wux Webtools Team

Paskutinį kartą atnaujinta:

Tęsti skaitymą