Strukturert data er kode som beskriver innholdet på en side i et format maskiner kan tolke direkte. I stedet for at søkemotoren skal utlede fra teksten at «dette ser ut som en artikkel skrevet av noen i august», får den det oppgitt eksplisitt.
Det gjør ikke innholdet bedre. Det gjør det entydig, og entydighet er verdt mer nå enn før, fordi stadig flere systemer enn Google leser nettsider maskinelt.
Hva du kan få ut av det
Strukturert data er ikke en rangeringsfaktor i seg selv. Google har vært konsekvente på det punktet. Det du kan få er tre andre ting:
- Rikere visning i søkeresultatet. Stjerner, priser, tilgjengelighet, tilberedningstid, spørsmål og svar. Dette påvirker ikke posisjonen, men det påvirker hvor mange som klikker.
- Bedre forståelse av hva siden handler om. Særlig for entiteter som virksomheter, personer og produkter, der navn alene kan være tvetydige.
- Lettere å plukke opp for AI-systemer. Se strukturert datas rolle i AI-genererte svar.
Legg merke til at rik visning er en mulighet, ikke en garanti. Google velger selv om og når det vises, og bruker gjerne ulik visning for ulike søk.
JSON-LD er formatet du skal bruke
Det finnes tre måter å legge inn strukturert data på: JSON-LD, Microdata og RDFa. De to siste flettes inn i HTML-en rundt selve innholdet. JSON-LD legges i en egen kodeblokk, atskilt fra resten.
Google anbefaler JSON-LD, og det gjør jeg også. Grunnen er praktisk: når koden ligger samlet ett sted, kan du endre design uten å ødelegge merkingen, og du kan lese den uten å lete gjennom hele malen. Microdata brekker i det øyeblikket noen flytter på et element.
Typene som er verdt å begynne med
Schema.org har flere hundre typer. De færreste er relevante. For et vanlig norsk bedriftsnettsted holder det lenge med disse:
- Organization eller LocalBusiness for virksomheten: navn, adresse, telefon, åpningstider, logo og profiler andre steder.
- WebSite for nettstedet som helhet.
- Article eller BlogPosting for artikler, med forfatter, publiseringsdato og oppdateringsdato.
- BreadcrumbList for brødsmulesti, som ofte vises direkte i søkeresultatet.
- Product med pris og tilgjengelighet for nettbutikker.
- Person for forfattere, koblet til artiklene deres.
Det siste punktet er undervurdert. Å oppgi hvem som har skrevet noe, og koble den personen til profiler og en om-side, er et av de enkleste grepene for å gjøre forfatterskap maskinlesbart.
Regelen som ikke kan bøyes
Strukturert data skal beskrive innhold som er synlig på siden. Ikke innhold som burde vært der, ikke innhold som ligger et annet sted, og ikke innhold du skulle ønske du hadde.
Det betyr blant annet:
- ingen stjernevurderinger uten reelle, synlige vurderinger på siden
- ingen priser som ikke stemmer med det som står i teksten
- ingen FAQ-merking av spørsmål som ikke finnes i innholdet
- ingen merking av anmeldelser du har skrevet om deg selv
Dette håndheves, og sanksjonen er som regel at rik visning fjernes for hele nettstedet, ofte lenge etter at merkingen ble lagt inn. Gevinsten står ikke i forhold til risikoen.
Slik tester du
To verktøy dekker behovet:
- Rich Results Test fra Google viser hva som kan gi rik visning, og hvilke feil som stopper det.
- Schema Markup Validator fra schema.org validerer koden i seg selv, uavhengig av hva Google støtter.
Bruk begge. Det første forteller deg hva du får ut av det hos Google, det andre om koden er riktig i utgangspunktet. Search Console har i tillegg egne rapporter som viser feil på tvers av nettstedet over tid, og det er der du oppdager at noe har brekt etter en oppdatering.
Vanlige feil
Dobbel merking. Både temaet og SEO-pluginen legger inn Article-schema, og siden ender med to motstridende beskrivelser av seg selv. Dette er svært vanlig i WordPress.
Løsrevne biter. Hver type ligger for seg selv uten kobling. En artikkel som ikke vet hvem som har skrevet den, og en forfatter som ikke er koblet til organisasjonen, gir mindre enn summen av delene. Bruk @id til å knytte dem sammen.
Feil type. LocalBusiness på en virksomhet uten fysisk besøksadresse, eller Product på en tjenesteside. Det er bedre å bruke en generell type riktig enn en spesifikk type feil.
Merking som forfaller. Åpningstider som ble endret for to år siden, priser som ikke stemmer lenger. Strukturert data er en påstand, og påstander må vedlikeholdes.
Hvordan tenke om innsatsen
Strukturert data er billig å få på plass og billig å holde ved like, men det er sjelden det som avgjør om et nettsted lykkes. Er innholdet svakt eller siden ikke indeksert, endrer ikke schema noe som helst.
Rekkefølgen jeg anbefaler er derfor: få det tekniske fundamentet i orden, få innholdet til å svare på noe folk lurer på, og legg deretter på strukturert data som et lag som gjør det du allerede har lettere å forstå.
Skal du gjøre det i WordPress, se strukturert data i WordPress uten kode.