Ø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 vi 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.
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.
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-contentog 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. Vi 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.
Når lønner headless WordPress seg?
Rammeverket vi 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.
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. BFSG i Tyskland siden juni 2025, EUs tilgjengelighetsdirektiv (European Accessibility Act) og den polske tilgjengelighetsloven straffer nettsteder med trege frontender som ikke er universelt utformet. 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.
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”.
