Spørsmålet i 2026 er ikke om WordPress kan kjøre uten temaet sitt. Det kan det. Spørsmålet er hvilken topologi som tåler Gutenberg, forhåndsvisning, innlogging og norsk checkout uten at origin blir et offentlig PHP-endepunkt.
I flere år betydde headless WordPress at redaktøren mistet forhåndsvisning, at menyer ble JSON-håndarbeid, og at hvert skjema krevde en egen rute mot REST. De hullene er tettet. WordPress 7.0 (Armstrong) kom 20. mai 2026. WordPress 7.1 på PHP 8.4 er origin vi bygger mot nå. Gutenberg leverer blokktrær som JSON. WPGraphQL har persisted queries. Astro 7 leverer HTML med JavaScript bare på øyer. Next.js 16 leverer Partial Prerendering og Server Actions. Det som gjenstår, er arkitektur: hvem som eier datakontrakten, hvor cachen bor, og hvordan norske rammer (NSM, Digdir, Vipps, Bring, VOEC) treffer flyten.
Denne guiden er en arkitekturtekst. Den fireårige kostnadsmodellen, med CapEx og OpEx, ligger i TCO-guiden for headless mot monolitt. Ikke lim inn den tabellen her. Les den når du skal forsvare budsjettet. Les denne når du skal tegne bokser og piler.
Frontend først: Astro 7-øyer og Next.js 16
Velg rammeverk etter hvor mye av siden som er dokument, og hvor mye som er applikasjon. Innholdstunge flater hører hjemme i Astro 7. Applikasjoner med sesjon, handlekurv og sanntidsfilter hører hjemme i Next.js 16. Begge leser samme WordPress-origin.
Astro 7 kompilerer sider til HTML. Standardleveransen er null kilobyte JavaScript i det første maleriet. Interaktive biter (søk, filter, minikurv, innloggingsknapp) hydreres som øyer med client:visible eller client:idle. Det er den arkitekturen som matcher en redaksjonell WordPress-installasjon: de fleste URL-ene er artikler, landinger og arkiv. De trenger ikke en React-runtime i <head>.
Next.js 16 er det riktige valget når store deler av visningen avhenger av innlogget tilstand, personalisering eller et handlekurvtre som ikke kan forhåndsrendres. App Router, React Server Components og Partial Prerendering (PPR) lar deg holde skallet statisk og la hull i treet (pris, lager, Vipps-knapp) fylles på kanten. Server Actions erstatter egne REST-endepunkter for skjemaer, så lenge actionen kaller WordPress bak Zero Trust og ikke eksponerer admin-cookie mot nettleseren.
En hybrid er vanlig: Astro 7 for magasin, merkevare og dokumentasjon, Next.js 16 for Min side og kasse. Da er WordPress fortsatt én origin. To fronter krever én felles blokk-til-komponent-katalog og ett GraphQL-skjema. Uten den katalogen divergerer visningen i løpet av et kvartal.
Faust.js og tilsvarende WordPress-spesifikke Next-lag kan være en snarvei for preview-cookies. De er ikke et krav. Et tynt preview-endepunkt med HMAC og Draft Mode gjør samme jobben, og det virker mot både Astro og Next. Ikke la leverandørens startmal bestemme topologien.
Klient (nettleser)
|
v
Kant (Cloudflare): HTML, assets, cache-tags
|
+-- treff: ferdig dokument, ingen PHP
|
+-- bom (preview, Min side, kasse)
|
v
Frontend-runtime (Astro 7 / Next.js 16)
|
v
Zero Trust-gateway
|
v
WordPress 7.1 / PHP 8.4 / WPGraphQL
|
v
MySQL + RedisHvis 80 prosent av sidetreffene aldri når PHP, har du en headless-arkitektur. Hvis hvert treff treffer origin for å «være dynamisk», har du en dyrere monolitt med ekstra hopp.
Når frikobling er riktig topologi
Frikobling lønner seg når innholdet har flere konsumenter, eller når sikkerhetspolitikken forbyr å eksponere PHP mot internett. Det lønner seg ikke som pynt på et markedssideprosjekt med tre redaktører og Gutenberg-landinger hver uke.
Velg headless når minst ett av disse holder:
- Samme innhold skal ut på nett, i app, på skjermer i butikk og som kilde for interne assistenter, uten at redaktøren limer inn teksten tre ganger.
- Frontend-teamet eier et designsystem i Astro eller React, og WordPress skal ikke diktere markup.
- wp-admin og databasen skal ligge i privat nett bak SSO. Offentlig origin skal være statiske filer og cachede dokumenter.
- TTFB under 50 ms globalt er et krav, og dere aksepterer at cachen bor på kanten med tag-basert ugyldiggjøring.
Bli på monolitt når:
- Marked skal sette sammen landingssider i Gutenberg uten å vente på en frontend-utvikler for hver ny blokkvariant.
- WooCommerce-kassen bruker utvidelser som skriver HTML, shortcodes og egne sesjonscookies i samme request som butikken.
- Teamet har PHP-kapasitet og mangler TypeScript-kapasitet. To pipelines uten eier er ikke en arkitektur, det er et hendelsesløp.
En moderne monolitt på PHP 8.4 med Full Site Editing, Redis og side-cache er ikke «gammel WordPress». Den taper på flerkanal og på angrepsflate. Den vinner på redaksjonell fart. Arkitekturen skal velges mot det tapet dere faktisk har, ikke mot et foredrag om headless.
Pris og eierskap over fire år er et annet spørsmål. Bruk TCO-guiden når du skal sammenligne CapEx i år 1 med drift senere. Her stopper vi på topologi.
Datakontrakten: WPGraphQL, REST og persisted queries
WPGraphQL er lesestien for rike sider. REST er skrivestien for enkle hendelser. Blandingen er bevisst, ikke et kompromiss dere «må rydde opp i senere».
Et klassisk REST-kall mot /wp-json/wp/v2/posts returnerer titalls felt du ikke bruker i et arkiv. For en side med innlegg, forfatter, tre relaterte poster og et ACF-repeaterfelt blir det flere HTTP-runder. WPGraphQL løser treet i ett kall, med DataLoader som slår sammen ID-oppslag til WHERE ID IN (...). Det er grunnen til at GraphQL vant i frikoblede WordPress-flater, ikke fordi GraphQL er «moderne».
Tre regler for skjemaet:
- Eksponer det redaktøren eier, ikke det temaet eide. Custom Post Types, taksonomier og felt. Ikke «the_content som HTML-sekk» med shortcodes som forventer PHP-runtime.
- Persisted queries i produksjon. Klienten sender en hash, ikke en vilkårlig spørring. Introspeksjon er av. Maks dybde og kompleksitet er satt. Uten det er GraphQL et åpent vindu inn i databasen.
- Cache-tags på svaret.
post-1425,tax-tema-headless,author-8,lang-nb. Uten tagger tømmer du hele kanten hver gang noen retter en skrivefeil.
REST beholder jobber GraphQL er dårlig på: innkommende webhooks fra Bring, betalingshendelser, skjemaposter fra et tynt endepunkt, og CRUD fra interne verktøy. De endepunktene autentiseres med App Passwords eller korte JWT-er, aldri med infinitt application password i et frontend-repo.
<?php
declare(strict_types=1);
namespace WPPoland\Nb\GraphQL;
add_action('graphql_register_types', static function (): void {
register_graphql_field('Post', 'heroAlt', [
'type' => 'String',
'description' => 'Alt-tekst for LCP-bildet, påkrevd i skjemaet.',
'resolve' => static function (array $post): string {
$id = (int) ($post['databaseId'] ?? 0);
$thumb = get_post_thumbnail_id($id);
if ($thumb === 0) {
return '';
}
$alt = get_post_meta($thumb, '_wp_attachment_image_alt', true);
return is_string($alt) ? $alt : '';
},
]);
});Et felt som heroAlt ser trivielt ut. Det er kontrakten som gjør at Astro og Next kan forhåndslaste LCP-bildet uten å gjette. Skjemaet er arkitekturen. Uten det blir hver side en ad hoc-spørring, og cache-nøklene slutter å stemme.
Norske rammer: NSM, Digdir, Vipps, Bring og VOEC
Headless i Norge styres av tilsyn, innlogging og kasse, ikke av om frontend er React. Hvis origin, sesjon og frakt ikke tåler NSM, Digdir og norske betalingsflater, er frikoblingen et skallselskap rundt samme PHP-risiko.
NSMs grunnprinsipper for IKT-sikkerhet treffer topologien i kategoriene som handler om anskaffelse, nettverk og dataflyt. En monolitt eksponerer en PHP-tolk og en database bak samme vertsnavn som kundene treffer. En frikoblet flate kan legge wp-admin og MySQL i privat nett, med offentlig origin som bare serverer dokumenter. Det er grunnprinsippet «beskytt virksomhetens nettverk» i praksis: angrepsflaten mot kjernen er ikke lenger den samme URL-en som magasinets forside. Kartlegging av leveranseledd (hvilken utvidelse som kjører, hvem som vedlikeholder den, hvor fort den historisk har fått fiks) blir kortere når utvidelsene ikke lenger skriver til den offentlige HTML-en.
Universell utforming er den kravtypen team undervurderer. Forskrift om universell utforming av IKT-løsninger gjør tilgjengelighet til et tilsynsobjekt, ikke et designønske. Digdir fører tilsyn med digitale offentlige tjenester. I anskaffelser og i EØS-sporet (EN 301 549, europeisk tilgjengelighetslov) er WCAG 2.2 nivå AA listen arkitekten bygger mot i 2026. Konsekvensen av headless er tosidig. Du eier all markup i Astro eller Next, så et tilfeldig plugin kan ikke smette inn en knapp uten navn eller en modal uten fokusfelle. Du arver heller ikke den markupen temaet og utvidelsene ellers hadde levert. Skip-lenke, fokusrekkefølge, tekstveksling og skjemafeil er da frontend-teamets kontrakt, testet i CI, ikke «noe WordPress fikser».
Vipps Login mot WordPress-sesjonscookies er det punktet der mange frikoblede flater knekker. WordPress-innlogging er cookie på origin (wordpress_logged_in_*, wordpress_sec_*) med PHP-sesjon bak. Vipps Login er OIDC: autorisasjonskode, tokenendepunkt, kortlevd ID-token, ofte med BankID i bunnen for offentlige spor via ID-porten. Du kan ikke lime Vipps-tokenet inn i en WordPress-cookie og kalle det ferdig. Riktig flyt er: identitetsleverandøren (Vipps eller ID-porten) autentiserer personen mot frontend-domenet. Frontend bytter koden mot tokens. Hvis origin trenger å vite hvem som forhåndsviser eller hvem som leser betalt innhold, utsteder WordPress et kortlevd applikasjonstoken bak gatewayen, bundet til den samme identiteten. Offentlig HTML forblir cachebar. Sesjonen bor i en HttpOnly-cookie på frontend-domenet, ikke i wp-login.php på det kundene treffer.
Posten og Bring mot en headless-kurv er det andre knekkpunktet. En klassisk WooCommerce-kasse kjører fraktkalkyle, Checkout hos Bring og label-API i samme PHP-request som handlekurven. I headless er kurven et tre i frontend (Astro-øy eller Next-server), og Bring er et eget bounded context: postnummer, servicenivå (Klimanøytral Servicepakke, Hjemlevering, Pickup), sporingsnummer tilbake som hendelser. Ikke kall Bring synkront fra nettleseren. Ikke la GraphQL-skjemaet late som frakt er et felt på Post. Kurv og checkout er skrivesti. De har egne feilbaner (nedetid hos Bring, Ukjent postnummer, VOEC-beløp som endrer totalsum) og skal ikke dele cache-nøkkel med artikkelen om produktet.
VOEC treffer hvis butikken sender varer til Norge fra utlandet. Vat On E-Commerce er Skatteetatens ordning for utenlandske tilbydere som selger varer til norske forbrukere under beløpsgrensen for forenklet registrering. Arkitekturen må vite om ordren er VOEC-pliktig før kassen viser totalsum, ikke etter at Stripe har trukket. Det er data i ordren (selgers registrering, varens opprinnelse, mottakerland NO), ikke et CSS-problem i headless-kurven. En frontend som hardkoder MVA til 25 prosent på alt som ser norsk ut, lyver i kassen. Hold VOEC-regelen på origin eller i et eget prisingstjenestelag, og la frontend bare vise det laget returnerer.
Disse fem punktene (NSM, Digdir/WCAG 2.2, Vipps, Bring, VOEC) er grunnen til at en «headless Woo-mal» fra et globalt tema feiler i Norge. Topologien må tegnes mot tilsyn og kasse, ikke mot en bloggdemo.
Gutenberg som AST, ikke som HTML-sekk
Send blokktrær, ikke ferdig HTML. rendered fra REST er en felle: shortcodes, oEmbed og blokk-support som forventer temaets CSS kommer med, og frontend-rammeverket mister kontrollen over markup.
Mønsteret er blokk-til-komponent. WPGraphQL (eller et eget felt) eksponerer blocks { name attributes innerBlocks }. Astro 7 og Next.js 16 har samme katalog: core/paragraph, core/heading, core/image, pluss deres egne wppoland/hero. Ukjente blokker logges i utviklingsmiljø og vises ikke i produksjon, eller de faller tilbake til en avvisende, sanitert tekstkomponent. set:html og dangerouslySetInnerHTML er unntak for innhold dere har sanitert, ikke standardstien.
Konsekvens for redaktøren: hver ny blokk i Gutenberg krever en komponent i katalogen. Det er den reelle kostnaden ved headless, og den hører hjemme i TCO-guiden, ikke som et avsnitt om «frihet». Begrens paletten. Et designsystem med 12 blokker slår et tema med 80 blokker som ingen har mappet.
Bilder går gjennom frontendens bilderør (Astro Assets eller next/image) til AVIF med bredder som matcher layouten. WordPress lagrer originalen. Origin skal ikke tjene hero-4000px.jpg til mobil.
Forhåndsvisning uten å knekke produksjonsbufferen
Uten pålitelig preview dør headless i redaksjonen. Draft Mode er en signert, kortlevd unntakstilstand, ikke en ?preview=true som bypasser all cache for hele sonen.
Flyt:
- Redaktøren trykker Forhåndsvis i wp-admin.
- WordPress lager et HMAC-SHA256 over
postId, tidsstempel og status, gyldig i noen minutter. - Nettleseren treffer
/api/previewpå frontend-domenet. - Endepunktet sjekker signatur med
timingSafeEqual, setter en HttpOnly-cookie for draft, og sender 307 til sidens slug. - Siden ser cookien, hopper over edge-cache, og spør GraphQL om revisjonen med et origin-token som bare preview-runtime har.
Produksjonscachen røres ikke. En utløpt token gir 403, ikke et tomt dokument. Scheduled publishing bruker samme sti: webhook ved future til publish purger taggene, preview-cookien er irrelevant for anonyme treff.
Faust.js kan bære denne cookien for Next.js. I Astro 7 skriver du ruten selv. Det er femti linjer, ikke et rammeverkvalg.
Cache-tags på kanten, ikke full rebuild
Behandle kanten som et dokumentlager med nøkler, ikke som en CDN som «cacher HTML i 60 sekunder». Cache-Control: public, s-maxage=31536000, stale-while-revalidate=86400 pluss Cache-Tag: post-1425 lang-nb er kontrakten. Ved save_post sender origin en asynkron purge av de taggene. Ingressen, forfatterarkivet og den ene artikkelen faller. Resten av magasinets ti tusen URL-er blir stående.
Full statisk rebuild av hele nettstedet ved hver retting er den antimønsteret som gjør at team flytter tilbake til monolitt. ISR og on-demand revalidation i Next.js 16, og cache-tag-purge mot Cloudflare for Astro 7 på Pages, er samme idé: kirurgi, ikke amputasjon.
SWR (stale-while-revalidate) viser gammelt dokument med en gang og henter nytt i bakgrunnen. For nyheter med synlig tidsstempel kan du senke s-maxage. For landinger som endres ukentlig, kan du la dokumentet leve. Det er en redaksjonell policy, ikke en magisk header.
Oslo mot en database i Frankfurt er irrelevant så lenge treffet stopper på et POP i Norge. Oslo mot origin på hver HTML-request er den forsinkelsen folk kaller «headless er tregt».
Autentisering bak origin
Offentlig origin har ingen WordPress-sesjon. Maskin-til-maskin (bygg, preview-server, revalidate-webhook) bruker App Passwords eller et HMAC delt som hemmelighet i miljøet. Personinnlogging (Min side, preview som menneske, betalt innhold) bruker OIDC, i Norge oftest Vipps Login eller ID-porten, som beskrevet over.
JWT mot WordPress skal være kortlivede, signert med asymmetrisk nøkkel (RS256 eller Ed25519), med rotasjon. Et plugin som deler ut evige tokens til frontend-repoet er et innbrudd som venter. GraphQL-introspeksjon av, query depth-lås, og WAF-regler mot $alias storm er del av samme flate.
wp-login.php og /xmlrpc.php er ikke på det offentlige vertsnavnet. Cloudflare Access eller tilsvarende Zero Trust foran admin. Passkeys eller SSO inn i admin, ikke «sterke passord» som eneste kontroll.
Observabilitet gjennom hele kjeden
Et treff i headless krysser kant, frontend-runtime, gateway, WPGraphQL og SQL. PHP-loggen alene forklarer ikke et 800 ms-hull i Oslo. Sett W3C traceparent på kanten og før den gjennom GraphQL-resolverne. Når INP eller TTFB hopper, skal du se om det var cache-bom, en N+1 i et ACF-felt, eller en øy som hydrerte for tidlig.
OpenTelemetry er den praktiske standarden. NIS2 og DORA krever at dere kan forklare avvik, ikke at dere har et pent dashboard. Headless uten spor er to systemer som peker på hverandre når noe er nede.
Kontraktstester i CI
Skjemaet er en API-kontrakt. Breaking change i WPGraphQL skal feile pipen før deploy. Lagre persisted query-hashes i repoet. Kjør et steg som introspekterer staging (der introspeksjon er på) og diff mot committed schema. Frontend-bygget skal ikke starte hvis heroAlt er borte.
E2E for preview: et utkast i WordPress skal være synlig med gyldig token og usynlig uten. E2E for cache: publisering av innlegg 1425 skal ikke 404-e ingressen. Dette er billigere enn å oppdage det i redaksjonen mandag morgen.
Hva WPPoland bygger
Vi tegner origin, kant og frontend som tre deployables med én datakontrakt. Det er innholdet i tjenesten for headless WordPress: skjema, blokk-katalog, preview, cache-tags, og innlogging som tåler Vipps uten å åpne wp-admin mot internett.
Vi blander ikke inn en fireårskalkyle i arkitekturmøtet. Den ligger i TCO-guiden. Hvis monolitt er svaret, sier vi det. Hvis svaret er Astro 7 for magasin og Next.js 16 for Min side, tegner vi to fronter mot samme WordPress 7.1-origin.
Migreringsstien (URL-kart, 301 på kanten, hreflang, cutover) er beskrevet i guiden for migrering til Next.js og Astro. Den er en operasjon. Denne teksten er topologien den operasjonen realiserer.
Konklusjon
Headless WordPress i 2026 er en origin på PHP 8.4, en kant som eier HTML, og en frontend i Astro 7 eller Next.js 16 som mapper Gutenberg til komponenter. Det er ikke et tema du installerer. Det er en datakontrakt, en preview-flyt, cache-tags, og i Norge en eksplisitt holdning til NSM, Digdir, Vipps, Bring og VOEC.
Hvis du trenger tall på eierskap over fire år, les TCO-guiden. Hvis du skal bygge, start med skjemaet og med hva som får lov å nå PHP.
Kontakt oss når du vil ha en arkitekturskisse mot deres origin, ikke en ny mal.
