Strukturerte data: Hvilke en bedriftsnettside faktisk trenger
Strukturerte data er ingen rangeringsfaktor. De er en oversettelse: de sier til maskiner hva et tekstavsnitt betyr, i stedet for å la dem gjette. Nettopp det avgjør i økende grad om en side i det hele tatt dukker opp i svar.
Det viktigste kort
- Fire typer holder for nesten enhver bedriftsside: Organization, WebPage eller Article, BreadcrumbList og FAQPage.
- Det leveres som JSON-LD i
<head>– ikke som merking inne i brødteksten. - Den vanligste feilen er stilltiende og dyr: opplysninger i de strukturerte dataene som ikke står på siden selv.
- Tre mye omtalte typer kan en tjenestebedrift spare seg – de virker bare med et passende tilbud eller ekte vurderinger.
En maskin som leser en side, ser i utgangspunktet bare tekst. At «Emma Woelk» er et menneske, «TEISENDA GmbH» en bedrift og «22. august 2026» en publiseringsdato, må den gjette – eller så står det uttrykkelig der.
Strukturerte data er nettopp dette uttrykkelige. De forbedrer ingen plassering. De avgjør om en side i det hele tatt kommer på tale for utvidede visninger og for genererte svar.
De fire som holder
1. Organization – én gang, på forsiden
Hvem dere er: navn, adresse, logo, stiftelsesår, profiler i andre nettverk. Det er oppføringen som sørger for at en logo kan vises ved siden av søkeresultatet – den vanligste grunnen til at den mangler, er ganske enkelt at denne oppføringen ikke finnes.
Viktig: Logoen må foreligge som rasterbilde. En SVG blir ikke lest på dette stedet.
2. WebPage eller Article – på hver side
Hva denne siden er: tittel, beskrivelse, språk, dato for publisering og siste bearbeiding. Ved innlegg i tillegg Article eller BlogPosting med forfatter som egen Person-oppføring – med rolle, ikke bare med navn.
Viktig: Endringsdatoen må stemme. En dato som settes på nytt ved hver sidevisning, er et signal som forringer seg selv.
3. BreadcrumbList – på alle undersider
Hvor denne siden står i strukturen. Synlig som en sti øverst på siden, maskinlesbar i hodedelen. Begge deler hører sammen – en sti i dataene som ikke finnes på siden, er en uriktig opplysning.
4. FAQPage – der det finnes ekte spørsmål
Spørsmålsdelen på slutten av et innlegg. For svarmaskiner den mest verdifulle typen overhodet, fordi den leverer spørsmål og svar allerede som et par – nøyaktig den formen det siteres i.
Viktig: Bare for spørsmål som faktisk er synlige på siden. Oppdiktede spørsmål som bare står i dataene, er et brudd på retningslinjene.
Tre man kan spare seg
Product og Offer. For tjenester med pris på forespørsel gir de ingenting – uten pris og tilgjengelighet blir de likevel ikke vist. Fornuftig først med en ekte nettbutikk.
AggregateRating. Stjerner i søkeresultatet er forlokkende og knyttet til strenge betingelser: vurderingene må være ekte, etterprøvbare og synlige på siden. Selvtildelte vurderinger er et brudd på retningslinjene med reell risiko.
HowTo. Ble tydelig nedtonet i visningen og er ikke lenger verdt vedlikeholdet for de fleste bedriftssider.
Visste du at …?
Strukturerte data er ingen rangeringsfaktor – det har Google klargjort flere ganger. De avgjør visningen, ikke posisjonen.
For svarmaskiner ligger saken litt annerledes an. En modell som skal bygge et svar ut fra en side, bruker helst det som er entydig merket: spørsmål-svar-par, forfatter med rolle, dato for siste kontroll. Da trenger den ikke gjette hva som hører sammen. Nytten ligger altså mindre i rangeringen enn i det å kunne siteres.
Hvordan de bygges inn
Tre regler som unngår de fleste problemer.
- JSON-LD, i
<head>. Ikke som attributter i brødteksten. JSON-LD lar seg vedlikeholde adskilt fra utformingen og går ikke tapt ved designendringer. - Én blokk per side, ikke fem. Flere oppføringer hører hjemme i én
@graphog knyttes sammen via@id. Slik viser innlegget til den samme organisasjonen som står på forsiden, i stedet for å gjenta den. - Generer dem fra samme kilde som det synlige innholdet. Når tittel, dato og forfatter kommer fra de samme feltene som siden selv, kan de ikke løpe fra hverandre. Det er den mest virksomme forebyggingen overhodet.
Den dyreste feilen er den mest lydløse: de strukturerte dataene sier noe som ikke står på siden. En endringsdato fra i går på en tekst fra 2023. En forfatter som ikke dukker opp i det synlige området. Spørsmål i dataene som ikke finnes på siden.
Det oppdages ikke av noe kontrollverktøy – dataene er formelt gyldige. Det oppdages ved en manuell kontroll, og da gjelder konsekvensen ikke bare den aktuelle merkingen. Derfor er regelen «generer fra samme kilde» viktigere enn all fullstendighet.
Kontroll – i denne rekkefølgen
| Trinn | Med hva | Hva dere ser |
|---|---|---|
| 1. Syntaks | Schema Markup Validator | Om JSON-en er gyldig og typen riktig |
| 2. Visbarhet | Test for rike søkeresultater | Om en utvidet visning ville vært mulig |
| 3. Virkelighet | Search Console, området Forbedringer | Hva som faktisk ble gjenkjent, på tvers av alle sider |
| 4. Samsvar | Lese selv | Om hver opplysning også står synlig på siden |
Trinn fire er det eneste ingen verktøy overtar – og det eneste der de alvorlige feilene oppdages.
Kontroller de strukturerte dataene på denne siden for fullstendighet og for samsvar med det synlige innholdet. Synlig sideinnhold: [sett inn teksten på siden] JSON-LD på siden: [sett inn blokken] Oppgaver: 1. Nevn hver opplysning i JSON-LD-en som ikke forekommer i det synlige innholdet. Det er det viktigste punktet – vær grundig her. 2. Nevn hver synlig opplysning som burde vært merket, men mangler (forfatter med rolle, endringsdato, spørsmål, sti). 3. Kontroller om de fire grunntypene er fornuftig besatt: Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Nevn typer i blokken som for en tjenestebedrift uten nettbutikk og uten etterprøvbare vurderinger ikke har noen nytte. 5. Påpek hvert brudd på retningslinjene, særlig selvtildelte vurderinger og spørsmål som ikke finnes på siden. Gi den korrigerte JSON-LD-en fullstendig til slutt. Ikke finn på verdier – merk det som mangler med [må suppleres].
Konklusjon
Strukturerte data blir raskt overvurdert og like raskt gjort feil. Fire typer dekker behovet til en bedriftsside, og nytten deres ligger mindre i posisjonen enn i det å kunne siteres.
Den ene regelen som bærer alt: ikke merk noe som ikke står på siden. Den som genererer dataene fra samme kilde som det synlige innholdet, har løst dette problemet strukturelt – og kan i stor grad spare seg etterkontrollene.
Vanlige spørsmål
Hvilke strukturerte data trenger en bedriftsnettside?
Fire typer holder: Organization én gang på forsiden, WebPage eller Article på hver side, BreadcrumbList på alle undersider og FAQPage overalt der det finnes ekte, synlige spørsmål. Product, AggregateRating og HowTo lønner seg som regel ikke for tjenestebedrifter.
Forbedrer strukturerte data rangeringen?
Nei. De er ingen rangeringsfaktor, men avgjør visningen – for eksempel om en logo, en sti eller utfellbare spørsmål kan vises i søkeresultatet. For svarmaskiner øker de muligheten for å bli sitert, fordi spørsmål-svar-par, forfatter og dato er entydig merket i stedet for å måtte gjettes.
Hvorfor viser Google ikke logoen vår?
Den vanligste grunnen er en manglende eller ufullstendig Organization-oppføring på forsiden. Nest vanligste grunn: den oppgitte logoen finnes bare som SVG – på dette stedet trengs et rasterbilde. Selv ved riktig merking finnes det ingen rett til å bli vist.
Hva er den vanligste feilen ved strukturerte data?
Opplysninger som står i dataene, men ikke i det synlige innholdet: en feil endringsdato, en forfatter som ikke er nevnt, oppdiktede spørsmål. Kontrollverktøy melder ikke fra om dette, fordi dataene er formelt gyldige. Det lar seg unngå ved at merkingen genereres fra samme kilde som den synlige teksten.
JSON-LD eller mikrodata?
JSON-LD i <head>. Det er formen Google anbefaler, den lar seg vedlikeholde adskilt fra utformingen og går ikke tapt ved designendringer. Mikrodata fordeler merkingen ut over brødteksten og brekker ved hver ombygging av siden.
Markedsføring som setter seg opp selv
Betaen for Studio Engine er åpen. Sikre deg en plass og bidra fra starten.
Bli med i betaen →