Der agentische Wandel: wie KI-Agenten Plattformwahl, Design und Sicherheit bei WordPress verändern

#Wie KI-Agenten eine CMS-Plattform auswählen

Die Plattformwahl war früher eine menschliche Entscheidung von Inhabern, Agenturen und CTOs. Andy Peatling, der 17 Jahre bei Automattic gearbeitet hat und heute Miles entwickelt, einen KI-Design-Agenten für WordPress, argumentiert, dass sich dieser Weg schließt. In Ideas for WordPress in an agentic world (14. September 2026) schreibt er, dass ein Agent eine Plattform aus seinen Trainingsdaten oder über eine Websuche auswählt und eine einfache Website in etwa 30 Sekunden aufsetzen kann. Sein Fazit ist unmissverständlich: “Wenn WordPress nicht gewählt wird, wird das Projekt nicht wachsen.” (eigene Übersetzung)

Er macht drei konkrete Vorschläge:

• Zwei verbindliche Agenten-Journeys. WordPress sollte zwei vollständige Abläufe definieren und sich öffentlich auf sie verpflichten, die ein Agent von Anfang bis Ende ausführen kann, zum Beispiel eine Website, die komplett von einem Coding-Agenten gebaut wird, von der Erstellung über die Veröffentlichung bis zum Hosting. Als Infrastruktur, die diese Abläufe verbinden soll, nennt er Abilities, MCP, Agent Skills, Theme-Metadaten und Plugin-Metadaten, mit festgelegten Berechtigungen, Freigaben, Rollback-Punkten und Audit-Trails.
• Öffentliche Benchmarks. Den Erfolg von Agenten auf diesen Abläufen messen, festhalten, wann und warum Agenten WordPress bei der Plattformwahl berücksichtigen oder ausschließen, und native Agentenfähigkeiten mit Tools wie WP-bench messen.
• Eine zentrale Agenten-Ressource auf WordPress.org. Erklären, wo WordPress die richtige Wahl ist und wo nicht, aktuelle APIs klar kennzeichnen und ältere zurückstufen sowie die Dokumentation so strukturieren, dass Agenten sie verarbeiten können.

Dieselbe Frage zog sich durch eine Folge von The WP Minute mit Alex Panagis, Brian Coords, Andy Peatling und Mike McAlister, How do we get agents to use WordPress. Laut den Shownotes empfehlen Agenten, die eine Website bauen sollen, nicht immer WordPress, WordPress braucht klarere Vorgaben dazu, wie Agenten es nutzen sollen, und die Abilities API könnte zur Grundlage für agentisches WordPress werden.

#Was die Beta des Elementor MCP-Servers in WordPress kann

Elementor hat seine MCP-Beta am 15. September 2026 gestartet. Sie stellt Funktionen zum Bauen von Websites über WordPress-Abilities bereit, sodass ein MCP-Client Seiten als native Elementor-Strukturen erstellen und bearbeiten kann, statt rohes HTML zu liefern, das jemand in ein Template einfügen muss. Als Clients nennt Elementor Claude Code, Claude Desktop, Codex und Cursor sowie jedes andere Tool, das MCP spricht.

Die Ankündigung listet neun Fähigkeiten auf:

• atomare Seiten und Layouts in einem Schritt bauen,
• bestehende atomare Seiten und Layouts bearbeiten oder neu gestalten,
• Klassen und Variablen anlegen, anwenden und neu ordnen, Hover-Zustände setzen und responsive Breakpoints anpassen,
• Theme-Bestandteile wie Header, Footer, Archive und Popups mit Anzeigebedingungen anlegen und verwalten,
• Komponenten platzieren, befüllen oder anlegen,
• dynamische Daten wie Beitragsfelder, benutzerdefinierte Felder und Taxonomien anbinden,
• eigene Widgets und Admin-Oberflächen erstellen,
• Inhalte in großen Mengen aktualisieren, Fehler debuggen und SEO-Lücken schließen,
• auf jede mit der WordPress Abilities API registrierte Ability zugreifen, auch auf solche aus Plugins wie WooCommerce, Yoast, WPForms, Jetpack und ACF.

Die letzten drei erfordern Angie, ein separates Elementor-Plugin. Die Beta hat feste Grenzen. Der Zugang ist auf Website-Administratoren beschränkt, die Verbindung gilt jeweils für eine Website, und alles, was der MCP erzeugt, wird als Entwurf gespeichert und nicht veröffentlicht. Für die Einrichtung sind der Beta-Tester-Kanal und der Atomic Editor nötig. Elementor erzeugt ein Anwendungspasswort und setzt es in einen Einrichtungs-Prompt für das KI-Tool ein; alternativ ist eine manuelle Konfiguration möglich. Pro-Elemente erfordern weiterhin einen Pro-Tarif, und der Standard-Editor bleibt für alle unverändert, die keine Verbindung herstellen.

#Wie Human Made Block Runner Gutenberg-Blöcke validiert

Block Runner ist ein Open-Source-CLI und eine JavaScript-Bibliothek von Human Made, lizenziert unter GPL-2.0-or-later. Die README beschreibt es als Tool, das “unterstütztes HTML in native Gutenberg-Blöcke umwandelt und das erzeugte Markup mit den Gutenberg-Paketen prüft, die der WordPress-Editor verwendet” (eigene Übersetzung). Das Paket wurde am 24. Juni 2026 erstmals auf npm veröffentlicht; Version 0.9.10 erschien am 4. Oktober 2026.

Das Problem, das es angeht, kennt jeder, der generiertes Markup in den Editor eingefügt hat: Markup, das der Editor nicht erkennt, landet in einem Custom-HTML-Block oder in einem Block, der eine Wiederherstellung verlangt. Block Runner bietet vier Wege, die in der README dokumentiert sind:

• convert wandelt HTML mit eingebauten Regeln in Block-Markup um,
• assemble baut Seiteninhalt aus einem Blockbaum, den ein Agent geplant hat,
• author erzeugt den Quellcode eines wiederverwendbaren registrierten Blocks, etwa eines Hinweisblocks, für ein Plugin,
• validate und fix prüfen bestehendes Block-Markup oder bringen es in die kanonische Form.

Das Paket ruft kein KI-Modell auf. Ein externer Agent kann ein Design interpretieren und Block Runner einen strukturierten Plan übergeben; deterministischer Code setzt das Ergebnis dann zusammen und validiert es. Ein mitgeliefertes Skill für Coding-Agenten wird mit npx --no-install block-runner skill --install installiert und nach .agents/skills/block-runner und .claude/skills/block-runner geschrieben. Die einfache Konvertierung braucht Node.js (20.19+, 22.13+ oder 24+) und keine WordPress-Website, kein Docker und keinen Agenten.

Die README benennt die Grenzen klar. Nicht unterstützte Strukturen können mit Warnungen als Custom HTML bestehen bleiben, und --strict lässt den Lauf bei Fallback-Blöcken und nicht aufgelösten Medien fehlschlagen. Im Wortlaut: “Gültiges Markup beweist weder visuelle Treue noch Kompatibilität mit jeder Website.” (eigene Übersetzung) Das Ergebnis muss also weiterhin in der Ziel-Installation von WordPress geprüft werden. Wie Blöcke, Muster und Templates zusammenspielen, erklärt unser Leitfaden zu Gutenberg-Blöcken und Full Site Editing.

#Welche Lücken WordPress 7.1.1 behoben hat und wer sie gemeldet hat

WordPress 7.1.1 ist am 17. September 2026 als Wartungs- und Sicherheitsrelease erschienen: 17 Fehlerbehebungen im Core, 19 im Block-Editor und 11 Sicherheitsfixes. Die Ankündigung empfiehlt, sofort zu aktualisieren, und gibt an, dass die Sicherheitsfixes, wo nötig, in alle Zweige zurückportiert werden, die noch Sicherheitsfixes erhalten. Die vollständige Liste mit Nennungen, wie veröffentlicht:

Anthropic werden zwei der elf Probleme zugeschrieben, pwn.ai teilt sich eine Nennung mit Paulos Yibelo. Beide Anthropic-Probleme setzen ein angemeldetes Konto voraus, eines davon nur mit der Rolle Mitarbeiter. Das ist für Agenten-Setups relevant: Ein mit einer Website verbundener Agent handelt als WordPress-Benutzer, also entscheidet die Rolle, die Sie ihm geben, welche dieser Fehlerklassen er auf einer nicht gepatchten Installation erreichen könnte. Unser Leitfaden zur WordPress-Sicherheitshärtung behandelt Rollen, Updates und Monitoring.

#WordPress-KI-Event in Faro im Oktober 2026

Die portugiesische WordPress-Community (Comunidade Portuguesa de WordPress) veranstaltet den WordPress Day for AI Faro 2026 am 24. Oktober 2026 im Hotel AP Eva Senses in Faro. Laut der Event-Website läuft er von 09:00 bis 18:00 Uhr mit 100 Plätzen, und die Vorträge sind auf Portugiesisch und Englisch.

Es gibt zwei Tracks. Der Entwicklungs-Track behandelt KI-gestützte Entwicklung, Programmierwerkzeuge, APIs, Automatisierung, LLM-Integrationen, MCP und Entwicklungs-Workflows für WordPress. Der Business-Track richtet sich an Inhaber, Agenturen und Fachleute und behandelt Produktivität, Workflow-Automatisierung und Kundenerlebnis.

#Was die WordPress Abilities API ist und wie man eine Ability registriert

Die Abilities API ist die Schicht, auf der Elementor aufbaut. Ihr serverseitiger Teil ist mit WordPress 6.9 erschienen. Eine Ability ist eine benannte Funktionseinheit in der Form namespace/ability-name, registriert mit wp_register_ability() in einem Callback am Hook wp_abilities_api_init. Jede Ability gehört zu genau einer Kategorie, die mit wp_register_ability_category() an wp_abilities_api_categories_init registriert wird.

Pflichtargumente sind label, description, category, output_schema, execute_callback und permission_callback. input_schema ist optional und nur nötig, wenn die Ability Eingaben annimmt. Beide Schemas sind JSON Schema, und Eingaben, die die Validierung nicht bestehen, erreichen den Permission-Callback nie. Das Array meta enthält in annotations Hinweise zum Verhalten: readonly, destructive und idempotent.

add_action( 'wp_abilities_api_init', function () {
	wp_register_ability( 'my-plugin/get-site-title', array(
		'label'               => __( 'Get site title', 'my-plugin' ),
		'description'         => __( 'Returns the title of this site.', 'my-plugin' ),
		'category'            => 'site',
		'output_schema'       => array( 'type' => 'string' ),
		'execute_callback'    => fn() => get_bloginfo( 'name' ),
		'permission_callback' => fn() => current_user_can( 'read' ),
		'meta'                => array(
			'annotations'  => array( 'readonly' => true ),
			'show_in_rest' => true,
		),
	) );
} );

Zwei Standardwerte sollten Sie kennen. Abilities werden nicht über REST bereitgestellt, solange show_in_rest nicht auf true gesetzt ist, und die REST-Endpunkte unter /wp-json/wp-abilities/v1 verlangen einen angemeldeten Benutzer und beachten den Permission-Callback jeder Ability. Der Core selbst registriert in 6.9 drei Abilities: core/get-site-info, core/get-user-info und core/get-environment-info. Das eigenständige GitHub-Repository wurde nach der Übernahme in den Core archiviert. Ausgearbeitete Beispiele für Abilities in redaktionellen Abläufen finden Sie unter KI-Workflows in WordPress mit der Abilities API.

#Wie der WordPress MCP Adapter Abilities für MCP-Clients bereitstellt

Der MCP Adapter ist das offizielle WordPress-Paket, das Abilities in MCP-Tools, -Ressourcen und -Prompts umwandelt. Version 0.7.0, erschienen am 2. Oktober 2026, macht ihn zu einem Canonical Plugin. Plugins sollten in ihrem Header Requires Plugins: mcp-adapter deklarieren, statt eine Kopie mitzuliefern; mitgelieferte Kopien funktionieren weiterhin, protokollieren aber einen Deprecation-Hinweis.

Aktualisierung, 28. Oktober 2026. Aktuell ist Version 0.7.1 vom 16. Oktober 2026. Sie bringt eine Schritt-für-Schritt-Anleitung für Website-Betreiber mit: KI-Client verbinden, Anwendungspasswort anlegen, Verbindung testen und typische Probleme beheben. Fragt ein Client nach einer Ability, die es nicht gibt, schlägt der Adapter passende verfügbare Abilities vor oder verweist den Client auf die Discovery.

Abilities sind standardmäßig privat. Eine Ability erreicht MCP nur, wenn meta.public (oder meta.mcp.public) true ist. Der Standardserver unter /wp-json/mcp/mcp-adapter-default-server stellt statt eines Tools pro Ability drei Meta-Tools bereit: mcp-adapter-discover-abilities, mcp-adapter-get-ability-info und mcp-adapter-execute-ability. Der Agent listet auf, was verfügbar ist, holt das benötigte Schema und führt dann aus. So bleibt die Antwort von tools/list bei drei Schemas, egal wie viele Plugins Abilities registrieren. Ein eigener Server, der am Hook mcp_adapter_init angelegt wird, macht es umgekehrt und listet jede ausgewählte Ability als eigenes Tool.

Es gibt zwei Wege, einen Client zu verbinden:

• STDIO über WP-CLI: wp mcp-adapter serve --server=mcp-adapter-default-server --user=admin. Das Flag --user bestimmt, als welcher WordPress-Benutzer die Berechtigungsprüfungen laufen; ohne es ist die Sitzung nicht angemeldet.
• HTTP über den Proxy @automattic/mcp-wordpress-remote, der sich mit einem Anwendungspasswort authentifiziert.

Die Sicherheit arbeitet in zwei Schichten. Ein Transport-Permission-Callback schützt den gesamten Server und ist standardmäßig is_user_logged_in(), und jede Ability führt weiterhin ihren eigenen permission_callback aus. Der Adapter unterstützt die MCP-Protokollrevisionen 2025-11-25 und 2026-07-28; ältere Clients werden über das Schema 2025-11-25 bedient.

#Was die MCP-Spezifikation von Tools und Hosts verlangt

Die Spezifikation des Model Context Protocol definiert JSON-RPC-2.0-Nachrichten zwischen Hosts (den LLM-Anwendungen), Clients (Konnektoren innerhalb des Hosts) und Servern (Diensten, die Kontext und Fähigkeiten bereitstellen). Server können Ressourcen, Prompts und Tools anbieten. Die aktuelle Revision 2026-07-28 definiert zwei Standard-Transporte: stdio für einen vom Client gestarteten Unterprozess und Streamable HTTP, bei dem jede Nachricht ein POST an einen einzigen Endpunkt ist.

Das Kapitel zu Tools legt die Regeln fest, auf die es ankommt, wenn ein Agent in WordPress schreibt. Es sollte immer ein Mensch eingebunden sein, der Tool-Aufrufe ablehnen kann. Server müssen alle Tool-Eingaben validieren, Zugriffskontrollen umsetzen, Aufrufe in der Rate begrenzen und Ausgaben bereinigen. Clients sollten bei sensiblen Operationen eine Bestätigung einholen, Tool-Eingaben vor dem Aufruf anzeigen, Timeouts setzen und die Tool-Nutzung protokollieren. Tool-Annotationen sind als nicht vertrauenswürdig zu behandeln, sofern sie nicht von einem vertrauenswürdigen Server stammen.

Die WordPress-Bausteine lassen sich auf diese Regeln abbilden. Die JSON-Schema-Validierung der Abilities API deckt die Eingabeprüfung ab, permission_callback die Zugriffskontrolle, die Annotationen readonly und destructive zeigen dem Client, welche Aufrufe eine Bestätigung brauchen, und dass Elementor nur Entwürfe speichert, hält einen Menschen zwischen Agent und veröffentlichter Seite. Der Adapter bringt keinen Rate Limiter mit (sein Observability-Leitfaden listet nur einen Fehlercode ability_rate_limit, den eine Ability zurückgeben kann), also bleibt die Ratenbegrenzung Sache der Hosting-Schicht oder der Ability selbst.

#Wie MCP Server Cards für die Auffindbarkeit funktionieren

Agenten müssen einen Server auch finden, bevor sie sich verbinden können. SEP-2127, das als Erweiterung den Status Final erreicht hat, definiert MCP Server Cards: statische Metadatendokumente, die Identität, Transport-Endpunkte und unterstützte Protokollversionen eines Remote-Servers beschreiben. Eine Card kann unter jeder nicht reservierten URI liegen, wobei streamable-http-url/server-card als empfohlener Ort reserviert ist. Für die Auffindbarkeit auf Domainebene kann ein unter /.well-known/ai-catalog.json veröffentlichter AI Catalog auf die Cards verlinken oder sie einbetten.

Cards lassen Tools, Ressourcen und Prompts bewusst weg. Das SEP begründet das damit, dass das, was ein Server bereitstellt, je nach Benutzer, Sitzung und Konfiguration variieren kann, weshalb Clients den Live-Aufruf tools/list verwenden müssen. Cards dürfen keine Zugangsdaten oder benutzerspezifischen Daten enthalten, und sie sind optional: Server ohne Card funktionieren weiter. Unter WordPress ist die Endpunkt-URL des Adapters die naheliegende Basis für eine Card. Unser Leitfaden zum WPPoland MCP-Live-Server zeigt einen öffentlichen Read-only-Server in der Praxis.

#Wie man WordPress-Websites für KI-Agenten und GEO baut

wppoland.com läuft auf Astro 7 auf Cloudflare Pages, mit Schema.org-Daten, die auf jeder Seite aus dem Frontmatter erzeugt werden. Unsere Arbeitsregel lautet: Eine Seite soll für eine Maschine so leicht lesbar sein wie für einen Menschen. Für WordPress-Websites ist der dokumentierte Weg kurz: Abilities mit ehrlichen Schemas und Annotationen registrieren, nur die gewünschten über den MCP Adapter öffentlich machen, dem Agenten einen WordPress-Benutzer mit der engsten Rolle geben, die für die Aufgabe reicht, und Inhaltsänderungen als Entwürfe halten, bis ein Mensch sie freigibt. Dieselben strukturierten Daten dienen auch der Generative Engine Optimization (GEO). Wann der gehostete WordPress.com-Agent und MCP write reichen und wann ein self-hosted Adapter nötig ist, steht in WordPress.com Agent und MCP write.

Wenn Sie dabei Unterstützung möchten, sehen Sie sich unsere MCP-Server-Entwicklung an oder fragen Sie ein Audit an.