A 74 on the agent-readiness scoreboard, and two checks worth failing

The arithmetic is worth doing before the argument. Essential 59, recommended 12.6, and a 2.4 bonus add to exactly the reported 74 ^[2][1]. Of the 26 points missing, 21 come from the essential band ^[2], and the bonus was under half of what was available ^[4]. So the story is not the headline number, it is which essential checks a site that had already shipped robots allowlists, a sitemap, llms.txt, llms-full.txt, JSON-LD, feeds and markdown siblings ^[6] still could not pass.

Read the ranked list and the answer is unflattering in a boring way. A 404 that returned the right status code but offered no route out ^[7]. No contact page and no privacy page ^[12]. Organization schema with a name and a description but no address and no contactPoint ^[13]. A homepage whose only nested headings were buried inside card links, so the outline read as flat ^[8]. None of that is agent-specific work. It is the same hygiene a human auditor would have flagged five years ago, now priced in a scoreboard.

Content efficiency is the one check that behaves like a budget rather than a checklist. Readable text was 4.83 percent of the homepage HTML against a bar of 5 ^[14]. Hold the prose constant and clearing it means deleting 3.4 percent of the markup ^[3]. That is a check you can pass by shipping less framework output, which is a strange incentive to hand a publication.

Then the two the author refused. The grader looked for "promptway developer resources" and found nothing ^[10], and it looked for MCP, which the site writes about but does not run ^[15]. is-agentic's own methodology says checks that do not apply are excluded ^[3], yet a magazine was still measured against a product-company shape. Publishing a manifest for a server that does not exist would have scored; it would also have lied to the first agent that tried to connect. The honest version of that fix is what actually shipped: a real developer surface page naming the tool the site does have, with an OpenAPI document and an RFC 9727 catalog ^[16], plus a section in llms.txt that says outright the site is the wrong fetch for a model API, an MCP server, OAuth, webhooks or unlabeled AI copy ^[17].

The genuinely technical repair was content negotiation. An Accept header asking for text/markdown came back as text/html, with a Vary that listed Next.js RSC headers and never mentioned Accept ^[9]. The fix parses Accept in proxy.ts, skips RSC requests, rewrites markdown-preferring GETs to the catch-all renderer, sets Vary: Accept, and returns 406 to a client that will take neither format ^[19]. That is a caching correctness bug as much as an agent feature: a shared cache told Vary the wrong thing was serving one representation for two request types.

One operational detail undercuts the scoreboard as a feedback loop. Reports cache for six hours, so rescanning straight after a deploy can hand you a stale number ^[4]. Verification runs on curl instead: the status line must be 404, and the markdown request must answer with content-type: text/markdown and a Vary that includes Accept ^[21]. The grader is the prompt. The shell is the test.