Headless WordPress i 2026 er et etablert teknisk valg med uavklart forretningssak. Spørsmålet er ikke om Next.js eller Astro kan rendre WordPress-innhold godt, for begge kan. Spørsmålet er hva du kjøper med den andre kodebasen, og det ærlige svaret står i WordPress core: en frakoblet frontend betaler kontant for hver bekvemmelighet monoliten får gratis.
De fleste sammenligninger priser dette som en multiplikator. Headless koster to eller tre ganger et tema-bygg, et tall ingen kan sjekke og alle siterer. Den nyttige versjonen er en liste over de spesifikke tingene core slutter å gjøre for deg når frontenden ikke lenger er et PHP-tema, fordi det er linjepostene byrået faktisk fakturerer. Listen er kort, kjent på forhånd, og den er hele år null.
Denne artikkelen er selve beslutningen. Lang modell med fireårs kontantstrøm: TCO-guiden headless vs monolittisk WordPress 2026.
1. Byggekostnader i starten (år 0)
Start med hva API-et faktisk gir deg, for gapet mellom det og et fungerende nettsted er bygget.
Core leverer REST, ikke GraphQL. REST_API_VERSION er 2.0 i wp-includes/rest-api.php, ruter har vært registrerbare siden 4.4, og wp/v2-namespace er det en stock WordPress 7.1.1 svarer på. GraphQL er WPGraphQL, som ble kanonisk plugin i oktober 2024 med Automattic-backing etter at Jason Bahl flyttet dit. Canonical er et sterkt signal om vedlikehold. Det er ikke core. Du installerer, versjonerer og patche, og ethvert byråtilbud som sier «WordPress snakker GraphQL» har hoppet over en avhengighet.
Deretter det du betaler en JavaScript-utvikler for å skrive:
Navigasjonen. wp/v2/menus finnes, WP_REST_Menus_Controller har vært i core siden 5.9, og den svarer ikke på anonyme forespørsler. check_has_read_only_access() returnerer true bare for edit_theme_options, edit_posts eller redigeringsrettighet på en offentlig posttype, med mindre noen snur rest_menu_read_access. Frontenden autentiserer på hvert bygg, eller du skriver et lite offentlig endepunkt og eier cachen. Dette er det hvert headless-innlegg mener med «du må bygge menyen» uten å si hvorfor.
Forhåndsvisning. Utkast er ikke offentlige data, og core har rett. Å lese upublisert innhold krever autentisert forespørsel: application passwords (core siden 5.6) eller JWT-plugin, pluss preview-rute på frontenden, pluss en måte for redaktøren å klikke Forhåndsvis i wp-admin og lande der. Tre bevegelige deler, ingen valgfrie, ingen i framework-starteren.
Blokk-CSS. Filteret should_load_separate_core_block_assets defaulter fortsatt til false, men core lar det ikke stå: _add_default_theme_supports() snur det til true for blokktemaer, og wp_load_classic_theme_block_styles_on_demand() (siden 6.9) gjør det samme for klassiske temaer. Et stock 7.x-nettsted printer stilene til blokkene som brukes, fra wp_head() og wp_footer(). Frontenden din kaller ingen av dem. Du importerer stylesheet-en, eller restyler hver core-blokk redaktørene kan sette inn: columns, gallery, quote, table, buttons, separator, cover. Det er ikke en hard jobb. Det er en jobb noen må scope, og den dukker sjelden opp i estimatet.
Skjemaer og alt med atferd. Seksjon fire, fordi det er kostnaden etter lansering.
Ingenting av dette gjør headless til et dårlig valg. Det gjør år null til et lett kall: hvis du ikke allerede finansierer et frontend-team, vinner monoliten på byggekostnad hver gang, fordi WordPress core gjør ubetalt arbeid for deg.
2. Vedlikehold og drift (år 1-3)
Sikkerhet
Den vanlige versjonen sier at en frakoblet arkitektur skiller angrepsflaten, så en sårbar skjemaplugin ikke lenger kan nå databasen. Det er usant som formulert. Pluginen kjører fortsatt inne i samme WordPress-installasjon, mot samme database, med samme capabilities. Decoupling flyttet rendering. Den flyttet ikke sårbarheten.
Det decoupling faktisk kjøper er et alternativ monoliten ikke har: fordi det offentlige nettstedet ikke lenger er WordPress, kan du sette originen bak IP-allowlist, VPN eller privat nettverk og eksponere bare frontenden og endepunktene den trenger. En monolit kan ikke det. Hvis headless WordPress sitter på et offentlig hostname med wp-admin nåbart fra hvor som helst, og de fleste gjør det, betalte du for arkitekturen og hoppet over fordelen.
Andre halvdel er mindre flatterende. Du patche to runtime-er på to kadenser. WordPress sender minor releases med automatiske bakgrunnsoppdateringer, og 7.1.1 landet 17. september 2026 uten at noen på teamet gjorde noe. Ingenting i JavaScript-avhengighetstreet oppfører seg slik. Next.js 16.3.5 ble publisert 11. september 2026, Astro 7.3.3 16. september 2026, og Nodes LTS-linjer utløper etter egen kalender (Node 18 Hydrogen tok siste release 27. mars 2025). En monolit har ett oppgraderingsløp. Headless har to, og det raskere er det ingen budsjetterte for.
Redesign
Smidighetsargumentet er det sterkeste reelle punktet for headless, og det overdrives vanligvis med ett ord. «Frontenden er ren React eller Vue» er ikke nøyaktig for Astro, som sender ingen klient-JavaScript som standard. Den nøyaktige påstanden: når innholdsmodellen står stille, kan en frakoblet frontend bygges om uten å røre WordPress, og det er genuint billigere enn å kjempe mot page-builder-markup eller et tema med ti år betingede maler.
Forbeholdet er samme setning i revers. Når redesignet endrer hvilket innhold som finnes, ikke bare hvordan det ser ut, redigerer du to repositories, koordinerer to deploys og skriver en migrering som må lande i begge. Halvparten av redesignene som selges som «bare frontend» trenger ett nytt felt, og det er dagen det andre repositoryet slutter å være gratis.
For offentlig sektor i USA: DOJs endelige regel under ADA Title II (Federal Register 24. april 2024) setter WCAG 2.1 Level AA for statlig og lokal offentlig webinnhold, med frister 2027 og 2028 avhengig av befolkning. Hvis ombygging skjer uansett, er det billigste øyeblikket for tilgjengelighetsarbeid. I Norge treffer det samme via universell utforming: WCAG går inn i scope ved ombygging, ikke som senere lag.
3. Ytelse og konverteringsrate
Ytelsesargumentet for headless var sterkt i 2020. Det er smalnet fra begge ender siden, og begge endringer er daterbare.
Metrikken endret seg først. INP erstattet FID som Core Web Vital 12. mars 2024. FID målte hvor lenge nettleseren brukte på å bekrefte første interaksjon, nær gratis for server-rendret side. INP måler latensen til interaksjoner gjennom hele besøket, direkte hovedtrådarbeid. En hydration-tung React-frontend er arkitekturen som sender mest hovedtrådarbeid. SSR får headless på nivå med PHP-tema på paint. Den setter det ikke foran, og på INP kan den sette det bak. Et bygg som behandler JavaScript som opt-in (Astro islands eller React Server Components) er versjonen som faktisk vinner.
Core beveget seg i den andre enden. Speculative loading landet i WordPress 6.8, dokumentert i dev note av 6. mars 2025. På nettsted med pretty permalinks, for utloggede, emitterer core Speculation Rules som standard, og 7.1 la til WP_SPECULATIVE_LOADING_DEFAULT_MODE og WP_SPECULATIVE_LOADING_DEFAULT_EAGERNESS. Default er prefetch med conservative eagerness. Det er prefetch, ikke prerender. Det tar fortsatt bort deler av det en JavaScript-router tidligere var synlig grunn til, på et stock-tema uten router.
Forretningssaken er aritmetikk på egne tall. Ta nåværende konverteringsrate, legg til ett prosentpoeng, multipliser med et år ordrer og gjennomsnittlig ordreverdi, og sammenlign med headless-bygg pluss stående frontend-ingeniør. På høyvolum-butikk klarer løftet kostnaden innen første år. På katalog med beskjedent volum klarer det den aldri, og den ærlige anbefalingen er den de fleste byråer hopper over: bruk de samme pengene på caching, bilder og checkout, og bli på temaet.
4. «Plugin-skatten»
Dette er kostnaden etter lansering, den som avslutter markedsteamets goodwill, og den har en presis mekanisme.
I WP_REST_Posts_Controller::prepare_item_for_response() bygges content-feltet slik:
$data['content']['rendered'] = post_password_required( $post )
? ''
: apply_filters( 'the_content', $post->post_content );the_content kjører. Shortcodes ekspanderer, blokk-callbacks utføres, markup kommer tilbake. Det som ikke kommer tilbake er alt pluginen registrerte på wp_enqueue_scripts, printet i wp_head(), eller hooked til wp_footer(). Resultatet ser ut som en bug: slider-shortcode returnerer div med riktige klasser, ingen stylesheet, ingen initialiser. Pristabell uten CSS. Skjema uten submit-handler. Redaktøren ser det fungere i wp-admin (fortsatt monolitt), ser det ødelagt i produksjon, og filer ticket mot frontend-teamet.
Skatten er ikke «finn et React-bibliotek for et lykkehjul». Den er at hver plugin markedsteamet installerer ankommer halvlevert. To plugins i året er støy. To i måneden er en retainer.
Unntak: WooCommerce vedlikeholder Store API under wc/store, så handlekurv og checkout er byggbare mot dokumentert kontrakt. Det overveldende flertallet av plugin-kataloget har ingen ekvivalent og får aldri det.
Flip side: Install-knappen er også monolitens største ansvar. Headless gjør hver installasjon til en samtale med en ingeniør. Er governance-problemet at hvem som helst kan installere hva som helst, er friksjonen en feature du betaler for med vilje.
5. Hostingkostnader
To runtime-er betyr to regninger, og det er den minst interessante delen av tallet.
Formen er PHP-origin for WordPress pluss separat host for frontenden, Node-runtime eller statisk bygg, typisk på Vercel, Netlify eller Cloudflare. WP Engines headless-plattform parer Node-miljø med WordPress-hosting under én leverandør. Uansett kjører du to ting der du kjørte én.
Linjeposten som glemmes er ikke den andre regningen. Det er publisering som når frontenden. På monolitt invaliderer publisering object cache og page cache. På statisk generert frontend må publisering trigge noe: on-demand revalidation-webhook, targeted purge eller scheduled rebuild. Stien er kode, skjør som webhooker, og når den feiler sier redaktøren at innlegget er live mens nettstedet er uenig. Noen må eie den, overvåke den og være tilgjengelig fredag klokken sytten.
Den andre glemte posten er observability. En monolit har én logg. En frakoblet stack har PHP-feil ett sted, frontend-byggfeil et annet, forespørslene mellom dem et tredje, og den første alvorlige produksjonsincidenten er der du oppdager at ingen korrelerte dem.
6. Dommen: når bør du gå headless?
Bruk tradisjonell WordPress hvis
- Budsjettet dekker én bygging, ikke stående frontend-ingeniør etterpå.
- Marked installerer visuelle plugins uten utvikler i løkken.
- Informativt nettsted: speculative loading og cache gir allerede det meste av hastighetsgevinsten.
- Ingen intern JS og ingen ansettelsesplan. Byrået kan bygge; noen må holde det i live.
Bruk headless WordPress hvis
- Du publiserer til mer enn én destinasjon fra én workflow (nettsted + app / innholdsflate i produktet).
- Du tar WordPress-originen av nettet; compliance eller trusselmodell rettferdiggjør det.
- Ytelse er inntekt, volumet dekker stående team, JS er opt-in.
- WordPress er ett system blant ERP/CRM, innholdsmodellen stabil.
Headless er en bemanningsbeslutning med arkitektur festet. Hvem skriver frontenden i måned atten, og er personen på lønningslisten? Uklart svar betyr monolitt.
Vi bygger begge; headless bare når tallene faller ut til dens fordel. Astro på shortlisten: Astro-utvikler. Scope: kontakt.
