Am 2. Juli 2026 hat das WordPress-Core-Team einen Merge Proposal veröffentlicht: WordPress 7.1 soll drei neue „Core Abilities“ bekommen – standardisierte Lese-Schnittstellen, über die KI-Agenten deine Website verstehen können. Klingt technisch, betrifft aber direkt die Frage, wie sichtbar und automatisierbar deine Website in den nächsten Jahren ist. Hier ist die Einordnung ohne Buzzwords.
Worum geht es konkret?
Mit WordPress 6.9 kam die Abilities API: ein System, mit dem WordPress-Funktionen als klar definierte, rechtegeprüfte „Fähigkeiten“ registriert werden – mit sauberem Eingabe- und Ausgabeschema. In 6.9 war das Set noch klein. Der neue Vorschlag erweitert es in 7.1 um drei Lese-Fähigkeiten:
- core/read-settings – liest freigegebene Website-Einstellungen (z. B. Titel, Permalinks),
- core/read-content – liest Inhalte aus freigegebenen Inhaltstypen, einzeln oder als Liste,
- core/read-users – liest Benutzerdaten, streng nach den Rechten des angemeldeten Nutzers.
Das Ziel laut Core-Team: Eine Standard-WordPress-Installation soll „agent-readable“ werden. Ein KI-Agent kann dann Konfiguration, Inhalte und Nutzer einer Website strukturiert abfragen – statt HTML zu parsen oder auf Umwegen zu raten.
Was heißt „KI-lesbar“ in der Praxis?
Das Beispiel aus dem Proposal selbst: Du gibst deinem KI-Client den Auftrag „Erstelle einen Entwurf mit dem Titel ‚Juni-Zusammenfassung‘, der alle meine Juni-Beiträge zusammenfasst und verlinkt.“ Damit das funktioniert, muss der Agent wissen, welche Beiträge es gibt – genau das liefern die Read Abilities als „Werkzeuge“ für den AI Client, der seit WordPress 7.0 im Core steckt.
Dazu kommt die Brücke nach außen: Über den MCP Adapter (Model Context Protocol) können auch externe KI-Tools wie Claude oder ChatGPT-Agenten diese Fähigkeiten als Tools nutzen. Und sobald sich Standards wie WebMCP stabilisieren, sollen dieselben Abilities direkt für Agenten im Browser verfügbar werden.
Ich arbeite selbst täglich so: Diese Website wird zu großen Teilen über MCP-Verbindungen gepflegt – von Inhalten bis zu ganzen Seiten. Wie das aussieht, zeigt die Case Study zur Content-Automatisierung mit KI.
Warum das für dich als Unternehmen relevant ist
Drei Gründe:
- Sichtbarkeit in der KI-Suche: Immer mehr Kunden fragen ChatGPT, Gemini oder Perplexity statt Google. Eine Website, die Agenten strukturiert lesen können, ist für diese Systeme leichter zu erfassen. Das ergänzt, was ich im Beitrag GEO für KMU beschrieben habe.
- Automatisierung: Wiederkehrende Aufgaben – Inhalte zusammenfassen, Entwürfe vorbereiten, Daten abfragen – lassen sich mit Agenten erledigen, die direkt und sicher mit deiner Website sprechen.
- Standard statt Insellösung: Bisher baut jedes Plugin seine eigene KI-Anbindung. Core Abilities schaffen einen gemeinsamen Standard, auf dem das ganze Ökosystem aufbaut. Das reduziert langfristig Kosten und Wildwuchs.
Wie sicher ist das?
Die berechtigte Frage. Das Sicherheitsmodell des Vorschlags ist konservativ:
- Alle drei Fähigkeiten sind read-only – sie können nichts verändern.
- Einstellungen und Inhaltstypen müssen per Opt-in (show_in_abilities) freigegeben werden. Nichts ist automatisch sichtbar, Geheimnisse bleiben außen vor.
- Jede Fähigkeit prüft die Rechte des aktuellen Nutzers – wer etwas nicht sehen darf, sieht es auch über einen Agenten nicht.
Trotzdem gilt: KI-Anbindungen erweitern die Angriffsfläche einer Website. Das Core-Team weist selbst darauf hin, dass Schutz vor Prompt Injection nicht Teil der Abilities ist – dafür sind die konsumierenden Agenten verantwortlich. Wer KI-Funktionen aktiviert, sollte seine Website also erst recht sauber warten und überwachen.
Der Zeitplan
WordPress 7.1 ist für den 19. August 2026 angekündigt. Beta 1 startet am 15. Juli, der Release Candidate folgt am 5. August. Ob die drei Read Abilities es final in den Release schaffen, entscheidet sich im Merge-Prozess – der Vorschlag ist offiziell, aber noch nicht beschlossen. Für 7.2 sind bereits die passenden Schreib-Fähigkeiten (core/manage-content & Co.) angedacht.
Was du jetzt tun solltest
- Nichts überstürzen: Für die meisten Websites ändert sich am 19. August erstmal nichts Sichtbares. Es gibt keinen Grund, jetzt hektisch Plugins zu installieren.
- Updates ernst nehmen: Wer auf alten WordPress-Versionen festhängt, verpasst diese Entwicklung komplett. Eine saubere Wartungsroutine ist die Grundlage.
- Chancen prüfen: Wenn du wiederkehrende Content- oder Datenprozesse hast, lohnt sich ein Blick darauf, was sich mit KI-Anbindung automatisieren lässt – mehr dazu unter KI-Infrastruktur & Automatisierung.
Fazit
WordPress baut sich Schritt für Schritt zur agentenfähigen Plattform um – kontrolliert, mit Opt-in und Rechteprüfung statt Wildwest. Für Unternehmen heißt das: Die eigene Website wird vom statischen Schaufenster zur strukturierten Datenquelle, die KI-Systeme verstehen und nutzen können. Wer seine Inhalte und seine Technik jetzt sauber aufstellt, profitiert doppelt – bei der Sichtbarkeit und bei der Automatisierung.
Du willst wissen, was das konkret für deine Website bedeutet? Sprich mit mir über dein Projekt.
Häufige Fragen zu den Core Abilities
Kann eine KI damit meine Website verändern?
Nein. Die für 7.1 vorgeschlagenen Fähigkeiten sind ausschließlich lesend. Schreib-Fähigkeiten sind erst für spätere Versionen geplant – mit zusätzlichen Schutzmechanismen.
Sieht eine KI dann alle meine Daten?
Nein. Es gilt ein Opt-in-Prinzip: Nur explizit freigegebene Einstellungen und Inhaltstypen sind überhaupt abfragbar. Zusätzlich greifen die normalen WordPress-Benutzerrechte – ein Agent sieht nie mehr als der Nutzer, in dessen Namen er agiert.
Muss ich dafür etwas tun?
Erstmal nicht. Die Fähigkeiten kommen mit dem normalen WordPress-Update. Relevant wird es, wenn du KI-Clients oder MCP-Verbindungen aktiv nutzen willst – dann lohnt sich eine geplante Einrichtung statt Trial-and-Error.
Was ist der Unterschied zur REST API?
Die REST API ist für Anwendungen mit Zeitdruck gebaut (z. B. den Block-Editor). Abilities sind für Agenten und Workflows gedacht: Sie beschreiben Absichten („Inhalt lesen“) statt technischer Details, können andere Daten freigeben als REST und erlauben perspektivisch auch aufwändigere Abfragen, die REST bewusst vermeidet.