Hva er strukturerte data (Schema)?

01Hva brukes strukturerte data til?

Når et menneske ser på produktsiden din, forstår det prisen, merket og lagerstatusen med en gang. Søkemotoren ser på den samme siden tall og ord, og må gjette hvilket tall som er prisen og hvilket som er produktkoden. Schema markup fjerner denne gjetningen og gir informasjonen merket.

Det mest synlige resultatet er at siden kvalifiserer for rike resultater (rich results): produktets pris og lagerstatus i søkeresultatet, tilberedningstid for en oppskrift, dato for et arrangement eller en brødsmulesti som viser sidens plassering. Slik ekstra informasjon gjør resultatet mer iøynefallende.

Et viktig faktum: strukturerte data er ingen garanti for rangering, og det er alltid Google som avgjør om et rikt resultat vises. Oppmerkingen gjør siden din til en kandidat for slike visninger, mens kvaliteten på innholdet og nettstedets generelle helse fortsatt er det som avgjør.

02JSON-LD, Microdata og RDFa

Det finnes tre måter å legge strukturerte data inn på en side. Google anbefaler formatet JSON-LD fordi det er enklest å vedlikeholde. JSON-LD legges til som en egen script-blokk uten å røre sidens synlige HTML.

03Pris og lagerstatus med produktskjema

I nettbutikker er Product-skjemaet den mest verdifulle oppmerkingen. Produktnavn, bilde, beskrivelse, merke, pris, valuta og lagerstatus sendes med dette skjemaet. Hvis ekte kundeanmeldelser vises på siden, kan også vurderingen legges til.

Regelen er enkel: all informasjon i skjemaet må være den samme som informasjonen som vises på siden. Å merke opp en vurdering som ikke vises på siden eller en utdatert pris strider mot retningslinjene og kan føre til manuelle tiltak.

• Skriv den faktiske prisen fra siden i prisfeltet. 0.00 i eksemplet er bare en plassholder.
• For produkter med varianter må pris og lagerstatus for hver variant stemme.
• At denne oppmerkingen genereres automatisk på malnivå er en egenskap du bør spørre om når du velger nettbutikkplattform.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Håndlaget lærlommebok",
  "image": "https://ornek.com/img/deri-cuzdan.webp",
  "description": "Håndsydd lommebok av vegetabilsk garvet lær.",
  "brand": {"@type": "Brand", "name": "Eksempelmerke"},
  "sku": "DC-001",
  "offers": {
    "@type": "Offer",
    "url": "https://ornek.com/urun/deri-cuzdan/",
    "priceCurrency": "TRY",
    "price": "0.00",
    "availability": "https://schema.org/InStock"
  }
}
</script>

04Skjema for bedrift og organisasjon

På bedriftsnettsteder definerer Organization-skjemaet, eller LocalBusiness-skjemaet for virksomheter med fysisk adresse, navn, logo, adresse, telefon, åpningstider og profiler i sosiale medier. Det er viktig at disse opplysningene er helt like som i Google Bedriftsprofil og på nettstedets kontaktside.

LocalBusiness har undertyper som Restaurant, Hotel og Dentist. Når du velger den typen som passer best, blir meningen tydeligere. På bedriftsnettsteder bør det å sette opp denne strukturen fra starten være et standardtrinn i prosjekter for bedriftsnettside.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Eksempelbedrift",
  "url": "https://ornek.com/",
  "logo": "https://ornek.com/img/logo.png",
  "telephone": "+90-000-000-00-00",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Eksempelveien 1",
    "addressLocality": "Kommune",
    "addressRegion": "Fylke",
    "addressCountry": "TR"
  },
  "openingHours": "Mo-Sa 09:00-19:00"
}
</script>

05Skjema for artikkel og brødsmulesti

På blogger og nyhetssider angir Article-skjemaet (eller BlogPosting) tittel, forfatter, publiserings- og oppdateringsdato og hovedbilde. Denne informasjonen hjelper søkemotoren å forstå riktig når og av hvem innholdet er skrevet.

BreadcrumbList viser sidens plass i nettstedet: Hjem › Blogg › Kategori › Artikkel. I søkeresultatet kan denne stien vises i stedet for en lang adresse, noe som gjør resultatet mer leselig.

• Forfatternavnet bør være en ekte person eller organisasjon, og om mulig lenke til en forfattersiden.
• Oppdateringsdatoen bør bare endres når innholdet faktisk er oppdatert.
• Brødsmulestien må følge samme struktur som brødsmulestien som er synlig på siden.

06Fungerer FAQ-skjema fortsatt?

FAQ-skjema (FAQPage) ble brukt veldig mye en periode fordi det viste spørsmål som uttrekkbare lister i søkeresultatet. Google begrenset senere dette rike resultatet til en snever gruppe, som autoritative offentlige og helserelaterte nettsteder. For de fleste kommersielle nettsteder vises det ikke lenger.

Likevel er FAQ-oppmerking en gyldig schema.org-type og hjelper maskiner å forstå spørsmål-svar-strukturen på siden. Den egentlige verdien ligger ikke i oppmerkingen, men i selve innholdet som gir klare svar på ekte kundespørsmål. Skriv derfor FAQ-delen for brukeren, ikke i forventning om rike resultater.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Hvor mange dager tar leveringen?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Bestillinger sendes vanligvis innen 1-3 virkedager."
    }
  }]
}
</script>

07Hvilket skjema passer for hvilken bransje?

Hvilket skjema du bør bruke, avhenger av hva nettstedet selger og hva den besøkende leter etter. I stedet for å legge alle mulige typer på hver side er det mer verdifullt å fylle ut noen få typer som virkelig stemmer med innholdet, fullstendig.

For hoteller kan Hotel-typen bære informasjon som adresse, kontakt, fasiliteter og prisklasse. Denne informasjonen må stemme med dataene i bookingsystemet. Hvis en hotellprogramvare som tar imot direkte bestillinger og nettstedet bruker de samme dataene, er det lettere å holde dette konsistent. For restauranter og kafeer kan Restaurant-typen inneholde kjøkkentype, åpningstider og lenke til menyen. For at menyen skal være oppdatert og gjennomsøkbar hjelper det at siden for QR-meny også er åpen på nettet.

For tjenestebedrifter utgjør LocalBusiness og passende undertype, i nettbutikker Product og BreadcrumbList, og på innholdssider Article grunnstrukturen. Å bygge disse typene inn i malene fra starten er den tydeligste forskjellen mellom SEO-vennlig webdesign og oppmerking som legges til i ettertid: når nye sider legges til, oppstår skjemaet av seg selv.

08Testing og oppfølging i Search Console

Test alltid oppmerkingen før du publiserer den. Googles test for rike resultater viser hvilke rike resultater siden kvalifiserer for, og hvilke felt som mangler eller er feil. For generell skjemavalidering kan du også bruke schema.org-validatoren.

Etter publisering lister rapportene under Forbedringer i Search Console opp gyldige og feilaktige elementer for typer som produktsnutter og brødsmulesti. Hvordan du leser advarslene her, har vi forklart nærmere i artikkelen om feil i Search Console.

1. Test en eksempelside i testen for rike resultater, med URL eller som kode.
2. Rett kritiske feil. Ta advarslene i rekkefølge etter viktighet.
3. Bruk malen på alle sidene og følg med på rapportene i Search Console.
4. Kontroller at felt som endrer seg, som pris, lagerstatus og dato, oppdateres automatisk.

09Vanlige feil

Feil i strukturerte data skyldes ofte en enkelt feil i malen og påvirker hundrevis av sider på en gang. Derfor kan de også som regel rettes ett sted.

• Å merke opp informasjon som ikke vises på siden (skjult vurdering, falske anmeldelser).
• Å legge samme bedriftsanmeldelser inn som Product-vurdering på alle sider.
• Å glemme gammel pris- eller lagerinformasjon i hurtigbufferen.
• Å la flere skjemaer som motsier hverandre stå på samme side.
• JSON-syntaksfeil: en manglende komma eller anførselstegn gjør at hele blokken ikke kan leses.