Sanity som headless CMS: sjekkliste før du velger

Sanity er et headless CMS der innholdet ligger i en strukturert database og hentes via API til frontend. Det passer når du trenger fleksibel innholdsmodell, flere kanaler eller et Next.js-prosjekt. For en enkel bedriftsside er WordPress ofte enklere og billigere å drifte.

Hva Sanity faktisk er – og ikke er

Sanity er et headless CMS. Det betyr at innholdet lagres som strukturerte data hos Sanity, og at du bygger selve nettsiden – frontend – som et separat prosjekt som henter innholdet via API. Redaktørene jobber i et grensesnitt som heter Sanity Studio, som du selv konfigurerer i kode og deployer et sted (ofte samme sted som resten av prosjektet).

Til forskjell fra WordPress som tradisjonell plattform, der tema og innhold er tett vevd sammen, gir Sanity deg full frihet på frontend. Det er både styrken og svakheten: du får ingen ferdig side, og du må ha noen som bygger den. En ny web-side med Sanity er alltid et utviklingsprosjekt, ikke et installasjonsprosjekt.

Sanity vs. WordPress vs. andre headless CMS

Valget står sjelden bare mellom Sanity og «noe annet headless». Det står som regel mellom Sanity og en tradisjonell løsning. WordPress dokumenterer selv hvordan plattformen kombinerer tema, redigering og hosting i én stack – se WordPress sin egen dokumentasjon – og det er nettopp den koblingen headless CMS bryter opp.

Sjekkliste: er Sanity riktig for prosjektet ditt?

Gå gjennom punktene under før du signerer noe. Hvis du svarer nei på mer enn tre, bør du vurdere en enklere plattform.

1. Har du en utvikler som skal drifte frontend? Sanity krever at noen bygger og vedlikeholder Next.js, Nuxt eller lignende. Hvis nei: velg en tradisjonell plattform, eller lei inn et byrå med kontinuerlig ansvar – ikke bare et byggeprosjekt.
2. Er innholdet strukturert og gjenbrukbart? Sanity skinner når samme innhold skal ut i app, nettside og nyhetsbrev. Hvis nei: en tradisjonell CMS med sider og blogg dekker behovet med mindre overhead.
3. Har du definert innholdsmodellen på papir før dere koder? Feltene i Sanity Studio er kode – å endre dem senere krever migrering. Hvis nei: sett av en workshop før utvikling starter, ellers bygger dere om halve modellen etter tre måneder.
4. Har dere avklart roller og publiseringsflyt? Sanity har roller, utkast og «drafts», men flyten må tenkes ut. Hvis nei: skisser hvem som skriver, godkjenner og publiserer før dere setter opp studioet.
5. Er bilder og media planlagt? Sanity har egen asset-pipeline med on-the-fly transformering. Hvis nei: les opp på image-URL-parametere før dere bygger komponenter som viser bilder.
6. Har dere estimert kostnaden ved reell trafikk? Prisplanen skalerer med brukere, API-kall og båndbredde. Hvis nei: sjekk aktuell prisplan hos Sanity med realistiske tall for antall redaktører og forventet trafikk før dere velger.
7. Er previews og utkast satt opp riktig? Redaktører må kunne se endringer før publisering – dette er ikke gratis i headless. Hvis nei: budsjetter tid for draft mode i Next.js eller tilsvarende, det er en fast kostnad i alle Sanity-prosjekter.
8. Har dere en plan for søk? Sanity har GROQ og et innebygget søk, men fritekstsøk for sluttbrukere er ofte en egen tjeneste (Algolia, Typesense). Hvis nei: bestem tidlig om søk er en feature eller ikke.
9. Hvordan skal skjemaer og innsendinger håndteres? Sanity lagrer innhold, ikke leads. Hvis nei: velg en skjemamotor og et CRM-system før dere bygger kontaktsiden, ikke etter.
10. Er analyse og sporing planlagt fra dag én? Headless betyr at du selv setter opp Google Analytics for web og eventuelle konverteringspiksler. Hvis nei: legg dette inn i sprintplanen, ikke som «vi tar det etterpå».
11. Har dere avklart hvem som eier domenet og DNS? Sanity leverer ikke hosting av frontend – den ligger typisk på Vercel eller Netlify. Hvis nei: rydd i eierskap før lansering, ikke i panikk kvelden før.
12. Vet dere hvordan innholdet skal migreres inn? Import fra WordPress eller Excel til Sanity krever et script. Hvis nei: budsjetter en til to dager utviklingstid per innholdstype, mer hvis dataene er rotete.

Fallgruver vi ser oftest i Sanity-prosjekter

De vanligste feilene er sjelden tekniske i seg selv – de handler om avgjørelser tatt for tidlig eller for sent.

• Innholdsmodell endret rett etter lansering: fordi ingen testet Studio med reelle redaktører, må halve modellen migreres etter én måned.
• Preview som ikke virker: draft mode er ikke satt opp, og redaktørene publiserer «for å se hvordan det ser ut». Deretter ligger halvferdige tekster live.
• Blandet test- og prod-datasett: samme API-nøkkel brukes begge steder, og testinnhold havner i produksjon.
• Manglende webhook mellom Sanity og Vercel/Netlify: publisering fører ikke til rebuild, og innholdet er «usynlig» i timer.
• Bilder uten alt-tekst-felt i schema: tilgjengelighet og SEO svekkes fordi redaktøren aldri fikk spurt.
• Ingen backup-strategi: Sanity har eksport, men ingen setter opp faste dumper før noe går galt.

Hva Sanity koster i praksis

Sanity har en gratisplan som holder for små prosjekter, men prisen skalerer med antall brukere, API-kall, båndbredde og datasett. Legger du til at frontend skal hostes (Vercel, Netlify), at previews krever egen konfigurasjon, og at utvikling av Studio-schemaene tar tid, blir totalen fort høyere enn en WordPress-side med samme funksjonalitet.

Box sin regel for verktøyvalg: færrest mulig systemer, dypest mulig integrasjon. Hver ekstra plattform er et nytt sted data kan gå tapt og en ny månedskostnad som sjelden evalueres.

Fra Box sine egne kundekontoer ser vi at regelen særlig gjelder headless-stacks: Sanity + Vercel + Algolia + separat skjemamotor + separat kommentarløsning ender i fem abonnementer og fem steder å feilsøke. En tradisjonell plattform samler det i én. Det er ikke et argument mot Sanity – det er et argument for å vite hvorfor du velger det.

Når Sanity ikke er riktig valg

Vi anbefaler mot Sanity når:

• Nettsiden er en klassisk bedriftsside med forside, om oss, tjenester og kontakt. WordPress eller Webflow er raskere å bygge og enklere å drifte.
• Redaktøren er én person uten teknisk bakgrunn som vil dra og slippe blokker. Sanity Studio er ryddig, men det er ikke Elementor.
• Prosjektet har ikke budsjett til vedlikehold av frontend. Headless flytter kompleksitet fra CMS til frontend – noen må eie den.
• Nettbutikken er standard Shopify- eller WooCommerce-scope. Sanity kan kobles til begge, men gir sjelden nok verdi til å forsvare merarbeidet på små butikker.
• Dere trenger å publisere i morgen. Et Sanity-prosjekt fra null tar uker, ikke dager.

I disse tilfellene er en tradisjonell plattform det riktige, og vi sier det til kundene våre selv om det betyr et mindre prosjekt for oss.

Sanity og AI: hva som er reelt i 2026

Strukturert innhold er en fordel når KI og andre former for kunstig intelligens skal bruke innholdet ditt – både internt (til en AI-chatbot som svarer på produktspørsmål) og eksternt, når søkemotorer og AI-flater trekker ut svar. Sanity gjør det enklere å eksponere ren, strukturert data enn en tradisjonell CMS full av HTML-blokker.

Men vær nøktern: strukturerte data gir ikke automatisk plass i AI-svar. Googles AI Overviews og AI Mode henter fra de vanlige søkesystemene, og det er kvaliteten og relevansen på innholdet som avgjør – ikke om det ligger i Sanity eller WordPress. At innholdet er lett å bygge om til flere format, er den reelle gevinsten. Bruk gjerne en AI-detektor for norsk tekst på det redaktørene skriver hvis dere har en policy på det, uansett plattform.

Hvordan komme i gang – og når hente inn hjelp

Har du bestemt deg for at Sanity er riktig, er rekkefølgen som regel: (1) modellere innhold på papir, (2) sette opp Sanity-prosjekt og Studio, (3) bygge frontend, (4) koble på webhooks og previews, (5) importere eksisterende innhold, (6) lansere. Hvert steg har fallgruver, men det er steg 1 som avgjør om resten går smertefritt.

Trenger du noen som kan bygge dette sammen med dere – både innholdsmodell, Studio og frontend – kan vi i Box hjelpe. Se hvordan vi jobber med nettside-prosjekter eller ta kontakt for en gjennomgang av om Sanity faktisk er riktig for dere. Skal siden også drive salg gjennom Google Ads eller andre annonsekanaler, bør sporing tenkes inn samtidig, ikke etterpå.