Magsimula sa pahina at isang suportadong feature
Huwag magsimula sa paglalagay ng bawat schema.org type na mukhang may kaugnayan sa iyong negosyo. Malawak ang schema.org bilang isang shared vocabulary, samantalang dinodokumento ng Google’s Search Gallery ang mga rich-result feature na sinusuportahan nito at ang mga property na kailangan ng mga iyon. Ang isang product, event, o article page ay dapat unang kapaki-pakinabang kahit walang markup.
Para sa bawat template, pangalanan ang pangunahing paksa nito at ang nakikitang sumusuportang mga katotohanan. Pagkatapos basahin ang kasalukuyang gabay ng Google para sa tumutugmang feature. Mga halimbawa: Product, Recipe, Article, Breadcrumb, Event, Organization, Local business, at Video. Ang isang vocabulary type lamang ay hindi lumilikha ng Google feature; ang mga kinakailangang property ng feature na iyon ang magtatakda ng pagiging karapat-dapat.
Gawing pangunahing markup ang pangunahing nakikitang item.
Gamitin ang gabay ng Google para sa pag-uugali ng feature at schema.org para sa vocabulary.
Gawing pinagmulan ng katotohanan ang nakikitang pahina
Dapat kumatawan ang markup sa pangunahing nilalaman ng pahina, hindi sa nakatago, hindi mahalaga, o nakalilitong materyal. Kung sinasabing may performer na lalabas, kailangang ilarawan iyon ng pahina. Kung minamarkup ang aggregate rating, kailangang makita ng mga bisita ang rating na iyon. Pinipigilan nito ang isang template na maging nakaliligaw na buod kapag ito ay nag-drift.
Buuin ang copy ng pahina at ang markup mula sa parehong aprubadong record. Maaaring mag-supply ng pareho ang product feed, event system, o CMS, ngunit kailangan i-review ang mga halaga bago i-publish. Huwag kopyahin ang presyo, stock state, petsa, o kabuuang review sa isang markup-only field na maaaring makalimutan. I-update o alisin ang markup kapag nagbago ang nakikitang impormasyon.
Panatilihing naka-align ang mga pangalan, petsa, presyo, availability, at rating sa pahina.
Huwag punan ang mga property ng hinuhulaang o luma na mga halaga.
Gamitin ang JSON-LD bilang isang maintainable data layer
Ang JSON-LD ay isang JSON-based linked-data format na inilalagay sa loob ng HTML document. Sinusuportahan ng Google ang JSON-LD, Microdata, at RDFa, at sinasabi nitong karaniwang pinakamadaling ipatupad at panatilihin sa scale ang JSON-LD. Ang paghihiwalay nito mula sa nakikitang markup ay maaaring gawing mas madaling i-modelo ang nested na impormasyon.
Gumamit ng isang malinaw na data object para sa bawat totoong item, na may angkop na schema.org type at tumpak na sinusuportahang property. Para sa bawat template, i-document ang feature guide, source field, required-field behavior, at owner. Suriin din ang rendered output: maaaring magdagdag ang isang plug-in o component ng duplicate o magkakasalungat na markup.
Pumili ng format na kayang panatilihin nang pare-pareho ng iyong team.
Huwag gumawa ng required value kapag wala ang source data.
I-validate ang code at ang accessible na pahina
Sumasagot ang validation sa dalawang tanong. Una, kumpleto ba ang markup upang suportahan ang isang feature? Tumatanggap ang Rich Results Test ng na-paste na code o isang publicly accessible URL at nire-report ang mga rich result na maaaring mabuo mula sa structured data. Subukan ang representatibong halimbawa para sa bawat template, hindi isang natatanging lubos na kumpletong pahina.
Pangalawa, kaya bang i-access ng Google ang na-release na pahina at mga resource? Huwag i-block ang mga naka-markup na pahina gamit ang robots.txt, noindex, o access controls. Suriin ang mga kaugnay na image URL. Hindi garantiya ng test ang kalidad: maaaring pigilan pa rin ng mga problema sa nakikitang nilalaman o patakaran ang pagpapakita.
Unang i-test ang code, pagkatapos i-test ang isang live public URL.
Ihambing ang rendered page, source, at test result kapag nagdaragdag ng markup ang tooling.
Ang potensyal na pagpapakita ay hindi pangako ng huling pagpapakita.
I-release ito tulad ng pagbabago sa template na nakikita ng user
Madalas nakadepende ang structured data sa mga template, feed, at patakaran sa publikasyon. Maaaring masira ng redesign, pagbabago sa inventory integration, localization update, o inalis na component ang maraming item. Idagdag ang representatibong markup checks sa pre-release review na ginagamit para sa canonical tags, titles, at images. Itala ang template, mga halimbawa ng pahina, source field, at petsa ng release.
Kapag ang isang template ay nag-emit ng maling markup, itama ang shared source o template, i-validate ang maliit na sample, i-deploy ang pinakamaliit na ligtas na pagbabago, at i-retest ang mga apektadong URL. Kung hindi inaasahang kumilos ang pag-aayos, gamitin ang karaniwang rollback process. Ang layunin ay evidence-based na remediation ng isang degraded web capability, hindi isang outage alert.
Suriin ang representatibong set ng mga pahina, hindi isang URL lang.
Itala ang pagbabago at ang markup component bago gawin ang sumusunod na pag-aayos.
Panatilihin, sukatin, at tanggapin ang limitasyon sa pagpapakita
Pagkatapos ng deployment, gamitin ang kaukulang Search Console rich-result report upang siyasatin ang mga isyu at kumpirmahin ang mga pag-aayos. Ang mga report ay mga sample kaysa kompletong imbentaryo, at tumutukoy ang mga bilang sa mga item, hindi mga pahina. Suriin ang isang partikular na URL kung kinakailangan.
Mag-measure nang maingat. Iminumungkahi ng Google ang paghahambing bago-at-pagkatapos sa mga stable, sapat na nababasang pahina sa loob ng mga buwan sa Search Console. Itala ang petsa ng release at iba pang pagbabago sa pahina. Pinapagana lang ng tamang markup ang pagiging karapat-dapat; ang Google ang nagtatakda ng presentasyon sa search.
Muling suriin pagkatapos ng CMS, template, feed, patakaran, o pagbabago sa content model.
Iwasan ang paghahambing na may ibang makabuluhang pagbabago sa pahina.