Økonomien i headless WordPress 2026: når det lønner seg, og når det ikke gjør det

#Økonomien i headless WordPress 2026: når det lønner seg, og når det ikke gjør det

De fleste påstander av typen “vi kuttet hostingkostnadene med 70 prosent med headless” er regnskapsfiksjon. De teller den nye regningen, ikke migreringskostnaden som skapte den, og de overser tiden fra erfarne utviklere som holder den nye arkitekturen i drift. Headless WordPress lønner seg, men det skjer ikke av seg selv.

Denne artikkelen beskriver rammeverket jeg bruker med kunder for å ta beslutningen før migreringen starter. Den er driftssidens motstykke til tjenesten headless WordPress og beslutningsmatrisen Next.js eller Astro.

Utgangspunktet er enkelt, men blir ofte oversett: å bytte abstraksjonslag er ikke gratis. Det økonomiske spørsmålet er om besparelsen på det nye laget er større enn kostnaden ved å flytte.

#Er headless WordPress verdt kostnaden

• Headless senker hostingkostnaden for offentlig trafikk ved å fjerne PHP per forespørsel.
• Headless legger til en engangskostnad for migrering, dominert av arbeidet med å bevare SEO.
• Headless legger til en løpende kjøretidskostnad på kanten som vokser med trafikken.
• For et innholdsnettsted er break-even som regel noen måneder. For et svært lite nettsted aldri.
• Den største gevinsten kommer på konverteringssiden, ikke kostnadssiden: Core Web Vitals gir inntekter. Rene Shopify-bygg prises med en Shopify-utvikler, ikke som et sideprosjekt i WordPress-budsjettet.

#Hvilke tre kostnadskolonner finnes i headless WordPress

Å kalle det “hostingkostnad” er den første feilen. Det finnes tre kolonner.

Kolonne én: infrastruktur for offentlig trafikk. Det du betaler for å betjene en besøkende. På en WordPress-monolitt er dette regningen fra PHP-verten pluss CDN. På headless er det kjøretiden på kanten (for eksempel Cloudflare Workers) pluss en mindre WordPress-origin som bare betjener redaktører og REST API-et.

Kolonne to: bygging og migrering. Det du betaler én gang for å flytte fra én arkitektur til en annen. Tid fra erfarne utviklere, bevaring av SEO, kartlegging av omdirigeringer, bildemigrering, opplæring av innholdsteamet, parallell drift av begge stakkene under overgangen.

Kolonne tre: løpende utviklingsarbeid. Det du betaler hver måned for å holde den nye arkitekturen i drift. CI-minutter, rammeverksoppdateringer, administrasjon av Cloudflare-kontoen, overvåking, kostnaden ved at en erfaren frontend-utvikler har ansvaret for frontend-rammeverket.

En seriøs sammenligning summerer alle tre kolonnene over samme tidshorisont. De fleste markedsføringspåstander summerer bare kolonne én og presenterer differansen som besparelsen.

#Hva koster hosting for headless WordPress

En WordPress-monolitt hos en typisk PHP-vert betaler for kapasitet. Enten nettstedet får én besøkende eller tusen, kjører en server. Regningen er fast. CDN-kostnadene vokser med trafikken. Database, objektcache og helsidecache reduserer CPU per forespørsel, men fjerner den ikke.

Headless på Cloudflare Workers betaler per forespørsel og per CPU-millisekund. Et svar med forhåndsrendret HTML på kanten tar en brøkdel av et CPU-millisekund. WordPress-origin kjører bare når en redaktør lagrer, når en webhook utløses eller når frontenden trenger nye data. For offentlig trafikk som stort sett består av lesing, er dette strukturelt billigere.

For en WooCommerce-butikk er bildet mer nyansert. Personaliserte sider og ruter for innloggede brukere koster fortsatt CPU i frontenden. Statiske katalogsider gjør det ikke. Når katalogen har stabilisert seg, taler fordelingen som regel likevel for headless.

#Prisene for Cloudflare Workers til en headless WordPress-frontend

Cloudflare publiserer satsene på prissiden for Workers. Gratisnivået gir 100 000 forespørsler per dag og 10 millisekunder CPU-tid per kall. Workers Paid har en minsteavgift på 5 USD i måneden per konto. I standard faktureringsmodell er 10 millioner forespørsler og 30 millioner CPU-millisekunder per måned inkludert. Hver ekstra million forespørsler koster 0,30 USD, hver ekstra million CPU-millisekunder 0,02 USD.

For headless-regnestykket betyr to setninger i denne dokumentasjonen mer enn satsene. Den første: forespørsler til statiske ressurser er gratis og ubegrensede. Forhåndsrendret HTML som publiseres som statisk ressurs, gir altså ingen avgift per forespørsel, og bare ruter som kjører Worker-kode faktureres: søk, skjemaer, handlekurv, forhåndsvisning av utkast. Den andre står på siden om grenser: venting på nettverket, altså fetch()-kall, KV-lesinger og databasespørringer, teller ikke som CPU-tid. En Worker som henter data fra WordPress REST API og venter på origin, betaler for sin egen beregning og ikke for en treg origin.

CPU-grensene avgjør nivået. På gratisnivået har et HTTP-kall 10 ms CPU-tid. På Workers Paid er standarden 30 sekunder per forespørsel, og den kan økes til 5 minutter. Forskjellen betyr noe for SSR, fordi hver rendring på forespørsel må passe inn i dette budsjettet. En helt statisk frontend leverer gratis statiske ressurser og berører aldri CPU-grensen.

#Full rebuild eller ISR for headless WordPress

Kostnaden for å oppdatere innhold havner ett av to steder: ved bygging eller ved forespørsel.

Med en full statisk build utløser hver publisering i WordPress en webhook og en ny build. Grensene for Cloudflare Pages viser hvor taket ligger: 500 builds per måned på Free, 5 000 på Pro og 20 000 på Business, med én build om gangen på Free, fem på Pro og tjue på Business. En build avbrytes etter 20 minutter. Free tar imot opptil 20 000 filer per nettsted, betalte nivåer opptil 100 000. En redaksjon som lagrer 20 ganger om dagen, med en build etter hver lagring, trenger rundt 600 builds i måneden, altså mer enn Free gir. Et flerspråklig nettsted med tusenvis av innlegg og bilder kan i stedet nå filgrensen. Begge grensene kan omgås, for eksempel ved å samle builds eller holde bilder utenfor deployen, men det er arbeid som skal planlegges i kolonne to og ikke oppdages etter lansering.

Incremental Static Regeneration i Next.js flytter denne kostnaden til forespørselstidspunktet. ISR-dokumentasjonen beskriver to moduser: tidsbasert oppdatering med revalidate og oppdatering ved behov med revalidatePath eller revalidateTag, som en webhook fra WordPress kan kalle etter at et innlegg er lagret. Den samme siden lister opp begrensninger som endrer regningen. ISR fungerer bare med Node.js-runtime og ikke ved statisk eksport. Med flere instanser er standard filsystem-cache separat for hver instans, og oppdatering ved behov ugyldiggjør bare instansen som mottar kallet, så det trengs en felles cache handler. Regenerering i bakgrunnen kjører på instansen som betjente forespørselen, og på plattformer med fakturering per forespørsel teller den som ekstra beregning. ISR sparer altså builds, men legger til infrastruktur og en post for beregning. En full build er enklere så lenge den holder seg innenfor grensene.

#Hvorfor er migreringen den bærende kostnaden i headless WordPress

Den største engangskostnaden i ethvert headless WordPress-prosjekt er selve migreringen, nærmere bestemt arbeidet med å bevare SEO. Alle de sju mønstrene i SEO-mønstre for headless WordPress tar tid. Å hoppe over noen av dem koster mer.

Konkrete elementer:

• Kartlegge hver eksisterende kanonisk URL.
• Ta vare på omdirigeringshistorikken, inkludert stille omdirigeringer fra /wp-content og landvelgere.
• Føre metadata fra Yoast eller Rank Math inn i frontend-renderingen.
• Bygge opp hreflang på nytt som selvrefererende HTML, ikke bare JSON.
• Kontrollere at strukturerte data samsvarer i rapportene for utvidede resultater i Search Console.
• Stenge den gamle WordPress-origin ute fra synlighet i søkeindeksen.
• Bygge opp alt-tekster og strukturerte bildedata på nytt for bildesøk.

En migrering som gjør dette arbeidet ordentlig, tar uker med tid fra erfarne utviklere. En migrering som lar være, koster måneder med opprydding senere. Spisset sagt: hver casestudie med “vi sparte 70 prosent” der selskapet også måtte “gjøre om SEO etter tre måneder”, er et tilfelle der migreringskostnaden ble betalt to ganger.

#Hva koster drift av headless WordPress

Et headless-oppsett legger til en permanent driftsflate. CI kjører ikke lenger bare utvidelsesoppdateringer for WordPress, men også rammeverksoppgraderinger, gjennomganger av avhengigheter og byggeløp for frontenden. Bruken av Cloudflare Workers må gjennomgås. Oppførselen til cachen på kanten må overvåkes. En erfaren frontend-utvikler må være med, der en monolitt noen ganger kunne driftes av en ren backend-generalist.

Konkret bør du forvente:

• Én CI-arbeidsflyt for WordPress-origin (utvidelser, temaer, kjerne).
• Én CI-arbeidsflyt for bygging og utrulling av frontenden.
• Én observerbarhetsflate som dekker kjøretiden på kanten, Workers-feil og helsen til REST API-et.
• Én person på vakt for begge stakkene som faktisk forstår grensen mellom dem.

Det siste punktet er det som oftest blir undervurdert. Jeg har revidert migreringer der det opprinnelige utviklingsteamet sluttet etter overgangen, og det neste teamet arvet en arkitektur de ikke følte eierskap til. Økonomien i en slik situasjon er dyster uansett besparelsene i kolonne én.

#Hva WordPress-origin fortsatt trenger etter overgangen til headless

Origin blir mindre, men forsvinner ikke. Kravene til WordPress er de samme som for en monolitt: anbefalt PHP 8.3 eller nyere, MySQL 8.0 eller MariaDB 10.11 eller nyere, og støtte for HTTPS. Det som endres, er lastprofilen, ikke listen over oppgaver. Serveren trenger fortsatt oppdateringer, sikkerhetskopier og overvåking, den betjener bare redaktører og build i stedet for besøkende.

Builden henter innhold gjennom REST API, og det har sin egen aritmetikk. Dokumentasjonen om paginering begrenser per_page til 100 poster, og headerne X-WP-Total og X-WP-TotalPages returnerer antall poster og sider. En full build av et nettsted med 10 000 innlegg er dermed minst 100 forespørsler bare for innleggslisten, før sider, kategorier, media og hver ekstra språkversjon kommer til. En origin som svarer tregt under denne lasten, forlenger hver build, og en build i Cloudflare Pages har 20 minutter på alt.

Forhåndsvisning av utkast krever autentisering. Håndboken for REST API begrenser autentisering med informasjonskapsler til forespørsler fra innsiden av WordPress, så en ekstern frontend bruker applikasjonspassord (Application Passwords). De har vært i kjernen siden versjon 5.6 og sendes til REST API over HTTPS som Basic Auth. Et applikasjonspassord er enda en hemmelighet som skal lagres i Worker-innstillingene og byttes jevnlig, altså enda en post i kolonne tre.

#Når lønner headless WordPress seg

Rammeverket jeg bruker med kunder, er konservativt. Vi modellerer 24 måneder og tre kolonner, med trafikkmønster og publiseringstakt som inndata.

Headless lønner seg som regel innen 12 måneder når:

• Den offentlige trafikken er så høy at kapasiteten hos PHP-verten er flaskehalsen.
• Mobile Core Web Vitals henger sammen med inntektene (netthandel, leadgenerering).
• Redaksjonen fortsetter å bruke WordPress og har nytte av den samme arbeidsflyten.
• En erfaren frontend-utvikler allerede er i teamet eller er engasjert for hele perioden.

Betingelsen om Core Web Vitals kan bare kontrolleres med måling før og etter migreringen. web.dev oppgir tersklene for et godt resultat: LCP innen 2,5 sekunder, INP på 200 millisekunder eller mindre og CLS på 0,1 eller mindre, målt ved 75. persentil av sidevisninger, delt på mobil og desktop. Hvis nettstedet allerede holder seg innenfor disse tersklene som monolitt, svekkes konverteringsargumentet, og regnestykket må stå på de andre kolonnene.

Det lønner seg ikke innen 24 måneder når:

• Den offentlige trafikken er lav og en liten PHP-vert holder.
• Publiseringstakten er lav (ett innlegg i måneden), slik at redaksjonens tempo ikke er en flaskehals.
• Nettstedet domineres av interaktive produktgrensesnitt som uansett trenger SSR og hydrering på klienten.
• Ingen erfaren frontend-utvikler er tilgjengelig, slik at orkestreringskostnaden havner hos en generalist.

#Hva endrer regnestykket for kostnadene ved headless WordPress

Tre forhold flytter break-even raskere enn ventet:

For det første, AI-funksjoner på kanten. Cloudflare Workers AI, MCP-servere og personalisering rendret på kanten er billig på en Workers-kjøretid og dyrt (ofte umulig) på en delt PHP-vert. Et nettsted som vil levere metabeskrivelser generert av LLM, agentvennlige endepunkter eller priser per region, når break-even for headless raskere.

For det andre, lovgivning om universell utforming. I Norge pålegger likestillings- og diskrimineringsloven § 18 både offentlige og private virksomheter å utforme hovedløsningene sine for IKT universelt, og § 36 regulerer håndhevingen av disse reglene. EUs tilgjengelighetsdirektiv (European Accessibility Act) kommer til Norge gjennom EØS-avtalen, og selger du til Tyskland, gjelder BFSG der siden juni 2025. Begge sporene kan gjøre en frontend som ikke er universelt utformet, til en juridisk kostnad, innenfor omfanget som er beskrevet nedenfor. Migreringsrevisjoner som uansett må rette opp tilgjengeligheten, betaler seg ofte inn på kolonnen for juridisk risiko alene.

For det tredje, AI-handel og oppdagelse via agenter. Siden Trial-ringen på vår Tech Radar omfatter Universal Commerce Protocol, blir handel som agenter kan lese, et kjøpssignal. Headless-arkitekturer eksponerer produkter som data på en ryddigere måte enn monolitter.

#Hvem European Accessibility Act omfatter

Det juridiske argumentet i forrige seksjon gjelder bare der regelverket gjelder. Direktiv (EU) 2019/882 omfatter tjenester som leveres til forbrukere etter 28. juni 2025, blant dem e-handelstjenester. Direktivet definerer disse som tjenester som leveres på avstand, gjennom nettsteder og mobile tjenester, elektronisk og på individuell forespørsel fra en forbruker, med sikte på å inngå en forbrukeravtale. Artikkel 4 nr. 5 unntar mikroforetak som leverer tjenester fra tilgjengelighetskravene. Et mikroforetak har etter direktivet færre enn 10 ansatte og en årlig omsetning eller balansesum som ikke overstiger 2 millioner euro.

Det gir en enkel fordeling. En nettbutikk over grensen for mikroforetak har kolonnen for juridisk risiko uansett arkitektur, og migreringen er tidspunktet der rettelser av tilgjengeligheten likevel går inn i frontenden. Et mikroforetak, eller et nettsted som ikke selger til forbrukere og ikke leverer noen av de andre tjenestene direktivet lister opp, har ikke denne kolonnen, og der gjør ikke det juridiske argumentet tilbakebetalingen raskere. Det er samme konklusjon som i seksjonen om når headless ikke lønner seg: små nettsteder mangler poster på sparesiden som kunne dekket migreringskostnaden.

#Relaterte guider om headless WordPress

Denne artikkelen støtter tjenesten headless WordPress, hører sammen med artikkelen om SEO-mønstre, lenker til vår TCO-guide for headless eller monolittisk WordPress 2026 for økonomisk modellering over flere år, og viser til beslutningsmatrisen Next.js eller Astro. Beslutningsløpet: les denne for “er byttet verdt det”; deretter TCO-guiden for den fullstendige økonomiske modellen over fire år; deretter SEO-mønstrene for “hvordan beholder vi rangeringene”; til slutt valget av rammeverk for “hvilken frontend trenger denne arbeidslasten”.