WordPress ist tot als die automatische Antwort, nicht als Software.
Diese Unterscheidung ist wichtig. Wenn Sie sagen "WordPress ist tot" als wörtliche Marktbehauptung, lehnt die Datenlage dies ab. W3Techs berichtet, dass WordPress 59,2 % der Websites mit einem bekannten CMS und 41,5 % aller Websites im Juni 2026 antreibt. Das kann man nicht als tot bezeichnen.
Aber wenn Sie 2026 Websites erstellen, beginnt der alte Reflex falsch zu erscheinen. Ein Kunde möchte eine schnelle Seite, ein benutzerdefiniertes Layout, sauberes SEO, ein paar Integrationen und einen Bearbeitungsworkflow, der nicht zehn Plugins benötigt. Die Antwort war früher WordPress, weil benutzerdefinierter Code langsam und teuer war. KI hat diese Berechnung geändert.
Cloudflares EmDash macht den Wechsel schwerer zu ignorieren. Cloudflare sagt nicht, dass WordPress keinen Wert hat. Es sagt, dass das nächste CMS TypeScript, serverlos, Astro-betrieben, plugin-sandboxed und von Anfang an für KI-Agenten gebaut sein kann.
Ich respektiere WordPress immer noch. Ich würde es immer noch im richtigen Projekt verwenden. Ich denke nicht mehr, dass es die Standardwahl verdient.
Warum WordPress als Standard tot ist
WordPress gewann, weil es nicht-technischen Menschen Publikationsmacht gab. Das war ein echter Durchbruch. Sie konnten ein Theme installieren, einen Page Builder hinzufügen, Blogbeiträge veröffentlichen, Formulare hinzufügen, SEO-Metadaten hinzufügen und die Seite an einen Kunden übergeben.
Diese Präsentation hat sich für viele Unternehmensseiten schlecht entwickelt.
Eine einfache Seite wird oft zu einem Stapel von Plugins: Page Builder, Cache-Plugin, SEO-Plugin, Formular-Plugin, Sicherheits-Plugin, Bild-Plugin, Cookie-Plugin, Redirects-Plugin, Schema-Plugin und manchmal ein benutzerdefiniertes Feld-Plugin, um den Page Builder weniger schmerzhaft zu machen. Jedes Stück fügt Updates, Einstellungen, Datenbanktabellen, Assets und einen weiteren Fehlerpunkt hinzu.
Das Problem ist nicht der WordPress-Kern. Das Problem ist die betriebliche Form, die viele WordPress-Projekte nach einem Jahr annehmen. Die Seite wird zu einem kleinen Backend-System für Seiten, die als sauberes HTML, ein kleines CMS und ein paar API-Aufrufe hätten ausgeliefert werden können.
Patchstack's 2026 WordPress-Sicherheitsbericht macht die Wartungskosten schwerer zu ignorieren. Der Bericht sagt, dass 11.334 neue Schwachstellen im WordPress-Ökosystem im Jahr 2025 gefunden wurden, ein Anstieg von 42 % im Vergleich zu 2024. Er sagt auch, dass 91 % der neuen Schwachstellen in Plugins gefunden wurden, 9 % in Themes und nur 6 Schwachstellen im WordPress-Kern gemeldet wurden, alle mit niedriger Priorität.
Das ist der Punkt. WordPress selbst ist nicht der Bösewicht. Die Plugin-Oberfläche ist der Ort, an dem das Risiko lebt.
EmDash ist das klarste Signal
Das war der Teil, den ich von Anfang an hätte einbeziehen sollen. Cloudflare stellte EmDash am 1. April 2026 als v0.1.0-Vorschau vor und beschrieb es als spirituellen Nachfolger von WordPress.
Die Details stimmen mit dem Argument in diesem Artikel überein. EmDash ist in TypeScript geschrieben, wird von Astro betrieben, ist Open Source unter MIT und für serverloses Hosting konzipiert. Es zielt auch auf den spezifischen WordPress-Schmerzpunkt ab, der immer wieder auftaucht: Plugins.
In WordPress läuft ein Plugin in derselben Welt wie die Seite. Es kann die Datenbank, das Dateisystem und die Laufzeit auf eine Weise berühren, die viel Vertrauen erfordert. Cloudflares EmDash-Modell drängt Plugins in isolierte Dynamic Workers und gibt ihnen deklarierte Fähigkeiten durch Bindungen. Ein Plugin sollte die genauen Berechtigungen anfordern, die es benötigt, wie das Lesen von Inhalten oder das Versenden von E-Mails, bevor es diese Arbeit erledigen kann.
Das ist die moderne CMS-Idee: weniger ambientes Vertrauen, mehr explizite Berechtigungen.
EmDash ist auch wichtig, weil es KI-Agenten als Teil des Workflows behandelt. Cloudflare sagt, dass jede EmDash-Instanz einen Remote-MCP-Server, CLI-Tools und Agentenfähigkeiten bereitstellen kann. Das bedeutet, dass ein Codierungsagent Inhalte, Schemata, Medien und Migrationsarbeiten durch strukturierte Tools verwalten kann, anstatt ein Admin-Panel zu scrapen oder zu raten, wo Daten gespeichert sind.
Ich würde einem Kunden heute nicht raten, blind zu EmDash zu migrieren. Es ist eine Vorschau. Der wichtige Teil ist die Richtung: Cloudflare baut den WordPress-Ersatz um die gleichen Dinge, die ich jetzt von Websites will: sandboxed Erweiterungen, saubere Frontend-Architektur, programmatische Kontrolle und agentenlesbare Operationen.
KI hat die Berechnung für benutzerdefinierte Seiten geändert
Vor ein paar Jahren bedeutete benutzerdefiniert teuer. Sie zahlten entweder einen Entwickler, um jede Seite und jedes Element zu erstellen, oder Sie verwendeten einen Page Builder und akzeptierten das Gewicht.
KI macht den Mittelweg praktikabel. Sie können ein Layout beschreiben, Komponenten generieren, Abstände verfeinern, Texte schreiben, strukturierte Inhalte erstellen, einen kleinen Admin-Flow aufbauen und die genauen Dienste verbinden, die Sie benötigen. Tools wie v0, Framer AI, Webflow AI, Lovable-Style-App-Builder und moderne Codierungsagenten haben die Erstellung benutzerdefinierter Schnittstellen schneller gemacht.
Das bedeutet nicht, dass KI Geschmack, QA oder Ingenieururteil ersetzt. Es bedeutet, dass der erste Entwurf nicht mehr das gesamte Budget in Anspruch nimmt.
Hier verliert WordPress seine Standardposition. Wenn ich einen benutzerdefinierten Next.js-, Astro-, EmDash- oder Webflow-Bau erhalten kann, der genau zur Marke passt, schnell lädt, sauberes Schema ausliefert und ein schweres Backend vermeidet, wird der WordPress-Kompromiss schwerer zu rechtfertigen.
Ein Page Builder gibt Ihnen Regler. Ein KI-unterstützter Code-Workflow gibt Ihnen das tatsächliche System: Komponenten, Inhaltsmodell, Routen, Metadaten, Bildverarbeitung, Formulare, Analysen und Bereitstellungsregeln. Sie können es inspizieren. Sie können es versionieren. Sie können es testen.
Das ist wichtiger als ein Theme-Marktplatz.
Das Backend sollte zur Aufgabe passen
Eine Broschürenseite benötigt standardmäßig kein datenbankgestütztes Admin-Panel. Eine Landingpage benötigt kein PHP, MySQL, zwanzig Optionsbildschirme und eine Cache-Schicht, um schnell auszusehen.
Verwenden Sie ein Backend, wenn das Projekt eines benötigt:
Fügen Sie kein Backend hinzu, nur weil ein Theme irgendwo Blöcke speichern muss.
Ein schlanker moderner Stack kann kleiner sein. Statische Seiten, servergerenderte Routen, ein headless CMS, Supabase, ein Git-basierten Inhaltsfluss, gehostete Formulare, Stripe, ein Suchanbieter und eine kleine API decken einen großen Prozentsatz von Websites ab. Sie erhalten weniger bewegliche Teile und eine bessere Kontrolle über die Leistung.
Das ist der gleiche Grund, warum mir sauberes HTML und gemessenes SEO wichtig sind. In meiner Lighthouse SEO Score Fallstudie→ kam der Gewinn von diszipliniertem Markup, Schema, Geschwindigkeit, Zugänglichkeit und Caching. Ein Seiten-Builder kann helfen, aber das endgültige Ergebnis muss immer noch von Browsern, Suchmaschinen und KI-Agenten lesbar sein.
KI macht exaktes Design weniger teuer
Das stärkste Argument gegen WordPress ist nicht mehr nur Geschwindigkeit. Es ist die Kontrolle über das Design.
Die meisten WordPress-Projekte beginnen mit einem Theme und biegen dann die Marke, um sie anzupassen. Sie ändern Schriftarten, Farben, Abschnitte und Abstände, aber das Theme hinterlässt immer noch Fingerabdrücke. Die Seite sieht aus wie das Tool, das sie erstellt hat.
KI kehrt diesen Workflow um. Sie können mit der Marke, dem Angebot, dem Publikum und dem tatsächlichen Interaktionsmodell beginnen. Dann generieren Sie die Schnittstelle um diese Einschränkungen.
Das ist eine bessere Reihenfolge.
Eine Beraterseite kann die genaue Struktur haben, die sie benötigt. Eine SaaS-Seite kann eine dichte Produktoberfläche zeigen, anstatt einen generischen Hero. Eine Musikproduktseite kann sich wie ein echtes Studio-Tool anfühlen, anstatt wie eine Vorlage. Eine lokale Unternehmensseite kann Buchungen, Vertrauen, Standort und Dienstleistungsinformationen sichtbar machen, ohne gegen die Layout-Annahmen eines Themes zu kämpfen.
Das Ergebnis muss immer noch überprüft werden. KI kann schlechtes CSS, schwache Zugänglichkeit, aufgeblähtes JavaScript und vage Texte generieren. Ein Mensch muss immer noch die Seite inspizieren, mobil testen, Links überprüfen, Metadaten verifizieren, Lighthouse ausführen und das Schreiben ehrlich halten.
Aber KI entfernt die Ausrede, dass benutzerdefiniert langsam bedeutet.
Wann WordPress immer noch gewinnt
Ich würde immer noch WordPress wählen, wenn der Bearbeitungsworkflow das Produkt ist.
Wenn ein Team viele Beiträge veröffentlicht, bestehende WordPress-redaktionelle Gewohnheiten nutzt, auf WooCommerce angewiesen ist, spezifische ausgereifte Plugins benötigt oder bereits Jahre an SEO-Historie in einem stabilen WordPress-Setup hat, ist es ein schlechter Schritt, für den Trend neu zu bauen.
WordPress funktioniert auch gut für Teams, die eine vertraute Admin-Oberfläche mehr benötigen als eine benutzerdefinierte Frontend. Es gibt einen Wert in einem Tool, das die Leute bereits kennen.
Der Fehler besteht darin, WordPress auszuwählen, bevor man fragt, was die Seite tun muss.
Für viele neue Builds benötigt die Seite Geschwindigkeit, Struktur, benutzerdefiniertes Design, kontrollierte Integrationen und geringe Wartung. WordPress kann diese Dinge tun, aber es erreicht sie oft durch zusätzliche Schichten. KI-unterstützte benutzerdefinierte Builds erreichen sie direkter.
Meine praktische Regel
Ich würde heute drei Fragen stellen, bevor ich WordPress wähle.
Erstens, benötigt der Kunde die WordPress-Admin-Erfahrung speziell?
Zweitens, löst ein Plugin ein schwieriges Geschäftsproblem besser als eine kleine benutzerdefinierte Integration?
Drittens, wird die Seite nach zwölf Monaten Updates, Marketinganfragen, Tracking-Skripten und Inhaltsänderungen immer noch leicht zu warten sein?
Wenn die Antwort ja ist, kann WordPress die richtige Wahl sein.
Wenn die Antwort nein ist, würde ich mit einer leichteren Architektur beginnen und KI verwenden, um die genaue Schnittstelle zu erstellen. Das kann eine statische Seite, ein headless CMS, ein React- oder Astro-Frontend, EmDash, Webflow, Framer oder eine kleine Full-Stack-App bedeuten. Der Stack sollte zur Arbeit passen, nicht zur Gewohnheit.
Das ist auch der Punkt, an dem KI-Agenten nützlich werden. Ein guter Agent kann die Seite inspizieren, Links überprüfen, Metadaten prüfen, einen Build testen, Inhalte aktualisieren und eine Spur hinterlassen. Ich habe über diese Kontrollschicht in meinem MCP-Entwickler-Workflows-Artikel→ geschrieben. Die gleiche Idee gilt für Websites: Tools sollten klare Aktionen bereitstellen und nicht alles hinter einem Plugin-Bildschirm verstecken.
Urteil
WordPress ist tot als die automatische Antwort. WordPress ist nicht tot als Software.
EmDash ist früh, aber es zeigt, wohin das CMS-Gespräch geht: serverlos standardmäßig, TypeScript-freundlich, frontend-nativ, sicherere Plugin-Grenzen und KI-Agenten-Workflows anstelle manueller Admin-Aufgaben.
Das Web hat sich in Richtung schnellerer Frontends, kleinerer Backends, KI-unterstütztem Design und mehr expliziter Kontrolle über das endgültige Ergebnis bewegt. WordPress hat immer noch einen Platz, aber es muss diesen Platz projektweise verdienen.
Wenn Sie eine Veröffentlichungsmaschine benötigen, verwenden Sie eine. Wenn Sie eine benutzerdefinierte Website benötigen, die genau wirkt, schnell lädt und ein schweres Backend vermeidet, hat KI den besseren Weg einfacher gemacht.