2026-01-14 · Redaktion Baduno · 6 blog.readMin · Blog & Viden
Strukturerede data: Schema.org forklaret forståeligt
Maskinlæsbare ekstraoplysninger gør søgeresultater til rige resultater med anmeldelser, FAQ'er og firmadata. Sådan fungerer det.
Hvad strukturerede data er
Usynlige JSON-blokke i kildekoden beskriver, hvad der står på siden: Det er en virksomhed med denne adresse, det er en artikel med denne dato, det er en FAQ med disse spørgsmål. Søgemaskiner behøver ikke at gætte – de læser.
Hvad det giver
Berettigelse til udvidede visninger (FAQ-uddrag, brødkrummer, organisationspanel), bedre forståelse af sammenhænge og renere vidensgraf-opslag. Ingen ranking-turbo – men mere plads og tillid i søgeresultatet.
De vigtigste typer for virksomheder
Organisation med registerdata, WebSite, Service eller Product med Offer, Article til fagindlæg, FAQPage og BreadcrumbList. Flersproget gælder: Hver sprogversion bærer sin egen, oversatte markering.
Glem ikke at validere
Rich-Results-testen viser, hvad Google læser, Schema-validereren tjekker syntaksen. Forkert markering er værre end ingen – det koster tillid og i værste fald den udvidede visning.
Strukturerede data og hreflang: Perfekt samspil til flersprogede sider
En hyppig fejlkilde på flersprogede hjemmesider er inkonsekvent brug af strukturerede data og hreflang-tags. Mens hreflang signalerer sprog- og regionsalternativerne for en side til søgemaskinerne, afslører strukturerede data indholdstypen. De er uafhængige af hinanden, men supplerer hinanden: En tysk produktside bør både have et hreflang-tag, der henviser til den engelske variant, og i det strukturerede datablok angive den samme produkt-ID med forskellige tilbud og sprog. Vigtigt: Hver sprogversion får sin egen JSON-LD-blok med passende værdier – ellers opstår der modsætninger. Googles Rich Results Test viser ofte fejl, hvis f.eks. organisationen i den tyske version indeholder en engelsk adresse. Kontrollér derfor altid begge markeringer parallelt efter hver sprogudrulning.
Vedligeholdelse og opdatering: Hvem vedligeholder dataene?
Strukturerede data er ikke et engangsprojekt. Ændrer priser, åbningstider eller produktdetaljer sig, skal JSON-LD-blokkene opdateres. Ideelt set sørger content management-systemet for den dynamiske udfyldning. Mangler denne automatisering, er der brug for en klar ansvarlig i teamet – f.eks. redaktøren for artikel- og FAQ-data, udvikleren for organisatoriske data. Undgå datasiloer: Et forældet telefonnummer i Organization-blokken skader tilliden. Planlæg kvartalsvise gennemgange af alle strukturerede data, i det mindste før enhver større relancering. Et centralt dashboard, der viser alle markerede sider og deres valideringsstatus, er nyttigt.
AI-understøttet oprettelse og kontrol af strukturerede data
Moderne AI-værktøjer kan automatisk generere JSON-LD ud fra ustruktureret tekst – f.eks. til FAQ-sider eller artikler. Det fremskynder arbejdet, men indebærer risici: AI overser ofte kontekstuelle nuancer (f.eks. forkert pris eller forældet dato). Derfor er modersmålsgennemgang fra en redaktør uundværlig. Brug AI til råudkastet, og lad derefter et menneske validere værdierne. Også på flersprogede sider hjælper AI med oversættelser af strukturerede data, men hreflang-tags og sprogspecifikke ID'er skal indstilles manuelt. En gennemprøvet metode: AI opretter den engelske standardblok, en lokal redaktør retter og tilføjer de landespecifikke felter.
Maskinlæsbare ekstraoplysninger gør søgeresultater til rige resultater med anmeldelser, FAQ'er og firmadata. Sådan fungerer det.
Marker dynamisk indhold: FAQ'er, anmeldelser og produkter
Særligt hyppigt opstår fejl ved dynamisk indhold. FAQ-sider bør have et JSON-LD-indlæg per spørgsmål – ikke hele listen som et enkelt Question-objekt. Ved anmeldelser skal bedømmelsesskalaen angives korrekt (f.eks. bestRating og worstRating). Produktsider med varianter kræver AggregateOffer-blokke med alle pris- og tilgængelighedsoplysninger. Brug skabeloner i CMS, som automatisk genererer de korrekte typer. Test hver dynamiske side individuelt i Rich Results-testen, da fejl først bliver synlige ved konkrete værdier. En hyppig fejl: brug af 'Review' i stedet for 'AggregateRating' til gennemsnitsbedømmelser.
Kombination af flere Schema.org-typer på én side
På en enkelt side kan du markere flere Schema.org-typer parallelt, forudsat at de beskriver forskellige aspekter af indholdet. En produktside kan samtidig indeholde en Product-blok (med pris, tilgængelighed), en Organization-blok (for producenten) og en Review-blok (for anmeldelser). Vigtigt er, at hver type står i et separat JSON-LD-script eller er forbundet konsistent via @id. Eksempel: Product-blokken henviser med "brand": {"@id": "#organisation"} til Organization-blokken. Undgå modstridende oplysninger – f.eks. forskellige adresser i Organization- og LocalBusiness-blokken. Hver type skal være indholdsmæssigt korrekt og sprogspecifikt markeret: En fransk side modtager franske værdier i alle blokke. Brug CMS'et til at administrere typer modulært, så du ikke behøver at tilpasse hver blok manuelt. Tjek i Rich-Results-testen, om alle blokke accepteres – nogle tests viser kun den første blok. En ren kombination af flere typer øger chancerne for rige resultater som karrusel, produktbokse eller organisationspanel.
Arbejde med @id og referencer for forbundne data
Schema.org gør det muligt at referere til objekter via @id og dermed undgå redundante data. I stedet for at gentage hele organisationen på hver side, definerer du en central Organization-blok med et unikt @id (f.eks. "https://eksempel.dk/#firma") og henviser i andre blokke til den via "@id": "https://eksempel.dk/#firma". Dette er især nyttigt på flersprogede websites: Organisationen forbliver den samme, kun de sprogspecifikke felter som „name“ eller „description“ afviger. Sørg for, at @id er konsistent på tværs af alle sprogversioner – altså samme URI for dansk, engelsk osv. Referencer kan også bruges til artikelforfattere, produktmærker eller anmeldelseselementer. Valider med Schema-validatoren, at alle @id-henvisninger kan opløses. En fejl: Hvis det refererede @id ikke er defineret i samme sidekildetekst eller på en anden side, fejler valideringen. Derfor bør du placere centrale enheder enten i en global fil (f.eks. organisation.json) og indsætte den via JavaScript, eller bruge CMS'et til dynamisk indbinding. En ren @id-struktur gør det lettere for søgemaskiner at forbinde oplysninger og forbedrer konsistensen i Knowledge Graph.
Korrekt opmærkning af BreadcrumbList: Tips og faldgruber
Opmærkning af BreadcrumbList kan virke enkel, men i praksis opstår der ofte fejl, der truer Rich-Snippet-succesen. En korrekt implementering starter med forståelsen af hierarkiet: Hver post i listen kræver et ItemListElement-objekt, som igen indeholder et ListItem-objekt. Afgørende er position-egenskaben: Den nummererer elementerne stigende, begyndende med 1 for startsiden. Undgå at udelade startsiden – selvom den ikke vises i den synlige breadcrumb, bør den være inkluderet i de strukturerede data. En almindelig fejl er brug af absolute URL'er uden hensyntagen til sprogversionen: Sørg for, at URL'en i breadcrumb henviser til den korrekte sprogvariant, f.eks. /da/produkter i stedet for /en/products. Også navngivningen af elementerne skal være sprogspecifik – 'Startside' på dansk, 'Home' på engelsk. Brug name-feltet til den viste tekst og undgå forkortelser eller akronymer, som søgemaskiner kunne misforstå. Efter implementering skal du teste hver sti med Rich-Results-Testen, da positioner let kan byttes om eller der kan opstå dubletter, især ved dynamisk genererede breadcrumbs. Bemærk desuden, at Google maksimalt viser ti elementer – en kortere, præcis navigation foretrækkes derfor frem for en for lang.
Indlejrede objekter og referencer: @id og @context
Komplekse strukturerede data bruger ofte sammenkædning af flere typer via @id-referencer. Et typisk eksempel er en Product-side, der både indeholder et Offer og en Review. I stedet for at putte alle data i en monolitisk blok, er det renere at definere separate blokke med entydige @id-værdier og derefter referere til dem. @id-værdien skal være unik inden for siden og hele domænet – ideelt set bruger du objektets absolutte URL med et fragment som #product-1. Undgå generiske ID'er som #produkt, da de kan føre til konflikter på flere sider. Et andet vigtigt aspekt er @context: Som standard bruges Schema.org-vokabularet, men for proprietære udvidelser kan der angives en egen kontekst. Vær opmærksom på, at testede udvidelser som health-lifesci eller bib ikke utilsigtet havner på kommercielle sider. På flersprogede sider skal @id-referencer være sprogspecifikke: Den danske produkt-side refererer til den danske Offer-ID, ikke den engelske. En nyttig teknik er brugen af @reverse for inverse relationer, f.eks. når et Product refererer til en Organisation, men organisationen ikke fører en direkte liste over alle produkter. Test sådanne sammenkædninger i Schema-Validatoren, da selv en manglende kolon kan føre til en valideringsfejl. Afsæt tilstrækkelig tid til fejlfinding af refererede objekter – de er en hyppig kilde til fejl i omfattende implementeringer.
blog.faqT
Kan jeg tilføje strukturerede data efterfølgende på gamle sider?
Ja, strukturerede data kan tilføjes når som helst. Sørg for, at alle oplysninger er aktuelle. Brug Googles Rich-Results-test til at kontrollere korrekt implementering. Ved mange sider anbefales en gradvis tilgang efter indholdstype.
Hvor ofte bør strukturerede data opdateres?
Altid når de underliggende oplysninger ændres (priser, åbningstider, produktdetaljer). Planlæg mindst en kvartalsvis gennemgang. Dynamiske systemer kan automatisk udfylde data – det reducerer opdateringsarbejde og fejlkilder.
