YOUNG CREATIVES

Warum wir keine WordPress-Seiten mehr bauen

Seit Anfang 2026 bauen wir bei Young Creatives keine neuen Websites mehr mit WordPress. Wir liefern sie statisch oder headless aus, mit React und Next.js über ein CDN wie Netlify oder Cloudflare. Der Grund ist weniger Geschmack als Betrieb: Eine Seite, die aus fertigem HTML besteht, hat weniger bewegliche Teile, die jemand pflegen muss. Neue Seiten stehen bei uns in 48 Stunden von der Anfrage bis zum Livegang. Hier lesen Sie, warum wir so entschieden haben und wo die Entscheidung Grenzen hat.

Abstrakte Website als schlanker statischer Baustein, der über ein CDN ausgeliefert wird, daneben ein offenes Plugin-Geflecht

Kernpunkte

Headless heißt: Redaktion und Datenhaltung sind vom Frontend getrennt. Die Seite wird vorab gebaut und als fertige Dateien über ein CDN ausgeliefert.
Bei WordPress liegen die Schwachstellen laut Patchstack fast ausschließlich in Plugins und Themes, nicht im Kern. Genau dieses Ökosystem war jahrelang der Vorteil.
Das größere Risiko ist nicht der Ausfall, sondern abfließende Kunden-, Bewerber- und Nutzerdaten.
Keine Technik ist immun. Auch Node.js, Next.js und Abhängigkeiten brauchen Updates, nur gibt es weniger Angriffsfläche.
WordPress bleibt für manche Fälle eine vernünftige Wahl. Wir bauen damit nur keine neuen Seiten mehr.

Was wir mit „statisch“ und „headless“ meinen

Bei einer klassischen WordPress-Installation laufen Redaktionsoberfläche, Datenbank und öffentliche Website auf demselben System. Jeder Seitenaufruf löst PHP-Code und Datenbankabfragen aus, und der Admin-Login ist über dieselbe Domain erreichbar.

Bei einer statischen Seite passiert die Arbeit vorher. Next.js erzeugt beim Build laut Dokumentation pro Route eine HTML-Datei, die sich auf jedem Server ausliefern lässt, der statische Dateien bereitstellen kann. Bei uns übernimmt das ein CDN. Inhalte, die jemand pflegen soll, liegen in einem getrennten Backend, das die Besucher nie direkt erreichen. Das ist der Kern von „headless“: Das Backend hat keinen Kopf, also kein öffentliches Gesicht.

Für Sie als Betreiber ändert sich vor allem eines. Beim Seitenaufruf läuft kein PHP-Interpreter und keine Datenbank, die jemand angreifen könnte. Weniger laufende Teile bedeuten weniger Stellen, die ausfallen oder aufgebrochen werden können.

Abstrakter Ablauf: Inhalte sichern, Seite neu bauen, Weiterleitungen setzen, live schalten — Umzug in vier Schritten: Inhalte sichern, neu bauen, Weiterleitungen setzen, live gehen.

Das Plugin-Ökosystem: früher Stärke, heute Wartungsschuld

WordPress hat lange davon gelebt, dass es für fast alles ein Plugin gibt. Kontaktformular, SEO, Cache, Galerie, Shop: ein Klick, fertig. Der Preis zeigt sich im Betrieb. Jedes Plugin ist Code von Dritten, den jemand aktuell halten muss. Verlieren Entwickler das Interesse, bleibt ein verwaistes Plugin auf Ihrer Seite zurück.

Der Sicherheitsanbieter Patchstack wertet das in seinem Report „State of WordPress Security in 2026“ aus. Danach lagen 91 Prozent der 2025 gemeldeten Schwachstellen in Plugins und 9 Prozent in Themes. Im WordPress-Kern wurden sechs Lücken gemeldet, alle niedrig priorisiert. Außerdem erhielten 46 Prozent der Schwachstellen vom Entwickler keinen Fix, bis sie öffentlich bekannt wurden. Beachten Sie: Patchstack verkauft selbst Schutz für WordPress-Seiten, die Zahlen kommen also von einem Anbieter mit Interesse. Sie bilden trotzdem ab, wo das Problem sitzt.

Dazu kommt das Tempo. Laut demselben Report liegt der gewichtete Median bis zur ersten Ausnutzung stark angegriffener Lücken bei fünf Stunden. Ein Update-Rhythmus von „einmal im Monat“ passt dazu nicht mehr.

Mit KI-Unterstützung lässt sich vieles, wofür man früher ein Plugin installiert hat, heute gezielt selbst bauen: ein Formular, eine Filterlogik, eine Anbindung an das CRM. Das ist schlanker, weil nur existiert, was Ihre Seite wirklich braucht. Eigener Code muss allerdings geprüft und gepflegt werden. Er verschiebt die Wartung an eine Stelle, die wir kennen.

Das eigentliche Risiko heißt Datenabfluss

Wenn über Sicherheit bei Websites gesprochen wird, geht es meist um den Ausfall: Die Seite ist offline oder verunstaltet. Das ärgert, ist aber meist behoben. Schwerer wiegt, was im Hintergrund abfließen kann: Anfragen aus Kontaktformularen, Bewerbungen mit Lebenslauf, Kundenkonten, Newsletter-Listen.

Dann geht es nicht mehr nur um Technik. Nach Art. 33 DSGVO muss der Verantwortliche eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden der Aufsichtsbehörde melden, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Die Frist beginnt, sobald Ihnen die Verletzung bekannt wird, nicht erst nach Abschluss der Untersuchung.

Eine statische Seite speichert selbst nichts. Formulareingaben laufen an einen schmalen, klar abgegrenzten Dienst, der nur diese eine Aufgabe hat. Das beseitigt das Risiko nicht, denn die Daten landen irgendwo. Es verkleinert aber die Fläche, auf der etwas schiefgehen kann, und macht sie überschaubar.

Schlanke Seiten sind für KI-Suche leichter zu lesen

Immer mehr Menschen fragen ChatGPT, Claude oder Perplexity, statt zu googeln. Für Ihre Sichtbarkeit zählt deshalb, ob diese Systeme Ihre Inhalte lesen können. Eine Analyse von Vercel und MERJ von Dezember 2024 zeigt: Die großen KI-Crawler von OpenAI, Anthropic und Perplexity führen kein JavaScript aus. Was nicht schon im ausgelieferten HTML steht, sehen sie nicht.

Das spricht für vorab erzeugtes HTML, wie es statische Auslieferung liefert, und gegen Seiten, die ihre Inhalte erst im Browser zusammensetzen. Fair gesagt: Auch ein gut gebautes WordPress liefert HTML aus. Der Unterschied liegt in Schlankheit und Ladezeit. Eine statische Seite kommt ohne Datenbankabfrage und Plugin-Ballast aus der Auslieferung. Messwerte zur Geschwindigkeit sollten Sie sich aber immer am konkreten Projekt zeigen lassen, nicht an einer Pauschalbehauptung.

Die Daten sind knapp zwei Jahre alt, das Verhalten der Crawler kann sich ändern. Wir prüfen es deshalb bei jedem Projekt neu, statt uns auf die Studie zu verlassen.

Schneller bauen, Automationen und KI im Backend

Der Vorteil für uns liegt im Tempo. Mit einer eigenen Komponentenbibliothek und einem festen Build-Ablauf entsteht eine Seite ohne Theme-Anpassungen, Plugin-Konflikte und Kompatibilitätsprüfungen. Deshalb können wir bei neuen Seiten 48 Stunden von der Anfrage bis zum Livegang anbieten.

Ein getrenntes Backend lässt sich außerdem gezielt erweitern: Anfragen automatisch einordnen, Inhalte vorbereiten, Daten an Ihr CRM weitergeben, einen KI-Assistenten anbinden. Das geht, ohne die öffentliche Seite anzufassen.

Was auch bei uns Pflege braucht

Wir behaupten nicht, dass der neue Aufbau wartungsfrei ist. Node.js, Next.js und die Abhängigkeiten im Projekt bekommen Sicherheitsupdates, und ein CDN oder ein Formulardienst kann falsch konfiguriert sein. Auch eine statische Seite, die an eine alte PHP-API oder ein WordPress-Backend angeschlossen bleibt, erbt deren Risiken.

Wie sich das konkret auswirkt, haben wir nach der BSI-Warnung vom 21. Oktober beschrieben. Die beiden PHP-Lücken CVE-2026-109618 und CVE-2026-109619 betreffen Server, auf denen PHP Anfragen verarbeitet. Eine rein statisch ausgelieferte Seite ist davon nicht betroffen. Den Hintergrund finden Sie im Insight zur PHP-Sicherheitslücke.

Und es gibt Fälle, in denen WordPress weiter passt: ein großes Redaktionsteam mit etablierten Abläufen, eine bestehende Seite, an der sich jahrelang nichts ändern soll und die zuverlässig gepflegt wird, oder ein Projekt, das auf ein bestimmtes Plugin angewiesen ist. Die Entscheidung gilt für unsere Neuprojekte, nicht als Urteil über jede WordPress-Seite. Warum wir dafür auf React und Next.js setzen, steht im Insight zu React und Next.js.

Umzug von WordPress: worauf es ankommt

Bei einem Umzug bauen wir die Seite neu und übernehmen Ihre Inhalte. Vorab klären wir diese Punkte:

1. Inhalte und Struktur: Welche Seiten, Beiträge und Bilder bleiben, welche fallen weg?

2. Adressen: Bestehende URLs bekommen Weiterleitungen, damit Rankings und externe Links nicht ins Leere laufen.

3. Funktionen: Welche Plugins haben bisher Aufgaben übernommen, und wie lösen wir sie neu, etwa Formulare, Suche oder Buchung?

4. Daten: Wo liegen Formulareingaben, Newsletter-Kontakte oder Nutzerkonten heute, und wohin ziehen sie?

5. Pflege: Wer ändert künftig Texte, und mit welcher Oberfläche?

Für neue Seiten ist unser Ziel 48 Stunden bis zum Livegang. Bei einem Umzug hängt der Aufwand vom Umfang der bestehenden Seite ab. Den Zeitrahmen nennen wir Ihnen nach der Bestandsaufnahme.

Quellen & weiterführende Links

Seite von WordPress umziehen?

Wir schauen uns Ihre bestehende Seite an, klären Inhalte, Adressen und Funktionen und sagen Ihnen, was ein Umzug auf eine schnelle, statisch ausgelieferte Seite bedeutet. Neue Seiten stehen bei uns in 48 Stunden von der Anfrage bis zum Livegang.

Umzug besprechen

Weiterführend: Webdesign Hamburg.