Die Revolution in der Redaktionsstube – Warum das CMS bleiben darf

Stell dir folgende Szene vor: Du sitzt im wöchentlichen Meeting. Das Marketing-Team beschwert sich lautstark. Die Webseite lädt quälend langsam, das Design atmet den verstaubten Charme des Jahres 2014 und die Conversion-Raten sind im freien Fall. Der Reflex der Entwickler lautet dann oft: "Wir müssen das alte System komplett loswerden!" Doch ein kompletter Neustart vernichtet jahrelanges Wissen der Redaktion. Die elegante und kostensparende Lösung für dieses Dilemma ist ein Headless CMS Contao WordPress Setup. Anstatt dein bewährtes Redaktionssystem wegzuwerfen, trennen wir das Backend einfach vom Frontend. So behalten deine Redakteure ihre gewohnte Umgebung, während die Nutzer ein pfeilschnelles Erlebnis genießen.

Die gute Nachricht lautet: Beide. Wir müssen diesen Krieg nicht führen. Die Lösung liegt in einem eleganten Kompromiss, der sich in der Software-Architektur als der absolute Goldstandard etabliert hat: Der Headless-Ansatz.

Um dieses Konzept zu verstehen, lass uns eine einfache Analogie nutzen. Dein aktuelles, monolithisches CMS ist wie ein traditionelles Restaurant. Die Küche (Datenbank und Backend) und der Speisesaal (das Frontend-Design) sind ein und derselbe Raum. Wenn die Tische abgenutzt sind und die Gäste sich über die unbequemen Stühle beschweren, musst du nicht den Herd herausreißen und die Köche feuern. Die Köche machen hervorragendes Essen! Was du brauchst, ist eine Trennwand zwischen Küche und Speisesaal. Du baust einen brandneuen, lichtdurchfluteten Speisesaal (dein neues Frontend) und stellst brillante Kellner ein (unsere APIs), die das Essen blitzschnell von der alten Küche zu den neuen Tischen bringen.

Genau diese Entkopplung (Decoupling) vollziehen wir jetzt. Wir degradieren dein altes, schwerfälliges System zu einer reinen Daten-Maschine. Durch ein sauberes Headless CMS Contao WordPress Setup verliert das System seinen alten 'Kopf' (Frontend) und liefert nur noch reine Daten an dein neues Design. Die Redakteure loggen sich morgens weiterhin in ihre exakt gleiche, geliebte Maske ein. Sie schreiben Texte, laden Bilder hoch und drücken auf "Veröffentlichen". Doch anstatt dass das CMS nun mühsam veraltete HTML-Templates zusammenbaut, stellt es die rohen Daten einfach über eine Schnittstelle zur Verfügung.

Wie ein perfekt abgestimmtes Uhrwerk greift nun eine moderne JavaScript-Applikation (wie Next.js oder Astro) diese Daten ab und rendert sie in Millisekunden auf den Bildschirmen deiner Nutzer. Keine zähen Ladebalken mehr. Keine starren Theme-Vorgaben. Volle kreative Freiheit für die Entwickler und absolute Workflow-Stabilität für die Redaktion.

Doch wie genau verständigen sich diese beiden Welten? Wie bestellt der neue Speisesaal das Menü in der alten Küche? Das schauen wir uns im nächsten Schritt an, wenn wir die beiden populärsten Kellner miteinander vergleichen: Die REST-API und GraphQL.

Ein geteiltes Bild: Links eine rustikale, beschäftigte Restaurantküche, rechts ein hochmoderner, minimalistischer Speisesaal, verbunden durch ein leuchtendes High-Tech-Förderband.

Die Kellner im Vergleich – REST-API vs. GraphQL

Nachdem wir unsere metaphorische Küche (das CMS-Backend) vom Speisesaal (dem neuen Frontend) getrennt haben, stehen wir vor einer entscheidenden Frage: Wie genau kommen die Daten nun von A nach B? Wir brauchen eine Schnittstelle, einen digitalen Kellner. In der modernen Webentwicklung gibt es hierfür zwei prominente Kandidaten, die in unseren Quellen – von WPGraphQL bis hin zu Headless Contao-Setups – immer wieder gegeneinander antreten: Die klassische REST-API und der moderne Herausforderer GraphQL.

Lass uns mit der REST-API beginnen. Sie ist der absolute Industriestandard und in Systemen wie WordPress bereits von Haus aus tief integriert. Ein REST-Kellner ist äußerst zuverlässig, aber er hat eine Schwäche: Er arbeitet streng nach Menükarte (Endpoints). Nehmen wir an, deine neue Next.js-Startseite benötigt nur die Titel der letzten drei Blogbeiträge und den Namen des jeweiligen Autors. Wenn du die REST-API danach fragst, liefert sie dir oftmals das komplette Datenpaket des Beitrags zurück – inklusive des gesamten Textes, aller Kommentare und Metadaten, die du an dieser Stelle gar nicht brauchst. Dieses Phänomen nennt man Overfetching (Datenmüll).

Noch frustrierender ist das Gegenteil, das Underfetching: Um den Namen des Autors zu bekommen, musst du oft eine zweite oder dritte Anfrage (Request) an einen völlig anderen Endpunkt (z.B. /users/) senden. Der Kellner muss also mehrfach zwischen Küche und Tisch hin- und herrennen. Bei komplexen Webseiten mit vielen verknüpften Daten (dem berüchtigten n+1 Problem) zwingt dieses Hin und Her selbst starke Server irgendwann in die Knie und treibt die Ladezeiten für mobile Nutzer in die Höhe.

Hier betritt GraphQL die Bühne, eine Technologie, die von Facebook entwickelt wurde und das Headless-Ökosystem revolutioniert hat. GraphQL ist wie ein Kellner mit telepathischen Fähigkeiten und einem absoluten Faible für Effizienz. Anstatt vorgegebene Endpunkte abzuklappern, gibt es bei GraphQL nur einen einzigen Zugangspunkt. Das Frontend schickt eine präzise Wunschliste an das Backend: "Gib mir exakt die Titel der letzten drei Beiträge und nur den Vornamen der Autoren. Sonst nichts." Und genau das passiert. Die Datenbank (sei es über das geniale WPGraphQL-Plugin für WordPress oder spezifische Headless-Bundles für Contao) sammelt all diese Informationen im Hintergrund zusammen und liefert sie in einer einzigen, maßgeschneiderten Lieferung ab. Keine überflüssigen Daten, keine mehrfachen Server-Anfragen. Das Ergebnis ist eine drastische Reduzierung der zu übertragenden Datenmengen (Payload) und eine Webseite, die sich auf dem Smartphone anfühlt, als wäre sie bereits vor dem Tippen geladen gewesen.

Für einfache Projekte ist die REST-API oft ausreichend und schnell aufgesetzt. Wenn du jedoch eine komplexe, moderne Architektur (JAMstack) mit Frameworks wie Next.js, Nuxt oder Astro aufbaust, ist GraphQL in den meisten Fällen der absolute Leistungssieger.

Zwei Roboter-Kellner im Vergleich: Einer balanciert gestresst einen riesigen Berg an Tellern, der andere serviert entspannt ein exaktes, kleines Gericht.

Magie im Frontend – Wie Astro und Next.js die Daten veredeln

Wir haben unseren telepathischen Kellner (GraphQL) nun erfolgreich in die Küche (WordPress oder Contao) geschickt. Er kommt mit exakt den richtigen Zutaten auf seinem Tablett zurück. Doch was passiert jetzt am Tisch? Wie verwandeln wir diese rohen, nackten JSON-Datenketten in ein visuelles Meisterwerk, das deine Nutzer begeistert?

Hier kommt die wahre Magie von modernen Frameworks wie Astro oder Next.js ins Spiel. Lass mich dir von Sarah erzählen, einer fiktiven, aber typischen Frontend-Entwicklerin. Sarah verbrachte Jahre ihres Lebens damit, frustriert auf den Lade-Spinner ihres Browsers zu starren. Jedes Mal, wenn ein Nutzer ihre alte WordPress-Seite aufrief, musste der Server Schwerstarbeit leisten: PHP-Skripte ausführen, Datenbank-Tabellen durchsuchen, Shortcodes parsen und HTML-Schnipsel mühsam zusammenkleben. Dieser Prozess dauerte bei jedem einzelnen Klick wertvolle Millisekunden – oft sogar Sekunden.

Mit dem Headless-Setup dreht Sarah diesen historischen Flaschenhals einfach komplett um. Sie nutzt ein Konzept namens Static Site Generation (SSG).

Wie funktioniert das? Anstatt die Webseite erst in dem Moment zu bauen, in dem der Nutzer danach fragt, baut Sarahs Astro-Frontend die gesamte Webseite bereits im Voraus zusammen. Während des sogenannten Build-Prozesses – also lange bevor überhaupt ein echter Besucher die Seite betritt – feuert Astro seine GraphQL-Queries in Richtung des CMS ab. Bei WordPress nutzt man dafür das geniale WPGraphQL-Plugin, bei Contao greift man auf die Core-API oder spezialisierte Bundles wie das contao-headless-cms-bundle zurück.

Astro nimmt diese frischen Daten, gießt sie in hochmoderne, wunderschöne Komponenten und webt daraus fertige, statische HTML-Dokumente. Wenn nun ein Besucher auf den Link klickt, muss der Server absolut nichts mehr berechnen. Er nimmt einfach das bereits fertig gebackene HTML-Dokument aus der Schublade und liefert es in einem Bruchteil einer Sekunde aus. Das ist keine Metapher: Die Ladezeiten sinken oft von zähen Sekunden auf unter 100 Millisekunden. Für den Nutzer fühlt es sich an, als würde er durch eine native App auf seinem Smartphone navigieren, nicht durch eine Webseite im Browser.

Gibt es dabei einen Haken? Was ist, wenn die Redaktion sekündlich Eilmeldungen publiziert? Muss dann jedes Mal die gesamte Seite neu generiert werden?

Nein, natürlich nicht. Die Architektur ist flexibel. Für hochdynamische Bereiche – wie einen Live-Ticker oder einen personalisierten Warenkorb – wechseln wir nahtlos in das Server-Side Rendering (SSR) oder nutzen Astros "Server Islands". Hierbei wird nur dieses eine, winzige Fragment der Webseite in Echtzeit vom CMS abgerufen, während das restliche, blitzschnelle Layout bestehen bleibt. Wir kombinieren das absolut Beste aus zwei Epochen: Die felsenfeste Stabilität und Datenstruktur eines klassischen CMS mit der kompromisslosen Geschwindigkeit modernster Web-Technologie.

Ein futuristischer, leuchtender Webstuhl, der aus rohen Datenströmen (JSON) eine physische, leuchtende Webseite webt.

Vom Backend zum Frontend – Echter Code, echte Ergebnisse

Wir haben viel über telepathische Kellner (GraphQL) und blitzschnelle Webstühle gesprochen. Aber wie sieht das Ganze aus, wenn du morgens deinen Code-Editor öffnest? Die Angst vor dem Wechsel zu einer Headless-Architektur verschwindet meist genau in dem Moment, in dem Entwickler zum ersten Mal sehen, wie unfassbar sauber dieser Ansatz in der Praxis ist.

Verabschiede dich von unübersichtlichen PHP-Templates, in denen Datenbankabfragen wild mit HTML-Tags vermischt sind (der berüchtigte "Spaghetti-Code", bei dem ein falsches Komma die ganze Seite lahmlegt). In der Headless-Welt herrscht strikte, elegante Ordnung.

Nehmen wir ein ganz konkretes Szenario: Du möchtest die drei neuesten Blog-Artikel aus deinem etablierten WordPress-System auf der Startseite deines neuen Astro-Frontends anzeigen. Auf der WordPress-Seite installierst du dafür lediglich das kostenlose und mächtige Plugin WPGraphQL. Das war’s. Dein betagtes CMS hat sich soeben in eine hochmoderne, API-gesteuerte Datenquelle verwandelt.

In deinem Astro-Projekt schreibst du nun eine präzise GraphQL-Abfrage. Wir fordern exakt das an, was wir für unser Design brauchen – und kein einziges Byte mehr:

GraphQL

query GetLatestPosts {
  posts(first: 3) {
    nodes {
      title
      slug
      date
      author {
        node {
          name
        }
      }
    }
  }
}

Ist das nicht wunderbar lesbar? Selbst jemand, der noch nie programmiert hat, versteht intuitiv, was hier passiert. Wir ordern drei Beiträge und möchten dazu den Titel, den Link (Slug), das Datum und den Namen des Autors haben. Keine überflüssigen Metadaten, keine unnötigen Kommentar-Arrays.

Nun binden wir diese Abfrage direkt in eine Astro-Komponente ein. Astro macht es uns hier extrem leicht, da wir Standard-JavaScript (die native fetch-API des Browsers/Servers) verwenden können, um unseren Kellner loszuschicken:

Code-Snippet

---
// src/components/LatestPosts.astro
const response = await fetch('https://deine-wordpress-seite.de/graphql', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    query: `
      query GetLatestPosts {
        posts(first: 3) {
          nodes {
            title
            slug
            date
          }
        }
      }
    `
  }),
});

const json = await response.json();
const posts = json.data.posts.nodes;
---

<section>
  <h2>Neueste Artikel</h2>
  <ul>
    {posts.map((post) => (
      <li>
        <a href={`/blog/${post.slug}`}>{post.title}</a>
        <time>{new Date(post.date).toLocaleDateString('de-DE')}</time>
      </li>
    ))}
  </ul>
</section>

Was hier passiert, ist schlichtweg genial. Astro ruft das WordPress-Backend während des Build-Prozesses (Static Site Generation) an, holt die Daten, baut die HTML-Liste zusammen und wirft danach das gesamte JavaScript wieder weg. Der Endnutzer bekommt reines, pfeilschnelles HTML ausgeliefert.

Dein Server muss beim Seitenaufruf nicht mehr rechnen. Dein WordPress-Backend wird nicht mehr bei jedem Klick der Nutzer belastet – es schlummert sicher hinter einer Firewall und wacht nur noch auf, wenn Redakteure neue Inhalte einpflegen oder Astro nach Updates fragt. Diese saubere Trennung sorgt nicht nur für Ladezeiten, die deine Konkurrenz alt aussehen lassen, sondern auch für extrem glückliche Teams. Frontend-Designer können sich voll auf das User Interface konzentrieren, während Backend-Entwickler das CMS verwalten, ohne sich gegenseitig im Code in die Quere zu kommen.

Ein leuchtender Code-Editor, aus dem strukturierte Datenströme direkt in eine visuell beeindruckende, schwebende Benutzeroberfläche fließen.

Die Brücke zur Echtzeit – Webhooks, ISR und das große Fazit

Wenn wir die Webseite im Voraus weben (Static Site Generation), wie wir es in Teil 3 besprochen haben, stehen wir plötzlich vor einem logischen Problem: Was passiert, wenn die Chefredakteurin in WordPress einen Tippfehler korrigiert und auf „Aktualisieren“ drückt? Bleibt der Fehler dann tagelang auf der statischen Seite stehen, bis ein Entwickler den Server manuell neu startet und die Seite neu generiert?

Natürlich nicht. Die moderne Headless-Architektur hat für genau dieses Szenario eine brillante Lösung parat: Incremental Static Regeneration (ISR) gepaart mit Webhooks.

Stell dir einen Webhook wie eine kleine digitale Service-Klingel in unserer Restaurant-Küche vor. Wenn der Redakteur in Contao oder WordPress auf „Speichern“ klickt, drückt das CMS diese Klingel. Es sendet ein winziges, automatisiertes Signal an deinen Frontend-Server (Vercel, Netlify oder deinen eigenen Node-Server): "Hey, Achtung! Der Blog-Artikel mit dem Slug 'headless-cms-guide' hat sich soeben geändert!"

Dein Next.js- oder Astro-Frontend reagiert auf dieses Signal völlig autark im Hintergrund. Es schickt unseren GraphQL-Kellner los, holt sich exakt diesen einen, aktualisierten Artikel, baut im Verborgenen das HTML nur für diese eine Unterseite neu und tauscht sie fließend aus. Der Rest deiner Webseite – die vielleicht aus zehntausend anderen, statischen Unterseiten besteht – bleibt davon völlig unberührt.

In Next.js sieht ein solcher Webhook-Empfänger (eine API-Route) verblüffend simpel aus:

JavaScript

// pages/api/revalidate.js
export default async function handler(req, res) {
  // Prüfe das geheime Token, damit nicht jeder deine Seite neu bauen kann
  if (req.query.secret !== process.env.MY_SECRET_TOKEN) {
    return res.status(401).json({ message: 'Ungültiges Token' })
  }

  try {
    // Next.js den Befehl geben, nur diese eine Route neu zu generieren
    await res.revalidate(`/blog/${req.body.post_slug}`)
    return res.json({ revalidated: true })
  } catch (err) {
    return res.status(500).send('Fehler bei der Revalidierung')
  }
}

Für den Endnutzer bedeutet das: Er sieht immer die brandaktuellen Inhalte, profitiert aber weiterhin von den unfassbar schnellen Ladezeiten einer statischen Seite.

Ein leuchtender, digitaler Schalter, der von einer mechanischen Hand gedrückt wird und eine Welle aus goldenen Daten durch ein Netzwerk schickt.

Die sanfte Evolution statt der harten Revolution

Der Wechsel zu einer Headless-Architektur mit WordPress oder Contao ist weitaus mehr als nur ein technischer Trend. Es ist die friedlichste und effizienteste Methode, um veraltete Web-Projekte zu retten. Anstatt das gesamte System in einem riskanten "Big Bang" einzureißen, bewahrst du das wertvolle, über Jahre gelernte Redaktions-Fundament. Du behältst deine Datenbank, deine Nutzerverwaltungen und die vertrauten Eingabemasken.

Alles, was du tust, ist, den verstaubten Präsentations-Kopf abzuschneiden und ihn durch ein blitzschnelles, sicheres und hochmodernes Gesicht (Next.js, Astro etc.) zu ersetzen. Durch Schnittstellen wie GraphQL und clevere Rendering-Strategien (SSG & ISR) schaffst du ein Nutzererlebnis, das messbar mehr Conversions liefert und SEO-Rankings in die Höhe treibt. Du machst dein altes CMS fit für das nächste Jahrzehnt.

#rest

Headless CMS Contao WordPress: Das alte Backend behalten und das Design modernisieren