Teenuselehel võib olla suurepärane tekst, kiire laadimisaeg ja tugevad backlink’id, kuid otsingumootoritele võivad siiski jääda ebaselgeks selle põhiasjad: mida ettevõte pakub, keda teenindab, kus tegutseb ning milline leheelement kujutab endast tegelikku arvustust, hinda, sündmust või toodet. Schema markup annab nendele detailidele selgelt määratletud struktuuri.
Õppimine, kuidas rakendada schema markup’it, ei tähenda koodi lisamist lihtsalt koodi pärast. Eesmärk on muuta veebisaidil juba olemas olevad signaalid otsingumootoritele lihtsamini tõlgendatavaks. Õigesti rakendatud schema toetab selgemat indekseerimist, võimalust kvalifitseeruda asjakohaste rich results’i jaoks ning ettevõtte täpsemat esitust otsingus.
Kasvule keskendunud ettevõtete jaoks kuulub see töö pideva tehnilise SEO süsteemi sisse. See peaks olema seotud lehemallide, sisustrateegia, analüütika ja konversioonieesmärkidega – mitte muutuma ühekordseks plugina seadistuseks, mida keegi enam kunagi üle ei vaata.
Mida schema markup teeb – ja mida ei tee
Schema markup on struktureeritud andmed, mis lisatakse tavaliselt JSON-LD koodina lehe HTML-i. See kasutab ühist sõnavara üksuste ja leheelementide märgistamiseks. Kohalik teenuseettevõte võib määratleda oma organisatsiooni, teeninduspiirkonnad, telefoninumbri ja arvustused. E-pood võib määratleda toote hinna, saadavuse, brändi ja hinnangud. Väljaandja võib märgistada artikli, autori ja avaldamiskuupäeva.
See lisakontekst võib aidata otsingumootoritel mõista seoseid, mida tavaline lehetekst alati selgelt ei väljenda. Samuti võib see muuta lehe sobivaks täiustatud otsingukuva jaoks, näiteks tootesnippet’id, arvustuste detailid, breadcrumbs, FAQ-d seal, kus neid toetatakse, või sündmuste info.
Kompromiss on lihtne: schema ei ole otsetee paremate positsioonideni. Product schema lisamine nõrgale tootelehele ei tekita nõudlust, ei paranda kehva sisu ega kompenseeri ebakonkurentsivõimelist pakkumist. Otsingumootorid otsustavad samuti ise, kas rich results’i kuvatakse. Korrektne markup loob võimaluse kvalifitseeruda, mitte garantiid nähtavusele.
Käsitlege schema’t toetava infrastruktuurina. See muudab hästi ehitatud lehe masinloetavamaks, samal ajal kui sisu, tehniline tervis, autoriteet ja konversioonikogemus teevad suurema töö kvalifitseeritud liikluse ligimeelitamisel, konverteerimisel ja skaleerimisel.
Kuidas rakendada schema markup’it ärieesmärkidest lähtuva plaaniga
Alustage lehtedest, millel on äriline väärtus või mis vastavad kõrge kavatsusega küsimustele. Ärge rakendage kogu saidile kõiki võimalikke schema tüüpe ainult seetõttu, et validator ütleb, et see on tehniliselt võimalik. Õige markup peab vastama tegelikule lehele ja toetama selget otsingutulemust.
1. Sobitage schema tüüp lehe eesmärgiga
Avaleht vajab tavaliselt Organization või LocalBusiness markup’it sõltuvalt ärimudelist ja asukohtadest. Teenuselehed võivad kasutada Service schema’t, kui need kirjeldavad selgelt määratletud teenust. Tootelehed vajavad üldjuhul Product ja Offer atribuute. Blogipostitustele sobib sageli Article või BlogPosting markup, samal ajal kui asukohalehed võivad vajada kohaliku ettevõtte detaile ainult siis, kui need detailid on päriselt unikaalsed ja täpsed.
Breadcrumb markup on kasulik paljudel suurematel saitidel, sest see selgitab hierarhiat. See võib aidata otsingumootoritel mõista, kuidas teenus, kategooria või toode veebisaidi arhitektuuri paigutub.
Vältige levinud viga: schema kasutamist millegi kirjeldamiseks, mida kasutajad tegelikult ei näe või kasutada ei saa. Kui leht väidab struktureeritud andmetes viietärniarvustusi, kuid ei kuva tegelikke arvustusi, on see compliance’i ja usalduse probleem. Sama kehtib väljamõeldud saadavuse, paisutatud hindade, nähtamatute FAQ-de ja teenuste kohta, mida ettevõte tegelikult ei paku.
2. Looge järjepidev entity-alus
Enne üksikute lehtede märgistamist määratlege ettevõtte entity üks kord. Kinnitage ametlik ettevõtte nimi, logo, veebiaadress, telefoninumber, sotsiaalmeedia profiilid, aadress seal, kus see on asjakohane, ja peamine ärikategooria. Need detailid peaksid olema järjepidevad kogu veebisaidil ja muudes avalikes ärikataloogides.
Mitme kontoriga ettevõtte puhul otsustage, kas iga asukoht on tegelik tegutsev üksus oma kontaktandmete, töötajate, lahtiolekuaegade ja kohaliku asjakohasusega. Kui jah, võib asukohataseme markup olla sobiv. Kui iga linnaleht viitab samale kontorile ja muudab ainult linna nime, võib LocalBusiness schema lisamine igale lehele õhukeste asukohalehtede probleemi pigem võimendada kui lahendada.
See alus on oluline, sest schema on relatsiooniline. Teie Organization saab olla seotud teenuste, artiklite, toodete, autorite ja asukohtadega. Selged seosed vähendavad saidi kasvades ebaselgust.
3. Kasutage JSON-LD-d ja genereerige see mallitasemel
JSON-LD on tavaliselt kõige praktilisem rakendusformaat, sest see võib paikneda lehe head- või body-osas ilma nähtavat lehesisu häirimata. Seda on lihtsam hooldada kui markup’i lisamist üksikute HTML-elementide ümber, eriti WordPressi, Elementori, e-kaubanduse platvormide ja kohandatud CMS-ide puhul.
Korduvate lehetüüpide puhul genereerige markup CMS-i väljadest. Tootemall peaks võtma tegeliku tootenime, pildi, hinna, valuuta, saadavuse ja canonical URL-i. Artiklimall peaks võtma korrektse pealkirja, featured image’i, autori ning avaldamis- või uuendamiskuupäeva. See kaitseb saiti aegunud markup’i eest siis, kui hind muutub või lehte uuendatakse.
Pluginad võivad olla kasulikud baastaseme Organization, Breadcrumb või Article schema jaoks. Need on vähem usaldusväärsed, kui ettevõte vajab kohandatud teenuseid, keerukaid e-kaubanduse atribuute, mitut asukohta või kohandatud sisumudelit. Ka plugina output vajab ülevaatamist. Kaks tööriista võivad märkamatult luua dubleeriva Organization schema, vastuolulised breadcrumbs’id või ebatäpsed lehetüübid.
4. Lisage ainult atribuudid, mis parandavad täpsust
Igal schema tüübil on kohustuslikud, soovituslikud ja valikulised atribuudid. Täitke esmalt kohustuslikud väljad ja lisage seejärel asjakohased detailid, mida leht selgelt toetab. Product markup’i puhul hõlmab see sageli nime, pilti, kirjeldust, SKU-d seal, kus seda kasutatakse, offers-andmeid ja saadavust. Service markup’i puhul keskenduge teenuse nimele, teenusepakkujale, kirjeldusele ja teeninduspiirkonnale, kui need on täpsed.
Rohkem välju ei ole automaatselt parem. Oletatud, üldise või aegunud infoga väli tekitab hooldusriski. Kõige tugevam schema on konkreetne, tõene ja seotud nähtava lehekogemusega.
Valideerige enne avaldamist ja jälgige pärast launch’i
Schema rakendamisel tuleks kasutada sama kvaliteedikontrolli distsipliini nagu tehnilise release’i puhul. Valideerige markup’i süntaks ja kontrollige, kas leht kvalifitseerub asjakohase Google’i otsingufunktsiooni jaoks. Seejärel kontrollige renderdatud lehte, et veenduda, et struktureeritud andmed säilivad caching’u, minification’i, consent-tööriistade ja JavaScripti käitumise kaudu.
Pärast deployment’i jälgige otsinguaruandlust struktureeritud andmete vigade, warning’ute ja rich-result impressions’ite muutuste osas. Vead nõuavad üldjuhul tegutsemist, sest need võivad takistada kvalifitseerumist. Warning’ud vajavad hinnangut: mõned on kasulikud parendusvõimalused, samas kui teised ei pruugi konkreetse lehe või ärimudeli puhul kehtida.
Praktiline QA-protsess kontrollib nelja asja:
- Markup vastab sellele, mida kasutajad lehel näevad.
- Leht väljastab igast entity’st ühe selge ja mitte-dubleeritud versiooni.
- Dünaamilised väärtused, nagu hind, laoseis, hinnangud ja kuupäevad, püsivad ajakohased.
- Otsinguaruandlus ei näita pärast indekseerimist olulisi rakendusvigu.
E-kaubanduse brändide puhul on selline monitooring eriti oluline. Müügilt eemaldatud toode, kampaaniahind või out-of-stock toode võib kiiresti muutuda. Kuude eest käsitsi lisatud staatiline schema võib muutuda ebatäpseks isegi siis, kui tooteleht ise näeb kasutajatele korrektne välja.
Levinud schema-vead, mis piiravad tulemusi
Suurimad vead on tavaliselt operatiivsed, mitte tehnilised. Ettevõtted paigaldavad schema plugina, märgivad kõik checkbox’id ja eeldavad, et töö on tehtud. Selline lähenemine loob markup’i ilma strateegiata.
Teine levinud probleem on selliste lehtede märgistamine, millel puudub unikaalne väärtus. Service schema lisamine kahekümnele peaaegu identsele linnalehele ei muuda neid kohalikult kasulikumaks. Otsingumootorid hindavad endiselt lehe kvaliteeti, unikaalsust, siselinkimist, jõudlust ja tegeliku ettevõtte usaldusväärsust.
Dubleeriv markup on samuti levinud WordPressi saitidel. Teema, SEO plugin, e-kaubanduse plugin ja page builder võivad kõik genereerida kattuvaid andmeid. Otsingumootorid suudavad neid mõnikord kokku viia, kuid vastuolulised nimed, URL-id, hinnad või ettevõtte andmed tekitavad tarbetut ebaselgust.
Lõpuks ärge mõõtke edu ainult selle järgi, kas rich result ilmub. Jälgige impressions’eid, click-through rate’i, kvalifitseeritud orgaanilisi sessioone, müügivihjeid, tulu ja konversioonimäära lehetüübi kaupa. Otsingukuva täiendus, mis suurendab klikke, kuid toob vähem kvalifitseeritud külastajaid, ei ole automaatselt võit. Äriline eesmärk on parem liiklus, mitte ilusam otsingutulemus.
Muutke schema pideva kasvutöö osaks
Schema vajab tähelepanu siis, kui käivitate uue malli, lisate tooteid, avaldate content hub’i, teete saidile redesign’i, muudate ettevõtte andmeid või näete otsinguaruandluses probleeme. Samuti vajab see ülevaatamist siis, kui otsingufunktsioonide nõuded muutuvad. See, mis töötas aasta tagasi, ei pruugi enam olla kõige kasulikum või kvalifitseeruv markup’i strateegia.
3Q Studios käsitletakse schema’t ühe tehnilise aluse kihina koos crawlability, lehekiiruse, siselinkimise, konversiooniteekondade ja mõõtmisega. Nii kumuleerivad veebisaidi tulemused aja jooksul: iga parendus toetab järgmist selle asemel, et jääda isoleeritud ülesandeks.
Alustage tulule kõige lähemal olevatest lehtedest, muutke andmed täpseks ja looge hooldusprotsess, mida teie meeskond suudab järjepidevalt hallata. Eesmärk ei ole lisada rohkem koodi. Eesmärk on aidata otsingumootoritel mõista ettevõtet, mille olete üles ehitanud, ja suunata õiged külastajad lehtedele, mis on loodud konverteerima.
