Zurück zum Blog
28. Februar 2026WordPress, Sicherheit, Webentwicklung, Erfahrung, Next.js

Warum ich kein WordPress mehr mache – und was ich daraus gelernt habe

Lange habe ich WordPress-Websites gebaut, Plugins installiert und Themes angepasst. Irgendwann wurde mir klar: Ich bin kein Entwickler, ich war ein Verwalter fremden Codes. Ein ehrlicher Rückblick.

Wenn ich ehrlich bin: Am Anfang fehlte mir der Weitblick, um zu erkennen, was ich mir da eingebrockt hatte.

WordPress war bequem. Ein Theme hier, ein Plugin da – und die Website hatte plötzlich Funktionen, für die ich sonst Wochen gebraucht hätte. Das fühlte sich produktiv an. Es war es nicht.

Das Plugin-Problem

WordPress selbst ist in vielen Fällen nicht das eigentliche Sicherheitsproblem. Das Problem sitzt in den Erweiterungen.

Sobald eine Website mehr können soll als eine Standard-Installation bietet, greift man zu Plugins. Kontaktformular, SEO-Tool, Slider, Backup, Cache, Galerie – schnell hat man 15 bis 20 Plugins aktiv. Und jedes davon bringt fremden Code mit, der im schlimmsten Fall nie oder selten gewartet wird.

Laut dem Sucuri Website Threat Research Report waren in den vergangenen Jahren über 97 % aller kompromittierten WordPress-Installationen durch veraltete oder unsichere Plugins und Themes angreifbar – nicht durch WordPress selbst.

In meiner Praxis sah das konkret so aus:

Fall 1 – Das Update mit Nebenwirkungen: Eine bekannte Sicherheitslücke in einem Plugin wird geschlossen. Das Update erscheint. Ich installiere es – und das Theme rendert die Seite nicht mehr korrekt, weil das Plugin seine API geändert hat. Also: Downgrade, warten, patchen, testen. In der Zwischenzeit läuft eine bekannt verwundbare Version.

Fall 2 – Das Update, das nie kam: Ein Plugin wird nicht mehr aktiv entwickelt. Die Lücke bleibt offen. Die einzige Option: Plugin austauschen, Design und Funktionen neu integrieren, alles neu testen. Stunden- oder tagelanges Rollback.

Und das waren nur die Lücken, die "bekannt" waren. Die Dunkelziffer nicht dokumentierter oder stiller Schwachstellen in weniger populären Plugins ist um ein Vielfaches höher.

Auch eigene Themes lösen das Problem nicht

Ich habe eigene Themes gebaut. Das klingt nach der logischen Antwort auf die Plugin-Abhängigkeit.

Das Problem: WordPress entwickelt sich weiter – und zieht einen mit. Die Einführung des Gutenberg-Block-Editors mit WordPress 5.0 hat viele selbst geschriebene Themes tief in die Kompatibilitätsfalle geführt. Was gestern noch funktionierte, war nach einem Core-Update auf einmal gebrochen oder zumindest stark eingeschränkt.

Man ist fremdgesteuert. Nicht von einem einzelnen Plugin, sondern vom gesamten Ökosystem.

Das eigentliche Gefühl: Gast in der eigenen Anwendung

Als Softwareentwickler war das frustrierender als jeder Fehler im Code. Ich schrieb keine Anwendung – ich verwaltete eine Plattform, die mir nie vollständig gehörte.

Bei jedem größeren WordPress-Update war die erste Frage: *Was bricht diesmal?* Nicht: *Was kann ich jetzt besser machen?*

Was ich heute anders mache

Statt WordPress setze ich zum Beispiel auf Next.js mit React und TypeScript. Kein CMS-Kern, kein Plugin-Ökosystem. Jede Zeile, die ausgeliefert wird, ist explizit da – entwickelt, geprüft und verstanden.

Das bedeutet nicht, dass keinerlei externe Abhängigkeiten verwendet werden. React, Next.js, Tailwind – das sind etablierte, aktiv gepflegte Open-Source-Projekte mit breiter Community und transparenten Changelogs. Der Unterschied liegt in der Kontrolle: Ich entscheide, was in die Anwendung kommt, wann es aktualisiert wird, und was es tut.

Eine WordPress-Standardinstallation liefert je nach Konfiguration in die Größenordnung von 50–80 MB Codebasis mit – inklusive REST-API-Endpoints, XML-RPC, Legacy-Kompatibilitätscode und Dutzenden ungenutzter Features. Alles potenziell angreifbar, alles ungenutztes Gewicht.

Eine moderne, schlanke Next.js-Seite bringt aus, was gebraucht wird. Nicht mehr.

Diese Webseite ist zum Zeitpunkt des Posts 248 KB groß – inklusive aller Bilder, Skripte und Styles. Und das bei deutlich besserer Performance und vor allem: ohne die ständige Sorge um Sicherheitslücken in Plugins.

Eine WordPress-Standardinstallation ohne Themes und Plugins ist somit ca. um das 300-fache größer als eine moderne, schlanke Next.js-Seite.

Fazit

WordPress war ein gutes Lernfeld. Aber es hat mir auch gezeigt, wo die Grenzen eines Plugin-basierten Systems liegen: in der Sicherheit, in der Performance und im Gefühl, selbst die Kontrolle zu haben.

Heute baue ich Websites, bei denen ich abends ruhig schlafen kann – weil ich weiß, was drin ist.

Wenn Sie sich fragen, wie Ihre bestehende Website in Sachen Sicherheit aufgestellt ist, können Sie das direkt hier kostenlos prüfen: Zum Website-Check