Liebes WordPress: Niemand hat nach AI Connectors gefragt. Wir wollten Caching.

Ich habe vor einer Weile einen Beitrag geschrieben über 20 WordPress-Plugins, die du mit ein paar Zeilen PHP ersetzen kannst. Er kam gut an. Leute haben ihn geteilt. Entwickler haben zustimmend genickt. Aber je mehr ich darüber nachgedacht habe, desto mehr hat es mich gestört.

Der Beitrag hat das Symptom behandelt. Die Krankheit ist WordPress selbst.

WordPress 7.0 steht vor der Tür. Die Hauptfeatures? Ein glänzender neuer Connectors Screen für OpenAI, Gemini und Claude. Ein MCP Adapter, der die Fähigkeiten deiner Seite für KI-Assistenten zugänglich macht. Eine Abilities API. Smart Content Suggestions. Auto-Alt Text.

Und du brauchst immer noch ein Plugin, um eine Seite zu cachen.

WordPress 7.0 kommt. Und es hat AI Connectors.

Lass mich kurz erklären, was hier passiert. WordPress 7.0, ursprünglich für den 9. April 2026 geplant, wurde auf den 20. Mai verschoben. Das erste Mal in der modernen WordPress-Geschichte, dass ein Release in der RC-Phase zurückgehalten wurde. Der Grund? Cache-Invalidierungsprobleme mit dem neuen Echtzeit-Kollaborationsfeature.

Die Ironie ist fast poetisch. Sie können die Kollaboration nicht ausliefern, weil sie intern das Caching nicht gelöst bekommen. Aber sie liefern AI Connectors, damit Claude deine Blogbeiträge schreiben kann.

Die neue KI-Infrastruktur umfasst einen Connectors Screen, in dem du API-Keys für verschiedene KI-Anbieter einträgst. Einen MCP Adapter, der deine WordPress-Seite in einen Tool Server für KI-Agenten verwandelt. Eine Abilities API, die definiert, welche Aktionen deine Seite ausführen kann. Das alles ist wirklich interessante Technologie. Ich habe über MCP geschrieben und halte es für eine der spannenderen Entwicklungen in der Art, wie wir mit Software interagieren.

Aber hier ist mein Problem. WordPress hatte 20 Jahre Zeit, grundlegende CMS-Features zu bauen, die jeder Wettbewerber von Haus aus mitbringt. Statt das Fundament zu reparieren, installieren sie eine smarte Türklingel an einem Haus ohne Dach.

Caching: Das Feature, das WordPress sich weigert zu bauen

Wir schreiben 2026. WordPress betreibt über 40% des Webs. Und es liefert null Caching.

Kein Page Caching. Kein Object Caching. Kein Cache Management. Jede WordPress-Seite auf dem Planeten installiert WP Super Cache, W3 Total Cache, LiteSpeed Cache oder FlyingPress. FlyingPress ist übrigens ausgezeichnet. Ich habe es getestet. Aber die Tatsache, dass es überhaupt existieren muss, ist das Problem.

Next.js hat ISR (Incremental Static Regeneration) eingebaut. Du definierst eine Revalidierungsperiode und das Framework kümmert sich darum. Astro liefert standardmäßig statisches HTML. Ghost ist 2-3x schneller als eine typische WordPress-Seite, weil es nicht 20 Jahre Architektur-Altlasten mit sich schleppt.

Und jetzt kommt der Hammer. WordPress 7.0 wurde genau wegen Cache-Invalidierungsproblemen in ihrem Echtzeit-Kollaborationsfeature verschoben. Sie kämpfen intern mit Caching, aber wollen es nicht als Feature für die Nutzer bauen. Das Engineering-Team versteht das Problem offensichtlich. Sie lösen es nur nicht für den Rest von uns.

Jeder Managed-WordPress-Hoster (Cloudways, Kinsta, WP Engine) hat eine eigene Caching-Schicht auf WordPress gebaut, weil WordPress es nicht tut. Die Hoster machen den Job von WordPress. Und berechnen dir dafür Geld.

SEO: Zwanzig Jahre und immer noch kein Meta-Description-Feld

Das hier verwirrt mich wirklich.

WordPress ist das beliebteste CMS der Welt. Es wird von Millionen Menschen genutzt, die bei Google gefunden werden wollen. Und es hat kein eingebautes Feld für einen Meta Title. Keine Meta Description. Keine Open Graph Tags. Keine JSON-LD Structured Data.

Jede einzelne WordPress-Seite installiert Yoast SEO oder Rank Math. Jede. Einzelne. Diese Plugins sind so allgegenwärtig, dass die meisten Leute denken, sie gehören zu WordPress. Tun sie nicht. Es ist Third-Party-Code, gepflegt von Unternehmen, die morgen verschwinden, ihr Preismodell ändern oder aufgekauft und ausgeweidet werden könnten.

Ghost hat native SEO-Felder. Du öffnest einen Beitrag, da ist ein Meta-Title-Feld, ein Meta-Description-Feld, ein Open-Graph-Bildauswähler. Fertig. Kein Plugin. Keine Konfiguration. Keine möglichen Konflikte mit deinem Theme oder anderen Plugins.

Next.js hat eine Metadata API. Du exportierst ein Metadata-Objekt aus deiner Seite und das Framework erledigt den Rest. Open Graph, Twitter Cards, JSON-LD, alles aus einer einfachen Datenstruktur generiert.

Das sind keine fortgeschrittenen Features. Das ist Standard. Ein Meta-Description-Feld ist buchstäblich ein Textfeld und eine Datenbankspalte. WordPress hatte 20 Jahre Zeit, eins hinzuzufügen. Stattdessen haben sie AI Connectors gebaut.

Custom Fields, die tatsächlich funktionieren

WordPress hat "Custom Fields." Das sind Key-Value-Paare. Dieselbe Implementierung von 2005. Du bekommst ein Textfeld für einen Key und ein Textfeld für einen Value. Das war's.

Repeater Fields? Installier ACF. Relationship Fields? Installier ACF. Flexible Content Layouts, mit denen Redakteure strukturierte Seiten bauen können? Installier ACF, oder Pods, oder Meta Box.

Die Antwort auf "Wie baue ich strukturierte Inhalte in WordPress?" lautet seit zwanzig Jahren "Installier ein Third-Party-Plugin." Und das ist auch 2026 noch so.

Statamic liefert ein komplettes Content-Modeling-System. Du definierst Blueprints mit Fieldsets, Repeatern, Relations, Bedingungen, Validierung. Alles eingebaut. Craft CMS macht dasselbe. Selbst Directus, das im Grunde eine Datenbank-UI ist, gibt dir vollständige Kontrolle über dein Content-Schema ohne Plugins.

WordPress hat einen anderen Weg gewählt. Sie haben Gutenberg gebaut, einen Block-Editor, der versucht ein Page Builder zu sein, anstatt die Datenschicht darunter zu reparieren. Du kannst Blöcke auf einer Seite herumschieben, klar. Aber das zugrundeliegende Content-Modell ist immer noch ein einzelner HTML-Blob in der post_content-Spalte. Keine Struktur. Keine abfragbaren Felder. Nur ein großer String.

Export, Import, Migration: Die Basics, über die niemand spricht

Versuch mal, eine WordPress-Seite mit den eingebauten Tools von einem Host zum anderen zu verschieben.

Der native WordPress-Export gibt dir eine XML-Datei. Sie enthält deine Beiträge, Seiten und einige Metadaten. Die Mediathek ist nicht zuverlässig enthalten. Plugin-Einstellungen nicht. Theme-Anpassungen nicht. Widget-Konfigurationen nicht. Bei komplexen Seiten mit Custom Post Types und ACF-Feldern bricht er oft komplett zusammen.

Was machen also alle? Sie installieren All-in-One WP Migration oder Duplicator. Plugins, die im Grunde deine gesamte WordPress-Installation und Datenbank zippen, weil der eingebaute Export so unzureichend ist.

Eine Website von einem Server auf einen anderen zu verschieben ist kein Sonderfall. Es ist eine der häufigsten Operationen in der Webentwicklung. Ghost hat einen One-Click-Export, der dir eine saubere JSON-Datei mit allem gibt. Du importierst sie auf einer anderen Ghost-Instanz und es funktioniert. Strapi und Directus sind API-first, deine Inhalte sind also immer über Standard-REST- oder GraphQL-Endpoints zugänglich und portabel.

WordPress gibt es seit 2003. Das Export-Tool produziert immer noch XML, das an komplexen Inhalten erstickt.

Security, Bildoptimierung und die Plugin-Steuer

Keine eingebaute Firewall. Keine eingebaute Zwei-Faktor-Authentifizierung. Kein eingebautes Login Rate Limiting. Keine eingebaute WebP- oder AVIF-Konvertierung.

Ich habe einen ganzen Guide über WordPress Security Plugins geschrieben. Diesen Guide sollte es nicht geben müssen. Grundlegende Sicherheitshärtung sollte Teil der Plattform sein.

Hier ist das Paradox, das mich wahnsinnig macht. WordPress hat ein Plugin-Problem, und die Lösung für jedes Problem ist ein weiteres Plugin. Deine Seite ist unsicher? Installier ein Security-Plugin. Deine Bilder sind zu groß? Installier ein Bildoptimierungs-Plugin. Deine Seite ist langsam? Installier ein Caching-Plugin.

Aber jedes Plugin, das du installierst, fügt Code hinzu, der bei jedem Seitenaufruf läuft. Jedes Plugin wird von einem anderen Entwickler gepflegt, mit unterschiedlichen Coding-Standards, unterschiedlichen Update-Zyklen und unterschiedlichen Sicherheitspraktiken. Jedes Plugin ist eine potentielle Schwachstelle. Jedes Plugin kann mit jedem anderen Plugin in Konflikt geraten.

Du installierst buchstäblich Security-Plugins, um dich vor den Sicherheitsrisiken zu schützen, die durch zu viele Plugins entstehen. Die Schlange frisst ihren eigenen Schwanz.

WordPress 6.5 hat gerade erst Plugin Dependencies als Feature eingeführt. In 2024. Nach zwei Jahrzehnten, in denen Plugins von anderen Plugins abhingen, ohne ein formales System dafür.

Es geht nicht darum, KI zu hassen. Es geht um Prioritäten.

Ich will fair sein. Die KI-Features in WordPress 7.0 sind keine schlechten Ideen. MCP-Integration ist zukunftsorientiert. Der Connectors Screen ist ein vernünftiger Ansatz, um API-Keys für KI-Anbieter zu verwalten. Auto-Alt Text für Bilder ist wirklich nützlich für Barrierefreiheit.

Aber Prioritäten zählen. Wenn du eine begrenzte Anzahl an Engineering-Stunden hast und AI Connectors statt eingebautem Caching wählst, machst du eine Aussage darüber, was dir wichtig ist. Wenn du mehrsprachige Unterstützung auf "vorläufig v7.2" schiebst, während du einen MCP Adapter auslieferst, sagst du deinen internationalen Nutzern, wo sie auf der Rangliste stehen.

WordPress betreibt über 40% des Webs. Ein riesiger Anteil davon sind kleine Unternehmen, Blogs und persönliche Projekte von Leuten, die keine Entwickler sind. Diese Leute interessieren sich nicht für AI Connectors. Sie wollen, dass ihre Seite schnell, sicher und einfach umzuziehen ist, wenn ihr Hoster die Preise erhöht. Sie wollen bei Google gefunden werden, ohne ein Plugin zu installieren, das 200KB JavaScript mitbringt.

Das WordPress-Ökosystem hat eine ganze Industrie geschaffen, die Probleme löst, die WordPress selbst lösen sollte. Hosting-Unternehmen verkaufen "Managed WordPress", weil unverwaltetes WordPress ein Minenfeld ist. Plugin-Unternehmen verkaufen Caching, weil WordPress nicht cached. SEO-Plugin-Unternehmen verkaufen Meta-Description-Felder, weil WordPress kein Textfeld zum Beitragseditor hinzufügen will.

Das ist ein Teil davon, warum ich nach 6 Jahren aufgehört habe, WordPress zu nutzen. Nicht weil die Technologie schlecht ist. Weil die Prioritäten falsch sind.

Ich brauche WordPress nicht, um mit Claude zu konkurrieren. Ich brauche es, um mit Ghost zu konkurrieren.

Du willst eine Website, die keine 23 Plugins braucht, um das zu tun, was ein CMS von Haus aus können sollte? Lass uns reden darüber, etwas zu bauen, das ohne Klebeband funktioniert.