WordPress vs. Contentful 2026: Headless CMS Architektur für Unternehmen

#WordPress oder Contentful als Headless CMS

Im Jahr 2026 hat der Begriff „CMS“ eine radikale Transformation durchlaufen. Wir verwalten nicht mehr nur Seiten; wir verwalten Content-Graphen. Da die Auslieferung über alle Kanäle (Omnichannel) zum Standard geworden ist, wurde die Wahl zwischen WordPress (in seiner Headless- oder Hybrid-Rolle) und Contentful (dem reinen SaaS-Headless-König) zu einer Entscheidung auf Architekturebene.

In dieser Analyse untersuchen wir die technischen, finanziellen und strategischen Implikationen der Wahl zwischen dem weltweit beliebtesten CMS und dem Branchenführer für Composable Content. Jedes API-Detail verlinkt auf die Dokumentation des jeweiligen Herstellers, damit Sie es mit Ihrer eingesetzten Version abgleichen können.

#Architektur von WordPress und Contentful im Vergleich

#WordPress als hybrides Decoupled CMS

WordPress wurde als Blogging-Engine geboren, ein dokumentenbasiertes System. Im Jahr 2026 ist es jedoch ein Hybrid-Framework, das mehrere Betriebsarten gleichzeitig beherrscht.

• Der Hybrid-Vorteil: Sie können WordPress für eine traditionelle Website nutzen und gleichzeitig alle Daten via WPGraphQL bereitstellen. So zieht ein Team Bereich für Bereich vom klassischen Theme auf ein Headless-Frontend um.
• Benutzerfreundlichkeit: Marketingteams können weiterhin den visuellen Block-Editor (Gutenberg) nutzen, um ihre Inhalte zu sehen, während das Frontend eine separate React- oder Astro-Anwendung ist.

#Contentful als reines Headless-CMS

Contentful ist API-First und Content-First. Es interessiert sich nicht für die Darstellung auf einer Website, sondern für strukturierte Daten, die jeder Kanal abrufen kann.

• Content Modeling: Sie beginnen mit einer leeren Leinwand und definieren „Content Types“ (z. B. „Produkt“, „Hero-Banner“, „Bewertung“). Diese strenge Struktur hält die Daten über alle Kanäle konsistent.
• Omnichannel Power: Da der Inhalt reine strukturierte Daten sind, können sie gleichermaßen von einer React-Website, einer Flutter-App, einem Apple Vision Pro Interface oder einem In-Store-Kiosk konsumiert werden.

#WPGraphQL oder Contentful API für Entwickler

Im modernen Dev-Stack von 2026 wollen Entwickler keine PHP-Templates mehr schreiben. Sie wollen JSON konsumieren und Oberflächen mit JavaScript-Frameworks bauen.

• Arbeiten mit WordPress: Entwickler nutzen WPGraphQL, ein kostenloses Open-Source-Plugin, das jeder WordPress-Website ein GraphQL-Schema und eine GraphQL-API hinzufügt. Laut seiner Seite auf WordPress.org wird es gerade zum Canonical Plugin. Die Fähigkeit, nur die benötigten Daten abzufragen (z. B. „Gib mir Titel und Beitragsbild der letzten 5 Posts“), reduziert die Payload-Größe massiv.

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

• Arbeiten mit Contentful: Die Content Management API (CMA) und die Content Delivery API (CDA) von Contentful sind ausgereift. Sie bieten spezialisierte SDKs für jede wichtige Sprache. Es fühlt sich wie ein Software-Tool an, während WordPress eher ein Content-Tool bleibt, und dieser Unterschied zählt für Engineering-Teams.

#Wie man Inhalte aus WordPress und Contentful per REST abruft

GraphQL ist auf beiden Seiten optional. Jede Plattform hat auch eine einfache REST-Schnittstelle, und die Unterschiede zeigen sich, sobald man ein großes Archiv seitenweise durchgeht.

WordPress REST API. Der Kern stellt Beiträge unter GET /wp/v2/posts bereit und antwortet in JSON. Laut Pagination-Leitfaden ist per_page auf 100 Datensätze begrenzt, und jede Collection-Antwort trägt zwei Header: X-WP-Total (Datensätze der Collection) und X-WP-TotalPages (Seiten, die nötig sind, um alle zu lesen). Ein Build-Skript liest den zweiten Header und hört dort auf. Die globalen Parameter _fields und _embed steuern die Antwortgröße: _fields liefert nur die genannten Felder, _embed bettet verknüpfte Ressourcen wie Autor oder Beitragsbild ein. Die Beitragsroute akzeptiert außerdem ein Argument search, das die Ergebnisse auf Treffer für eine Zeichenkette beschränkt.

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. Der offizielle JavaScript-Client contentful.js löst verknüpfte Einträge standardmäßig direkt in der Antwort auf und belässt nicht auflösbare Links als Link-Objekte. Verkettete Modifier ändern das: withAllLocales liefert alle Sprachen in einer Antwort, withoutLinkResolution lässt alle Links als Link-Objekte stehen. Der Client wiederholt fehlgeschlagene Anfragen selbst: retryOnError ist standardmäßig aktiv, retryLimit steht auf 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' })

Der praktische Unterschied: Bei WordPress steuern Sie Paginierung und Antwortgröße selbst über Kernparameter, das Contentful-SDK versteckt Link-Auflösung und Wiederholungen bei Rate Limits im Client.

#Wie man Inhaltstypen als Code in WordPress und Contentful definiert

Beide Plattformen erlauben es, das Content-Modell in der Versionsverwaltung zu halten, statt es in einer Admin-Oberfläche zusammenzuklicken.

WordPress. Ein eigener Inhaltstyp wird in PHP mit register_post_type registriert. Für Headless zählen zwei Argumente: show_in_rest, standardmäßig false, muss true sein, damit der Typ in der REST API und im Block-Editor erscheint, und rest_base legt das URL-Segment der REST-Route fest. WPGraphQL braucht eigene Argumente. Laut WPGraphQL-Dokumentation nimmt show_in_graphql den Typ ins Schema auf, graphql_single_name setzt den Namen in Camel Case, graphql_plural_name ist optional. Dort ist auch eine Falle dokumentiert: Wird der Typ mit public auf false registriert, muss publicly_queryable auf true ergänzt werden, sonst liefern anonyme Abfragen leere Ergebnisse ohne Fehler.

Contentful. Das Tool contentful-migration beschreibt Änderungen am Content-Modell als JavaScript- oder TypeScript-Skripte. createContentType und createField nehmen einen Feldtyp aus einer festen Liste: Symbol (kurzer Text), Text (langer Text), Integer, Number, Date, Boolean, Object, Location, RichText, Array, Link und ResourceLink. Felder akzeptieren validations, ein required-Flag und ein localized-Flag. Dasselbe Tool schreibt vorhandene Inhalte um: transformEntries ändert Feldwerte in großen Mengen, deriveLinkedEntries lagert Daten in einen neuen verknüpften Eintrag aus.

Das WordPress-Modell ist ein Inhaltstyp mit Feldern, die Plugins oder die Meta-Registrierung ergänzen. Das Contentful-Modell ist vom ersten Feld an typisiert. Deshalb sind seine API-Antworten vorhersehbar, und deshalb braucht jede spätere Modelländerung ein Migrationsskript.

#Headless CMS SEO mit WordPress und Contentful

Wie KI-Modelle Ihre Inhalte „verstehen“, hängt von der Klarheit Ihrer Struktur ab. 2026 umfasst SEO auch die Optimierung für große Sprachmodelle.

E-E-A-T Signal: WordPress erlaubt es einfach, Autoren mit autoritativen Expertenprofilen zu verknüpfen. In Contentful müssen Sie dieses Beziehungsmodell von Grund auf neu bauen, was dem Projekt Aufwand hinzufügt.

#Was kostet Contentful im Vergleich zu WordPress

Hier driften die Kosten am weitesten auseinander, und oft entscheidet genau das.

Die WordPress TCO:

• Lizenz: 0 $. WordPress ist Open Source unter der GPL.
• Laufende Kosten: Hosting für das WordPress-Backend und das Frontend sowie Entwicklerzeit für die Pflege von beidem.
• Skalierung: Linear. Eine Million Nutzer via statischem Frontend (Astro) mit WordPress als Quelle kostet kaum Server-Ressourcen.

Die Contentful TCO:

• Lizenz: ein Abonnement. Contentful veröffentlicht Tarife und Nutzungslimits auf seiner Preisseite. Tarife ändern sich, lesen Sie die aktuellen Konditionen dort; dieser Artikel gibt keine Zahlen wieder.
• Management: Sie müssen keinen Server managen, was Zeit spart, aber das Abonnement bleibt ein fester Posten im Budget.

So vergleichen Sie die Kosten über 3 Jahre: Auf der WordPress-Seite addieren Sie die Erstumsetzung und drei Jahre Hosting und Wartung. Auf der Contentful-Seite addieren Sie die Erstumsetzung und drei Jahre des Tarifs, der zu Ihrem Projekt passt, zum Preis, den die Preisseite an diesem Tag zeigt. Das Frontend kostet in beiden Fällen ähnlich viel, weil die Arbeit mit Astro oder Next.js dieselbe ist.

#Ist Headless WordPress sicherer als Contentful

• WordPress: Sicherheit ist eine „geteilte Verantwortung“. Sie müssen sicherstellen, dass Ihre API-Endpunkte gesperrt und der WordPress-Kern aktuell sind. 2026 ist Headless WordPress jedoch inhärent sicherer, da die öffentliche Seite vom Backend entkoppelt ist.
• Contentful: Sicherheit ist „verwaltet“. Contentful kümmert sich um das Backend. Sie müssen sich nur um Ihre API-Keys sorgen. Für risikoaverse Konzerne ist dieser „Walled Garden“ sehr attraktiv.

#Updates und Kontrolle in beiden CMS

#Wie die API-Authentifizierung in WordPress und Contentful funktioniert

Wer Entwürfe lesen und wer Inhalte schreiben darf, entscheiden Tokens, und beide Plattformen teilen das unterschiedlich auf.

WordPress. Der Leitfaden zur REST-API-Authentifizierung nennt die Cookie-Authentifizierung als Standardmethode, sie gilt aber nur für Code, der innerhalb von WordPress für einen angemeldeten Nutzer läuft, und jede Anfrage braucht eine Nonce, sonst behandelt die API den Nutzer als anonym. Für ein externes Frontend oder einen Build-Server sind Application Passwords die passende Methode: Sie sind seit WordPress 5.6 im Kern und werden mit Anfragen über HTTPS gesendet. OAuth 1.0a und JSON Web Tokens gibt es nur als Plugins; das Plugin Basic Authentication ist für Entwicklung und Tests gedacht.

Contentful. Veröffentlichte Inhalte und Entwürfe werden mit getrennten Zugangsdaten gelesen. contentful.js dokumentiert das Muster: Derselbe Client spricht mit der Preview API, wenn Sie ein Preview-Token übergeben und host auf preview.contentful.com setzen. Schreibzugriffe laufen über die Content Management API mit dem Client contentful-management.js, der wie der Delivery-Client Anfragen mit einem 500-Fehler oder einer 429-Antwort wegen Rate Limit wiederholt, solange Sie retryOnError nicht auf false setzen.

In der Praxis braucht ein Headless-WordPress-Frontend für veröffentlichte Inhalte meist keine Zugangsdaten, während jede Anfrage an Contentful ein Token trägt. Das Delivery-Token gehört in die Build-Umgebung, das Management-Token gar nicht ins Frontend.

#Performance von Headless WordPress und Contentful

Bei Hochleistungs-Websites im Jahr 2026 ist Edge Computation entscheidend.

• Headless WordPress: Mit Lösungen wie WP Engine Headless Platform oder Vercel können Sie die gesamte Seite statisch rendern. Der WordPress-Kern löst bei jedem Statuswechsel eines Beitrags die Action transition_post_status aus, also kann ein kleines Plugin den Build Hook Ihrer CI/CD-Pipeline aufrufen, wenn ein Redakteur „Veröffentlichen“ klickt, und die statische Seite wird neu gebaut.
• Contentful: Perfekt für diesen Workflow ausgelegt. Webhooks gehören zur Konfiguration eines Space (die Export- und Import-Tools kopieren sie zwischen Spaces), also kann ein Veröffentlichungsereignis denselben Rebuild auslösen. Da es multi-tenant SaaS ist, kontrollieren Sie die Infrastruktur nicht, während eine dedizierte WordPress-Instanz unter Ihrer vollen Kontrolle steht.

#Gutenberg oder Contentful-Editor für Redakteure

Dies ist der größte Schmerzpunkt für Marketing-Teams.

• WordPress: Redakteure lieben es. Drag & Drop von Blöcken, Layout-Vorschau und KI-Bilderzeugung direkt im Editor.
• Contentful: Redakteure finden es oft „kalt“. Man füllt Formularfelder aus. Das Live Preview SDK von Contentful verkleinert diese Lücke mit einem Inspector-Modus, der Elemente der Seite mit ihren Feldern verbindet, und mit Live-Updates, die Änderungen vor dem Veröffentlichen zeigen. Die Bearbeitung selbst bleibt aber ein Formular, näher an einer Datenbankoberfläche als an einem Schreibwerkzeug.

#Wie mehrsprachige Inhalte in WordPress und Contentful funktionieren

Bei der Lokalisierung unterscheiden sich die Standardarchitekturen am stärksten.

WordPress. Das Handbuch zur erweiterten Administration von WordPress stellt fest, dass WordPress eine zwei- oder mehrsprachige Website nicht von Haus aus unterstützt. Es nennt die Wege: Plugins mit einem Beitrag pro Sprache, die Übersetzungen als Gruppe verknüpfen, Plugins mit allen Sprachen in einem Beitrag, Plugins, die die generierte Seite übersetzen, externe Übersetzungs-Widgets und Multisite mit einer Website pro Sprache. Für ein Headless-Projekt heißt das: Das Frontend muss das Modell des gewählten Plugins kennen, weil REST- und GraphQL-Antworten ihm folgen.

Contentful. Die Lokalisierung sitzt im Content-Modell. Jedes Feld trägt ein localized-Flag (siehe contentful-migration), Sie entscheiden also Feld für Feld, was übersetzt wird und was gemeinsam bleibt, etwa eine SKU oder ein Preis. contentful.js liefert standardmäßig eine Sprache und mit withAllLocales alle. Das Tool contentful-import erwartet, dass der Ziel-Space dieselbe Standardsprache hat wie der exportierte, was man vor dem ersten Eintrag festlegen sollte.

#Wann sich Contentful für Omnichannel im Einzelhandel lohnt

Ein globaler Händler musste Produktbeschreibungen verwalten für:

1. Den E-Commerce Store.
2. Die iOS/Android App.
3. Interaktive Bildschirme in Umkleidekabinen.

Die Wahl: Sie wählten Contentful. Begründung: Sie brauchten keine „Website“ im klassischen Sinne, sondern einen „Central Hub of Truth“. Die strikte Modellierung sicherte die Konsistenz über alle drei Devices.

#Wann Headless WordPress für ein Newsportal mit 50.000 Artikeln passt

Ein Technikverlag verwaltete 50.000 Artikel. Die Wahl: Sie wählten Headless WordPress. Begründung: Die Kosten von Contentful für 50.000 Datensätze waren prohibitiv. Mit WordPress und WPGraphQL behielten sie ihre Datenhoheit bei maximaler Geschwindigkeit via Astro 5 Frontend.

#Wie man Inhalte zwischen WordPress und Contentful umzieht

Es gibt keinen Export-Knopf, der WordPress-Beiträge in Contentful-Einträge verwandelt, weil die Modelle verschieden sind. Die Werkzeuge auf jeder Seite decken ihre Hälfte ab.

Raus aus WordPress. Die REST API ist die sauberste Quelle: /wp/v2/posts mit per_page=100 bis X-WP-TotalPages durchgehen und _embed ergänzen, um Autoren und Beitragsbilder in derselben Antwort zu erhalten. Der Beitragsinhalt kommt als gerendertes HTML, also muss das Migrationsskript ihn in die Feldtypen des Contentful-Modells umwandeln, meist RichText, Text oder eine Reihe verknüpfter Einträge.

Innerhalb von Contentful. contentful-export sichert Content-Modell, Inhalte und Assets, mit Optionen wie skipContentModel, skipContent, skipRoles, skipWebhooks, includeDrafts und includeArchived. contentful-import lädt diese Datei in einen anderen Space, mit dokumentierten Grenzen: Space-Mitgliedschaften und Rollen werden nicht importiert, Webhook-Zugangsdaten und geheime Header müssen von Hand nachgetragen und eigene UI-Erweiterungen neu installiert werden. Für die Umformung bauen transformEntries und deriveLinkedEntries aus contentful-migration die Einträge nach dem Import um.

Zurück zu WordPress. Der umgekehrte Weg heißt: Beiträge über die REST API mit einem Application Password schreiben und jedes Contentful-Feld einem Beitragsfeld, einer Taxonomie oder Post-Meta zuordnen. Rich Text und Referenzen brauchen dieselbe Zuordnungsarbeit in Gegenrichtung.

#Vergleichstabelle WordPress vs. Contentful 2026

Der Marktanteil stammt von W3Techs (15. Oktober 2026), die Plugin-Zahl aus der Plugin-API von WordPress.org vom selben Tag. Die Contentful-Tarife stehen auf der Seite Contentful Pricing und werden hier nicht wiederholt.

#Sollten Sie WordPress oder Contentful wählen

2026 punktet WordPress bei Vielseitigkeit, Kosten und Redaktionserfahrung. Es ist die „sichere“ Wahl für die meisten Business-Cases. Contentful punktet bei reinem Datenmodelling und Omnichannel-Anspruch für globale Brands mit komplexen App-Landschaften.

Bei WPPoland sind wir Experten für Headless WordPress. Ich helfe Ihnen, WordPress in eine High-Performance Engine für die Frontends der Zukunft zu verwandeln.

Bauen Sie nicht für gestern. Bauen Sie für 2026 mit WPPoland.

Mehr über unsere WordPress-Geschwindigkeitsoptimierung.