Structured data og schema markup: hvað á að merkja upp og hvað má sleppa

Flest fyrirtæki þurfa minna schema en þau halda

Structured data hljómar oft stærra og flóknara en það þarf að vera. Fólk sér stjörnur, FAQ box eða aðrar ríkari birtingar í Google og hoppar beint í að bæta alls konar schema á vefinn án þess að stoppa og spyrja einfaldustu spurningarinnar:

• *Hvaða upplýsingar á Google í raun að skilja betur á þessari síðu?**

Ef svarið er óskýrt er mjög líklegt að uppsetningin verði líka óskýr.

Google lýsir structured data sem stöðluðu sniði sem gefur skýrar vísbendingar um merkingu efnis á síðu. Það getur hjálpað Google að skilja síðuna betur og í sumum tilvikum gert hana gjaldgenga fyrir rich results. Það er samt ekki loforð um meiri sýnileika sjálfkrafa og alls ekki staðgengill fyrir gott efni eða skýra uppbyggingu. Introduction to structured data markup in Google Search

Fyrir 55.is og svipuð þjónustufyrirtæki er þetta því ekki “setjum schema alls staðar” verkefni. Þetta er forgangsröðunarverkefni.

Hvað structured data er í raun að gera

Structured data er viðbótarmerking sem hjálpar leitarvélum að lesa samhengi. Í stað þess að sjá bara texta sér Google skýrari vísbendingu um hvort síðan sé grein, þjónusta, fyrirtæki, brauðmylsna, vara eða eitthvað annað.

Það skiptir máli vegna þess að sumar síður verða skýrari í leit þegar merkingin styður það sem er þegar sýnilegt á síðunni. Google mælir almennt með JSON-LD ef tæknilega uppsetningin leyfir það, bæði af því það er auðveldara að viðhalda og síður líklegt til að brotna í templating. General structured data guidelines

Það sem structured data gerir ekki:

• hún lagar ekki þunnt efni
• hún bætir ekki veik headlines eða óskýra þjónustusíðu
• hún tryggir ekki rich result
• hún bjargar ekki síðu sem Google treystir lítið eða skilur illa af öðrum ástæðum

Þess vegna er schema best þegar það styður síðu sem er þegar með skýrt hlutverk.

Byrjaðu á síðutegundinni, ekki á feature-lista

Veikasta leiðin til að vinna með schema er að byrja á því sem væri “gaman að fá” í leitarniðurstöðum. Sterkari leið er að byrja á því sem síðan er.

Til dæmis:

• Forsíða eða fyrirtækjasíða: Organization eða LocalBusiness þar sem það á við
• Þjónustusíða: Service
• Bloggfærsla: Article eða BlogPosting
• Brauðmylsna: BreadcrumbList
• Vörusíða: Product aðeins ef um raunverulega vöruupplýsingu er að ræða
• FAQ: aðeins ef spurningarnar eru sýnilegur og raunverulegur hluti af síðunni

Þessi röð er mikilvæg af því hún dregur úr rugli. Þegar þú velur schema út frá hlutverki síðunnar verður mun auðveldara að sjá hvaða properties eiga heima þar og hvaða merking er bara skraut.

Hvar schema skilar mestu fyrir þjónustufyrirtæki

Ef þú rekur þjónustufyrirtæki er oft nóg að byrja á fáum, sterkum hlutum í stað þess að merkja upp allt.

1. Fyrirtækis- og tengiliðaupplýsingar

Ef fyrirtækið þjónustar ákveðið svæði, er með fasta staðsetningu eða vill gera tengiliðaupplýsingar skýrari, þá getur Organization eða LocalBusiness verið góður grunnur. Þetta á þó aðeins við ef upplýsingarnar eru raunverulega sýnilegar og samræmdar á vefnum.

Fyrir fyrirtæki sem vinna líka í staðbundinni leit tengist þetta beint local SEO. Schema styrkir ekki staðbundna sýnileika eitt og sér, en það getur hjálpað Google að lesa fyrirtækisgögn með skýrari hætti ef restin af grunninum er líka í lagi.

2. Þjónustusíður sem eiga að vera primary pages

Ef þú ert með lykilsíður eins og leitarvélabestun, stafrænar auglýsingar eða vefsíðugerð, þá getur Service schema hjálpað til við að skýra hvað síðan er í raun.

Þetta skiptir mest máli þegar:

• þjónustan er skýrt afmörkuð
• síðan hefur eitt hlutverk
• efnið, titillinn og CTA segja sömu sögu

Ef þjónustusíðan er enn ruglingsleg eða of víð mun schema ekki laga það. Þá þarf fyrst að laga síðuna sjálfa.

3. Blogg og fræðsluefni

Article eða BlogPosting schema er yfirleitt einföld og skynsamleg merking fyrir greinar. Hún er ekki töfralausn, en hún hjálpar til við að festa samhengi: þetta er grein með höfundi, birtingardegi og skýru meginviðfangi.

Á bloggi eins og 55.is er þetta sérstaklega nytsamlegt þegar hver grein hefur skýrt efnislegt hlutverk inni í cluster og leiðir lesandann áfram inn á primary þjónustusíðu.

4. Breadcrumbs

BreadcrumbList er oft vanmetið. Það hjálpar ekki bara notendum á síðunni sjálfri heldur styrkir það líka skýrleika í site architecture.

Ef þú ert að byggja SEO cluster þar sem grein styður þjónustusíðu og fleiri undirsíður tengjast saman er brauðmylsnumerking ein af hreinni leiðunum til að styðja þann strúktúr.

Hvar fólk fer oft útaf sporinu

Structured data verður oft gagnslaus eða jafnvel varasöm þegar fólk reynir að merkja upp meira en síðan stendur undir.

FAQ sem er sett inn bara til að ná auka plássi

Ef FAQ er ekki raunverulegur hluti af síðunni á það ekki að vera í schema heldur. Google er skýrt um að structured data eigi að endurspegla efni sem notandinn sér og að merking sem er villandi eða ekki sýnileg geti valdið því að rich result eligibility tapist. General structured data guidelines

Þess vegna á ekki að bæta við tíu spurningum bara af því “SEO greinar eru oft með FAQ”.

Review eða rating schema án traustrar heimildar

Margir hafa séð stjörnubirtingar og vilja endurtaka það. En ef umsagnirnar eru ekki raunverulegar, sýnilegar og studdar réttum gögnum er þetta veik uppsetning. Það sama gildir ef reynt er að merkja upp þjónustusíðu eins og hún sé vara með aggregate rating bara til að elta snippet.

Of margar tegundir á sömu síðu

Stundum sér maður síðu með Organization, LocalBusiness, Service, FAQ, Review, BreadcrumbList og fleiri tegundum í einu án þess að það sé skýr ástæða fyrir hverri þeirra. Tæknilega getur hluti af þessu verið gilt, en ef meginhlutverk síðunnar verður óskýrt er uppsetningin yfirleitt farin að vinna gegn sjálfri sér.

Sterkari regla er þessi:

• *Settu fyrst upp schema sem skýrir meginhlutverk síðunnar. Bættu svo aðeins við því sem styður það hlutverk.**

Svona myndi ég forgangsraða schema á venjulegum þjónustuvef

Ef markmiðið er að bæta skýrleika og gera grunninn traustari, frekar en að elta hvert mögulegt SERP feature, myndi ég vinna þetta í svona röð:

Skref 1: Merktu upp kjarna síðurnar

Byrjaðu á:

• Organization eða LocalBusiness
• Service á helstu þjónustusíðum
• Article/BlogPosting á bloggi
• BreadcrumbList þar sem notendaflæði styður það

Þetta skilar yfirleitt meiri aga og meiri langtímavirði en að hoppa beint í sértækari tegundir.

Skref 2: Athugaðu hvaða rich results skipta þig raunverulega máli

Google heldur utan um hvaða structured data features það styður í Search. Það er betra að skoða þann lista fyrst en að byggja schema út frá gömlum bloggpóstum eða outdated plugins. Structured data markup that Google Search supports

Spurningin á ekki að vera “hvað er hægt að merkja upp?” heldur:

• *Hvaða rich result er raunhæft fyrir þessa síðu og þjónar leitinni sem hún á að vinna?**

Skref 3: Valideraðu áður en þú telur þetta búið

Google bendir sjálft á Rich Results Test sem fyrsta tækið til að staðfesta merkinguna og síðan Search Console til að fylgjast með stöðu eftir birtingu. Introduction to structured data markup in Google Search

Góð rútína er:

1. skrifa schema sem passar við sýnilegt efni 2. keyra Rich Results Test 3. birta 4. fylgjast með í Search Console 5. laga aðeins það sem skýrt þjónar síðunni

Dæmi um skynsamlega uppsetningu

Segjum að þú sért með þjónustusíðu fyrir SEO.

Síðan er með:

• skýra lýsingu á þjónustunni
• raunveruleg dæmi eða trúverðugleika
• skýra leið að fyrirspurn
• samræmda titla, headinga og efni

Þá gæti skynsamleg merking verið:

• Service fyrir síðuna sjálfa
• BreadcrumbList fyrir leiðsögn
• Organization fyrir vefinn í heild

Ekki:

• Product schema ef þú ert ekki með vörusíðu
• FAQPage ef spurningarnar eru ekki raunverulegur kafli á síðunni
• Review markup ef engar sýnilegar umsagnir með réttum forsendum eru þar

Þetta er oft allur munurinn á schema sem styður SEO vinnu og schema sem lítur bara út fyrir að vera mikið.

Einfalt JSON-LD dæmi fyrir þjónustusíðu

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Leitarvélabestun",
  "provider": {
    "@type": "Organization",
    "name": "55.is",
    "url": "https://55.is"
  },
  "areaServed": "IS",
  "url": "https://55.is/leitarvelabestun",
  "description": "SEO þjónusta fyrir fyrirtæki sem vilja bæta sýnileika og fá fleiri fyrirspurnir."
}

Þetta er ekki flókið og það er nákvæmlega málið. Structured data á oft að vera einfalt ef síðan sjálf er skýr.

Hvenær er betra að sleppa schema í bili?

Stundum er rétta ákvörðunin ekki að bæta við meiri merkingu heldur að laga annað fyrst.

Slepptu eða frestaðu schema vinnu ef:

• síðan er enn ókláruð eða innihaldið breytist stöðugt
• canonical, indexing eða sitemap eru ekki í lagi
• enginn veit hvaða síða á að vera primary fyrir viðfangið
• efnið er of veikt til að standa undir meginmerkingunni

Ef tæknilegi grunnurinn er óhreinn, þá er skynsamlegra að byrja á Search Console, sitemap eða canonical áður en schema er stækkað.

Gátlisti áður en þú setur structured data í loftið

• Lýsir schema því sem síðan er í raun?
• Er efnið sem schema vísar í sýnilegt notandanum?
• Er valin tegund sú skýrust fyrir meginhlutverk síðunnar?
• Er þetta studd tegund eða feature samkvæmt Google Search Central?
• Passa canonical, sitemap og innri tenglar við sömu aðalsíðu?
• Hefurðu keyrt Rich Results Test?

Ef þú getur ekki svarað þessu hreint er betra að stoppa og einfalda uppsetninguna.

Niðurstaða

Structured data er best þegar hún gerir skýra síðu enn skýrari. Hún á ekki að vera skraut, ekki SEO sjónhverfing og ekki leið til að merkja upp hluti sem síðan stendur ekki undir.

Fyrir flest fyrirtæki er sterkasta leiðin að byrja á fáum síðum með skýrt hlutverk, velja schema sem passar því hlutverki og prófa það almennilega. Þá verður uppsetningin bæði trúverðugri og gagnlegri til lengri tíma.

Ef þú vilt vinna þetta í réttri röð skaltu para schema vinnuna við leitarvélabestun, nota Google Search Console til að staðfesta stöðuna og passa að tæknigrunnurinn sé samræmdur áður en þú bætir við flóknari merkingu.