Revisjon av strukturerte data for LLM: Sjekk skjemaet ditt for KI-forståelse

En revisjon av strukturerte data for LLM sjekker om siden din oppgir de viktigste fakta sine i en form maskiner ikke må gjette seg til: hvem som publiserer den, hva slags side det er, og hvor den ligger på nettstedet. Schema.org-markering er felles vokabular for dette, og Google anbefaler JSON-LD som formatet som er enklest å implementere og vedlikeholde (Google Search Central, innføring i strukturerte data). Det er likevel langt fra universelt: i 2024 fantes JSON-LD på 41% av sidene, opp fra 34% i 2022 (HTTP Archive Web Almanac 2024, strukturerte data).

Hvordan fungerer revisjonen av strukturerte data for LLM?

Skriv inn et domene eller hele nettadressen til en side, fullfør antibot-sjekken og kjør analysen. Verktøyet henter siden slik en crawler ville gjort, uten å kjøre JavaScript, og leser to slags markering.

• JSON-LD-blokker: hver <script type="application/ld+json"> analyseres. Typene leses på hvert toppnivåobjekt, i matriser og inne i @graph. En blokk som ikke er gyldig JSON, regnes som ugyldig.
• Microdata: hvert itemtype="https://schema.org/..."-attributt legger sin type til listen.

Rapporten viser poengsummen og karakteren, antall JSON-LD-blokker og ugyldige blokker, skjematypene som er funnet, og deretter de fem forventede typene merket til stede eller mangler, hver med en forklaring på én linje og en anbefaling. Gratisversjonen tillater tre revisjoner per dag.

Test sidene som betyr noe for siteringer, ikke bare forsiden: en bloggartikkel, en produkt- eller tjenesteside, en sammenligning. Hver mal har sin egen markering.

Hvordan beregnes poengsummen?

Poengsummen er en vektet andel av sjekkene som består. Hver sjekk består eller feiler; vektene summerer til 9, og resultatet omregnes til en poengsum av 100.

Karakteren følger poengsummen: A fra 90, B fra 75, C fra 60, D fra 40, F under det. Merkelappen lyder «Sterk» fra 75, «God, rom for forbedring» fra 60, «Trenger arbeid» fra 40 og «Kritiske hull» under 40. Noen typiske tilfeller:

• Ingen strukturerte data i det hele tatt: 11/100, karakter F. Bare sjekken «ingen ugyldig blokk» består, siden det ikke finnes noe som kan gå i stykker.
• En forside med Organization og WebSite: 61/100, karakter C. Å legge til BreadcrumbList gir 72.
• En bloggartikkel med Article, Organization, WebSite og BreadcrumbList: 89/100, karakter B. FAQPage er den eneste typen som mangler.

Hvilke skjematyper hjelper LLM-er å forstå siden din?

De fem forventede typene svarer på fem spørsmål en modell ellers måtte utlede fra teksten. Tabellen legger til hvor ofte hver type forekommer på mobilsider i JSON-LD, ifølge Web Almanac 2024.

Organization er ankerpunktet. Google forklarer at markering for organisasjoner hjelper den å forstå de administrative opplysningene dine og skille organisasjonen din fra andre (Google Search Central, strukturerte data for organisasjoner). Egenskapen sameAs gjør samme jobb for enhver leser: schema.org definerer den som adressen til en referanseside som entydig viser hva elementet er, for eksempel et Wikipedia- eller Wikidata-oppslag eller en offisiell profil (schema.org, sameAs).

Får strukturerte data KI-assistenter til å sitere deg?

Ikke alene, og det er verdt å være presis her. Google sier at det ikke finnes noen tilleggskrav og ingen spesiell schema.org-markering som trengs for å vises i AI Overviews eller AI Mode; de ber om at strukturerte data samsvarer med den synlige teksten på siden (Google Search Central, KI-funksjoner og nettstedet ditt). Assistenter siterer sider for innholdet og autoriteten deres.

Det markeringen gjør, er å fjerne tvetydighet. Den oppgir merkevarenavnet ditt, logoen, de offisielle profilene dine, forfatteren og datoen for en artikkel og plasseringen av siden i nettstedet ditt, i én konsekvent form. Når en assistent, eller søkeindeksen bak den, må avgjøre hvilken «Acme» du er, eller om en artikkel er aktuell, hjelper disse eksplisitte fakta. Se på strukturerte data som sidens identitetskort, og det synlige innholdet som grunnen til at siden bør siteres.

FAQPage fortjener en merknad. Google viser ikke lenger FAQ-rikresultatet i søkeresultatene og fjernet dokumentasjonen sin i juni 2026 (Google Search Central, siste oppdateringer av dokumentasjonen). Revisjonen sjekker typen likevel, fordi par med spørsmål og svar er et rent, selvstendig format for ethvert system som leser siden, men ikke forvent en synlig effekt i Google.

Hvordan retter du problemene revisjonen finner?

Arbeid i denne rekkefølgen, fra det som gjør mest skade til det som gjør minst.

1. Ugyldige blokker. En JSON-LD-blokk som ikke kan leses, ignoreres helt. De vanlige synderne er et etterfølgende komma, et anførselstegn som ikke er escapet i en beskrivelse, eller en malvariabel som står tom. Lim blokken inn i en JSON-validator, rett feilen og kjør revisjonen på nytt.
2. Ingen JSON-LD. Legg til en første blokk med Organization (name, url, logo, sameAs) og WebSite på hver side via malen din. Skjemageneratoren lager gyldig JSON-LD å starte fra.
3. Article på redaksjonelle sider, med overskrift, forfatter, datePublished og dateModified som stemmer med det leserne ser.
4. BreadcrumbList som speiler den synlige brødsmulesporen.
5. FAQPage bare når siden viser ekte spørsmål og svar. Merk aldri innhold som ikke er synlig.

Sjekk deretter siden fra andre vinkler: sjekken for LLM-lesbarhet måler hvor lett en modell kan hente ut svar fra teksten din, og revisjonen av optimalisering for svarmotorer går gjennom sidestrukturen bak direkte svar. For definisjoner, se oppslaget vårt i ordlisten om skjemamarkering.

Hva er begrensningene ved revisjonen?

Den sjekker tilstedeværelse og syntaks, ikke kvalitet. Husk disse punktene når du leser poengsummen.

• Egenskaper sjekkes ikke. En Article-blokk uten forfatter består Article-sjekken. Gå gjennom innholdet i hver blokk selv.
• Innebygde typer telles ikke. En Organization som bare er deklarert som publisher inni en Article-blokk, består ikke Organization-sjekken. Å deklarere den som et eget objekt, i matrisen eller i @graph, løser det og gjør enheten gjenbrukbar med en @id.
• Ingen JavaScript-gjengivelse. Markering som settes inn av en tag-manager eller et skript på klientsiden, blir ikke sett. Google kan lese JSON-LD som legges til dynamisk, men mange andre crawlere kjører ikke JavaScript, så markering på serversiden er det tryggere valget.
• De fem typene er et minimum. En produktside trenger også Product og Offer, en lokal virksomhet LocalBusiness, og et arrangement Event. Revisjonen straffer ikke at de mangler.

For å se om bedre markering og innhold gir siteringer, følger sporing av KI-omtaler merkevaren din i svarene fra ChatGPT, Claude og Gemini hver måned, og generatoren for blogginnlegg publiserer kildebelagte, strukturerte artikler på nettstedet ditt.

Gyldig JSON-LD med Organization og Article er minimumet hver side bør oppfylle. Revider nøkkelsidene dine ovenfor, og se deretter abonnementene til Sorank for å følge synligheten din i KI-svar på autopilot.