In my previous post I described why WordPress sites should become agent-ready and which building blocks are needed to get there. The matching plugin has been running in pilot mode on selected sites since mid-April, including netzkundig.com itself. Today comes the next step: the toolkit is now also available as an open-source variant on GitHub.
That gives you two ways to use the plugin. A commercial distribution with automatic updates via the Netzkundig servers, intended for production sites with minimal maintenance overhead. And an open-source variant for cloning, forking, auditing, or self-hosting. The code is identical in both cases.
The repository is available at github.com/netzkundig/wp-ai-agent-readiness. Anyone wanting to inspect, review, or adapt the code will find the full source base and the accompanying documentation there, including the filter catalog in DOCS/FILTERS.md. Issues and pull requests are welcome. Accepted contributions flow back into the upstream codebase and ship with the next official release — including the commercial variant.
The difference between the two distributions
The code in both distributions is identical. The difference lies in the delivery channel and the update mechanism.
The commercial distribution runs through my servers and pushes automatic updates directly to the WordPress installations of my clients. If you want to operate a production site with low maintenance overhead, this is the right path. This variant comes with support, a vetted release pipeline, and the assurance that new standards are picked up promptly.
The open-source variant on GitHub ships without active auto-updates. To use it, clone the repository, download a release ZIP, or wire in your own update server. For that purpose the plugin includes the constant NK_AIART_UPDATE_URI, which can point to your own JSON manifest URL in wp-config.php. That way the update flow can be adapted to your specific infrastructure — whether through GitHub Releases, a private mirror, or a pipeline on an internal network.
What the plugin covers
The modules will look familiar to anyone who read the previous post. Here’s a compact summary for readers who landed directly on this one.
The Markdown Negotiation module handles requests through three trigger paths: the Accept header, the .md URL variant, and a query parameter. It returns a clean Markdown body with YAML frontmatter, takes care of conditional GET requests, and uses a transient cache so each page is processed only once per change cycle.
Content Signals set a Content-Signal header on every response and add a consistent policy to robots.txt. A registry of 21 known bots plus a custom section allows fine-grained disallow paths per bot, instead of the blanket yes-or-no decision the older logic offers.
The llms.txt generator produces the /llms.txt file and, on demand, a more detailed /llms-full.txt, in three modes: automatic, manual, or by post type. Existing Yoast SEO settings are not overwritten in the process.
The well-known endpoints include /.well-known/api-catalog, /.well-known/agent-skills/, /.well-known/mcp.json, and /.well-known/ai.txt. Each endpoint can be enabled individually and returns a clean 404 status when disabled, instead of producing an empty or misleading response.
Link headers per RFC 8288 are routed through path patterns. Three preset bundles for “Standard agent discovery”, “API site”, and “Documentation” cover the most common cases. In parallel, the plugin injects <link rel="alternate" type="text/markdown"> into the HTML head of every singular post — both checked by isitagentready.com and used directly by many agents.
The diagnostics module runs loopback self-tests and presents the result as a weighted score together with probe cards per feature. That way, you can verify your own configuration without an external tool, which is especially helpful in staging environments behind a firewall.
The per-block opt-out remains the unique selling point compared to most other solutions. The Gutenberg editor shows a “Disable in Markdown” toggle on every block. Flagged blocks together with their inner blocks disappear only from the Markdown response, while remaining visible to human visitors.
Above all of this sits the filter-first principle. Every output runs through apply_filters(), which lets themes and companion plugins adjust behavior without touching the plugin core. The full filter catalog is documented in DOCS/FILTERS.md in the repository (to the filter docs).
When each variant makes sense
For many enterprise environments, the commercial variant is the more pragmatic path. It comes with auto-updates, a vetted release pipeline, and a clear support contact. If you’re deploying the plugin on a client site and want a clean contractual record of who is responsible for maintenance, security patches, and adaptation to new standards, this is the way to go.
The open-source variant is aimed primarily at developers who want to read, review, and possibly adapt the code in their own setups, and at operators of WordPress multisites or specialized hosting setups who run their own update logic and want to integrate the plugin lifecycle into an existing pipeline.
In all other cases, the two paths can also be combined. Anyone using the commercial variant can pull up the source code on GitHub for review without changing license or configuration. The codebase is the same.
What’s next
The codebase has been cleanly documented for release, with input from the pilot phase. The roadmap now turns to extensions around standards that are currently emerging or maturing in the agent-readiness space. Web Bot Auth for authenticating legitimate agents is one of them, alongside extended MCP server cards with additional capability profiles and expanded skill definitions for applications that go beyond pure reading.
Test your own site
If you don’t yet know where your own site stands on agent-readiness, you can check it in two minutes at isitagentready.com. The result delivers an initial reference point. With the plugin in place, a score between eighty and ninety percent is typically achievable, depending on theme, hosting, and individual configuration.
For pilot installations, individual audits, and setup in more complex environments, I’m available as usual. Contact details are just below. If you’d rather get started yourself, GitHub has everything needed to put together an initial configuration in about an hour and verify the result in a transparent way.
