Eine WordPress-Website tut über Jahre, was sie soll — bis sie es nicht mehr tut. Die Ladezeiten kriechen nach oben, jedes neue Plugin bringt ein neues Risiko, und irgendwann steht die Frage im Raum, ob die Architektur dem nächsten Wachstumsschritt überhaupt noch gewachsen ist. Genau an diesem Punkt fällt der Begriff Headless WordPress — meist ohne dass jemand ihn sauber erklärt. Dieser Beitrag holt das nach: was Headless WordPress ist und wie es funktioniert. Wer danach tiefer einsteigen will, findet auf der Themenseite zu Headless WordPress die vollständige Einordnung.
Kurz vorab: Headless WordPress nutzt WordPress weiterhin als Redaktions-Backend, liefert die Inhalte aber nicht mehr selbst als fertige Website aus. Stattdessen reicht eine Schnittstelle (API) die Inhalte an ein eigenständiges Frontend weiter — meist mit Next.js gebaut. Backend und Frontend sind entkoppelt. Diese Trennung ist der Kern der Architektur und erklärt ihre drei wiederkehrenden Vorteile: schnellere Ladezeiten, eine kleinere Angriffsfläche gegenüber klassischem WordPress und mehr Flexibilität bei der Anbindung externer Systeme.
Wir bauen seit über zehn Jahren WordPress-Sites und seit einigen Jahren Headless-Setups für Schweizer KMU. Was folgt, ist die Erklärung, die wir Entscheidern geben, die keine Tech-Tiefe brauchen, sondern eine belastbare Grundlage für den nächsten Schritt.
Was ist Headless WordPress — die Definition
Die kürzeste ehrliche Antwort: Headless WordPress nutzt WordPress nur noch für das, worin es stark ist — Inhalte verwalten — und gibt die Darstellung an ein eigenständiges Frontend ab. Das «Head» (der Kopf) im Begriff meint die Präsentationsschicht: die fertig gerenderte Webseite. Wird dieser Kopf abgetrennt, bleibt WordPress als reines Redaktionssystem zurück, und die sichtbare Website entsteht woanders.
WordPress betreibt nach wie vor rund 42 % aller Websites weltweit (Quelle: W3Techs, 2026). Die allermeisten dieser Sites laufen klassisch: Ein Theme bestimmt das Aussehen, Plugins liefern Funktionen, und WordPress baut bei jedem Seitenaufruf die fertige Seite zusammen. Backend und Frontend sind dabei untrennbar verschmolzen. Headless löst genau diese Verschmelzung auf.
Wichtig für die Einordnung: Headless ist keine andere Software und kein Ersatz für WordPress. Es ist eine Architektur-Entscheidung. Das Backend bleibt das vertraute WordPress, das Ihre Redaktion kennt. Nur der Weg vom Inhalt zur sichtbaren Seite ändert sich grundlegend.
Was ist der Unterschied zu klassischem WordPress?
Der Unterschied ist die Trennung von Inhalt und Darstellung. Klassisches WordPress baut jede Seite bei jedem Aufruf live aus Datenbank, Theme und Plugins zusammen; Headless WordPress entkoppelt diesen Schritt und liefert die Inhalte über eine API an ein separates Frontend, das die Seiten vorab rendert. Backend und ausgelieferte Website laufen damit getrennt — technisch wie organisatorisch.
| Kriterium | Klassisches WordPress | Headless WordPress |
|---|---|---|
| Frontend | Theme rendert direkt aus WordPress | Eigenständiges Frontend (z. B. Next.js) |
| Seitenaufbau | Bei jedem Aufruf live aus der Datenbank | Vorab gerendert, statisch ausgeliefert |
| Datenanbindung | Theme und Datenbank fest verbunden | Über API (REST oder WPGraphQL) entkoppelt |
| Öffentliche Angriffsfläche | WordPress samt Plugins ist öffentlich erreichbar | Backend nicht öffentlich, Frontend ohne Datenbank-Zugriff |
| Redaktion | Gutenberg-Editor mit Live-Vorschau aus dem Theme | Gutenberg-Editor mit Preview-Anbindung ans Frontend |
| Typisches Profil | Kleine bis mittlere Sites ohne Wachstumsdruck | Performance-, SEO- oder integrationsgetriebene Sites |
Häufig wird Headless WordPress mit verwandten Begriffen verwechselt. «JAMstack» beschreibt das umfassendere Bauprinzip aus JavaScript, APIs und vorab gerendertem Markup — Headless WordPress ist eine konkrete Ausprägung davon, bei der WordPress die Rolle der Content-API übernimmt. Ein «Static Site Generator» wiederum erzeugt rein statische Seiten ohne laufendes Backend; Headless WordPress behält das dynamische Redaktions-Backend bei und kann einzelne Routen bei Bedarf weiterhin serverseitig oder per Revalidierung aktualisieren. Headless meint also nicht «statisch um jeden Preis», sondern «Redaktion und Auslieferung getrennt».
Wie Headless WordPress funktioniert
Stellen Sie sich den Ablauf in drei Stationen vor. Erstens das Backend: Ihre Redaktion schreibt Artikel, pflegt Seiten und lädt Bilder hoch — alles im gewohnten WordPress-Editor. Zweitens die Schnittstelle: WordPress stellt diese Inhalte nicht mehr als fertige HTML-Seiten bereit, sondern als strukturierte Daten über eine API. Drittens das Frontend: Ein eigenständiges Programm ruft diese Daten ab und baut daraus die fertige, sichtbare Website.
Für die Schnittstelle gibt es zwei etablierte Wege. Die in WordPress eingebaute REST-API liefert Inhalte als standardisierte Datenpakete. WPGraphQL ist eine flexiblere Abfragesprache, mit der das Frontend gezielt genau die Felder anfordert, die es braucht. Welcher Weg passt, hängt vom Projekt ab — die ehrliche Gegenüberstellung liefert unser Beitrag zu WPGraphQL vs. REST-API als Entscheidungshilfe.
Das Frontend ist in den meisten unserer Schweizer Projekte mit Next.js gebaut, einem React-basierten Framework. Der entscheidende Unterschied zum klassischen WordPress: Next.js rendert die Seiten in der Regel vorab beim Build-Vorgang vor. Der Besucher erhält dann fertiges, statisches HTML — keine Seite, die bei jedem Aufruf erst aus Datenbank, Theme und Plugins zusammengesetzt werden muss. Genau hier liegt der Performance-Hebel: Laut dem HTTP Archive Web Almanac 2024 bestehen nur rund 40 % der WordPress-Origins auf Mobilgeräten alle drei Core Web Vitals (Quelle: Web Almanac 2024, CMS-Kapitel) — vorab gerendertes HTML setzt genau an dieser Schwachstelle an.
Die Redaktion arbeitet weiter wie bisher. Was sich ändert, ist alles, was der Besucher sieht — und wie schnell er es sieht.
Dieser eine Unterschied erklärt die meisten Vorteile auf einmal: weniger Server-Last, schnellere Ladezeiten, eine kleinere Angriffsfläche, weil das öffentliche Frontend gar keine direkte Verbindung zur WordPress-Datenbank hat. Der Sicherheitsaspekt ist dabei kein Nebeneffekt: Im ersten Halbjahr 2025 entfielen 3'044 der neu gemeldeten WordPress-Schwachstellen auf Plugins und Themes, während im WordPress-Core selbst nur eine einzige gefunden wurde (Quelle: Patchstack, 2025 Mid-Year Vulnerability Report). Ein öffentlich nicht erreichbares Backend reduziert genau diese Plugin-Angriffsfläche — wie genau, vertieft der Beitrag zur Angriffsfläche von Headless WordPress. Die konkreten Vorteile von Headless WordPress ordnen das im Detail ein.
Wer das Bild noch konkreter braucht, kann es so lesen: WordPress läuft auf einem Server — gerne in der Schweiz — und ist nur noch das Werkzeug Ihrer Redaktion. Die API ist die Leitung, über die der Inhalt fliesst. Das Frontend ist die Schicht, die der Besucher tatsächlich erreicht; sie liegt auf einer eigenen, auf Auslieferung optimierten Plattform. Fällt das Backend kurz aus, bleiben statisch oder per ISR vorgerenderte Seiten weiterhin abrufbar, weil sie nicht bei jedem Aufruf neu aus der Datenbank gebaut werden. Wovon das Backend abhängig bleibt: die Redaktions-Vorschau, die On-Demand-Revalidierung (das gezielte Neuerzeugen einer Seite nach einer Inhaltsänderung) sowie dynamische Routen, die ihre Daten bei Anfrage live abrufen (Next.js: How Revalidation Works). Diese Entkopplung ist der eigentliche Kern der Architektur — und der Grund, warum Headless im Auslieferungspfad robuster und schneller ist als ein klassisches Theme-Setup.
Was ändert sich bei Headless WordPress im Alltag?
Für den Betreiber ändert sich im Tagesgeschäft überraschend wenig: Die Redaktion arbeitet weiter im gewohnten WordPress-Editor mit Mediathek, Benutzerrollen und Workflows. Spürbar anders werden vor allem Performance und Sicherheit — und die Live-Vorschau, die nun über eine eigene Preview-Anbindung statt direkt aus dem Theme läuft. Die folgende Tabelle trennt beides sauber.
| Bereich | Bleibt gleich | Ändert sich |
|---|---|---|
| Redaktion | WordPress-Editor, Mediathek, Benutzerrollen, Workflows | Live-Vorschau läuft über eine eigene Preview-Anbindung statt direkt aus dem Theme |
| Inhalte | Beiträge, Seiten, Custom Fields, Kategorien — alles vertraut | Inhalte werden über eine API ausgeliefert, nicht mehr direkt gerendert |
| Performance | — | Deutlich schnellere Ladezeiten durch vorab gerendertes HTML |
| Sicherheit | WordPress-Updates, Backups | Öffentliches Frontend ohne direkten Datenbank-Zugriff, kleinere Angriffsfläche |
| Hosting | WordPress-Backend braucht weiterhin einen Server | Frontend wird separat deployt, oft auf einer spezialisierten Plattform |
Der Punkt, der erfahrungsgemäss die meisten Rückfragen auslöst, ist die Redaktion. Die kurze Entwarnung: Wer heute WordPress bedient, bedient auch Headless WordPress. Der Gutenberg-Editor bleibt, Benutzerrollen bleiben, der Publish-Knopf bleibt. Was sich ändert, ist die Vorschau — sie läuft nicht mehr unmittelbar aus dem Theme, sondern über eine eingerichtete Verbindung zum Frontend. Was das für den redaktionellen Alltag konkret heisst, vertieft der Beitrag dazu, was sich für die Redaktion bei Headless ändert.
Ebenfalls häufig unterschätzt: SEO und Datenschutz bleiben Ihre Verantwortung, nicht die des Frameworks. Auf der SEO-Seite arbeiten Yoast oder Rank Math im Backend zwar weiter, ihre Ausgabe muss aber sauber ans Frontend übergeben werden — die SEO-Frage bei Headless WordPress erklärt, was hier funktioniert und was nicht. Beim Datenschutz gilt für Schweizer Sites das revDSG unabhängig von der Architektur (EDÖB / PwC Schweiz zu den Informationspflichten) — die Trennung verschiebt aber, wo Sie es umsetzen: Analyse- und Tracking-Skripte sowie die Cookie-Information liegen jetzt im Frontend, nicht mehr im WordPress-Theme, und müssen dort sauber eingebunden werden. Was das konkret heisst, vertieft der Beitrag zu Headless WordPress und revDSG.
Wann lohnt sich Headless WordPress für ein KMU?
Headless WordPress lohnt sich, sobald die Website ein aktives Werkzeug im Geschäft ist: regelmässige Publikation, geschäftskritische Performance oder SEO, mehrsprachige Expansion oder die Anbindung externer Systeme wie CRM und ERP. Für eine kleine Visitenkarten-Site ohne laufende Pflege bleibt klassisches WordPress mit Theme, Caching und CDN die günstigere Wahl.
In unseren Schweizer KMU-Projekten 2024–2026 kam der Anstoss selten aus einem Architektur-Wunsch, sondern aus einem konkreten Auslöser — am häufigsten die mehrsprachige Expansion über die Sprachgrenze hinweg: eine bislang rein deutschsprachige Site, die sauber auf Französisch und Italienisch wachsen soll und an der gewachsenen Plugin-Konstruktion zu scheitern droht.
Diese Definition beantwortet das Was und Wie — die Wann-Frage ist eine eigene Entscheidung mit Schwellenwerten, Break-even-Rechnung und einer profilbasierten Scorecard. Statt sie hier zu verkürzen, führt der dedizierte Beitrag dazu, wann sich Headless WordPress lohnt, die Entscheidung Profil für Profil durch. Wer zuerst den Investitionsrahmen einordnen will, findet die drei Budgetstufen im Beitrag zu Headless-WordPress-Kosten 2026; die grundsätzliche Abgrenzung vertieft die Vergleichsseite Headless vs. klassisches WordPress. Ist die Entscheidung gefallen, lohnt vorab ein Blick auf die häufigsten Stolperfallen bei der Headless-Migration.
Nächster Schritt
Wenn Sie wissen wollen, wo Ihre aktuelle Site bei Performance, SEO und Sicherheit steht, ist der schnellste Weg ein Blick von aussen. Mit dem kostenlosen Website-Check in unter einer Minute sehen Sie, wo die grössten Hebel liegen — und bekommen einen ersten Eindruck, ob ein Headless-Wechsel für Ihr Profil überhaupt sinnvoll ist.
Wenn Sie die Frage direkt besprechen wollen, vereinbaren wir gerne ein Erstgespräch — 15 Minuten, kostenlos. In dieser Zeit ordnen wir Ihre Ausgangslage ein und sagen ehrlich, ob Headless WordPress für Sie wirtschaftlich sinnvoll ist — oder ob ein optimiertes klassisches Setup die bessere Wahl bleibt.