Legg inn LocalBusiness i JSON‑LD nå: navn, adresse, telefon, åpningstider og sameAs. Det er et sentralt tiltak lokale bedrifter kan gjøre for schema markup. Prioriter kjernefeltene name, address, telephone, openingHours, geo og sameAs, valider koden på validator.schema.org, og sørg for at alt stemmer nøyaktig med Google Business‑profilen din.
Kort oppsummert:
- Kontrollér at LocalBusiness-koden har riktige felter for navn, adresse, telefon, åpningstider og sammeAs, og valider den før publisering.
- Velg den mest spesifikke schema-typen, som for eksempel "Tannlege" eller "Rørlegger", for å gi tydeligere signal til søkemotorer.
- Oppdater alltid NAP-oplysninger slik at de stemmer nøyaktig overens med Google Business-profilen for å unngå feil og mistillit.
- Bruk schema for å styrke AI-forståelsen, men husk at riktig plassering i Google Maps er avhengig av profil, geografi og anmeldelser.
- Valider schema-koden regelmessig i validator.schema.org og oppdater den umiddelbart ved endringer for å unngå feil som påvirker synlighet og tillit.
Innholdsfortegnelse
- Hva er schema markup, og hvorfor bruker vi JSON‑LD?
- Hvilke schema-typer trenger en lokal bedrift?
- Hjelper schema fortsatt i 2026, med all AI-oppmerksomheten?
- Slik ser et gyldig LocalBusiness-eksempel ut
- Fra kode til publisert side: en praktisk fremgangsmåte
- Hvordan validerer og vedlikeholder du markeringen?
- Hvilke feil koster deg mest?
- Tre tiltak du kan starte med i dag
- Hva kan du forvente etter at koden er lagt inn?
- SkapeFlyts erfaring med strukturert data for lokale kunder
- Vil du ha schema riktig fra start?
- Kilder
Hva er schema markup, og hvorfor bruker vi JSON‑LD?
Schema markup er strukturert data. Det er kode du legger i nettsiden som forklarer for maskiner hva innholdet faktisk betyr, ikke bare hvordan det ser ut. Et telefonnummer på siden er for et menneske bare tekst. Med riktig markering vet Google, og etter hvert AI‑modeller, at nettopp dette nummeret er bedriftens telefonnummer.
JSON‑LD er formatet Google har anbefalt siden 2015, og det er i praksis standarden i dag. Det er en egen kodeblokk du limer inn i sidens <head>, separert fra det synlige innholdet. Fordelen er at du kan oppdatere den maskinlesbare informasjonen uten å røre designet, og utviklere finner feil raskere enn med eldre formater som microdata.
Hvilke schema-typer trenger en lokal bedrift?
De fleste lokale nettsteder trenger bare noen få typer, men de må velges riktig. Skjelvet mellom en generisk og en spesifikk type er større enn mange tror.
- LocalBusiness eller en undertype: velg den mest spesifikke typen som finnes, for eksempel
Restaurant,DentistellerPlumber, i stedet for generiskLocalBusiness. Schema hundrevis av undertyper, og de gir et klarere signal enn en generell klassifisering. - Service: brukes på egne tjenestesider når bedriften selger avgrensede tjenester, for eksempel «rørleggerservice akutt» eller «tannrens».
- Review/AggregateRating: kun hvis anmeldelser faktisk vises på siden. Aldri som utsmykning.
- BreadcrumbList: viser stien brukeren tok gjennom nettstedet, og hjelper søkemotorer å forstå sidehierarki.
- Article: relevant for blogginnhold, spesielt hvis du publiserer lokale nyheter eller guider.
- sameAs: lenker til offisielle profiler som Google Business, Facebook eller bransjeregistre. Feltet er underbrukt, men det knytter nettstedet ditt til en verifiserbar digital identitet utenfor egen side, ifølge Schema.
Hjelper schema fortsatt i 2026, med all AI-oppmerksomheten?
Ja, men rollen har endret seg. Strukturert data er i økende grad et signal AI‑svarmotorer bruker for å forstå hvem du er og hva du tilbyr, og det påvirker sjansen for at tjenesten din blir sitert i et AI‑generert svar. Se det som en investering i maskinforståelse og digital tillit, ikke en snarvei til høyere rangering.
Det schema ikke gjør, er å plassere deg i det lokale pakkesøket i Google Maps. Den plasseringen styres av Google Business‑profilen din, geografisk nærhet og anmeldelser, ikke av kodeblokken alene. Og merk aldri opp innhold som ikke faktisk vises på siden. Det er både et Google‑brudd og villedende for AI‑lesere.
Slik ser et gyldig LocalBusiness-eksempel ut
Et minimalt, men fullverdig eksempel for en tannklinikk kan se slik ut:
{
"@context": "https://schema.org",
"@type": "Dentist",
"@id": "https://eksempel.no/#bedrift",
"name": "Eksempel Tannklinikk",
"address": {
"@type": "PostalAddress",
"streetAddress": "Storgata 12",
"addressLocality": "Bergen",
"postalCode": "5003",
"addressCountry": "NO"
},
"telephone": "+4755123456",
"geo": {
"@type": "GeoCoordinates",
"latitude": 60.3913,
"longitude": 5.3221
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:00",
"closes": "16:00"
}
],
"sameAs": ["https://www.facebook.com/eksempeltannklinikk"]
}
| Felt | Hva det gjør |
|---|---|
@id | Gir bedriften en stabil identitet du kan referere til fra andre markup‑blokker, som brødsmuler eller artikler |
address (PostalAddress) | Strukturerer gateadresse, poststed og land i separate, maskinlesbare deler |
geo (GeoCoordinates) | Gir eksakte koordinater, nyttig for kart og nærhetsbaserte søk |
openingHoursSpecification | Lister åpningstider per ukedag i et format maskiner kan tolke uten gjetting |
Et stabilt @id styrker entitetskonsistens fordi andre deler av koden kan peke tilbake til samme enhet. Alt i blokken må stemme nøyaktig med det som står synlig på siden og i Google Business‑profilen din. Et avvik, selv et lite, skaper mistillit hos algoritmen.
Fra kode til publisert side: en praktisk fremgangsmåte
- Bestem hvor koden skal ligge. Forsiden trenger LocalBusiness‑blokken. Har du flere avdelinger, legger du en egen blokk per fysisk lokasjon, aldri én blokk som dekker alle adresser.
- Velg genereringsmetode. WordPress‑brukere kan bruke plugins som Yoast SEO eller Rank Math, som fyller ut mye automatisk. Alternativt bruker du Googles Structured Data Markup Helper, eller skriver JSON‑LD‑koden manuelt hvis du vil ha full kontroll.
- Legg inn tjenestespesifikk markup. Egne Service‑blokker på tjenestesider, ikke bare på forsiden.
- Kjør en siste sjekkliste før publisering: stemmer NAP (navn, adresse, telefon) med Google Business‑profilen? Har hver lokasjon sitt eget
@id? Er sameAs‑lenkene riktige? Vises eventuelle anmeldelser faktisk på siden hvis du bruker AggregateRating?
Profftips: Lim JSON‑LD‑koden inn i validator.schema.org før du publiserer, ikke etter. Det tar to minutter og fanger opp feil i typer og felt du ellers ikke ser før Google gjør det for deg.
Hvordan validerer og vedlikeholder du markeringen?
Validator.schema.org er hovedverktøyet for å sjekke at koden følger schema.org‑vokabularet riktig. Merk at Google har fjernet FAQ‑resultater fra Rich Results Test, så det verktøyet er ikke lenger like relevant for strukturkontroll generelt.
Sett en enkel rutine: hver gang du endrer åpningstider, adresse eller telefonnummer, oppdaterer du JSON‑LD‑koden samme dag og kjører en ny validering. Bekreft også visuelt på den live siden, ikke bare i utviklingsmiljøet. Har du tilgang til Search Console, sjekk den regelmessig for strukturfeil i indeksert innhold. Feil som oppdages tidlig, er langt billigere å fikse enn feil som har ligget udetektert i månedsvis.
Hvilke feil koster deg mest?
Den vanligste feilen er FAQ‑markup uten synlig FAQ‑tekst på siden. Det er ikke bare mot Googles retningslinjer, det er direkte villedende for AI‑verktøy som stoler på at markert innhold faktisk finnes. FAQPage er fortsatt en gyldig type, men etter at Google fjernet FAQ‑rich results i mai 2026, gir det ingen synlig dropdown i søkeresultatene lenger, bare verdi for AI‑parsere som leser strukturen.
Nummer to er NAP‑mismatch: adressen i koden stemmer ikke med Google Business‑profilen. Nummer tre er falske eller manglende anmeldelser bak en AggregateRating‑blokk. Bruk aldri et gjennomsnitt du ikke kan vise frem på siden.
Tre tiltak du kan starte med i dag
- Oppdater LocalBusiness‑blokken med de seks kjernefeltene, og valider den umiddelbart.
- Legg til sameAs‑lenker til dine offisielle profiler, og vis lenkene et sted på siden.
- Kjør validator.schema.org og ta et skjermbilde av et grønt resultat til intern kvalitetskontroll.
Hva kan du forvente etter at koden er lagt inn?
Søkemotorer finner vanligvis den nye koden innen noen dager. AI‑svarmotorer tar ofte lengre tid, gjerne noen uker, før endringen slår ut i faktiske sitater. Målbare resultater i AI‑sitering krever tålmodighet; følg med på endring i sitatsannsynlighet, om kunnskapsfeltet om bedriften blir mer nøyaktig, og CTR i organisk søk. Forvent derimot ikke en umiddelbar hopp i det lokale pakkesøket. Det styres av andre faktorer.
SkapeFlyts erfaring med strukturert data for lokale kunder
Skapeflyt bygger schema som en fast del av hver nettsideleveranse til lokale kunder i Bergen, ikke som et tillegg man selger inn etterpå. Det handler om å få navn, adresse, tjenester og åpningstider til å stemme overalt, fra synlig tekst til kode til Google Business‑profilen.
Erfaringen er at entitetsklarhet gjør en konkret forskjell: besøkende som allerede har sett riktig informasjon om bedriften i søkeresultatet, tar kontakt med færre spørsmål og mer tillit. DIY fungerer godt for en enkeltside med én lokasjon. Har du flere avdelinger, tjenestesider og et ønske om at alt skal holde seg konsistent over tid, er profesjonell hjelp verdt investeringen.
— Skape
Vil du ha schema riktig fra start?
Skapeflyt er alternativet til å lete deg fram i plugin‑innstillinger og validator‑feilmeldinger på egen hånd. Vi legger inn korrekt @type, kjernefelter og sameAs‑lenker som en del av selve nettsideleveransen, ikke som et separat prosjekt du må sette bort etterpå.
I det første møtet går vi gjennom en enkel sjekkliste: hvilken undertype som passer bedriften din, hvilke felter som mangler i dagens informasjon, og om du har flere lokasjoner som krever separate blokker. Trenger du bare en oppdatering av eksisterende side, eller en helt ny nettside i Bergen, får du en konkret plan samme uke. Se prisene for nettside eller ta kontakt for et estimat basert på antall lokasjoner og tjenester du trenger markert opp.