WordPress mot Contentful 2026: Headless CMS-arkitektur for bedrifter

#WordPress eller Contentful som headless CMS

Innen 2026 har begrepet “CMS” gjennomgått en radikal forvandling. Vi administrerer ikke lenger bare sider; vi administrerer innholdsgrafer. Ettersom levering på tvers av kanaler (omnichannel) blir standarden, har valget mellom WordPress (i sin Headless- eller hybridkapasitet) og Contentful (den rendyrkede SaaS Headless-kongen) blitt en kritisk arkitekturbeslutning.

I denne analysen utforsker vi de tekniske, økonomiske og strategiske implikasjonene ved å velge mellom verdens mest populære CMS og bransjelederen innen Composable Content. Hver API-detalj lenker til produsentens egen dokumentasjon, så du kan sjekke den mot versjonen du kjører.

#Forskjellen på WordPress og Contentful i arkitektur

#WordPress som decoupled hybrid-CMS

WordPress ble født som en bloggmotor, et dokumentbasert system. I 2026 er det imidlertid et hybridrammeverk som kan kjøre i flere moduser samtidig.

• Hybridfordelen: Du kan bruke WordPress for en tradisjonell nettside, samtidig som du eksponerer alle data via WPGraphQL. Slik kan et team flytte fra et klassisk tema til en headless frontend én seksjon av gangen.
• Brukervennlighet: Markedsføringsteam kan fortsatt bruke den visuelle blokkredigereren (Gutenberg) for å se innholdet sitt, selv om den faktiske frontenden er en separat React- eller Astro-applikasjon.

#Contentful som rent headless CMS

Contentful er API-First og Content-First. Den bryr seg ikke om en nettside, men om strukturerte data som enhver kanal kan hente.

• Innholdsmodellering: Du starter med et blankt lerret og definerer “innholdstyper” (f.eks. “Produkt”, “Hero-banner”, “Anmeldelse”). Den strenge strukturen holder dataene konsistente på tvers av kanaler.
• Omnichannel-kraft: Fordi innholdet er rene strukturerte data, kan det like gjerne konsumeres av en React-nettside, en Flutter-app, et Apple Vision Pro-grensesnitt eller en kiosk i butikken.

#WordPress og Contentful med React, Next.js og Astro

I den moderne teknologistabelen i 2026 ønsker ikke utviklere lenger å skrive PHP-maler. De ønsker å konsumere JSON og bygge grensesnitt med JavaScript-rammeverk.

• Jobbe med WordPress: Utviklere bruker WPGraphQL, en gratis utvidelse med åpen kildekode som gir enhver WordPress-side et GraphQL-skjema og et GraphQL-API. Siden på WordPress.org oppgir at den er i ferd med å bli en kanonisk utvidelse. Evnen til å spørre etter bare de dataene du trenger (f.eks. “gi meg tittel og hovedbilde for de siste 5 innleggene”) reduserer datamengden betydelig.

query SisteInnlegg {
  posts(first: 5) {
    nodes {
      title
      featuredImage {
        node {
          sourceUrl(size: MEDIUM)
          altText
        }
      }
      slug
    }
  }
}

• Jobbe med Contentful: Contentfuls Content Management API (CMA) og Content Delivery API (CDA) er modne og godt dokumentert. De tilbyr spesialiserte SDK-er for alle store språk. Det føles som et programvareverktøy, mens WordPress fortsatt føles som et innholdsverktøy, og det skillet betyr noe for utviklingsteam.

#Slik henter du innhold fra WordPress og Contentful via REST

GraphQL er valgfritt på begge sider. Hver plattform har også et enkelt REST-grensesnitt, og forskjellene viser seg så snart du blar gjennom et stort arkiv.

WordPress REST API. Kjernen eksponerer innlegg på GET /wp/v2/posts og svarer i JSON. Pagineringsguiden sier at per_page er begrenset til 100 poster, og hvert samlingssvar har to headere: X-WP-Total (antall poster i samlingen) og X-WP-TotalPages (antall sider som trengs for å lese alle). Et byggeskript leser den andre headeren og stopper der. De globale parameterne _fields og _embed styrer størrelsen på svaret: _fields returnerer bare de oppgitte feltene, _embed bygger inn lenkede ressurser som forfatter eller fremhevet bilde. Innleggsruten tar også et search-argument som begrenser resultatene til treff på en tekststreng.

curl -sD - "https://example.com/wp-json/wp/v2/posts?per_page=100&page=2&_fields=id,slug,title,modified" -o posts-2.json

Contentful Content Delivery API. Den offisielle JavaScript-klienten contentful.js løser som standard opp lenkede oppføringer direkte i svaret og lar uløselige lenker stå som lenkeobjekter. Kjedede modifikatorer endrer dette: withAllLocales returnerer alle språk i ett svar, withoutLinkResolution lar alle lenker stå som lenkeobjekter. Klienten prøver også mislykkede forespørsler på nytt selv: retryOnError er på som standard, og retryLimit er 5.

import * as contentful from 'contentful'

const client = contentful.createClient({ space: '<space_id>', accessToken: '<delivery_token>' })
const entries = await client.withAllLocales.getEntries({ content_type: 'article' })

Den praktiske forskjellen: I WordPress styrer du paginering og svarstørrelse selv med kjerneparametere, mens Contentful-SDK-et skjuler lenkeoppløsning og nye forsøk ved rate limit inne i klienten.

#Slik definerer du innholdstyper som kode i WordPress og Contentful

Begge plattformene lar deg holde innholdsmodellen i versjonskontroll i stedet for å klikke den sammen i et adminpanel.

WordPress. En egen innholdstype registreres i PHP med register_post_type. For et headless-prosjekt teller to argumenter: show_in_rest, som er false som standard og må være true for at typen skal dukke opp i REST API og i blokkredigereren, og rest_base, URL-segmentet REST-ruten bruker. WPGraphQL trenger egne argumenter. Ifølge WPGraphQL-dokumentasjonen legger show_in_graphql typen til i skjemaet, graphql_single_name setter navnet i camel case, og graphql_plural_name er valgfritt. Der er også en felle dokumentert: Registreres typen med public satt til false, må du legge til publicly_queryable satt til true, ellers gir anonyme spørringer tomme svar uten feilmelding.

Contentful. Verktøyet contentful-migration beskriver endringer i innholdsmodellen som JavaScript- eller TypeScript-skript. createContentType og createField tar en felttype fra en fast liste: Symbol (kort tekst), Text (lang tekst), Integer, Number, Date, Boolean, Object, Location, RichText, Array, Link og ResourceLink. Felt tar imot validations, et required-flagg og et localized-flagg. Det samme verktøyet skriver om eksisterende innhold: transformEntries endrer feltverdier i bulk, og deriveLinkedEntries skiller ut data til en ny lenket oppføring.

WordPress-modellen er en innholdstype med felt lagt til av utvidelser eller metaregistrering. Contentful-modellen er typet fra første felt. Derfor er API-svarene forutsigbare, og derfor krever enhver senere endring av modellen et migreringsskript.

#SEO i headless WordPress og Contentful

Hvordan AI-modeller “forstår” innholdet ditt avhenger av hvor tydelig strukturen din er. I 2026 omfatter SEO også optimalisering for store språkmodeller.

E-E-A-T-signal: WordPress lar deg enkelt koble forfattere til autoritative ekspertprofiler. I Contentful må du bygge hele denne relasjonsmodellen fra bunnen av, noe som gir prosjektet mer arbeid.

#Hva koster Contentful sammenlignet med WordPress

Her er forskjellene mest synlige, og ofte avgjør de valget.

WordPress TCO:

• Lisens: 0 kr. WordPress er åpen kildekode under GPL.
• Driftskostnader: hosting for WordPress-backend og frontend, pluss utviklertid til å vedlikeholde begge.
• Skalering: Lineær. Å betjene en million brukere via en statisk frontend (Astro) med WordPress som kilde koster svært lite i serverressurser.

Contentful TCO:

• Lisens: et abonnement. Contentful publiserer planer og bruksgrenser på prissiden. Planene endrer seg, så les gjeldende vilkår der; denne artikkelen gjengir ikke tall.
• Administrasjon: Du trenger ikke administrere serveren, noe som sparer tid, men abonnementet er en fast post i budsjettet.

Slik sammenligner du kostnaden over 3 år: På WordPress-siden legger du sammen førstegangsutviklingen og tre år med hosting og vedlikehold. På Contentful-siden legger du sammen førstegangsutviklingen og tre år med den planen som passer prosjektet ditt, til prisen prissiden viser den dagen. Frontenden koster omtrent det samme i begge tilfeller, fordi arbeidet i Astro eller Next.js er det samme.

#Er Contentful sikrere enn WordPress

• WordPress: Sikkerhet er et “delt ansvar”. Du må sørge for at API-endepunktene dine er låst og at WordPress-kjernen er oppdatert. I 2026 er imidlertid Headless WordPress iboende sikrere fordi “angrepsflaten” (den offentlige delen) er skilt fra backend.
• Contentful: Sikkerhet er “administrert”. Contentful håndterer backend-sikkerheten. Du trenger bare å bekymre deg for sikkerheten til dine egne API-nøkler. For risikosky selskaper som ikke vil styre oppdateringer, er Contentfuls “lukkede hage” attraktiv.

#Oppdateringer og kontroll i begge CMS

#Slik fungerer API-autentisering i WordPress og Contentful

Hvem som kan lese utkast og hvem som kan skrive innhold, avgjøres av tokens, og de to plattformene deler dette ulikt.

WordPress. Guiden til REST API-autentisering nevner cookie-autentisering som standardmetoden, men den gjelder bare kode som kjører inne i WordPress for en innlogget bruker, og hver forespørsel trenger en nonce, ellers behandler API-et brukeren som anonym. For en ekstern frontend eller en byggeserver er Application Passwords riktig metode: De har vært i kjernen siden WordPress 5.6 og sendes med forespørsler over HTTPS. OAuth 1.0a og JSON Web Tokens finnes bare som utvidelser; utvidelsen Basic Authentication er ment for utvikling og testing.

Contentful. Publisert innhold og utkast leses med separate nøkler. contentful.js dokumenterer mønsteret: Den samme klienten snakker med Preview API når du gir den et forhåndsvisningstoken og setter host til preview.contentful.com. Skriving går gjennom Content Management API med klienten contentful-management.js, som i likhet med leveringsklienten prøver på nytt ved en 500-feil eller et 429-svar på grunn av rate limit, med mindre du setter retryOnError til false.

I praksis trenger en frontend med headless WordPress som regel ingen nøkler for publisert innhold, mens hver forespørsel til Contentful bærer et token. Hold leveringstokenet i byggemiljøet, og hold administrasjonstokenet helt ute av frontenden.

#API-hastighet i headless WordPress og Contentful

Når du bygger en nettside med høy ytelse i 2026, er Edge Computation avgjørende.

• Headless WordPress: Ved å bruke løsninger som WP Engine Headless Platform eller et tilpasset Vercel/Netlify-oppsett, kan du forhåndsrendere hele siden din. WordPress-kjernen utløser handlingen transition_post_status hver gang et innlegg skifter status, så en liten utvidelse kan kalle build hooken i CI/CD-pipelinen din når en redaktør trykker på “Publiser”, og den statiske siden bygges på nytt.
• Contentful: Designet for denne arbeidsflyten. Webhooks er en del av konfigurasjonen til et space (eksport- og importverktøyene kopierer dem mellom spaces), så en publisering kan utløse den samme ombyggingen. Siden det er multi-tenant SaaS, styrer du ikke infrastrukturen, mens en dedikert WordPress-instans er helt under din kontroll.

#Gutenberg eller Contentful for redaktører

Dette er det største smertepunktet for markedsføringsteam.

• WordPress: Redaktører elsker det. De kan dra og slippe blokker, se oppsettet og bruke AI til å generere bilder og tekst direkte i redigereren.
• Contentful: Redaktører synes ofte det er “kaldt”. Du fyller ut skjemafelt. Contentfuls Live Preview SDK minsker gapet med en inspektørmodus som kobler elementer på siden til feltene sine, og med live-oppdateringer som viser endringer før publisering, men selve redigeringen skjer fortsatt i et skjema, nærmere et databasegrensesnitt enn et skriveverktøy.

#Slik fungerer flerspråklig innhold i WordPress og Contentful

Lokalisering er området der standardarkitekturene skiller seg mest.

WordPress. Håndboken for avansert administrasjon av WordPress slår fast at WordPress ikke støtter en to- eller flerspråklig side rett ut av boksen. Den lister veiene: utvidelser som har ett innlegg per språk og kobler oversettelser i en gruppe, utvidelser som lagrer alle språk i ett innlegg, utvidelser som oversetter den genererte siden, eksterne oversettelsesmoduler og Multisite med én side per språk. For et headless-prosjekt betyr det at frontenden må kjenne modellen til utvidelsen du valgte, fordi REST- og GraphQL-svarene følger den.

Contentful. Lokaliseringen ligger i innholdsmodellen. Hvert felt har et localized-flagg (se contentful-migration), så du bestemmer felt for felt hva som oversettes og hva som deles, for eksempel en SKU eller en pris. contentful.js returnerer ett språk som standard og alle med withAllLocales. Verktøyet contentful-import forventer at mål-spacet har samme standardspråk som det eksporterte, noe som bør avklares før den første oppføringen skrives.

#Når passer Contentful for en omnichannel-forhandler

En global merkevare trengte å administrere produktbeskrivelser på tvers av:

1. En e-handelsside.
2. En iOS/Android-app.
3. Interaktive skjermer i prøverom.

Valget: De valgte Contentful. Begrunnelse: De trengte ikke en “nettside” i tradisjonell forstand; de trengte en sentral kilde til sannhet. Contentfuls strenge modellering sikret at en oppdatert produktbeskrivelse ble reflektert perfekt på alle enheter med 100 % API-pålitelighet.

#Når passer headless WordPress for en blogg med 50 000 artikler

En ledende teknisk utgiver administrerte 50 000 artikler. Valget: De valgte Headless WordPress. Begrunnelse: Contentfuls kostnad for 50 000 oppføringer var avskrekkende. Ved å bruke WordPress med WPGraphQL, beholdt de sine eksisterende data mens de bygde en lynrask frontend med Astro 5.

#Slik flytter du innhold mellom WordPress og Contentful

Det finnes ingen eksportknapp som gjør WordPress-innlegg om til Contentful-oppføringer, fordi modellene er forskjellige. Verktøyene på hver side dekker sin halvdel.

Ut av WordPress. REST API er den reneste kilden: Bla gjennom /wp/v2/posts med per_page=100 til X-WP-TotalPages, og legg til _embed for å få forfattere og fremhevede bilder i samme svar. Innleggsinnholdet kommer som ferdig rendret HTML, så migreringsskriptet må gjøre det om til felttypene i Contentful-modellen, som regel RichText, Text eller et sett lenkede oppføringer.

Inne i Contentful. contentful-export sikkerhetskopierer innholdsmodell, innhold og assets, med valg som skipContentModel, skipContent, skipRoles, skipWebhooks, includeDrafts og includeArchived. contentful-import laster filen inn i et annet space, med dokumenterte begrensninger: Medlemskap i spacet og roller importeres ikke, webhook-nøkler og hemmelige headere må legges inn igjen for hånd, og egne UI-utvidelser må installeres på nytt. Til omformingen bygger transformEntries og deriveLinkedEntries fra contentful-migration om oppføringene etter importen.

Tilbake til WordPress. Motsatt vei betyr å skrive innlegg via REST API med et Application Password og koble hvert Contentful-felt til et innleggsfelt, en taksonomi eller post meta. Rik tekst og referanser krever det samme kartleggingsarbeidet i motsatt retning.

#WordPress og Contentful sammenlignet i tabell

Markedsandelen kommer fra W3Techs (15. oktober 2026), antallet utvidelser fra utvidelses-API-et til WordPress.org samme dag. Contentfuls planer står på siden Contentful-priser og gjentas ikke her.

#Bør du velge WordPress eller Contentful

I 2026 vinner WordPress på allsidighet, kostnad og redaktøropplevelse. Det er det trygge og skalerbare valget for de fleste bedriftsbehov. Contentful vinner på ren datamodellering og kompleks omnichannel-levering for massive globale merkevarer.

Hos WPPoland er vi eksperter på Headless WordPress. Jeg hjelper deg å gjøre om din WordPress til en høyytelses innholdsmotor som driver fremtidens frontender.

Ikke nøy deg med gårsdagens CMS. Bygg for 2026 med WPPoland.

Se vår WordPress-hastighetsoptimalisering.