Der schleichende Bruch: Mein Abschied von WordPress

WordPress ist überall. Aktuell betreibt es etwa 43% aller Websites weltweit – eine beeindruckende Dominanz, die das System über Jahre hinweg aufgebaut hat. Lange Zeit war ich selbst überzeugt: flexibel, offen, ein riesiges Ökosystem aus Themes und Plugins.

Aber irgendwann kippt etwas. Nicht schlagartig, sondern schleichend.

In den letzten Jahren – mit Gutenberg, Full-Site-Editing und immer komplexeren Update-Zyklen – hatte ich zunehmend das Gefühl, nicht mehr mit WordPress zu arbeiten, sondern für WordPress. Dieser Artikel ist keine emotionale Abrechnung. Es ist eine nüchterne Bestandsaufnahme aus der Praxis eines langjährigen Nutzers.

Der Update-Kreislauf: Von Bugfixes zu Bauchschmerzen

Früher bedeutete ein Update: Bugfixes, Sicherheit, fertig.

Heute bedeutet ein Update vor allem eines: Bauchschmerzen.

Jedes größere Release bringt neue Funktionen – und neue Bruchstellen. Themes brechen, vor allem ältere oder nicht blockbasierte Setups. Page Builder kollidieren mit dem Block-Editor. SEO-Plugins greifen tief ins System ein und verursachen Nebenwirkungen.

Was früher ein Klick war, ist heute ein Prozess: Staging anlegen, Backup prüfen, Plugins deaktivieren, testen, rollbacken, hoffen.

Selbst automatische Minor-Updates sind kein Selbstläufer mehr, weil ein einzelnes Plugin reicht, um das System zu destabilisieren.

Gutenberg: Gut gemeint, schlecht geerdet

Gutenberg sollte WordPress modernisieren. In der Realität ist es für viele bis heute ein Fremdkörper.

Typische Probleme aus dem Alltag: Blöcke verschachteln HTML auf unvorhersehbare Weise. Klassen landen nicht dort, wo man sie erwartet. Responsives Verhalten ist entweder eingeschränkt oder umständlich. Layout-Logik wird durch abstrakte Block-Konzepte ersetzt.

Was besonders stört: Gutenberg ist kein echter Page Builder, will aber einer sein.

Viele professionelle Nutzer umgehen das Problem, indem sie zusätzliche Block-Libraries installieren, den Classic Editor wieder aktivieren oder gleich komplett auf externe Builder setzen. Das Ergebnis ist ein hybrides System, das technisch funktioniert, aber konzeptionell nie rund wird.

Performance: Komplexität hat ihren Preis

Ein Thema, das selten ehrlich diskutiert wird: Ladezeit und Overhead.

Block-basierte Seiten bringen oft mehr DOM-Tiefe, mehr CSS-Layer, mehr JavaScript. Natürlich lässt sich das optimieren. Aber genau hier liegt das Problem: Warum muss ich ein CMS erst entkernen, um es effizient nutzen zu können?

Das Abo-Paradoxon

Fast alles, was früher selbstverständlich war, liegt heute hinter einer Paywall: erweiterte Felder, saubere Layout-Kontrolle, professionelle SEO-Funktionen, Backups, Sicherheit, Performance.

Nicht, weil Entwickler gierig sind – sondern weil das System sie dazu zwingt. Regelmäßige Breaking Changes erfordern regelmäßige Einnahmen.

Das Paradoxe daran: Je mehr Abos aktiv sind, desto abhängiger wird man von Updates. Und je abhängiger man ist, desto größer wird der Stress bei jedem Release.

Die Frage, die alles verändert hat

Irgendwann habe ich mir eine einfache Frage gestellt: Was brauche ich wirklich?

Die Antwort war ernüchternd: Texte. Bilder. Struktur. Kontrolle.

Kein Plugin-Zoo. Keine Abhängigkeiten. Keine Überraschungen nach einem Update.

Eine Eigenentwicklung mit einem Static Site Generator wie Hugo oder Eleventy bedeutet weniger Features – aber mehr Ruhe, mehr Verständnis, mehr Nachhaltigkeit.

Mein Blog ist heute kein Produkt mehr, das gewartet werden will. Er ist ein Werkzeug – schnell, stabil und minimalistisch.

Kein Abschied im Zorn

WordPress ist mächtig. Für viele Projekte – Shops, komplexe Sites, Teams – weiterhin sinnvoll. Aber es ist komplex geworden, laut, schwer. Was früher Freude gemacht hat, fühlt sich heute oft wie Betrieb an.

Vielleicht ist das der natürliche Weg eines Systems, das zu groß geworden ist. Vielleicht ist es einfach Zeit, wieder kleiner zu denken.

Ich bin WordPress dankbar für all die Jahre. Aber ich bin froh, diesen Teil hinter mir gelassen zu haben.