Zwei Systeme betreiben — ohne dass eins davon vergessen wird.

WordPress abschirmen.

Das Redaktionssystem bekommt keine Besucher mehr, also kann es klein und ruhig laufen. Was dort eingerichtet gehört:

• Eigene Adresse, die nicht beworben wird.
• Zugangsschutz auf Serverebene oder Beschränkung auf bestimmte Adressen.
• Indexierung gesperrt, damit keine doppelten Inhalte entstehen (SEO).
• Theme abgeschaltet oder auf eine leere Seite umgeleitet.
• Schnittstelle erreichbar für das Frontend, sonst beschränkt.
• Verschlüsselung wie bei jeder anderen Adresse (SSL).

Der Gewinn ist handfest: Was nicht öffentlich erreichbar ist, wird nicht automatisiert angegriffen. Das ist einer der wenigen Punkte, bei denen headless ohne Abstriche besser ist (WordPress absichern).

Zur Leistung: Ein kleines Hosting reicht meist, weil nur Redakteure und der Bauprozess darauf zugreifen. Was es braucht, ist Zuverlässigkeit — fällt WordPress aus, kann nicht veröffentlicht werden.

Hosting fürs Frontend.

Zeile drei wird unterschätzt: Wenn die Seite vollständig statisch erzeugt werden kann, ist das Ergebnis ein Ordner mit Dateien — und der läuft auf jedem Webspace. Das ist die günstigste und ausfallsicherste Variante, schließt aber Funktionen aus, die beim Aufruf gebaut werden müssen.

Zeile zwei passt, wenn ohnehin ein Server betrieben wird oder die Daten das Haus nicht verlassen sollen. Dann gilt alles, was für jeden eigenen Server gilt: Jemand muss ihn pflegen (Hosting-Arten).

Der Bauprozess.

1. Quelltext liegt in einer Versionsverwaltung.
2. Eine Änderung am Code oder an den Inhalten löst den Vorgang aus.
3. Abhängigkeiten werden geladen, das Projekt gebaut.
4. Inhalte werden abgerufen und Seiten erzeugt.
5. Prüfungen laufen — Übersetzungsfehler, Verlinkungen, Formate.
6. Die neue Fassung wird veröffentlicht.
7. Die alte bleibt erreichbar, bis die neue vollständig steht.

Punkt sieben ist ein wesentlicher Vorteil: Die Umschaltung passiert erst, wenn alles fertig ist. Es gibt keinen Moment, in dem die Seite halb aktualisiert ist — und ein Rückschritt auf die vorige Fassung ist eine Sache von Sekunden.

Was den Neubau auslöst.

Zeile zwei ist der Normalfall im Alltag und der Punkt, an dem sich gute von schlechter Umsetzung unterscheidet. Wird bei jedem gespeicherten Beitrag alles neu gebaut, dauert eine Tippfehlerkorrektur bei einer großen Website zwanzig Minuten. Wird nur die betroffene Seite erneuert, sind es Sekunden.

Denk dabei an die Nebenwirkungen: Ein geänderter Beitrag betrifft auch Übersichten, Kategorieseiten, die Sitemap und womöglich die Startseite. Diese Abhängigkeiten gehören beim Bau mitgedacht (Neuaufbau).

Umgebungen.

Mindestens zwei, besser drei: Entwicklung auf dem eigenen Rechner, eine Vorschauumgebung zum Abstimmen, und die Live-Fassung.

Die Vorschauumgebung ist bei spezialisierten Diensten meist eingebaut — jede Änderung bekommt eine eigene Adresse, unter der man sie ansehen kann, bevor sie live geht. Das ist ein echter Gewinn gegenüber dem klassischen Betrieb, wo eine Testumgebung erst eingerichtet werden muss (Staging).

Wichtig: Jede Umgebung außer der Live-Fassung gehört vor Suchmaschinen gesperrt. Und sie sollte nicht auf die Live-Inhalte schreiben dürfen.

Bilder ausliefern.

Die Bilder liegen zunächst in der WordPress-Mediathek. Werden sie von dort ausgeliefert, kommt jeder Besucherzugriff doch wieder beim abgeschirmten System an — das widerspricht dem Aufbau und belastet einen Server, der dafür nicht gedacht ist.

Drei Wege: Die Bildverarbeitung des Frontends holt sie einmalig ab, verarbeitet und liefert sie selbst aus. Oder die Mediathek liegt von vornherein auf einem eigenen Speicher mit eigener Adresse. Oder ein Dienst sitzt davor und liefert optimierte Fassungen aus.

Der erste Weg ist bei überschaubaren Mengen der einfachste. Bei vielen tausend Bildern lohnt der zweite, weil der Bauvorgang sonst lange dauert (Bilder optimieren).

Zugangsdaten.

• Nie im Quelltext und nie in der Versionsverwaltung.
• In der Umgebungskonfiguration des jeweiligen Dienstes hinterlegen.
• Je Umgebung eigene, damit die Vorschauumgebung nicht auf Live schreibt.
• Technischer Benutzer in WordPress mit minimalen Rechten.
• Nur serverseitig verwenden — was im Browser landet, ist öffentlich.

Der letzte Punkt ist der, an dem am meisten schiefgeht. In modernen Frameworks gibt es Variablen, die ausdrücklich in den Browser ausgeliefert werden, und solche, die nur serverseitig verfügbar sind. Ein Zugangsschlüssel in der falschen Kategorie steht im Quelltext jeder Seite.

Überwachung.

1. Erreichbarkeit der Website, mit Benachrichtigung.
2. Erreichbarkeit von WordPress — sonst kann niemand veröffentlichen.
3. Erfolg des Bauvorgangs, mit Meldung bei Fehlschlag.
4. Zertifikate für beide Adressen (SSL).
5. Fehler im Frontend, über eine Fehlererfassung.
6. Letzte erfolgreiche Aktualisierung — ein Datum, das jemand ansieht.

Punkt drei und sechs sind die wichtigsten und fehlen am häufigsten. Dazu gleich mehr.

Wenn ein Bauvorgang scheitert.

Der tückischste Betriebsfall des ganzen Aufbaus. Scheitert der Vorgang, bleibt die zuletzt erfolgreiche Fassung online — die Website funktioniert also einwandfrei, sieht normal aus und ist erreichbar. Nur: Nichts, was seitdem veröffentlicht wurde, erscheint.

Ohne Benachrichtigung merkt das niemand. Die Redaktion veröffentlicht weiter, wundert sich vielleicht, prüft im Zweifel nicht nach — und nach drei Wochen fällt auf, dass seit einem Monat nichts mehr live gegangen ist.

Was dagegen hilft:

• Benachrichtigung bei Fehlschlag an jemanden, der reagiert — nicht an ein Sammelpostfach.
• Rückmeldung in WordPress, sichtbar für die Redaktion.
• Datum der letzten Aktualisierung an einer Stelle, die regelmäßig gesehen wird.
• Regelmäßiger Blick auf die Protokolle, etwa monatlich.

Die zweite Zeile ist der eleganteste Weg: ein kleiner Hinweis im WordPress-Dashboard, der den Zustand des letzten Bauvorgangs zeigt. Dann sieht die Redaktion sofort, ob ihre Änderung angekommen ist.

Updates und Pflege.

Zeile zwei und drei sind der Unterschied zum klassischen Betrieb. Regelmäßig gepflegt ist das eine kleine Routine; zwei Jahre liegen gelassen wird daraus ein Projekt, weil mehrere Versionssprünge auf einmal anstehen und sich Änderungen überlagern.

Mein Rat: ein fester Termin im Quartal, an dem Abhängigkeiten aktualisiert und die Seite durchgeklickt wird. Das ist in einer laufenden Betreuung gut aufgehoben (Laufende Betreuung).

Notfallplan.

Drei Fragen, die vor dem Start beantwortet sein sollten:

1. Wie kommt man auf die vorige Fassung zurück? Bei den meisten Diensten ein Knopfdruck — probier ihn einmal aus, bevor du ihn brauchst.
2. Was passiert, wenn WordPress ausfällt? Die Website bleibt bei statischen Seiten erreichbar, veröffentlichen geht nicht. Das ist auszuhalten, sollte aber bekannt sein.
3. Wer kann im Notfall ran? Zugänge dokumentiert, mehr als eine Person berechtigt.

Dazu Sicherungen für beide Seiten: WordPress-Datenbank und Mediathek wie gewohnt, der Quelltext liegt in der Versionsverwaltung. Letzteres ersetzt kein Backup der Inhalte — der Code ist nur die halbe Website (Backups).

Wenn du weiterkommen willst.

Wenn du so einen Aufbau betreiben musst oder nicht sicher bist, ob deiner überwacht wird. 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.