Warum WordPress 2026 nicht mehr der richtige Weg ist

Ich arbeite seit Jahren mit WordPress und betreue bis heute über zehn WordPress-Seiten. Dieser Artikel ist deshalb keine Abrechnung von außen, sondern eine Bestandsaufnahme aus dem Alltag. Und die fällt 2026 deutlich schlechter aus als noch vor ein paar Jahren.

WordPress war die richtige Wahl – vor 15 Jahren

WordPress hat das Web demokratisiert: Hosting für ein paar Euro, ein Theme, ein paar Plugins, fertig. Für Blogs und einfache Firmenseiten war das lange unschlagbar. Heute läuft WordPress laut W3Techs auf 39,7 % aller Websites und auf 58,5 % aller Seiten mit bekanntem CMS. Das ist viel, aber der Anteil sinkt seit Anfang 2025 stetig: von 43,6 % auf unter 40 %.

Der Rückgang allein ist kein Argument. Interessanter ist, warum Unternehmen wechseln. In meinen Projekten sind es fast immer dieselben vier Gründe: Sicherheit, Geschwindigkeit, Wartungsaufwand und die Frage, wer das System eigentlich kontrolliert.

Sicherheit: 11.334 neue Lücken in einem Jahr

Der Sicherheitsanbieter Patchstack zählt jedes Jahr die neu gemeldeten Schwachstellen im WordPress-Ökosystem. Für 2025 waren es 11.334 – ein Plus von 42 % gegenüber dem Vorjahr. 91 % davon steckten in Plugins, 9 % in Themes.

neue Schwachstellen im WordPress-Ökosystem 2025 (+42 %)

11.334

neue Schwachstellen im WordPress-Ökosystem 2025 (+42 %)

waren zum Zeitpunkt der Veröffentlichung noch nicht behoben

46 %

waren zum Zeitpunkt der Veröffentlichung noch nicht behoben

gewichteter Median bis zur ersten Ausnutzung

5 Std.

gewichteter Median bis zur ersten Ausnutzung

Die letzte Zahl ist die entscheidende. Zwischen der Veröffentlichung einer Lücke und den ersten Angriffen vergehen im Median fünf Stunden. Rund die Hälfte der schweren Lücken wird innerhalb von 24 Stunden ausgenutzt. Wer Updates einmal pro Woche oder einmal im Monat einspielt, ist in diesem Zeitfenster schlicht offen.

Was 2026 konkret passiert ist

• Gravity SMTP (März): Eine Schnittstelle des Mail-Plugins lieferte jedem Besucher ohne Login einen Systembericht – inklusive der API-Schlüssel und Tokens der hinterlegten Mail-Anbieter. Laut Wordfence wurden über 17 Millionen Angriffsversuche geblockt.
• ShapedPlugin Pro (Mai): Angreifer schleusten über den Update-Mechanismus eine Backdoor in drei Premium-Plugins. Sie stahl Zugangsdaten, Session-Cookies, 2FA-Geheimnisse, die Datenbank-Zugangsdaten aus der wp-config.php und WooCommerce-Bestellungen der letzten drei Monate inklusive Zahlungsart-Informationen. Die Kunden haben nichts falsch gemacht – sie haben ein Update installiert.
• Burst Statistics und Kirki (Mai): Zwei Plugins mit zusammen 700.000 Installationen erlaubten die Übernahme von Admin-Konten ohne Passwort. Beide wurden kurz nach Bekanntwerden aktiv angegriffen.
• All-in-One WP Migration (August): Eine Lücke im Backup-Plugin mit 5 Millionen Installationen erlaubte über eine SQL-Injection die Codeausführung. Zwei Wochen nach dem Fix hatten laut BleepingComputer erst rund 35 % aktualisiert.

Warum Plugins das Grundproblem sind

Ein WordPress-Plugin ist Code von einem fremden Entwickler, der mit vollen Rechten im selben Prozess läuft wie Ihre Website – mit Zugriff auf die Datenbank, die Dateien und alle Kundendaten. Gewachsene Unternehmensseiten kommen schnell auf ein paar Dutzend davon; ein WooCommerce-Shop hat laut Metorik im Schnitt 58 aktive Plugins. Jedes einzelne ist eine Tür, und die Website ist nur so sicher wie das am schlechtesten gewartete Plugin.

Dazu kommt: Premium-Plugins werden oft außerhalb von WordPress.org verteilt, über eigene Update-Server. Genau dort setzte der ShapedPlugin-Angriff an. Laut Patchstack betrafen 29 % aller Meldungen 2025 Premium- oder Freemium-Komponenten – mit fast dreimal so vielen kritischen Zero-Days wie bei kostenlosen Plugins. Und die Firewalls der Hoster sind kein Ersatz: In Patchstacks Tests blockierten sie nur 12 bis 26 % der Angriffe.

Performance: Nur jede zweite WordPress-Seite ist schnell genug

Google bewertet die Ladeerfahrung über die Core Web Vitals: wie schnell der Hauptinhalt erscheint (LCP), wie flott die Seite auf Eingaben reagiert (INP) und wie stabil das Layout bleibt (CLS). Die echten Nutzerdaten aus Chrome zeigen: Im September 2026 bestanden nur 48,3 % der WordPress-Seiten diesen Test auf dem Smartphone.

Eine ehrliche Anmerkung, bevor jemand fragt: Next.js schneidet in dieser Statistik noch schlechter ab (35,7 %). Das Framework allein macht also keine schnelle Website. Viele Next.js-Seiten laden riesige JavaScript-Pakete, rendern alles im Browser oder binden ungefilterte Tracking-Skripte ein. Geschwindigkeit entsteht durch Architektur-Entscheidungen, nicht durch ein Logo im Footer.

Der Unterschied ist, wer diese Entscheidungen trifft. Bei WordPress treffen sie Theme- und Plugin-Hersteller, die für tausende Seiten gleichzeitig bauen: Ein Page-Builder lädt seine CSS- und JavaScript-Dateien auf jeder Seite, ein Slider-Plugin auch dort, wo kein Slider ist, ein Formular-Plugin seine Skripte im ganzen Frontend. Die mittlere WordPress-Seite ist auf dem Smartphone 2,7 MB schwer, der mittlere Lighthouse-Performance-Score liegt laut Web Almanac 2025 bei 41 von 100. Caching-Plugins kaschieren das, aber sie sind ein weiteres Plugin.

Bei einer individuell gebauten Next.js-Seite liegt jede dieser Entscheidungen bei Ihnen beziehungsweise bei Ihrem Entwickler: Seiten werden vorab generiert, Bilder automatisch in passenden Größen und modernen Formaten ausgeliefert, und JavaScript landet nur dort im Browser, wo es gebraucht wird. Das ist kein Automatismus – aber es ist möglich, ohne gegen ein Theme anzukämpfen.

Wartung: der Update-Zirkus

Wer eine WordPress-Seite verantwortungsvoll betreibt, aktualisiert wöchentlich Kern, Theme und Plugins – und prüft danach, ob noch alles funktioniert. Denn Plugins verschiedener Hersteller werden nicht miteinander getestet. In der Praxis passiert deshalb oft das Gegenteil: Updates werden aufgeschoben, bis „mal Zeit ist“. Genau das zeigen die Zahlen zur Server-Software.

Rund 37 % aller WordPress-Seiten laufen auf PHP 8.1 oder älter – Versionen, für die es keine Sicherheitsupdates mehr gibt. Und für PHP 8.2, auf dem weitere 24 % laufen, endet der Support am 31. Dezember 2026. Ein PHP-Upgrade ist bei WordPress selten ein Klick, weil ältere Plugins dabei gern brechen. Also bleibt es liegen.

Wie sich das im Alltag anfühlt, zeigt eine nachgestellte, typisch gewachsene Firmen-Installation mit Theme, Page-Builder, Shop und 15 Plugins:

musterfirma.at/wp-admin/plugins.php

musterfirma.at/wp-admin/site-health.php

Wer kontrolliert eigentlich WordPress?

Seit Oktober 2024 streiten Automattic, das Unternehmen von WordPress-Mitgründer Matt Mullenweg, und der Hoster WP Engine vor Gericht. Für Website-Betreiber wurde das ganz praktisch: Im Oktober 2024 übernahm WordPress.org das beliebte Plugin Advanced Custom Fields als „Secure Custom Fields“ – und Seiten mit aktivierten Auto-Updates wurden automatisch auf die neue Version umgestellt. Ende September 2026 ließ das Gericht die meisten Klagepunkte zu, einschließlich kartellrechtlicher. Ein Ende ist nicht in Sicht.

Man muss in diesem Streit keine Partei ergreifen, um das Problem zu sehen: Ein Ökosystem, auf dem 40 % des Webs laufen, hängt an den Entscheidungen sehr weniger Menschen. Als Betreiber haben Sie darauf keinen Einfluss.

Inhalte: Seitenbauer statt Struktur

WordPress speichert Seiteninhalte im Kern als HTML-Block in einem einzigen Datenbankfeld. Mit Gutenberg oder einem Page-Builder wird daraus ein Mix aus Inhalt und Layout. Das fühlt sich anfangs flexibel an, rächt sich aber: Die gleichen Inhalte in einer App, einem Newsletter oder auf einer zweiten Marken-Website zu verwenden, ist kaum möglich. Für AI-Workflows – etwa Übersetzungen oder Entwürfe – fehlt die Struktur, mit der ein Modell zuverlässig arbeiten kann. Und Redakteure verbringen mehr Zeit damit, Abstände zu korrigieren, als Inhalte zu schreiben.

Wann WordPress trotzdem passt

Fairerweise: WordPress ist nicht für jeden die falsche Wahl. Es kann weiterhin sinnvoll sein, wenn

• Sie einen einfachen Blog oder eine kleine Seite mit sehr knappem Budget betreiben,
• die Seite mit wenigen, gut gepflegten Plugins auskommt,
• ein Managed-Hosting mit automatischen Updates und Monitoring dahintersteht,
• oder Ihr Team WordPress kennt und den Wartungsaufwand bewusst trägt.

Sobald eine Website aber Leads bringen, Kundendaten verarbeiten, mehrsprachig sein oder mit anderen Systemen sprechen soll, wird die Rechnung eine andere.

Warum ich heute auf Payload CMS setze

Payload ist ein Open-Source-CMS (MIT-Lizenz), das direkt in einer Next.js-Anwendung läuft. Seit Juni 2025 gehört es zu Figma und ist laut Hersteller weiterhin Open Source. Bei der NCA NewConcept Agentur habe ich mehrere Projekte von WordPress auf Payload gebracht; das sind die Unterschiede, die in der Praxis zählen:

• Kein Plugin-Marktplatz von Fremden. Inhaltsmodell, Rollen und Funktionen sind Code im eigenen Repository. Jede Abhängigkeit ist bewusst gewählt, versioniert und wird vor dem Deployment getestet.
• Kleinere Angriffsfläche. Das Admin-Panel lässt sich auf eine eigene Domain legen oder per IP absichern; die öffentliche Website kann komplett statisch ausgeliefert werden.
• Strukturierte Inhalte. Felder, Blöcke und Beziehungen statt HTML-Brei. Dieselben Inhalte versorgen Website, App, Newsletter oder AI-Workflows.
• Geschwindigkeit nach Maß. Weil Frontend und CMS eine Anwendung sind, entscheidet nur das Projekt, welches JavaScript im Browser landet – kein Theme, kein Page-Builder.
• Sie besitzen alles. Code und Daten liegen bei Ihnen, gehostet in der EU. Keine Lizenzkosten pro Nutzer, keine Abhängigkeit von einem SaaS-Anbieter.

localhost/admin/collections/pages

So läuft ein Umstieg von WordPress auf Payload

1. 1.Bestandsaufnahme: Welche Inhalte, Plugins und Funktionen gibt es – und welche davon werden wirklich gebraucht? Dazu die aktuellen Rankings und Zugriffe aus der Search Console.
2. 2.Inhaltsmodell: Aus Beiträgen, Seiten und Page-Builder-Layouts werden saubere Collections und Blöcke.
3. 3.Migration per Skript: Texte, Bilder, Kategorien und SEO-Metadaten werden automatisiert übernommen und stichprobenartig geprüft.
4. 4.Neues Frontend: Komponenten werden individuell gebaut – schnell, barrierearm und im eigenen Design.
5. 5.Launch ohne Ranking-Verlust: Jede alte URL bekommt eine 301-Weiterleitung, Sitemap und Search Console werden aktualisiert.