Sanity headless CMS: hvordan det fungerer og når det passer

Sanity er en headless CMS der innholdet ligger i en skybasert database og hentes ut via API, mens redigeringsverktøyet Sanity Studio kjører som en egen React-applikasjon du selv tilpasser. Det gir stor fleksibilitet, men forutsetter at noen bygger og drifter frontenden – det følger ingen ferdige temaer med.

Hva er Sanity, konkret?

Sanity er en headless CMS. «Headless» betyr at systemet ikke bestemmer hvordan innholdet ser ut. Det lagrer innhold som strukturerte data og gjør dem tilgjengelige via API. Hvordan innholdet presenteres – nettside, app, skjerm i butikk – er en helt separat jobb.

I praksis møter du tre deler. Sanity Studio er redigeringsverktøyet redaktørene logger inn i. Det er en applikasjon bygget i React som du selv konfigurerer og publiserer, ikke et ferdig grensesnitt du bare får utdelt. Content Lake er den skybaserte databasen der innholdet faktisk ligger, driftet av Sanity. API-ene er det frontenden snakker med når den skal hente ut innhold.

Den viktigste forskjellen fra WordPress er at innholdsmodellen defineres i kode. Du skriver skjemaer som sier at en artikkel har en tittel, en ingress, en brødtekst og en forfatterreferanse – og Studio bygger redigeringsgrensesnittet ut fra det. En redaktør kan ikke legge til et nytt felt selv. Det er både poenget og prisen.

Rik tekst lagres som Portable Text, et JSON-format, i stedet for som HTML. Det høres teknisk ut, men konsekvensen er praktisk: samme avsnitt kan rendres som HTML på nettsiden, som ren tekst i et nyhetsbrev og som noe helt tredje i en app, uten at noen har limt inn `<div>`-er i brødteksten.

Et konkret tilfelle: når WordPress slutter å være problemet, og blir det

Ta en typisk situasjon vi kjenner igjen: en norsk produsent med en produktkatalog som har vokst i mange år. Nettsiden ligger på WordPress, produktene er lagt inn som vanlige sider med tekst, bilder og tabeller limt inn i editoren. Selgerne bruker de samme produktdataene i tilbudsdokumenter. Datablader ligger som PDF-er. Ingen vet lenger hvilken versjon som er den riktige.

Utgangspunktet var ikke at WordPress var tregt eller stygt. Det fungerte fint som nettsted. Problemet var at produktinformasjonen bare eksisterte som formatert tekst inne i sider. Skulle et teknisk spesifikasjonsfelt endres på tvers av femti produkter, måtte noen åpne femti sider.

Valget som måtte tas var egentlig ikke «Sanity eller WordPress». Det var: skal produktdata behandles som tekst eller som data? Man kan komme et godt stykke med egendefinerte felttyper i WordPress. Det er en reell mulighet, og for en bedrift uten utviklerressurser er det ofte det rette svaret. Vi ville ikke anbefalt en migrering til Sanity kun for å slippe å redigere femti sider én gang.

Det som tipper regnestykket er når de samme dataene skal brukes flere steder: på nettsiden, i en produktvelger, i et datablad som genereres automatisk, og etter hvert i en nettbutikk. Da er strukturert innhold i en headless CMS ikke en luksus, det er forutsetningen for at det i det hele tatt lar seg gjøre.

Jobben som faktisk ble gjort i et slikt prosjekt, er heller ikke først og fremst teknisk. Den store innsatsen ligger i å bestemme hva et produkt *er*: hvilke felt som er obligatoriske, hva som er en referanse til noe annet, og hva som skal være fritekst. Selve importen fra det gamle systemet er et script. Modelleringen er uker med diskusjoner mellom folk som kan produktene.

Hva du faktisk får igjen

Innhold som kan gjenbrukes. Når en produktspesifikasjon er ett felt og ikke en setning inne i et avsnitt, kan den vises i en tabell, i en sammenligning og i et generert PDF-datablad – fra samme kilde. Dette er den eneste fordelen som er verdt en migrering alene.

Redigeringsgrensesnittet kan formes. Fordi Studio er kode, kan du skjule alt en redaktør ikke trenger, legge inn valideringsregler og lage forhåndsvisning som viser den ekte siden. I ferdige systemer må redaktøren tilpasse seg verktøyet. Her er det motsatt.

Sanntid og historikk. Flere kan jobbe i samme dokument samtidig, og endringer versjoneres. For redaksjoner med flere hender i samme innhold er dette merkbart i hverdagen.

Frontend-frihet. Du velger rammeverk og hosting fritt, og du er ikke avhengig av et tradisjonelt webhotell med PHP og MySQL på samme måte som med WordPress. Design og komponentbibliotek kan utvikles uavhengig av innholdssystemet, noe som gjør det enklere å holde en konsistent visuell profil på tvers av flater.

Hva det koster deg

Dette er delen som pleier å mangle i artikler om headless, så la oss være tydelige.

• Du må ha utviklere, permanent. Ikke bare til lansering. Nye innholdstyper, nye seksjoner og nye felt er utviklingsoppgaver. Har du ingen fast teknisk partner, blir dette en flaskehals.
• Det finnes ingen tema- eller plugin-marked. Alt du i WordPress løser med en utvidelse – skjemaer, søk, kaker, nyhetsbrevpåmelding – må velges og kobles på selv.
• To systemer å drifte. Studio og frontend er separate applikasjoner med hver sin livssyklus og hver sine oppdateringer.
• Prismodellen er bruksbasert. Antall brukere, API-kall og båndbredde påvirker kostnaden. Det er en annen logikk enn en fast månedspris som hos tjenester med pakkepriser, og den er vanskeligere å budsjettere før du kjenner trafikken. Sjekk gjeldende priser og grenser hos Sanity selv, de endres.
• Innholdet ligger i en tjeneste du ikke drifter. Du kan eksportere hele datasettet, så det er ikke en innelåsing i innholdet ditt. Men driften ligger hos leverandøren, og det bør være et bevisst valg.

Sanity sammenlignet med alternativene

Sanity konkurrerer i praksis i to retninger: mot tradisjonelle CMS-er og mot andre headless-leverandører som Contentful, Storyblok og Strapi. Den korte versjonen er at Sanity ligger lengst mot «tilpassbart» og lengst fra «ferdig ut av boksen».

Skal du ha en presentasjonsside med noen få undersider, er en nettsidebygger et bedre og billigere svar enn headless. Vi sier det rett ut, fordi vi ser altfor mange som velger headless på grunn av arkitekturargumenter som ikke gjelder deres situasjon.

SEO og synlighet: det headless krever av deg

Headless er hverken bra eller dårlig for søk i seg selv. Det flytter ansvaret. Alt WordPress-plugins gjør automatisk – tittel-tagger, metabeskrivelser, kanoniske URL-er, sitemap, videresendinger – må bygges inn i frontenden og i innholdsmodellen din.

Vi anbefaler at metafelter legges inn som egne felt i skjemaet fra dag én, med validering og forhåndsvisning av hvordan tittelen ser ut i søkeresultatet. Årsaken er at hvis feltene ikke finnes, blir de aldri fylt ut, og da genereres metadata automatisk fra brødteksten. Det er sjelden bra nok.

Etter opprydding i tittel-tagger og metabeskrivelser alene ser Box typisk 15–30 % høyere organisk klikkrate i Search Console innen 4-8 uker.

Det andre punktet er rendering. Sanity leverer JSON; noen må gjøre det om til HTML. Gjøres det utelukkende i nettleseren, gjør du deg avhengig av at hver enkelt konsument klarer å kjøre JavaScript. Vi anbefaler server-rendering eller forhåndsgenererte sider for alt innhold som skal være synlig i søk. Dette er ikke omdiskutert lenger, og det er den vanligste tekniske feilen vi ser i headless-prosjekter.

I 2026 handler synlighet også om AI-flatene. Googles AI Overviews og AI Mode henter fra de samme søkesystemene som vanlige resultater, og Googles egen veiledning for generative AI-funksjoner peker på det samme grunnarbeidet: innhold som lar seg hente, indekseres og forstås. Google har uttalt at de ikke bruker llms.txt. Det finnes en inkluderingsinnstilling i Search Console, og Search Console har egen rapportering for AI-flatene, slik at du kan se dem i ytelsestallene.

Det som *er* omdiskutert, er hvor mye strukturerte data betyr for å bli sitert i AI-svar. Vi lener mot at det hjelper indirekte – ved at maskiner forstår hva siden handler om – men vi ville ikke solgt inn schema-markup som en garanti for plass i AI-svar. Det er ikke dokumentert. Sjekk heller i sideindekseringsrapporten at sidene faktisk indekseres etter en migrering; det er det målbare.

Ved bytte av system er videresendinger fra gamle til nye URL-er den delen som oftest blir gjort halvveis. Har du hundrevis av gamle adresser, er det verdt å bruke verktøy som kan hjelpe med kartlegging og opprydding, men listen må kvalitetssikres manuelt.

Hvem bør velge Sanity – og hvem bør la være

Sanity er et godt valg når innholdet ditt er en ressurs som skal brukes flere steder, når strukturen er sammensatt nok til at «side med tekst» ikke holder, og når du har eller vil ha en fast teknisk partner. Det gjelder produsenter med kataloger, tjenestebedrifter med mange varianter av samme innhold, og virksomheter som skal betjene flere markeder eller språk fra samme kilde.

Det er et dårlig valg hvis du er en liten bedrift med en informasjonsside, hvis budsjettet ikke tåler løpende utviklingstimer, eller hvis den som skal drifte nettsiden internt forventer å kunne dra og slippe nye seksjoner selv. Da kjøper du kompleksitet uten å få noe igjen for den.

Er du usikker på hvilken side av den grensen du står på, er det verdt å ta beslutningen sammen med noen som har bygget begge deler – vi hjelper gjerne til med å vurdere det i en gjennomgang av nettsideprosjektet før du binder deg til en plattform.