WordPress hinten, Next.js vorn — wie das praktisch aussieht.

Der Aufbau.

Die erste Zeile ist eine bewusste Entscheidung: WordPress liegt auf einer eigenen Adresse, die Besucher nie sehen. Das schirmt es ab und vermeidet, dass dieselben Inhalte unter zwei Adressen im Suchindex landen (Headless und SEO).

Der Datenfluss.

1. Redakteur speichert einen Beitrag in WordPress.
2. WordPress meldet die Änderung an das Frontend — über einen Aufruf, der beim Speichern ausgelöst wird.
3. Next.js holt den geänderten Inhalt über die Schnittstelle.
4. Die betroffene Seite wird neu gebaut, die anderen bleiben.
5. Besucher bekommen die fertige Seite ausgeliefert.

Schritt zwei und vier sind das Herzstück und zugleich der Teil, der am häufigsten fehlt. Ohne diese Rückmeldung muss die ganze Website neu gebaut werden, und bei mehreren tausend Seiten dauert das — aus einer Korrektur wird dann ein Vorgang von zwanzig Minuten (Betrieb).

Welche Seite wie gebaut wird.

Diese Mischung ist der eigentliche Vorteil moderner Frameworks: Man muss sich nicht für eine Bauweise entscheiden, sondern wählt sie je Seitentyp. Zeile eins beschreibt dabei ein nützliches Mittelding — die Seite liegt fertig da, wird aber nach einer festgelegten Zeit im Hintergrund erneuert.

Adressen und Routing.

Eine der unterschätzten Aufgaben. WordPress hat eine eigene Logik für Adressen — Kategorien, Schlagwörter, Datumsarchive, Autorenseiten, Blätterseiten, Anhänge. Im Frontend muss all das nachgebaut werden, und zwar so, dass die bestehenden Adressen erhalten bleiben.

Bei einer Neuentwicklung kann man die Struktur frei wählen. Bei einer Umstellung einer bestehenden Seite ist jede abweichende Adresse ein verlorenes Ranking — deshalb gehört zuerst eine vollständige Liste aller bestehenden Adressen gezogen und danach geprüft (Umstellung, Weiterleitungen).

Vergiss dabei nicht die Nebensachen: Sitemap, robots.txt, Feed, Fehlerseite. Die kommen klassisch von WordPress oder einem Plugin und müssen jetzt gebaut werden.

Bilder.

WordPress erzeugt beim Hochladen mehrere Größen und liefert sie je nach Bildschirm aus. Diese Logik muss im Frontend fortgeführt werden, sonst verliert man genau den Vorteil, den man gewinnen wollte.

Zwei Wege. Entweder man nutzt die von WordPress erzeugten Größen und bindet sie direkt ein — einfach, aber die Bilder kommen vom WordPress-Server, der dafür nicht ausgelegt ist. Oder das Frontend übernimmt die Bildverarbeitung und optimiert selbst; das ist meist die bessere Lösung, verlangt aber, dass der Bildserver die Quelle kennen darf.

In beiden Fällen gehören Breite und Höhe mitgegeben, sonst springt das Layout (Bilder optimieren, CLS).

Formulare.

Ein typischer Stolperstein. Das Kontaktformular-Plugin in WordPress erzeugt klassisch das HTML und verarbeitet den Versand. Beides fällt weg.

Drei Möglichkeiten: Das Formular im Frontend bauen und die Daten an die Schnittstelle des Plugins schicken — manche unterstützen das. Oder einen eigenen Endpunkt in WordPress anlegen. Oder einen externen Formulardienst nutzen.

Woran dabei gedacht werden muss: Spamschutz ohne Bildabfrage, Bestätigungsmail, Speicherung der Einsendungen, Datenschutzhinweis und Einwilligung. Das ist mehr Arbeit als das Formular selbst (Spamschutz, Barrierefreie Formulare).

Mehrsprachigkeit.

Die üblichen Übersetzungs-Plugins arbeiten eng mit dem Theme zusammen und geben ihre Daten nicht vollständig über die Schnittstelle heraus. Das wird regelmäßig unterschätzt.

Praktikabel sind zwei Wege: ein Plugin, das die Schnittstelle sauber bedient, oder getrennte Inhaltsbäume je Sprache mit einer Verknüpfung dazwischen. In beiden Fällen muss das Frontend Sprachumschaltung, Adressstruktur je Sprache und die Angaben für Suchmaschinen selbst erzeugen (Mehrsprachigkeit).

Neuaufbau bei Änderungen.

Bei statisch erzeugten Seiten stellt sich die Frage, was nach einer Änderung passiert. Drei Strategien:

• Gezielte Erneuerung: WordPress meldet beim Speichern, welche Seite betroffen ist, und nur die wird neu gebaut. Der beste Weg.
• Zeitgesteuerte Erneuerung: Jede Seite wird nach einer festgelegten Zeit im Hintergrund aktualisiert. Einfach und robust.
• Vollständiger Neubau: Alles wird neu erzeugt. Bei wenigen Seiten in Ordnung, bei vielen unpraktikabel.

In der Praxis kombiniert man eins und zwei. Wichtig ist, auch die Nebenwirkungen zu bedenken: Ein geänderter Beitrag betrifft nicht nur seine eigene Seite, sondern auch Übersichten, Kategorieseiten und womöglich die Startseite.

Suche.

Ohne Theme gibt es keine Suche mehr. Möglichkeiten: die Suche von WordPress über die Schnittstelle nutzen — einfach, aber langsam und schwach; eine eigene Suche im Frontend über einen vorbereiteten Index — schnell, braucht Pflege; oder ein externer Suchdienst — leistungsfähig, mit laufenden Kosten.

Bei wenigen hundert Seiten reicht ein kleiner selbst erzeugter Index. Ab einigen tausend Seiten lohnt ein eigener Dienst (Suche).

Stolpersteine.

• Vorschau funktioniert nicht — der häufigste Beschwerdepunkt der Redaktion (Vorschau).
• Blockeditor-Ausgabe kommt als HTML-Block und muss im Frontend sinnvoll dargestellt werden.
• Eingebettete Inhalte aus dem Editor funktionieren nicht automatisch.
• Plugins, die im Frontend wirken, fallen ersatzlos weg.
• Weiterleitungs-Plugins werden nicht mehr ausgeführt.
• Kommentare müssen neu gebaut werden.
• Zwei Systeme aktualisieren statt einem.

Punkt zwei verdient Aufmerksamkeit: Der Editor liefert den Inhalt als fertiges HTML. Das kann man direkt ausgeben — dann sieht es ungestaltet aus — oder man zerlegt es und bildet jeden Blocktyp im Frontend ab. Letzteres ist deutlich mehr Arbeit und der richtige Weg.

Wo die Arbeit steckt.

Nicht in der Verbindung — die steht an einem Tag. Die Arbeit steckt in all dem, was WordPress vorher nebenbei erledigt hat: Adressen, Bilder, Formulare, Suche, Vorschau, Sitemap, Weiterleitungen, Fehlerseiten, Mehrsprachigkeit, Blockdarstellung.

Das ist der ehrliche Grund, warum ein headless-Projekt mehr kostet als dieselbe Website klassisch. Wer das vorher weiß, trifft eine gute Entscheidung (Was es kostet).

Wenn du weiterkommen willst.

Wenn du diese Kombination einsetzen willst und wissen musst, was dabei auf dich zukommt. Ich schaue mir an, was du vorhast, und sage dir, ob headless passt — und wenn nicht, was stattdessen: Headless WordPress. Geht es nur um Tempo, ist oft Ladezeitarbeit an der bestehenden Seite der günstigere Weg.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich arbeite seit Jahren mit WordPress und baue daneben eigene Plattformen mit Next.js — Lernplattformen mit mehreren tausend Seiten, bei denen WordPress als Redaktionssystem im Hintergrund läuft und das Frontend davon getrennt ist. Das ist also keine Theorie, sondern das, womit ich meine eigenen Projekte betreibe.

Genau deshalb sage ich auch offen, wann es sich nicht lohnt. Headless ist aufwendiger im Bau und im Betrieb, und für eine normale Unternehmenswebsite ist es fast immer die falsche Antwort. Wer mir schreibt und eine fünfzehnseitige Firmenwebsite headless bauen lassen will, bekommt von mir eine Rückfrage und keinen Kostenvoranschlag.

Was ich nicht mache: große Teams begleiten oder bestehende Frontends in anderen Frameworks übernehmen. Mein Feld ist WordPress als Redaktionssystem plus ein Frontend in Next.js — überschaubar im Umfang, von einer Person wartbar.