I don’t only want my site to be agent-ready; I also want it to be generally healthy and optimized for the web overall. So I have a monthly process running where Claude reviews my entire site against the full specification.website checklist and reports back the gaps it found, and what can and should be improved.
What the site already had going for it
When I started running this process, quite a lot was already in place: doctype, lang attribute, charset, viewport, and title tag; meta description, canonical URL, Open Graph and Twitter card tags were populated; favicons and app icons were there too, missing only an SVG variant. robots.txt was there, and the sitemap resolved through a 301 to sitemap_index.xml. AI crawlers (GPTBot, ClaudeBot, Anthropic-AI, PerplexityBot) were explicitly allowed, llms.txt and llms-full.txt were live and well-curated, and every page had its own markdown endpoint: a rel=”alternate” link paired with a matching /page.md URL. A lot of this was thanks to my Make My Site Agent-Ready plugin (learn about how it improved my site’s agent-readiness score).
Structured data held up too. A Yoast-generated graph covers Person, WebSite, WebPage, and BreadcrumbList, plus Event schema for talks. security.txt was present with a contact and an expiry date. HTTPS redirected properly over HTTP/2. HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy were all sent. Brotli compression was on, 404s returned a real 404 status instead of a soft one, and the skip link jumped straight to #main-content, with nav, main, and footer all carrying proper landmarks. Images lazy-loaded as WebP with a real srcset, and the cookie banner and the meta robots tag were both exactly where they should be.
Most of it came from work done for other reasons like improving performance and security headers.
What was missing
Four gaps were found:
- The page head had no RSS feed discovery link, even though the feed lives at /feed/ and is linked in the footer, so a feed reader or an agent checking for a link rel=”alternate” tag had no way to find it without already knowing the URL.
- There were no theme-color or color-scheme meta tags either: dark mode works fine once the page’s own JavaScript runs, but before that, the browser chrome and any native form controls have no signal about which palette the page is using.
- HSTS was set, but without includeSubDomains, and that one isn’t mine to fix directly since it comes from Cloudflare, which Elementor manages on my behalf.
- One podcast cover image in the media library had no alt text at all, an empty string that had sat there since it was uploaded.
Claude pulled the theme zip from my project folder, added add_theme_support(‘automatic-feed-links’) to functions.php, added the theme-color and color-scheme meta tags to header.php using the site’s actual palette (#FAFAF8 light, #0D0D0D dark, straight from main.css).
Claude fixed the alt text for me through the WordPress MCP connection we have in place, combined with my Abilities plugin that gives it actual capabilities in my site.
What I’m doing about it
Now I have a new monthly routine that runs against the live site itself, analyzing the categories that change that aren’t necessarily agent-specific and would make it into my Make My Site Agent Ready plugin’s features: foundations, accessibility, security, performance, resilience.
These changes aren’t being added to the plugin since its whole identity is agent and crawler exposure, and folding in accessibility and security scanning would lose focus. They get added on the theme level, and I do try to make sure to add new learnings to my WP Site Builder Skill so new sites would be have this infrastructure in place from day one.
