Strukturerede data: Hvilke I har brug for

Q: JSON-LD eller mikrodata?

JSON-LD i <head> . Det er den form, Google anbefaler, kan vedligeholdes adskilt fra layoutet og går ikke tabt ved ændringer i udformningen. Mikrodata fordeler mærkningen ud over brødteksten og bryder sammen ved hver ombygning af siden.

Det vigtigste kort

Fire typer rækker til næsten enhver virksomhedsside: Organization, WebPage henholdsvis Article, BreadcrumbList og FAQPage.
Det leveres som JSON-LD i <head> – ikke som mærkning inde i brødteksten.
Den hyppigste fejl er stiltiende og dyr: oplysninger i de strukturerede data, som ikke står på selve siden.
Tre meget omtalte typer kan en servicevirksomhed spare sig – de virker kun med et passende udbud eller med ægte anmeldelser.

En maskine, der læser en side, ser til at begynde med kun tekst. At «Emma Woelk» er et menneske, «TEISENDA GmbH» en virksomhed og «22. august 2026» en udgivelsesdato, må den gætte sig til – eller det står der udtrykkeligt.

Strukturerede data er netop dette udtrykkelige. De forbedrer ikke en placering. De afgør, om en side overhovedet kommer i betragtning til udvidede visninger og til genererede svar.

De fire, der rækker

1. Organization – én gang, på forsiden

Hvem I er: navn, adresse, logo, stiftelsesår, profiler i andre netværk. Det er den post, der sørger for, at et logo kan vise sig ved siden af søgeresultatet – den hyppigste grund til, at det mangler, er ganske enkelt, at posten ikke findes.

Vigtigt: Logoet skal foreligge som rasterbillede. En SVG bliver ikke aflæst på dette sted.

2. WebPage eller Article – på hver side

Hvad denne side er: titel, beskrivelse, sprog, dato for udgivelse og for seneste bearbejdning. Ved indlæg desuden Article henholdsvis BlogPosting med forfatteren som en egen Person-post – med rolle, ikke kun med navn.

Vigtigt: Ændringsdatoen skal passe. En dato, der sættes på ny ved hver sideopbygning, er et signal, der forringer sig selv.

3. BreadcrumbList – på alle undersider

Hvor denne side står i strukturen. Synlig som en sti øverst på siden, maskinlæsbar i hovedet. Begge dele hører sammen – en sti i dataene, som ikke findes på siden, er en fejlangivelse.

4. FAQPage – hvor der er ægte spørgsmål

Spørgsmålsafsnittet i slutningen af et indlæg. For svarmaskiner den mest værdifulde type overhovedet, fordi den allerede leverer spørgsmål og svar som et par – præcis den form, der bliver citeret.

Vigtigt: Kun til spørgsmål, der faktisk er synlige på siden. Opdigtede spørgsmål, der kun står i dataene, er en overtrædelse af retningslinjerne.

Fire tydeligt adskilte beholdere med forskelligt tæt lys, bag dem tre tomme grå — Fire fyldte typer bærer mere end syv halvt passede.

Tre, man kan spare sig

Product og Offer. Til ydelser med pris efter forespørgsel giver de intet – uden pris og tilgængelighed bliver de alligevel ikke vist. Først meningsfulde ved en rigtig butik.

AggregateRating. Stjerner i søgeresultatet er fristende og bundet til strenge betingelser: anmeldelserne skal være ægte, kontrollerbare og synlige på siden. Selvtildelte anmeldelser er en overtrædelse af retningslinjerne med reel risiko.

HowTo. Er blevet tydeligt nedtonet i visningen og er for de fleste virksomhedssider ikke længere vedligeholdelsen værd.

Vidste du det?

Strukturerede data er ikke en rangfaktor – det har Google slået fast flere gange. De afgør visningen, ikke positionen.

For svarmaskiner ligger sagen lidt anderledes. En model, der skal bygge et svar ud af en side, bruger fortrinsvis det, der er entydigt mærket: spørgsmål-svar-par, forfatter med rolle, dato for seneste kontrol. Så behøver den ikke gætte, hvad der hører sammen. Nytten ligger altså mindre i placeringen end i at kunne citeres.

Hvordan de bygges ind

Tre regler, der undgår de fleste problemer.

JSON-LD, i <head>. Ikke som attributter i brødteksten. JSON-LD kan vedligeholdes adskilt fra layoutet og går ikke tabt ved ændringer i udformningen.
Én blok pr. side, ikke fem. Flere poster hører hjemme i en @graph og forbindes med hinanden via @id. Sådan henviser indlægget til den samme organisation, der står på forsiden, i stedet for at gentage den.
Frembring dem fra den samme kilde som det synlige indhold. Når titel, dato og forfatter kommer fra de samme felter som siden selv, kan de slet ikke løbe fra hinanden. Det er den mest virksomme forebyggelse overhovedet.

Fra praksis

Den dyreste fejl er den stilleste: de strukturerede data siger noget, som ikke står på siden. En ændringsdato fra i går ved en tekst fra 2023. En forfatter, der ikke dukker op i det synlige område. Spørgsmål i dataene, som ikke findes på siden.

Det bemærkes af intet kontrolværktøj – dataene er formelt gyldige. Det bemærkes ved en manuel kontrol, og så rammer konsekvensen ikke kun den pågældende mærkning. Derfor er reglen «frembring dem fra den samme kilde» vigtigere end enhver fuldstændighed.

Kontrol – i denne rækkefølge

Trin	Hvormed	Hvad I ser
1. Syntaks	Schema Markup Validator	Om JSON er gyldigt, og typen er korrekt
2. Visningsegnethed	Test af udvidede søgeresultater	Om en udvidet visning ville være mulig
3. Virkelighed	Search Console, området Forbedringer	Hvad der faktisk blev genkendt, på tværs af alle sider
4. Overensstemmelse	Læs selv efter	Om hver oplysning også står synligt på siden

Trin fire er det eneste, intet værktøj overtager – og det eneste, hvor de alvorlige fejl bliver bemærket.

Tip Området «Forbedringer» i Search Console er den eneste kilde, der viser, hvad der faktisk blev genkendt på tværs af alle sider – og ikke kun, hvad der fungerer på en enkelt eksempelside. Ved flersprogede sider afdækker det pålideligt, at en sprogversion blev glemt ved den seneste ombygning.

Prompt

Kontrollér denne sides strukturerede data for fuldstændighed og
for overensstemmelse med det synlige indhold.

Synligt sideindhold:
[indsæt sidens tekst]

Sidens JSON-LD:
[indsæt blokken]

Opgaver:
1. Nævn hver oplysning i JSON-LD, som ikke forekommer i det
   synlige indhold. Det er det vigtigste punkt – vær grundig her.
2. Nævn hver synlig oplysning, som burde være mærket,
   men mangler (forfatter med rolle, ændringsdato, spørgsmål, sti).
3. Kontrollér, om de fire grundtyper er meningsfuldt besat:
   Organization, WebPage/Article, BreadcrumbList, FAQPage.
4. Nævn typer i blokken, som for en servicevirksomhed
   uden butik og uden kontrollerbare anmeldelser ikke er til
   nogen nytte.
5. Gør opmærksom på enhver overtrædelse af retningslinjerne, især
   selvtildelte anmeldelser og spørgsmål, som ikke findes på
   siden.

Udskriv til sidst det rettede JSON-LD fuldstændigt. Opfind ingen
værdier – markér det manglende som [skal udfyldes].

Konklusion

Strukturerede data bliver hurtigt overvurderet og lige så hurtigt gjort forkert. Fire typer dækker behovet på en virksomhedsside, og deres nytte ligger mindre i positionen end i at kunne citeres.

Den ene regel, der bærer det hele: mærk intet, som ikke står på siden. Den, der frembringer dataene fra den samme kilde som det synlige indhold, har løst det problem strukturelt – og kan i vidt omfang spare sig efterkontrollerne.

Ofte stillede spørgsmål

Hvilke strukturerede data har en virksomhedswebsite brug for?

Fire typer rækker: Organization én gang på forsiden, WebPage henholdsvis Article på hver side, BreadcrumbList på alle undersider og FAQPage overalt, hvor der er ægte, synlige spørgsmål. Product, AggregateRating og HowTo kan som regel ikke betale sig for servicevirksomheder.

Forbedrer strukturerede data placeringen?

Nej. De er ikke en rangfaktor, men afgør visningen – for eksempel om et logo, en sti eller udfoldelige spørgsmål kan vise sig i søgeresultatet. For svarmaskiner øger de muligheden for at blive citeret, fordi spørgsmål-svar-par, forfatter og dato er entydigt mærket i stedet for at skulle gættes.

Hvorfor viser Google ikke vores logo?

Den hyppigste grund er en manglende eller ufuldstændig Organization-post på forsiden. Næsthyppigste grund: det angivne logo foreligger kun som SVG – på dette sted kræves der et rasterbillede. Selv ved korrekt mærkning består der intet krav på visning.

Hvad er den hyppigste fejl ved strukturerede data?

Oplysninger, der står i dataene, men ikke i det synlige indhold: en forkert ændringsdato, en forfatter, der ikke nævnes, opdigtede spørgsmål. Kontrolværktøjer melder det ikke, fordi dataene er formelt gyldige. Det kan undgås ved at frembringe mærkningen fra den samme kilde som den synlige tekst.

JSON-LD eller mikrodata?

JSON-LD i <head>. Det er den form, Google anbefaler, kan vedligeholdes adskilt fra layoutet og går ikke tabt ved ændringer i udformningen. Mikrodata fordeler mærkningen ud over brødteksten og bryder sammen ved hver ombygning af siden.