back to writing
July 15, 2026

How I improved by my site’s AI-Readiness score from 51 to 86

I’m a tiny bit obsessed with iterating my site to agenty-ready and web-optimized perfection. That’s why I’ve spent many sessions running my site against specification.website‘s checklist and fixing what it...

I’m a tiny bit obsessed with iterating my site to agenty-ready and web-optimized perfection.

That’s why I’ve spent many sessions running my site against specification.website‘s checklist and fixing what it found either by improving my site’s structure via the theme, or updating my Make My Site Agent Ready plugin. I started running my site against isitagentready.com too, but my score there was very sad:

51 out of 100. Blah.

It flagged three issues:

  1. No Link response headers. The site had a <link rel="alternate" type="text/markdown"> tag in the page head pointing agents at the markdown version of each page, but nothing in the actual HTTP headers – which matters because some agents read headers without ever parsing the HTML body.
  2. No Content Signals in robots.txt. This is a newer, still-draft convention: a Content-Signal: line that tells a crawler, separately, whether it can index your content for search, use it to answer a live question, or train a model on it – three separate permissions instead of one blanket rule.
  3. No DNS for AI Discovery. This one wants DNS records published under a _agents subdomain, pointing agents at services before they even make an HTTP request, backed by DNSSEC.

I asked Claude to analyze these issues to see if they’re worth adding to my plugin, and if so, to go ahead.

Adding Link Response Headers

Claude said we should add the first two in my Make My Site Agent-Ready plugin that I mentioned above. Adding the Link headers was mechanical: every page now sends a header pointing at a machine-readable catalog of what the site exposes, plus the Agent Skills index, plus the markdown version of whatever page you’re on. This is based on one line of logic shared between the header and the existing head tag.

Adding Content Signals

Before writing the Content-Signal line, I had to decide what it should actually say. Three settings could be added:

  1. Allow search indexing
  2. Allow live AI retrieval
  3. Allow training.

The first two were an obvious yes, but I wasn’t sure about the third one, so I consulted with Claude: does letting AI train on my writing help me get recognized as a thought leader by AI, which is one of the goals of this website.

The answer was no. Training compresses everything into statistical weights rather than a source list, so it doesn’t preserve attribution – a model trained on a blog post has no way to turn around and cite that post by name. Getting cited actually happens through a different mechanism entirely: an assistant reading my site live at the moment someone asks a question and linking back to it, which is exactly what the second setting already covers. And essentially no model provider reads this particular signal yet anyway, so today it’s a stated preference for a future landscape that hasn’t arrived, with zero practical effect either way.

So I configured the plugin as follows: yes to search and live AI input, no to training. I can always opt in to training later, but I can’t opt-out once a model has already trained on something.

Why we didn’t build the DNS for AI Discovery feature

DNS for AI Discovery is irrelevant for my how my site is set up, and too risky. It demands a DNS zone change at my registrar, and also asks you to advertise services like an MCP server or an agent-to-endpoint under specific subdomains. I don’t have either, at least not publicly, so publishing those records would have advertised something that doesn’t exist.

The DNSSEC part of the requirement requires you to sign the zone but if you miss pasting the resulting record at the registrar, and validating resolvers stop trusting the domain entirely, that could end up taking the whole site down for anyone whose DNS checks that chain. Yikes. Not worth the risk.

That’s a lot of downside for one line item that’s marked as “optional” in the underlying spec anyway.

Score boosted ✅

The site’s score increased from 51 to 86, and my Make My Site Ready plugin now has four new capabilities: a machine-readable catalog of what the site exposes, a published skill file teaching agents how to use the markdown endpoints, headers advertising both, and an explicit, considered answer to what AI is and isn’t allowed to do with what I write here.

The remaining points are DNS records I’m choosing not to publish, so we’re good for now 💪

filed under tagged

Other posts

all posts
Security headers matter, so I created a plugin to improve this site’s score
Dries Buytaert, creator of Drupal and co-founder of Acquia, built a tool called headers.dev that analyzes the HTTP security headers on any website and gives it a score. I came...
I wanted to be able to do more with AI on my site, so I gave Claude WP REST API access – with limitations
A conversation about why WordPress core still ships so few AI abilities and the limitations they have got me thinking: why am I making my site fully dependent on Abilities...