#TEKNISK SEO
16 min lesing 2026-07-20

Schema markup og JSON-LD: komplett norsk guide

Lær å velge, implementere og teste schema markup i JSON-LD. Med korrekte eksempler for Organization, Article, BreadcrumbList og Product.

MS
Maaz Surchy
Ansvarlig avsender
📌 Del av tema-klyngen: TEKNISK SEOGå til Hovedguide
Emneklynge: Teknisk SEO

Relaterte artikler i denne silogruppen:

Schema markup og JSON-LD: komplett norsk guideDu leser nå
Google Search Console-guide: fra visninger til SEO-tiltakLes guide →

Schema markup og JSON-LD: komplett norsk guide#

Schema markup, eller strukturert data, er maskinlesbar informasjon som beskriver hva en side og elementene på den representerer. Med riktig markup kan du fortelle at innholdet er en artikkel, at en navnekjede er brødsmuler, eller at en side beskriver et bestemt produkt.

Google kan bruke opplysningene til å forstå siden og gjøre den kvalifisert for bestemte rike søkeresultater. Kvalifisert er nøkkelordet: korrekt strukturert data garanterer verken rikt resultat, bedre rangering eller indeksering.

Denne guiden viser hvordan norske nettsteder velger riktig type, skriver vedlikeholdbar JSON-LD og unngår markup som ikke samsvarer med det brukeren ser.

Kort svar: Schema.org, schema markup og JSON-LD#

  • Schema.org er ordforrådet med typer og egenskaper, som Organization, Article og name.
  • Schema markup er den strukturerte informasjonen du legger på nettsiden.
  • JSON-LD er et JSON-format for å uttrykke informasjonen. Google anbefaler ofte JSON-LD fordi det er enkelt å implementere uten å blande markup inn i synlig HTML.
  • Rikt resultat er en søkefunksjon som kan vise mer enn en vanlig lenke når siden, markuppen og situasjonen oppfyller kravene.
Google støtter også Microdata og RDFa. Velg formatet teamet kan generere korrekt og holde synkronisert. For de fleste moderne nettsteder er JSON-LD et praktisk førstevalg.

Hva strukturert data kan – og ikke kan – gjøre#

Strukturert data kan:
  • gi eksplisitte opplysninger om innholdstype og relasjoner
  • gjøre kvalifiserte sider tilgjengelige for støttede søkefunksjoner
  • beskrive forfatter, publiseringsdato, produktpris eller organisasjonsdetaljer
  • gi konsistente signaler på tvers av sidemaler
Strukturert data kan ikke:
  • gjøre svakt eller irrelevant innhold nyttig
  • tvinge Google til å vise stjerner, pris, bilde eller FAQ
  • erstatte crawlbar HTML, canonical eller interne lenker
  • legitimere anmeldelser eller priser som ikke finnes synlig på siden
  • automatisk etablere E-E-A-T eller plassering i Knowledge Graph
Behandle schema som et presist datalag over innholdet, ikke som en snarvei til rangering.

Velg bare typer som passer siden#

Start i Googles galleri over støttet strukturert data, ikke med en tilfeldig liste over alle typene på Schema.org. Google støtter bestemte typer og egenskaper for søkefunksjonene sine.

| Sidetype | Aktuell markup | Når den passer |
|---|---|---|
| Forside eller om-side | Organization eller relevant undertype | Beskriver den faktiske virksomheten |
| Bloggartikkel | BlogPosting eller Article | Synlig redaksjonelt innhold med korrekt forfatter og dato |
| Navigasjonshierarki | BreadcrumbList | Brødsmuler til siden |
| Produktdetaljside | Product | Ett identifiserbart produkt med samsvarende pris og tilgjengelighet |
| Lokal virksomhet | Spesifikk LocalBusiness-undertype | Reell fysisk virksomhet og korrekte lokale opplysninger |
| Oppskrift, arrangement eller stilling | Dokumentert spesialtype | Siden oppfyller alle innholds- og tekniske krav |
Ikke legg Product på en generell tjenesteside bare for å få pris eller stjerner. Ikke bruk LocalBusiness for virtuelle bysider uten reelle lokasjoner. Den mest spesifikke korrekte typen er bedre enn en imponerende, men uriktig type.

Organization: én tydelig virksomhetsidentitet#

Google anbefaler normalt organisasjonsinformasjon på forsiden eller én side som beskriver virksomheten; den trenger ikke kopieres til alle sider. Ta med opplysninger som finnes og kan verifiseres.
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://eksempel.no/#organization",
  "name": "Eksempel AS",
  "url": "https://eksempel.no/",
  "logo": "https://eksempel.no/logo.png",
  "email": "post@eksempel.no",
  "sameAs": [
    "https://www.linkedin.com/company/eksempel"
  ]
}
Bruk sameAs bare for profiler som faktisk representerer organisasjonen. En stabil @id kan brukes hvis organisasjonen refereres fra andre noder, for eksempel som utgiver av en artikkel. Ikke dikt opp telefon, adresse eller profiler for å fylle alle feltene.
For en butikk eller fysisk virksomhet kan en mer spesifikk undertype være riktigere. Følg da dokumentasjonen for den typen og sørg for samsvar med kontakt- og stedsinformasjonen brukeren ser.

Article og BlogPosting: beskriv den faktiske artikkelen#

Article, NewsArticle og BlogPosting kan hjelpe Google å forstå overskrift, bilder, dato og forfatter. Markup er ikke et krav for å bli indeksert eller vist i Google News.
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://eksempel.no/blogg/seo-guide#article",
  "mainEntityOfPage": "https://eksempel.no/blogg/seo-guide",
  "headline": "SEO-guide for norske bedrifter",
  "description": "En praktisk introduksjon til norsk SEO.",
  "image": [
    "https://eksempel.no/bilder/seo-guide-16x9.jpg"
  ],
  "datePublished": "2026-07-20",
  "dateModified": "2026-08-13",
  "author": {
    "@type": "Person",
    "name": "Ola Nordmann",
    "url": "https://eksempel.no/forfattere/ola-nordmann"
  },
  "publisher": {
    "@id": "https://eksempel.no/#organization"
  }
}
Overskrift, forfatter og datoer må samsvare med siden. dateModified skal endres når innholdet faktisk revideres, ikke ved hver bygging eller sidevisning. Bruk en ekte forfatterside når den finnes.
Brødsmulemarkup kan forklare hvor siden hører hjemme i hierarkiet. Hvert listepunkt får posisjon, navn og URL.
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Forside",
      "item": "https://eksempel.no/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "SEO-guider",
      "item": "https://eksempel.no/blogg/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Schema markup"
    }
  ]
}

Rekkefølgen skal gjenspeile en fornuftig brukerreise. Breadcrumb-schema erstatter ikke god navigasjon eller interne lenker.

Product: pris, tilgjengelighet og anmeldelser#

Produktmarkup har mange detaljer og to hovedsituasjoner i Google: produktsnutter og merchant listings. Kravene varierer. Følg dokumentasjonen for funksjonen nettbutikken faktisk trenger.
Et forenklet eksempel uten anmeldelser:
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Eksempelstol",
  "image": ["https://butikk.no/bilder/eksempelstol.jpg"],
  "description": "Ergonomisk kontorstol i svart stoff.",
  "sku": "STOL-100",
  "brand": {
    "@type": "Brand",
    "name": "Eksempel"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://butikk.no/produkter/eksempelstol",
    "priceCurrency": "NOK",
    "price": "3490.00",
    "availability": "https://schema.org/InStock"
  }
}
Pris og lagerstatus må oppdateres samtidig med det synlige produktet. Hvis markuppen sier «på lager» mens siden sier utsolgt, er datalaget feil. Anmeldelser må komme fra reelle, synlige anmeldelser og følge Googles retningslinjer. Ikke legg inn en egenkomponert aggregateRating.

FAQPage og QAPage: to vanlige feilvalg#

FAQPage er for en side med spørsmål og svar skrevet av nettstedet. Google begrenser imidlertid FAQ-rike resultater til kjente, autoritative myndighets- og helsenettsteder. For et vanlig norsk kommersielt nettsted gir FAQ-markup derfor normalt ingen synlig søkefunksjon. Den kan beholdes når den er korrekt, men bør ikke prioriteres som et trafikktiltak.
QAPage er noe annet: siden fokuserer på ett spørsmål der brukere kan sende inn alternative svar, som et forum. En bloggpost som svarer på et spørsmål er ikke en QAPage.
Ikke generer FAQ-schema automatisk fra alle overskrifter. Spørsmålene og hele svarene må finnes synlig, og typen må passe bruken.

Kombiner relaterte objekter med @graph#

En side kan beskrive flere relaterte entiteter. På en artikkel kan du for eksempel ha Organization, WebSite, WebPage, BlogPosting og BreadcrumbList. @graph samler dem i ett JSON-LD-skript, mens stabile @id-verdier kobler dem sammen.
Flest mulig noder er ikke best. Hver node skal ha et formål, være korrekt og kunne vedlikeholdes. Duplikate organisasjonsobjekter med ulike navn eller URL-er skaper unødvendig uklarhet.

Implementering i HTML, React og serverrendring#

JSON-LD plasseres i et script-element med typen application/ld+json, i head eller body. Google kan behandle strukturert data som injiseres med JavaScript når siden rendres, men servergenerert markup er ofte enklere å kontrollere og mindre avhengig av klientkjøring.
I React bør dataobjektet bygges fra samme kilde som det synlige innholdet. Unngå manuell strengkonkatenering. Serialiser objektet sikkert og sørg for at brukerdata ikke kan avslutte script-elementet eller injisere kode.
På statisk genererte sider bør du inspisere den ferdige HTML-filen. Kontroller at schema ikke er duplisert av både rammeverket, en plugin og en tag manager.

Test i riktig rekkefølge#

1. Kontroller synlig innhold

Før validering: finnes navnet, datoen, prisen, bildet eller anmeldelsen faktisk på siden? Markup som er teknisk gyldig, men misvisende, er fortsatt feil.

2. Bruk Rich Results Test

Rich Results Test viser hvilke Google-støttede funksjoner siden kan være kvalifisert for, og hvilke påkrevde eller anbefalte felter som mangler.

3. Bruk Schema Markup Validator

Schema Markup Validator validerer det bredere Schema.org-ordforrådet. En type kan være gyldig der uten å være støttet som rikt resultat i Google.

4. Inspiser produksjons-URL-en

Bruk URL-inspeksjon i Search Console etter utrulling. Test den levende URL-en, ikke bare et lokalt kodeutdrag. Googlebot må kunne hente siden og ressursene.

5. Overvåk Search Console

Følg rapportene for rike resultater og manuelle tiltak. Skill mellom feil, advarsler og endringer i Googles støtte. En advarsel om en anbefalt egenskap betyr ikke nødvendigvis at siden er ugyldig.

Vanlige schema-feil#

  • Markup beskriver informasjon som ikke er synlig på siden.
  • Pris, lagerstatus eller dato er foreldet.
  • En generell tjeneste merkes som Product uten å oppfylle produktkravene.
  • Oppdiktede anmeldelser brukes i Review eller aggregateRating.
  • FAQPage legges overalt med forventning om større søkeresultat.
  • Flere plugins genererer motstridende objekter.
  • Relative eller feil URL-er brukes i url, @id eller mainEntityOfPage.
  • Samme forfatter har ulike navn og identifikatorer mellom artikler.
  • dateModified settes til dagens dato uten innholdsendring.
  • Schema er kun tilgjengelig etter en feilfri JavaScript-kjøring.

Ta kontrollene inn i en SEO-audit, men prioriter schema etter crawling, indeksering, canonical og synlig innhold. Strukturert data kan ikke reparere et ødelagt fundament.

En praktisk vedlikeholdsmodell#

Strukturert data bør eies som produktkode, ikke som et engangsprosjekt.
  1. Definer hvilke sidemaler og søkefunksjoner som støttes.
  2. Kartlegg hvert schema-felt til en autoritativ datakilde.
  3. Lag automatiske tester for nødvendige felt, URL-er og gyldig JSON.
  4. Test representative produksjonssider ved hver malendring.
  5. Overvåk Search Console etter utrulling.
  6. Revider implementasjonen når Google endrer dokumentasjonen.
For nettbutikker bør pris og lagerstatus komme fra samme produktdata som siden. For artikler bør dato og forfatter komme fra publiseringssystemet. Dette reduserer avvik mellom markup og brukeropplevelse.

Offisielle ressurser#

Oppsummering#

God schema markup er nøktern, korrekt og synkronisert med siden. Velg en Google-støttet type som passer innholdet, inkluder bare opplysninger du kan dokumentere, test både syntaks og kvalifisering, og følg produksjonsdata i Search Console.
Start med Organization på riktig organisasjonsside, Article på redaksjonelle guider og BreadcrumbList der nettstedet har et tydelig hierarki. Bruk Product og andre spesialtyper først når siden oppfyller de konkrete kravene. Da blir strukturert data et robust forståelseslag – uten løfter det ikke kan holde.

SEO kunnskapssenter

Bygg videre på SEO-strategien din

Disse guidene dekker de viktigste delene av søkemotoroptimalisering for norske virksomheter. Velg neste steg ut fra hva som begrenser synligheten din nå.

MS

Grunnlegger av SEOGiant og ansvarlig for denne artikkelen. Se Om oss-siden for bakgrunn og kontaktinformasjon.

Relaterte Guider i Samme SEO & GEO Klynge

Se alle artikler (14)
SEOGiant SEO & GEO Analyse

Finn neste SEO-tiltak for nettsiden din

Start med en analyse, se hva leveransen koster, eller beskriv utfordringen hvis du ønsker personlig hjelp.