Schema.org for norske bedrifter: våre 7 must-have markup-typer i 2026

Hvilke schema.org-typer Medcom implementerer på hver eneste nettside vi leverer — med konkrete eksempler fra norske kunder og hvorfor det avgjør om ChatGPT siterer deg.

Kort fortalt: Vi implementerer syv schema.org-typer på hver eneste nettside vi leverer: Organization, LocalBusiness, WebSite, Service med Offer, FAQPage, BreadcrumbList og Person. Sammen danner de et komplett maskin-leselig visittkort som AI-modeller og søkemotorer bruker for å forstå hvem du er, hva du gjør, og om du er en troverdig kilde å sitere.

Schema.org er ikke et tema vi diskuterer med kunder. Det er noe vi bare gjør, fordi det er en forutsetning for AEO i 2026. Men siden flere har spurt hva vi faktisk implementerer og hvorfor, her er oppskriften vi følger på hvert eneste prosjekt.

Dette er ikke en akademisk gjennomgang av schema.org-vokabularet. Det er den konkrete listen over hva vi setter inn i <head> på hver kundenettside, med begrunnelse for hvorfor akkurat disse syv typene gjør forskjell.

1. Organization med sameAs til norske registre

Organization er det grunnleggende visittkortet. Navn, logo, kontakt, e-post. Men det som faktisk flytter nålen, er sameAs-arrayet — lenker til andre steder samme entitet eksisterer.

For norske bedrifter implementerer vi alltid disse:

"sameAs": [
  "https://www.brreg.no/enhet/<orgnr>",
  "https://www.proff.no/selskap/<slug>",
  "https://www.1881.no/<slug>",
  "https://www.linkedin.com/company/<slug>"
]

Brønnøysund-lenken er den viktigste. Den forteller AI-modeller at dette er en juridisk registrert norsk bedrift, ikke et hjemmelaget nettsted. Proff og 1881 bekrefter forretningsadresse og kontaktinfo. LinkedIn gir en uavhengig sosial verifisering.

ChatGPT, Gemini og Perplexity bygger interne grafer over hvilke entiteter som henger sammen. Når du har sameAs til fire offentlige eller etablerte kilder, blir du en «sterk noden» i den grafen. Når noen spør om « i », er det de sterke nodene som siteres.

2. LocalBusiness for fysiske lokasjoner

Hvis kunden har et lokale folk kan besøke — butikk, klinikk, frisør, restaurant — legger vi til LocalBusiness oppå Organization, og kobler dem via parentOrganization.

LocalBusiness gir oss tre nye felter som er kritiske for lokalt søk:

openingHoursSpecification — strukturerte åpningstider Google Maps og GBP plukker direkte
geo — eksakt lat/lng som matcher Maps-pinnen
address — strukturert postadresse med separat postnummer, by, region

Vi bruker undertyper når det er hensiktsmessig. En tannlegekunde får Dentist, en frisør får HairSalon, en restaurant får Restaurant. Det er et signal om at vi forstår bransjen, ikke bare har klistret på et generisk merke.

3. WebSite med søke-funksjonalitet

WebSite-schemaet høres trivielt ut, men det er det som lar Google vise det interne søke-feltet under sitelinks i SERP. Vi legger alltid på potentialAction med SearchAction når nettsiden har en søkefunksjon.

For nettsider uten søk, holder vi det enkelt — bare WebSite med url, name, inLanguage: "nb-NO" og publisher som peker til Organization-noden. Det er nok til å skape en sammenhengende entitetsgraf.

4. Service med Offer per pillar-tjeneste

For hver tjeneste-side (typisk fire-syv per bedrift) emitterer vi Service-schema med tilknyttet Offer. Offer er det som gjør at Google viser pris i Rich Results.

Vi bruker tre Offer-shapes avhengig av prismodellen:

Abonnement: UnitPriceSpecification med unitCode: "MON" for månedlig
Range: PriceSpecification med minPrice og maxPrice for «fra X til Y»
Fast pris: PriceSpecification med ett enkelt price

Det viktigste er at vi alltid setter priceCurrency: "NOK" og valueAddedTaxIncluded: false. Norsk publikum forventer at oppgitt pris er eks. mva for B2B-tjenester. Hvis schema sier inkludert mva men siden sier eks. mva, så plukker AI-modeller den ene eller den andre — vilkårlig — og du får inkonsistente svar i ChatGPT.

5. FAQPage på hver pillar-side

FAQPage er det enkleste rich result å vinne, og den schema-typen ChatGPT siterer aller oftest. Vi legger alltid 5-7 spørsmål på hver tjeneste-side, hentet fra reelle kundespørsmål.

Format-mässig er det rett frem:

{
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Hvor lang tid tar prosjektet?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Typisk 2-4 uker fra første møte til lansering..."
      }
    }
  ]
}

Det vi har lært gjennom tre års arbeid: svar-tekstene må stå alene. Hvis svaret begynner med «Det avhenger av flere faktorer, men generelt sett...», så plukker ikke AI-modellene det. De vil ha et konkret svar de kan sitere ordrett.

Vi bruker stort sett mellom 80 og 200 ord per svar. Kortere blir for tynt for AI å bygge en setning av. Lengre, så plukker den feil del.

6. BreadcrumbList for navigasjon

Breadcrumbs er små, men de gjør to ting: de hjelper Google å forstå sidehierarkiet, og de gir oss et reservepunkt for inntreden hvis brukeren lander mid-sti via et AI-svar.

Vi setter dem på alle sider unntatt forsiden:

Hjem > Tjenester > AEO – AI-optimalisert SEO

I schema implementeres det som BreadcrumbList med ListItem-elementer som har position, name og item (full URL). På siden vises de visuelt øverst, like under headeren.

Detalj som ofte misses: hver item-URL må være absolutt (https://...), ikke relativ. Relative URL-er i breadcrumb-schema blir tolket som ugyldige av Google og hele structured data-blokken kan bli ignorert.

7. Person for forfattere og lederskap

Person-schema er det som bygger E-E-A-T (Experience, Expertise, Authority, Trust) — det Google og AI-modeller bruker for å vurdere om innholdet kan tas på alvor.

For hver kunde som har offentlige team-medlemmer (CEO, fagperson, daglig leder), oppretter vi en Person-node per individ med:

name og jobTitle
description med bio (1-2 setninger)
knowsAbout med 3-5 fagområder
worksFor koblet til Organization
sameAs til LinkedIn-profilen
image som peker til profilfoto

Når kunden skriver blogginnlegg, kobler vi BlogPosting.author til denne Person-noden via @id. Det betyr at AI-modeller kan traversere fra en blogartikkel → forfatter → fagområder → arbeidsgiver → registrert bedrift. Hele kjeden er sporbar.

Det er denne traverseringen som avgjør om du blir sitert eller ikke når noen spør «hvem er ekspert på X i Norge?».

Hva vi har lært etter 50+ implementeringer

Tre praktiske lærdommer fra arbeid med norske kunder:

Konsistens slår fullstendighet. En kunde som har Organization, LocalBusiness og WebSite korrekt implementert — alle med samme @id-strategi og samme info — slår en kunde som har 15 schema-typer som motsier hverandre. AI-modeller får mistillit av motsigelser. Bedre å gjøre fem ting riktig enn 15 ting halvveis.

sameAs er undervurdert. De fleste byråer hopper over sameAs-arrayet. Det er et halvtimes oppslag på Brønnøysund og Proff per kunde, men det er sannsynligvis den enkelt-faktoren som har mest direkte påvirkning på om ChatGPT verifiserer deg som ekte bedrift.

Sub-typer er gull. «LocalBusiness» er generisk. «Dentist» eller «HairSalon» eller «Plumber» er presist. Når AI-modeller besvarer bransje-spesifikke spørsmål («tannlege i Bergen»), prioriterer de sider som har den eksakte sub-typen over generiske LocalBusiness-sider. Det er en 30-sekunders endring som gir betydelig løft.

Hva vi ikke gjør

Det er flere schema-typer som høres lovende ut, men som vi har valgt å holde oss unna:

Review og AggregateRating: Bare hvis kunden har et reelt og verifiserbart anmeldelses-grunnlag. Falske ratings utløser manuell straff fra Google.
HowTo: Bare for sider som faktisk er steg-for-steg-instruksjoner. Tjeneste-sider med «vår prosess» er ikke HowTo — det er beskrivelse, ikke instruksjon. Misbruk får schemaet ignorert.
Event: Bare for tidsbegrensede ting (foredrag, kurs). Permanente tjenester er ikke events.
Course: Bare for reelle kurs med læringsutbytte, ikke «vi tilbyr opplæring».

Vi har sett konkurrenter pakke nettsider med schema-typer som ikke matcher innholdet. Det får et midlertidig løft i Rich Results, men når Googles kvalitetsteam plukker det opp manuelt, blir hele nettsiden devaluert i 3-6 måneder. Risiko-justert avkastning er negativ.

Konkret om hvordan vi rull dette ut

På et standard Medcom-prosjekt går schema-implementering slik:

Uke 1, dag 1-2: Innsamling. Vi henter org.nr fra Brønnøysund, søker opp Proff og 1881-oppføringer, dokumenterer åpningstider, samler inn Person-bios fra kunden.

Uke 1, dag 3: Sitewide injection. Organization, LocalBusiness, WebSite i <head> på alle sider — gjøres én gang via Vite-template.

Uke 1, dag 4-5: Per-route schemas. Service med Offer på tjeneste-sider, FAQPage på pillar-sider, BreadcrumbList overalt, Person-noder.

Uke 2: Validering. Vi kjører hver hovedside gjennom Google Rich Results Test og rapporterer alle valid types til kunden. Etter det er det vedlikehold, ikke gjenstand for endring.

Det er rundt seks-åtte timer effektiv implementering for en typisk SMB. Det vi ser i Google Search Console og AI-citation-spørringer 3-6 måneder senere er enkelt det høyest avkastende SEO-arbeidet vi gjør.

Spør oss

Hvis du lurer på om din egen nettside har schema riktig implementert, kan du teste det selv på vårt verktøy sjekksynlighet.no. Det er en 30-sekunders sjekk som blant annet identifiserer manglende schema-typer.

Hvis du vil at vi gjør jobben for deg, gir vi gratis estimat per kunde-prosjekt. Schema er sjelden en jobb i seg selv — det inngår i AEO-grunnmuren som vi leverer som del av månedlig SEO-abonnement eller engangs ved nytt nettsted.