記事一覧に戻る
We Raised Our Own Site's Agent Readiness — Taking zench-aine.io from Level 1 to Level 2 (Hands-On)

We Raised Our Own Site's Agent Readiness — Taking zench-aine.io from Level 1 to Level 2 (Hands-On)

ZenChAIne·
AI AgentCloudflareWeb Standards

Introduction

In part one, we explained what Cloudflare's Agent Readiness Score — "Lighthouse for AI agents" — actually checks. This hands-on follow-up does the real thing: we scan our own site zench-aine.io, fix the failing checks, and raise its level by one, with code and before/after scores included.

Unlike a desk explainer, doing it for real reveals that the single most important step is judgment: deciding which checks genuinely apply to your site. This article is the raw record of that judgment and the implementation.

For context, zench-aine.io is built on Next.js 15 (App Router) combined with Velite, an MDX-based content library. The code below assumes that stack, but the thinking applies to any framework.

Key takeaways

  • The first scan of zench-aine.io came back at Level 1 "Basic Web Presence" (score 29).
  • We focused on just two checks that genuinely matter for a content site — Content Signals (robots.txt) and llms.txt.
  • A re-scan moved us to Level 2 "Bot-Aware" (score 36), and revealed the requirement for the next level too.

What Did the Scan Show?

The first scan returned Level 1 "Basic Web Presence," score 29. Here is the result of feeding https://zench-aine.io into isitagentready.com.

First scan of zench-aine.io (Level 1)
First scan of zench-aine.io (Level 1)

By category, the passes and gaps were cleanly split:

CategoryResult
Discoverabilityrobots.txt ✅ / sitemap ✅ / Link headers ✅ / DNS-AID ❌
Content AccessibilityMarkdown negotiation ❌
Bot Access ControlAI bot rules ✅ / Content Signals ❌ / Web Bot Auth ⚪
Protocol DiscoveryAPI catalog, OAuth, MCP, Agent Skills — 0/7 (all ❌)
CommerceAll neutral ⚪ (not applicable)

robots.txt and sitemap were already in place, so Discoverability looked good. Protocol Discovery was a clean sweep of failures, and Commerce was not applicable (neutral).

Which Checks Should We Fix?

This is the most important judgment in practice. The short version: we did not chase every check — we picked only the ones that genuinely matter for a content site.

As covered in part one, Protocol Discovery (MCP, OAuth, API catalog) is for systems that expose APIs or services to agents, and is generally unnecessary for a media site that just serves articles. Commerce is for e-commerce sites, so it is not applicable to us with nothing to sell. Force-filling those would be "gaming the score" in a way that doesn't match the site's reality.

So we checked the tool's "requirement for the next level." The scan result includes a nextLevel field, and the only requirement to reach Level 2 "Bot-Aware" was Content Signals — a sure win. Alongside it, we also decided to add llms.txt, which is purely valuable for a media site.

Adding Content Signals to robots.txt

The first fix is Content Signals. Content Signals is a mechanism for declaring content-usage preferences in a machine-readable way inside robots.txt, across three axes: search, ai-input (use in AI answer generation), and ai-train (use for model training).

As an owned media site, our policy is "welcome citation in search and AI answers, but disallow use for model training." Next.js's metadata API (app/robots.ts) can't emit a Content-Signal: line, so we generate robots.txt directly with a Route Handler.

typescript
// app/robots.txt/route.ts
const ROBOTS_TXT = `# robots.txt for zench-aine.io
User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /
Disallow: /api/
Disallow: /admin/
Disallow: /private/
 
User-Agent: GPTBot
Allow: /
 
User-Agent: Google-Extended
Allow: /
 
User-Agent: PerplexityBot
Allow: /
 
Sitemap: https://zench-aine.io/sitemap.xml
`
 
export const dynamic = 'force-static'
 
export function GET() {
  return new Response(ROBOTS_TXT, {
    headers: { 'Content-Type': 'text/plain; charset=utf-8' },
  })
}

The existing app/robots.ts (metadata version) and app/robots.txt/route.ts (Route Handler version) cannot coexist. When you need lines like Content Signals that the standard robots metadata can't express, consolidate on the Route Handler.

Providing an AI Index with llms.txt

Next is llms.txt. llms.txt is a Markdown "table of contents for AI" placed at the site root, compensating for the fact that an LLM cannot ingest a whole site and which can make articles easier to discover and cite. Build it dynamically from the article metadata Velite generates, and it updates automatically every time you add a post.

typescript
// app/llms.txt/route.ts
import { posts } from '#site/content'
 
const BASE_URL = 'https://zench-aine.io'
export const dynamic = 'force-static'
 
export function GET() {
  const jaPosts = posts
    .filter((p) => p.published && p.locale === 'ja')
    .sort((a, b) => (a.date < b.date ? 1 : -1))
 
  const lines = jaPosts
    .map((p) => `- [${p.title}](${BASE_URL}/media/${p.slug}): ${p.description}`)
    .join('\n')
 
  const body = `# ZenChAIne\n\n> An owned media outlet covering the frontier of AI and blockchain.\n\n## Articles\n\n${lines}\n`
  return new Response(body, {
    headers: { 'Content-Type': 'text/plain; charset=utf-8' },
  })
}

Note that llms.txt is not one of the Agent Readiness Score's 21 checks (it doesn't move the score directly). We implemented it anyway because there is a real, practical benefit: helping AI search discover our articles. It's a good reminder that score and real value don't always coincide.

What Did the Re-Scan Show? Level 2

After deploying to production (zench-aine.io) and re-scanning, we rose to Level 2 "Bot-Aware," score 36. Content Signals flipped to pass, satisfying the Bot Access Control category.

Re-scan of zench-aine.io (Level 2)
Re-scan of zench-aine.io (Level 2)

A single check (a few lines in robots.txt) raised our level by one — that is the power of identifying the checks that actually apply to you. The tool also showed that the requirement for the next Level 3 "Agent-Readable" is Markdown content negotiation — serving clean Markdown instead of HTML to agents that send Accept: text/markdown. That's our next realistic target.

FAQ

Q. Why didn't you try to fill in every check?

A. Because the 21 checks include items that don't apply depending on the site. Protocol Discovery is for API/service-providing systems and Commerce is for e-commerce — neither fits a content site's reality. When raising the score becomes the goal itself, you just end up adding endpoints nobody uses.

Q. How should I decide the Content Signals values?

A. It depends on your site's policy. You declare which uses you allow across search, ai-input, and ai-train. We prioritize citation in AI search, so we set search=yes, ai-input=yes, while avoiding training use with ai-train=no. An e-commerce or members' site would choose differently.

Q. Why add llms.txt if it doesn't affect the score?

A. Because score and real value are different things. llms.txt isn't among the 21 checks, but it can help AI search and agents discover and cite your articles. Rather than chasing the score alone, choose the work that's valuable for your goals.

Conclusion

What mattered most in practicing the Agent Readiness Score wasn't the code — it was the judgment to identify the checks that genuinely apply to your own site. With two targeted fixes — Content Signals and llms.txt — zench-aine.io rose from Level 1 (score 29) to Level 2 (score 36).

Our next target is Level 3 "Agent-Readable," i.e., Markdown content negotiation — a good fit for a media site and helpful for token efficiency, so it's worth tackling next. Raising our site's "agent readiness" one step at a time, through the score — at ZenChAIne, we share efforts like these with the hands-on detail intact.

If you haven't read part one (the explainer and analysis), see What Is Cloudflare's Agent Readiness Score as well.

References