Schema markup: Hvad er strukturerede data?

Hvad er schema markup og strukturerede data?

Schema markup er en standardiseret måde at skrive strukturerede data ind i din kode, så søgemaskiner som Google bedre forstår, hvad din side handler om, og kan vise mere informative søgeresultater. Strukturerede data er selve den organiserede information, mens schema markup er den konkrete kode, der beskriver den.

Når du bare skriver tekst på en side, kan en søgemaskine godt læse ordene, men den gætter på sammenhængen. Med strukturerede data fortæller du eksplicit: “Det her er en artikel om X”, “det her er en produktpris”, “det her er virksomhedens adresse”.

De mest brugte standarder for strukturerede data på websites er defineret på Schema.org. Her er der et stort “ordforråd” af typer og felter (properties), som Google, Bing og andre søgemaskiner forstår på samme måde.

Tre begreber er gode at holde adskilt:

Strukturerede data: Den organiserede information (fx “navn”, “pris”, “åbningstider”) i et klart format.
Schema markup: Koden, typisk i JSON-LD-format, der beskriver de strukturerede data på din side.
Rich results (ofte kaldt rich snippets): De visuelle, udvidede søgeresultater i Google, der opstå, når dine strukturerede data er korrekte og relevante.

Schema markup er altså ikke magi, men en slags “undertekst” til dit indhold, der forklarer konteksten for maskiner. Det er kernen i det, mange kalder semantisk SEO.

Påvirker schema markup SEO og ranking?

Schema markup er ikke en direkte rankingfaktor, men det kan forbedre din SEO indirekte ved at gøre dine resultater mere synlige og klikbare. Korrekt markup kan give rich results, som ofte fylder mere og ser mere troværdige ud, hvilket kan øge din CTR (klikrate).

Google vurderer stadig dine sider på de klassiske ting: kvaliteten af indholdet, relevans, teknisk sundhed, links osv. Schema markup ændrer ikke det. Men når Google forstår din side bedre, er det lettere at:

matche den til de rigtige søgninger
vise ekstra information (fx stjerner, pris, FAQ-udvidelser)
præsentere dit brand mere tydeligt (fx i Knowledge Graph-resultater)

Den praktiske effekt, du kan holde øje med, er især:

Flere impressions og klik på de sider, hvor du får rich results.
Højere CTR, fordi resultatet simpelthen ser bedre ud end de rene blå links.

Det er vigtigt at have forventningerne på plads: schema markup er en forstærker af noget, der allerede er godt. Det løfter ikke en svag side op i toppen alene, men det kan gøre en i forvejen relevant side mere attraktiv i søgeresultaterne.

Hvilken schema-type skal du bruge?

Den rigtige schema-type afhænger af, hvilken slags side du har, og hvad målet er. Artikler bruger typisk Article, produktsider Product, lokale virksomheder LocalBusiness, events Event og spørge-/svar-sider FAQPage. Du skal altid vælge den type, der bedst beskriver sidens faktiske indhold.

Hvis du prøver at “gætte” dig frem, ender du hurtigt med enten for generelle eller for specifikke typer. En simpel beslutningsmatrix hjælper dig bedre på vej:

Sidetype	Mål	Anbefalet schema-type	Data du skal have styr på	Typiske fejl
Blogindlæg / nyhedsartikel	Synlighed, evt. artikel-rich result	Article (eller BlogPosting/NewsArticle)	Titel, forfatter, dato, beskrivelse, URL, evt. billede	Manglende dato eller forfatter, brug af for generisk type (Thing)
Produktside i webshop	Pris, lagerstatus, anmeldelser i SERP	Product	Navn, pris, valuta, lagerstatus, brand, evt. rating	Fiktionelle priser, rating uden reelle anmeldelser
Side om en lokal virksomhed	Adresse og kontakt tydeligt i Google	LocalBusiness (og evt. under-type)	Navn, adresse, telefon, åbningstider, URL	Forkert adresse, åbningstider der ikke matcher siden
Event-side	Dato, sted, billetter i SERP	Event	Navn, startdato, sted, arrangør, billetinfo	Manglende dato/sted, events der ikke længere er aktuelle
Q&A / hjælpeside	FAQ-udvidelser under resultatet	FAQPage	Klare spørgsmål og svar på siden	Schema-Q&A som ikke svarer til det faktiske indhold
Anmeldelser	Stjernerating i SERP	Review eller AggregateRating i Product/LocalBusiness	Ægte anmeldelser, gennemsnitlig rating, antal reviews	Selv-promoverende ratings, ingen rigtige brugeranmeldelser

Nogle typer har under-typer, som gør din opmærkning mere præcis. For lokale virksomheder kan du fx gå fra:

LocalBusiness til FoodEstablishment til Restaurant eller BarOrPub

Start dog hellere lidt for generelt end for specifikt, hvis du er i tvivl. Det vigtigste er, at det du beskriver i schema markup, også findes tydeligt på selve siden.

Hvordan implementerer du schema markup?

Den typiske proces er: vælg schema-type, skriv eller generer JSON-LD-koden, tilføj den til den relevante side (ofte i <head>), og test den bagefter. Du kan gøre det manuelt, via et CMS-plugin eller gennem et værktøj som Google Tag Manager.

1. JSON-LD, Microdata eller RDFa?

Der findes tre hovedformater til schema markup:

JSON-LD: Et separat <script type="application/ld+json">-tag med din markup som ren JSON. Dette er normalt det bedste valg og anbefales af Google i de fleste tilfælde.
Microdata: Markup spredt direkte i HTML-elementerne via attributter som itemtype og itemprop.
RDFa: Minder om microdata, men med et lidt andet attribut-sæt.

JSON-LD er lettest at vedligeholde, fordi du kan ændre din markup uden at pille ved masser af HTML-tags. Det spiller også bedre sammen med moderne frontend-setup og build-pipelines.

2. Tre praktiske implementerings-veje

Hvordan du helt konkret får JSON-LD ind på siden, afhænger af dit setup:

CMS-plugin (fx WordPress)
Godt hvis du ikke vil kode selv. Mange SEO-plugins kan generere Article, Product, LocalBusiness osv. ud fra felter, du udfylder i backend. Fordele: hurtigt at komme i gang, skalerbart på mange sider. Ulemper: mindre fleksibilitet, og du skal holde øje med, hvad plugin’et faktisk genererer.
Manuel JSON-LD i skabeloner
Du skriver selv JSON-LD og lægger det i temaet eller template-filerne. Fordele: fuld kontrol, ingen afhængighed af plugins. Ulemper: kræver mere teknisk forståelse og sørger for, at data holdes opdaterede.
Google Tag Manager eller andet tag-setup
Du injicerer JSON-LD via et script, typisk baseret på data-lag eller side-URL. Fordele: fleksibelt, kræver ikke kode-deploy hver gang. Ulemper: sværere at overskue, og du skal sikre at markup’en faktisk er der ved render-tid for søgemaskiner. I SPA-setup er det ekstra vigtigt at forstå, hvordan indexering og rendering fungerer (se fx artiklen om SPA vs. server routing).

Valget handler mest om dit CMS, din tekniske komfort og hvor ofte data ændrer sig. En produktpris, der opdateres ofte, bør helst komme direkte fra samme datakilde som vises på selve siden, ikke fra en manuelt vedligeholdt JSON-klump.

Sådan ser JSON-LD ud i praksis

JSON-LD er en lille kodeblok i et <script type="application/ld+json">-tag, som du typisk lægger i sidens <head> eller lige før </body>. Koden beskriver sidens indhold med felter, som Schema.org og Google forstår.

Her er et konkret eksempel på schema markup for en simpel artikel:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema markup: hvad er struktureret data, og hvordan bruger du det?",
  "description": "En praktisk introduktion til schema markup og JSON-LD på websites.",
  "author": {
    "@type": "Person",
    "name": "Mikkel Schrøder"
  },
  "datePublished": "2026-01-15",
  "dateModified": "2026-01-15",
  "url": "https://example.com/schema-markup-strukturerede-data",
  "image": "https://example.com/images/schema-guide.jpg",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/schema-markup-strukturerede-data"
  }
}

Og sådan kan du sætte det ind i HTML’en:

<script type="application/ld+json">
{ ... JSON-LD her ... }
</script>

Hvad betyder felterne?

Felt	Forklaring
`@context`	Fortæller, at vi bruger ordforrådet fra Schema.org. For almindelige cases er værdien næsten altid `https://schema.org`.
`@type`	Angiver typen af indhold. Her er det en `Article`, men det kunne også være `Product`, `LocalBusiness` osv.
`headline`	Artiklens titel. Bør matche eller ligge tæt på den faktiske overskrift på siden.
`description`	Kort beskrivelse af artiklen. Brug noget, der også giver mening for mennesker.
`author`	Objekt, der beskriver forfatteren. Her er det en person med et navn.
`datePublished` / `dateModified`	Publiceringsdato og seneste opdateringsdato i ISO-format (`ÅÅÅÅ-MM-DD`).
`url`	Kanonisk URL til artiklen. Skal være den samme som brugt i fx canonical-tag.
`image`	URL til et repræsentativt billede. Gerne samme billede som brugt som hero/preview.
`mainEntityOfPage`	Binder artiklen til den overordnede webside. Hjælper Google med at forstå, hvad hovedindholdet er.

Nogle felter er påkrævede eller stærkt anbefalede, hvis du vil være eligible (berettiget) til bestemte rich results. Det varierer fra type til type. Produkt-markup kræver fx pris og valuta, mens Article fokuserer på titel, dato, billede osv.

Hvis du vil gå dybere ned i selve JSON-formatet, dvs. hvordan nøgler, værdier og objekter fungerer, giver det mening at læse en mere generel introduktion til JSON og JavaScript først, fx via vores indhold under JavaScript til web.

En ting, mange glemmer, er sikkerhed: JSON-LD er et inline script. Har du en stram Content Security Policy (CSP), kan det blive blokeret. Det kan du løse ved at whiteliste script-src for application/ld+json, hvilket er uddybet i fx guiden om Content Security Policy.

Hvordan tester og validerer du schema markup?

Du tester schema markup med tre hovedværktøjer: Googles Rich Results Test, Schema Markup Validator og Google Search Console. Først tjekker du om formatet er gyldigt, derefter om siden er eligible til rich results, og til sidst holder du øje med fejl og performance over tid.

1. Rich Results Test

Rich Results Test fortæller dig, om Google kan læse din markup, og om siden kan få bestemte typer rich results. Du kan enten indsætte en URL eller kopiere din kode direkte ind.

Her kigger du efter:

Om der overhovedet findes strukturerede data på siden.
Om der er fejl (røde) eller advarsler (gule) i dine schema-typer.
Om siden er eligible til fx Article, Product eller FAQ rich results.

2. Schema Markup Validator

Schema Markup Validator fokuserer mere på selve schema.org-standarden end på Googles rich results. Den er god til at finde rene syntaksfejl, manglende felter ift. schema.org-beskrivelsen og generelle problemer i din JSON-LD.

3. Google Search Console

Når siden er indekseret, bliver Search Console dit løbende kontrolpanel. Her kan du:

Se rapporter for strukturerede data-typer (fx Produkter, FAQ, Events).
Få liste over fejl og advarsler, som Google har fundet.
Se, om antallet af gyldige elementer stiger eller falder efter ændringer.

Hvis du i forvejen bruger Search Console til debugging af andre ting, kan du overføre mange af principperne herfra. Hvis ikke, er det værd at lære det grundlæggende set-up at kende, især når du begynder at måle CTR og impressions over tid. Artikler som logs vs. mavefornemmelse rammer meget godt den tankegang, du også bør bruge på schema.

Typiske fejl og hvordan du finder dem

Symptom	Sandsynlig årsag	Værktøj	Løsning
Rich results vises slet ikke	Ikke eligible type, manglende required properties, eller Google vælger at ignorere markup	Rich Results Test, Search Console	Ret fejl/advarsler, tjek at markup matcher indholdet, og vær tålmodig med re-indeksering
Fejl om manglende felter	Required properties for din type mangler eller er tomme	Rich Results Test, Schema Markup Validator	Tilføj de felter, værktøjet efterspørger, baseret på dokumentationen på Schema.org
Modstridende data (fx forskellige priser)	Markup og synligt indhold bruger ikke samme datakilde	Rich Results Test, manuel gennemgang	Sørg for at schema-data genereres fra samme system som frontenden, så priser og lagerstatus altid matcher
Markup forsvinder efter deploy	Build-scripts eller CMS-opdateringer overskriver templates	DevTools, CI-logs	Gør schema-indsættelsen til en del af din build-pipeline, se fx principperne i CI-guiden

Hvis du er vant til at debugge JavaScript, vil du nok genkende mønstret: ændr én ting ad gangen, test igen, og brug værktøjerne systematisk. Hvis du savner en generel introduktion til debugging-metoder, er der gode pointer at hente i artiklen “Stop med bare at stirre på fejl i console”.

Hvad kan schema markup ikke gøre?

Schema markup kan ikke garantere dig bedre placeringer eller sikre, at Google viser rich results hver gang. Det kan gøre dine sider berettigede til udvidede resultater og hjælpe søgemaskiner med at forstå indholdet bedre, men der er ingen løfter om synlig effekt.

Der er især tre begrænsninger, du skal kende:

Ikke en direkte rankingfaktor
Google har flere gange sagt, at strukturerede data ikke i sig selv er en direkte rankingfaktor. De kan understøtte forståelse og synlighed, men ikke kompensere for tyndt eller irrelevant indhold.
Ingen garanti for rich results
Selv med perfekt markup kan Google vælge at vise et almindeligt resultat, fx hvis de vurderer, at brugeren ikke vil have gavn af rich result-varianten, eller hvis der er mange lignende resultater på søgningen.
Irrelevant eller aggressiv markup kan ignoreres
Hvis du overdriver (fx sætter stjernerating på alle sider uden rigtige anmeldelser) eller bruger typer, der ikke svarer til sidens indhold, kan Google ignorere eller i værste fald straffe din implementation ift. deres spam-regler.

Det er derfor bedre at se schema markup som en del af din tekniske kvalitet og informationsarkitektur end som et “trick”. Fokusér på at:

beskrive det indhold, du faktisk har
holde data ajour (især priser, lagerstatus og åbningstider)
måle effekten nøgternt via Search Console (impressions, klik, CTR pr. side)

Når du arbejder systematisk med ændringer, er det en fordel at have styr på caching og deployment. Det er ikke ualmindeligt, at du tror, du har rettet et felt i schema, men brugerne stadig får en gammel version pga. cache. Den slags finesser er beskrevet ret godt i artiklen “Cachen lyver oftere end din kode”.

Hvor skal du starte på dit website?

Hvis du ikke har uendeligt med tid, giver det mening at starte med de sider, hvor schema realistisk kan gøre størst forskel. Typisk er det dine vigtigste artikler, produktsider og din side om virksomheden.

En pragmatisk rækkefølge kan være:

Brand-/virksomhedsside
Implementer Organization eller LocalBusiness med navn, adresse, telefon, URL og evt. socials. Det skaber en ren basisforståelse af, hvem du er.
Top-traffic artikler
Vælg de artikler, der allerede får mest organisk trafik, og tilføj Article-markup. Her er chancen størst for, at rich results faktisk bliver vist og brugt.
Vigtige produktsider
Har du en webshop, så start med dine bedst sælgende eller strategisk vigtigste produkter, og tilføj Product-markup med pris, lagerstatus osv.
FAQ-/hjælpesider
Har du allerede rene Q&A-sektioner, kan FAQPage give ekstra synlighed på udvalgte søgninger.

På større eller mere komplekse sites (fx headless CMS, SPA-frontends eller mange sidetyper) kan det være værd at tænke schema ind i din arkitektur fra starten: hvilke templates har du, hvilke datakilder skal fodre markup, og hvordan tester du det i din CI-pipeline før deploy? Her kan erfarne udviklere og SEO-folk ofte spare dig for en del forsøg-og-fejl.

Hvorfor viser min side ikke rich results, selvom markup validerer uden fejl?

Google viser ikke nødvendigvis rich results selvom din markup er korrekt. Årsager kan være at siden ikke opfylder øvrige kvalitetskriterier, at typen ikke er berettiget til rich results, lavt indholdskvalitetsindeks eller simpelthen at Google endnu ikke har crawleret og indekseret ændringen. Tjek Search Console for dækning og manuel handling, giv det tid, og forbedr sidekvaliteten og struktur oftest løser det problemet.

Hvordan håndterer jeg struktureret data i single-page apps og dynamisk indhold?

Brug server-side rendering eller prerendering hvis det er muligt, så søgemaskiner får markup server-side. Alternativt kan du indsætte JSON-LD i DOM'en efter klient-rendering, men sørg for at Google kan se det ved at bruge URL-inspektion i Search Console. Kort sagt: sørg for at markup er synlig for crawleren, ikke kun for brugeren via JS.

Er der nogen risici ved at tilføje for meget eller 'over-optimaliseret' struktureret data?

Ja. At markere information som ikke fremgår af siden eller at give vildledende data kan føre til manuelle sanktioner eller fjernelse af rich results. Hold markupen sand, synlig for brugeren og relevant for sidens indhold, og undlad at gentage unødvendige felter.

Hvad er forskellen på JSON-LD, Microdata og RDFa, og hvilken bør jeg vælge?

JSON-LD er et separat script-blokformat og er lettest at vedligeholde og testen; det er også Googles foretrukne format. Microdata og RDFa indlejrer markup direkte i HTML-elementerne, hvilket kan være nyttigt ved CMS-begrænsninger, men det gør koden mere rodet. Vælg JSON-LD med mindre du har en konkret grund til at bruge de andre formater.

Coding Class

Schema markup: hvad er struktureret data, og hvordan bruger du det på et website?

Hvad er schema markup og strukturerede data?

Påvirker schema markup SEO og ranking?

Hvilken schema-type skal du bruge?