--- title: "Agent-Readiness-Plugin für WordPress: Ab sofort verfügbar" description: "Das Plugin, das eine WordPress-Site vollständig agent-ready macht, gibt es ab sofort in zwei Distributionen. Eine kommerzielle Variante mit automatischen Updates und ein Open-Source-Mirror auf GitHub unter GPL-2.0" date: 2026-05-06 modified: 2026-05-06 author: "Eberhard Lauth" url: "https://netzkundig.com/blog/agent-readiness-plugin-fur-wordpress-fuer-wordpress/" featured_image: "https://netzkundig.com/wp-content/uploads/2026/05/nk-wp-agent-ready-wordpress-plugin.jpg" categories: - name: "AI" url: "https://netzkundig.com/thema/ai/" - name: "Code" url: "https://netzkundig.com/thema/code/" - name: "WordPress" url: "https://netzkundig.com/thema/code/wordpress/" language: "de-DE" --- # Agent-Readiness-Plugin für WordPress: Ab sofort verfügbar In meinem [letzten Beitrag](https://netzkundig.com/blog/wordpress-agent-ready-machen/) habe ich beschrieben, warum WordPress-Sites agent-ready werden sollten und welche Bausteine dafür nötig sind. Seit Mitte April läuft das dazu passende Plugin im Pilotbetrieb auf ausgewählten Sites, darunter auf netzkundig.com selbst. Heute folgt der nächste Schritt: Das Toolkit steht ab sofort auch als Open-Source-Variante auf GitHub zur Verfügung. Damit gibt es nun zwei Wege, das Plugin einzusetzen. Eine kommerzielle Distribution mit automatischen Updates über die Server von Netzkundig, gedacht für produktive Sites mit minimalem Wartungsaufwand. Und eine Open-Source-Variante zum Klonen, Forken, Auditieren oder Selbstbetrieb. Der Code ist in beiden Fällen identisch. Das Repository ist unter [github.com/netzkundig/wp-ai-agent-readiness](https://github.com/netzkundig/wp-ai-agent-readiness) erreichbar. Wer den Code prüfen, einsehen oder selbst anpassen möchte, findet dort die vollständige Quelltextbasis und die zugehörige Dokumentation, einschließlich des Filter-Katalogs in `DOCS/FILTERS.md`. Issues und Pull Requests sind willkommen. Akzeptierte Beiträge fließen in die Upstream-Codebasis zurück und werden mit der nächsten offiziellen Version ausgeliefert, also auch in der kommerziellen Variante. ## Der Unterschied zwischen den beiden Distributionen Inhaltlich ist der Code in beiden Distributionen identisch. Der Unterschied liegt in der Art der Auslieferung und im Update-Mechanismus. Die kommerzielle Distribution läuft über meine Server und liefert automatische Updates direkt an die WordPress-Installation meiner Kund:innen. Wer eine produktive Site mit geringem Wartungsaufwand betreiben möchte, ist hier richtig. Für diese Variante gibt es Support, eine geprüfte Release-Pipeline und die Sicherheit, dass neue Standards zeitnah nachgezogen werden. Die Open-Source-Variante auf GitHub kommt ohne aktivierte Auto-Updates. Wer sie nutzen möchte, klont das Repository, lädt eine Release-ZIP herunter oder bindet einen eigenen Update-Server ein. Dafür enthält das Plugin die Konstante `NK_AIART_UPDATE_URI`, die in der `wp-config.php` auf eine eigene JSON-Manifest-URL zeigen kann. Damit lässt sich die Aktualisierung an die jeweilige Infrastruktur anpassen, ob über GitHub Releases, einen privaten Mirror oder eine Pipeline im internen Netzwerk. ## Was das Plugin abdeckt Die Module sind aus dem vorhergehenden Beitrag bereits bekannt. Hier eine kompakte Zusammenfassung für Leserinnen und Leser, die direkt in diesen Beitrag eingestiegen sind. Das Modul **Markdown Negotiation** beantwortet Anfragen über drei Triggerpfade, also Accept-Header, `.md`-URL-Variante und Query-Parameter. Es liefert einen aufgeräumten Markdown-Body mit YAML-Frontmatter, kümmert sich um konditionelle GET-Requests und nutzt einen Transient-Cache, damit jede Seite nur einmal pro Änderungszyklus aufbereitet werden muss. **Content Signals** setzen einen `Content-Signal`-Header auf jeder Antwort und ergänzen die robots.txt um eine konsistente Policy. Eine Registry mit 21 bekannten Bots und einer Custom-Sektion erlaubt feingranulare Disallow-Pfade je Bot, statt nur eine pauschale Ja-oder-Nein-Entscheidung anzubieten. Der **llms.txt-Generatorerzeugt** die Datei `/llms.txt` und auf Wunsch eine ausführlichere `/llms-full.txt` in drei Modi: automatisch, manuell oder nach Post-Type. Bestehende Yoast-SEO-Einstellungen werden dabei nicht überschrieben. Die **Well-Known-Endpunkte** umfassen `/.well-known/api-catalog`, `/.well-known/agent-skills/`, `/.well-known/mcp.json` und `/.well-known/ai.txt`. Jeder Endpunkt lässt sich einzeln aktivieren und liefert bei Deaktivierung einen sauberen 404-Status, statt eine leere oder irreführende Antwort zu erzeugen. **Link-Header** nach RFC 8288 werden über Pfadmuster geroutet. Drei Preset-Bundles für „Standard agent discovery“, „API site“ und „Documentation“ decken die häufigsten Fälle ab. Parallel dazu fügt das Plugin in jeden singulären Beitrag im HTML-Head ein `` ein, was sowohl von isitagentready.com geprüft als auch von vielen Agenten direkt ausgewertet wird. **Diagnostics-Modul** führt Loopback-Selbsttests durch und zeigt das Ergebnis als gewichteten Score zusammen mit Probe-Karten je Feature. Damit lässt sich die eigene Konfiguration ohne externes Werkzeug prüfen, was vor allem in Staging-Umgebungen hinter einer Firewall hilfreich ist. Der **Per-Block-Opt-Out** bleibt das Alleinstellungsmerkmal gegenüber den meisten anderen Lösungen. Im Gutenberg-Editor erscheint in jedem Block ein Toggle „Disable in Markdown“. Markierte Blöcke samt ihrer Inner Blocks verschwinden ausschließlich aus der Markdown-Antwort, bleiben aber für menschliche Besucher sichtbar. Über allem liegt das **Filter-First-Prinzip**. Jede Ausgabe läuft durch `apply_filters()`, was Themes und Begleit-Plugins erlaubt, das Verhalten ohne Eingriff in den Plugin-Kern anzupassen. Den vollständigen Filter-Katalog dokumentiert die Datei `DOCS/FILTERS.md` im Repository ([Zur Filter-Doku](https://github.com/netzkundig/wp-ai-agent-readiness/blob/main/DOCS/FILTERS.md)). ## Wann welche Variante sinnvoll ist Für viele Unternehmensumgebungen ist die kommerzielle Variante der pragmatischere Weg. Sie kommt mit Auto-Updates, einer geprüften Release-Pipeline und einem klaren Support-Ansprechpartner. Wer das Plugin auf einer Kundensite einsetzt und vertraglich sauber dokumentieren möchte, wer für Wartung, Sicherheits-Patches und Anpassung an neue Standards zuständig ist, sollte diesen Weg wählen. Die Open-Source-Variante richtet sich primär an Entwickler:innen, die den Code lesen, prüfen und gegebenenfalls in eigenen Setups anpassen wollen oder an Betreiber:innen von WordPress-Multisites oder spezialisierten Hosting-Setups, die ihre eigene Update-Logik fahren und den Plugin-Lebenszyklus in eine vorhandene Pipeline integrieren möchten. In allen anderen Fällen lassen sich beide Wege auch kombinieren. Wer die kommerzielle Variante einsetzt, kann den Quellcode auf GitHub zur Code-Review heranziehen, ohne Lizenz oder Konfiguration zu wechseln. Die Codebasis ist dieselbe. ## Was als nächstes ansteht Die Codebasis wurde für die Veröffentlichung sauber dokumentiert, mit Beiträgen aus der Pilotphase. Auf der Roadmap stehen jetzt Erweiterungen rund um Standards, die im Bereich Agent-Readiness gerade entstehen oder reifen. Web Bot Auth zur Authentifizierung legitimer Agenten gehört dazu, ebenso erweiterte MCP-Server-Cards mit weiteren Capability-Profilen und ausgebaute Skill-Definitionen für Anwendungen, die über reines Lesen hinausgehen. ## Test der eigenen Site Wer noch nicht weiß, wie die eigene Site bei Agent-Readiness steht, kann das in zwei Minuten unter [isitagentready.com](https://isitagentready.com/)prüfen. Das Ergebnis liefert eine erste Standortbestimmung. Mit dem Plugin lässt sich daraus in den meisten Fällen ein Wert zwischen achtzig und neunzig Prozent erreichen, abhängig von Theme, Hosting und individueller Konfiguration. Für Pilotinstallationen, individuelle Audits und die Einrichtung in komplexeren Setups stehe ich wie gewohnt zur Verfügung. Der Kontakt geht direkt [weiter unten](#kontakt). Wer lieber selbst loslegt, findet auf GitHub alles Notwendige, um in einer Stunde eine erste Konfiguration aufzusetzen und das Ergebnis nachvollziehbar zu prüfen.