Der neue WordPress-Core-Vorschlag zur Erweiterung der Abilities API klingt zunächst nach Entwicklerstoff. Für österreichische Website-Betreiber, Agenturen und KMU steckt darin aber ein praktischer Hinweis: Audits, KI-Agenten und Automatisierungen werden nur dann wirklich nützlich, wenn sie WordPress nicht raten lassen, sondern sauber auslesen dürfen, was eine Website tatsächlich enthält.
Am 2. Juli 2026 wurde im WordPress-Core-Blog ein Merge Proposal für WordPress 7.1 veröffentlicht. Vorgeschlagen werden drei neue, rein lesende Core-Abilities: core/read-settings, core/read-content und core/read-users. Sie sollen WordPress für geprüfte Workflows besser maschinenlesbar machen, ohne sofort Schreibrechte zu öffnen. Genau dieser Unterschied ist wichtig: Es geht nicht um einen KI-Autopiloten, der beliebig Seiten ändert, sondern um strukturierte Leserechte für Einstellungen, Inhalte und Nutzerinformationen, soweit Berechtigungen und Opt-in-Regeln das zulassen.
Für AdSimple ist der Anlass spannend, weil viele Datenschutz-, Consent-, SEO- und Content-Fragen heute an derselben Stelle scheitern: Das Audit sieht nur die öffentliche Website, nicht aber den tatsächlichen WordPress-Zustand dahinter. Ein Scanner kann Skripte, Cookie-Banner und sichtbare Texte prüfen. Ein Agent kann Content analysieren. Doch ohne kontrollierten Zugriff auf Content-Typen, Einstellungen, Rollen und ausgewählte Metadaten bleibt viel Handarbeit übrig.
Warum Abilities mehr sind als eine neue API
Die Abilities API wurde in WordPress 6.9 eingeführt und beschreibt Funktionen in einer Form, die Menschen, Plugins, Automatisierungstools und KI-Agenten verstehen können. Eine Ability ist dabei nicht einfach ein beliebiger Endpunkt. Sie hat einen Namen, eine Beschreibung, definierte Eingaben, definierte Ausgaben und Berechtigungsregeln. Das macht sie für Agenten-Workflows interessanter als klassische Admin-Screens oder selbst gebaute Sonderlösungen.
WordPress 7.0 brachte den AI Client als Infrastruktur für KI-Integrationen in den Core. Der aktuelle Vorschlag schließt daran an: Wenn Agenten in WordPress sinnvoll arbeiten sollen, brauchen sie Werkzeuge, mit denen sie Grundfragen beantworten können. Welche Beiträge gibt es? Welche Seite ist die Startseite? Welche Nutzerrollen sind sichtbar? Welche Einstellungen sind bewusst für solche Workflows freigegeben?
Das ist auch aus Sicherheits- und Compliance-Sicht der richtige Ausgangspunkt. Wer eine Website prüfen lässt, sollte zuerst lesen, vergleichen und dokumentieren, bevor irgendein Tool Inhalte verändert. Für österreichische Unternehmen heißt das: Ein WordPress-Audit kann näher an echte Arbeitsabläufe rücken, ohne dass Administrator-Zugänge breit geteilt oder unkontrollierte Schreibrechte vergeben werden müssen.
Was die vorgeschlagenen Core-Abilities lesen sollen
core/read-settings soll Einstellungen zurückgeben, die ausdrücklich für Abilities freigegeben wurden. Der Vorschlag nennt dafür ein Opt-in-Prinzip, ähnlich dem bekannten show_in_rest: Nicht jede registrierte Einstellung wird automatisch maschinenlesbar. Für Website-Audits ist das wichtig, weil Einstellungen oft technische, organisatorische oder potenziell sensible Informationen enthalten.
core/read-content soll Inhalte aus Post Types auslesen, die für Abilities freigegeben sind. Die Standardantwort soll schlank bleiben; teurere oder sensiblere Felder müssten ausdrücklich angefordert werden. Praktisch könnte das später helfen, Content-Bestände, Landingpages, Pflichtseiten, Blogartikel, Medienbezüge und interne Veröffentlichungsprozesse strukturierter zu prüfen.
core/read-users soll Nutzer einzeln oder als Sammlung auslesen können, aber nur mit jenen Feldern, die der aktuelle Nutzer laut bestehenden WordPress-Berechtigungen sehen darf. Genau hier wird die Trennlinie zwischen hilfreichem Audit und unnötiger Datenfreigabe sichtbar: Ein SEO-Check braucht selten E-Mail-Adressen aller Benutzer. Ein Rollen- und Berechtigungsaudit kann dagegen wissen müssen, ob zu viele Personen Administratorrechte haben.
Der Nutzen für Website-Audits
Für KMU in Österreich liegt der Nutzen weniger in der API selbst als im künftigen Audit-Muster. Heute laufen viele Prüfungen über Screenshots, Exportdateien, manuelle Checklisten und temporäre Admin-Accounts. Das funktioniert, ist aber fehleranfällig. Sobald WordPress Kerninformationen standardisiert und lesbar bereitstellt, können Audits gezielter werden.
Ein Datenschutz-Audit kann zum Beispiel prüfen, ob die tatsächlich verwendeten Formulare, Tracking-Dienste, eingebetteten Medien und Content-Prozesse zur Datenschutzerklärung passen. Der AdSimple Datenschutz Generator hilft bei der sauberen Erstellung und Aktualisierung der Datenschutzerklärung; ein lesender WordPress-Workflow könnte künftig besser sichtbar machen, welche Website-Bausteine überhaupt dokumentiert werden müssen.
Ein Consent-Audit kann öffentliche Skripte mit internen Einstellungen und Content-Bereichen abgleichen. Wenn eine Website neue Einbettungen, Marketing-Pixel oder Formular-Plugins nutzt, sollte das nicht erst bei einer Beschwerde auffallen. Der AdSimple Consent Manager bleibt dabei die operative Ebene für Einwilligungen und Dienste-Kategorien; WordPress-Abilities könnten die Bestandsaufnahme strukturieren.
Auch für SEO ist der Ansatz relevant. Ein Audit muss nicht nur wissen, welche URLs öffentlich erreichbar sind. Es sollte auch verstehen, welche Inhalte redaktionell gepflegt werden, welche Post Types existieren, wo alte Kampagnen-Landingpages liegen und welche Inhalte nie aktualisiert wurden. In Kombination mit SEO-Beratung und Online-Marketing-Arbeit kann daraus ein besserer Content- und Technik-Plan entstehen.
Warum Leserechte trotzdem Governance brauchen
Read-only klingt harmlos, ist aber kein Freibrief. Wer Nutzerlisten, interne Entwürfe, Einstellungen oder unveröffentlichte Inhalte ausliest, verarbeitet möglicherweise personenbezogene Daten oder vertrauliche Unternehmensinformationen. Deshalb sollte jedes Unternehmen vor einem Agenten- oder Audit-Zugriff klären, wer den Zugriff erhält, welche Datenfelder wirklich gebraucht werden und ob der Zweck intern dokumentiert ist.
Der WordPress-Vorschlag erwähnt mehrere Schutzlinien: Abilities sollen Berechtigungsprüfungen verwenden, Einstellungen und Post Types sollen opt-in sein, und für spätere Schreibfähigkeiten ist ein getrenntes Muster geplant. Gleichzeitig wird klar gesagt, dass Prompt-Injection-Schutz nicht Aufgabe der Ability-Ergebnisse selbst ist. Agenten und Modelle müssen die Rückgaben als Daten behandeln, nicht als Befehle. Für professionelle Workflows ist das ein zentraler Punkt.
In der Praxis heißt das: Keine beliebigen KI-Plugins auf Produktivsystemen installieren, nur weil sie “Agent-ready” versprechen. Zuerst braucht es ein Staging-System, ein minimales Rollenmodell, Logging, eine klare Trennung zwischen Lesen und Schreiben und eine Entscheidung, welche Custom Post Types, Felder oder Plugin-Einstellungen überhaupt sichtbar werden dürfen.
Prüfpunkte für österreichische WordPress-Teams
Wer eine WordPress-Website betreibt oder betreut, muss nicht auf WordPress 7.1 warten, um sinnvoll vorzubereiten. Der erste Schritt ist ein nüchternes Inventar: Welche Plugins, Post Types, Formulare, Tracking-Dienste, Benutzerrollen und Content-Prozesse gibt es wirklich? Der Beitrag zu KI-Tools im Inventar zeigt denselben Grundgedanken aus der AI-Act-Perspektive: Ohne Bestand gibt es keine belastbare Steuerung.
Zweitens sollten Teams prüfen, welche Daten ein externer Audit-Dienst überhaupt sehen darf. Bei Datenschutz- und Consent-Fragen ist weniger oft besser: Ein Tool muss erkennen können, dass ein Newsletter-Formular existiert, aber nicht die Empfängerliste lesen. Es muss erkennen können, welche Content-Typen aktiv sind, aber nicht automatisch alle Entwürfe oder personenbezogenen Metafelder exportieren.
Drittens gehört der Abgleich mit bestehenden Pflichtseiten dazu. Wenn neue Automatisierungstools, KI-Dienste oder Analyseprozesse eingebunden werden, kann das Auswirkungen auf Datenschutzerklärung, Cookie-Consent und interne Dokumentation haben. Für viele Unternehmen ist deshalb das AdSimple Business Paket sinnvoll, weil Datenschutztexte, Consent und laufende Website-Compliance nicht isoliert betrachtet werden.
Viertens sollte jeder Schreibzugriff getrennt diskutiert werden. Der aktuelle WordPress-Vorschlag dreht sich bewusst um Lesen. Management-Abilities für Inhalte, Einstellungen oder Nutzer werden als spätere Schicht genannt. Das ist kein Detail, sondern die zentrale Sicherheitsgrenze. Ein Audit-Agent darf Schwachstellen, Lücken und veraltete Inhalte melden. Ob er sie selbst ändert, ist eine andere Entscheidung und braucht strengere Freigaben.
Was jetzt konkret zu tun ist
Für Website-Betreiber ist die beste Reaktion kein hektisches Update, sondern ein vorbereiteter Audit-Plan. Dokumentieren Sie, welche WordPress-Bereiche regelmäßig geprüft werden sollen: Inhalte, Nutzerrollen, Datenschutztexte, Consent-Setup, SEO-Grundlagen, Formulare und eingebettete Dienste. Legen Sie fest, wer Zugriff geben darf und welche Rolle dafür genutzt wird. Prüfen Sie außerdem, ob Agenten- oder Audit-Tools Ergebnisse exportieren, speichern oder an Dritte übertragen.
Agentenfähiges WordPress wird nicht automatisch sicherer. Es wird dann besser, wenn strukturierte Schnittstellen mit klaren Rollen, minimalen Rechten und sauberer Dokumentation kombiniert werden. Genau darin liegt die Chance des aktuellen Core-Vorschlags: Website-Audits könnten weniger improvisiert, wiederholbarer und näher an echten WordPress-Daten werden.
Für österreichische KMU lohnt sich daher ein einfacher nächster Schritt: WordPress nicht nur als CMS betrachten, sondern als prüfbaren Website-Stack. Wer Datenschutz Generator, Consent Manager, SEO-Audit und interne Rollenpflege zusammen denkt, ist besser vorbereitet, wenn lesende Core-Abilities tatsächlich breiter im WordPress-Alltag ankommen.
