DEV Community: 301ST

How to audit agent readiness when the scanner cannot reach the site

301ST — Fri, 07 Aug 2026 14:00:58 +0000

Cloudflare runs a scanner that grades a domain on how ready it is for AI agents. We went through all twenty one of its checks in July: which four were worth implementing, and why eight of the failures were the right answer.

You point it at your site, get a number, and fix what it flags. Then you try to check the version that actually matters — the staging build with the change in it, the site that has not launched, the pages behind a login — and there is nothing to point the scanner at.

That is not a bug in the scanner. It runs in somebody else's datacenter, so it can only answer for origins that datacenter can reach. Both failure modes are one curl away, checked 4 August 2026:

$ curl -sS -X POST https://isitagentready.com/api/scan \
    -H 'content-type: application/json' -d '{"url":"http://localhost:3000"}'
{"error":"Invalid URL provided"}

$ curl -sS -X POST https://isitagentready.com/api/scan \
    -H 'content-type: application/json' -d '{"url":"https://staging.301.sh"}'
{"url":"https://staging.301.sh","scannedAt":"2026-08-04T18:31:38.462Z",
 "siteError":{"httpStatus":530,"statusText":"","bodyPreview":null,
 "retryAfter":null,"server":"cloudflare"}}

A local address is rejected outright. A host the scanner cannot resolve returns a site error instead of a scorecard. Not a low score: no score.

This matters more than it sounds, because of when you want the answer. Taking this site from Level 1 to Level 5 meant a batch of static files, then a /mcp server, then DNS records, and every one of those steps was a deploy to production first and a scan second. Publish, then find out. For a redirect you would never accept that loop.

The other place to run the checks is the browser, which reaches whatever you can reach. This article is about what that changes, what it costs, and the one rule that decides whether the result is worth anything.

What the browser has that the datacenter does not

Three things, and only the first one is obvious.

Reachability. localhost:5173, a staging host behind a VPN, an internal tool, a domain whose DNS is not public yet. If the tab loads, the audit runs.

A session. Your cookies are attached to the page request, so a site that shows an anonymous visitor a login wall gets graded on what a logged-in client actually receives.

An in-page runtime. Some of what an agent consumes is not an HTTP response at all. WebMCP exposes tools through document.modelContext inside the page, after scripts run. An HTTP probe from outside cannot see it; a script in the page can.

The rule that keeps a browser audit honest

The session is also the trap, and it is worth understanding before you write your own script, never mind which tool you use.

An agent readiness audit fetches two very different classes of thing. There is the page, which may legitimately live behind a login. And there are the machine files — robots.txt, the sitemap, llms.txt, everything under /.well-known/ — which are public by definition, because the client reading them has no account and never will.

Send your session to both and you grade a site that nobody but you can see. A /.well-known/ document that only answers for authenticated requests is a document an agent gets a 401 or a login page from. Passing it in your browser tells you nothing true.

So the split is per request, not per scan:

What is fetched	Credentials	Why
The page itself	`include`	It may be behind a login, and that is the case the external scanner cannot cover
`Accept: text/markdown` on the page	`include`	Same URL, same session, a different representation
`robots.txt`, `sitemap.xml`	`omit`	Public machine files — judge them as a crawler receives them
`llms.txt`, `llms-full.txt`	`omit`	Same
Everything under `/.well-known/`	`omit`	Discovery documents are read by clients with no account

Redirects follow the same logic. The probe follows hops the way a navigation does, each hop attaching its own cookies, and the response records the final URL. A check that passed on a URL you did not request is a check you want to see the address for.

What changes shape when the audit moves into a browser

Moving the audit into the browser is not a free upgrade. It trades one set of blind spots for another, and a tool that hides the trade is worse than the gap.

DNS-AID needs a different question, not a different tool. The extension APIs have no DNS resolver, which is where this write-up originally stopped — wrongly, because a resolver is not what you need. DNS-over-HTTPS is an ordinary fetch, and its JSON answer carries both halves of the verdict: the SVCB records under _index._agents, and AD, the resolver's DNSSEC judgement. That second half matters, because a site publishing records without a validated chain is failed by the scanner too. No token and no account are involved, so the answer is the same for every user. On this site it was the last check to pass — the resolver cache in front of it took about forty minutes of rescans after the records were already live.

WebMCP only works here. In-page detection returns one of three answers, and the third one is the point: detected, confirmed absent, or detection unavailable. A browser without the API, or a page where the injected script could not run, produces "unavailable" — not a failure. Not detectable is not the same as not present, and a check that scores those the same way manufactures a defect.

The MCP Server Card needs five addresses. The audit already flagged this, and it has not improved: the draft-canonical path, the IETF one, the two Cloudflare probes and the de-facto legacy file are all in play because the specification moved and the scanners did not move with it. A checker that probes one of them reports the state of that address, not the state of your server.

Where it breaks: the number is not one number

Three separate reasons a score you read today will not match a score somewhere else.

Not-applicable checks leave the denominator. The composite is passing checks over applicable ones, and a check that cannot apply is excluded rather than failed. Anything the browser genuinely cannot reach — a resolver that will not answer, an in-page runtime that never ran — drops out there and stays in from outside. Same site, same day, different arithmetic.

Cloudflare's own two surfaces disagree. On 30 July 2026 this site read 79 of 100 and Level 5 "Agent-Native" in the web interface, while /api/scan reported Level 4 for the same domain in the same hour. That is stable, not a glitch we caught mid-deploy, and it means "what level are we" has two correct answers depending on which endpoint you ask.

The check matrix itself moves. The MCP Server Card above is one example; DNS-AID is another, resting on an individual Internet-Draft that expires on 28 November 2026, probed through labels that draft does not define. And llms.txt is not a scored check in either tool: the audit measures content negotiation, so a site can publish a complete llms.txt surface and score zero on content accessibility, which is exactly how the July audit opened. What counts as readiness is being decided while you measure it.

The conclusion is not that the score is worthless. It is that the score is only meaningful against itself. What did this origin do yesterday, and what changed after the last deploy. Comparing your number to another site's number compares two arithmetics.

The extension

That is what Agent Readiness Inspector does, and shipping it is the occasion for this article. It is our own extension, it runs 22 checks in the browser against whatever origin the current tab is on, and it is free. Firefox and Edge builds are with the stores for review; today the link above is the one that works.

22 checks, versioned as data. Robots and AI crawler rules, sitemaps, Link headers, Markdown negotiation, Content Signals, Agent Skills, API Catalog, MCP Server Card, OAuth discovery, Web Bot Auth, WebMCP, plus the agentic commerce protocols as an unscored preview. The matrix carries a version and a CI job watches the upstream one for drift, because the section above is a permanent condition rather than a bad month.
Evidence per check. The response that produced the verdict, including the final URL after redirects, and a copy-ready prompt for the fix.
Saved sites and regressions. Scheduled rescans, history, and an alert when a check that used to pass stops passing. Alerts land in a local inbox first; the notification permission is optional and asked for only if you turn it on.
Local-first. Scans, history, settings and alerts live in browser storage. The optional outside comparison uses your own Cloudflare URL Scanner credentials and is off by default.

It is an independent implementation of open web standards, not affiliated with or endorsed by Cloudflare.

Which tool to use

You need	isitagentready.com	Agent Readiness Inspector
A public production site	yes	yes
Staging, localhost, pre-launch, VPN	no, site error or invalid URL	yes, if the tab loads
Pages behind a login	anonymous view only	your session, on the page probes
WebMCP in the page	no	yes, in-page detection
DNS-AID	yes	yes, over DNS-over-HTTPS
The score Cloudflare will quote at you	yes, this is the source	no, a second opinion
Rescan on a schedule, alert on regression	no	yes, on the machine it is installed on

Where the extension stops

It audits the origin of the tab you have open, on the machine it is installed on, while the browser is running. Scheduled rescans go through a bounded batch per cycle, so a watch list is a handful of sites you care about, not an inventory.

For getting a site agent-ready before you publish it, that is the whole job, and it costs nothing. The point where it stops is the point where the question changes from "is this site ready" to "are all of them still ready" — every domain in a portfolio, checked on a schedule that does not depend on someone's laptop being awake, with the alert going to whoever is on call. That is the same boundary the redirect chain recorder runs into, for the same reason, and it is what 301.st does across a portfolio. For the site in front of you, install the extension and read the evidence.

A unique click id on a free Cloudflare redirect, no Worker involved

301ST — Thu, 06 Aug 2026 14:00:21 +0000

You send paid or partner traffic through a redirect and you want every click to arrive at the destination carrying its own identifier — something to join against a conversion later. The obvious tool is a Worker, and for anything that needs to record the click, a Worker is still the only primitive that can. But if all you need is for each click to carry a unique id, there is a way to get one on the free plan, inside a plain Single Redirect, with no code in the request path at all.

We tested it on this site's zone on 30 July 2026. It works, and three of its edges bite. Here is the rule, the measurements, and the traps.

The function that is banned, and the field that is not

The ruleset expression language has uuidv4(). You cannot use it here. The documentation restricts it to rewrite expressions of Transform Rules, and the API enforces that at validation time. This is the live answer to an attempt to put it in a redirect target:

"'concat(\"https://301.sh/?click_id=\", uuidv4(cf.random_seed))' is not a valid
value for target_url because the use of field cf.random_seed is not allowed,
the use of function uuidv4 is not allowed" (code 20083)

Both the function and its seed field are named as forbidden. So the expression language cannot mint randomness in a redirect. What it can do is reuse an identifier Cloudflare has already minted for the request: cf.ray_id, the ray ID that every request through Cloudflare gets, the same value the CF-RAY response header and the dashboard logs show. Its field documentation carries no product restriction, and the validator accepts it in a redirect target.

One rule, measured

A dynamic Single Redirect. The match is ordinary; the target is an expression instead of a static URL:

Expression:  (http.host eq "301.sh" and http.request.uri.path eq "/go")
Target URL:  concat("https://destination.example/?click_id=", cf.ray_id)
Status:      302, preserve query string off

Five requests in a row through that rule, on this zone:

Location: https://301.sh/…/?click_id=a23684c8a885b183-BTS   CF-RAY: a23684c8a885b183-BTS
Location: https://301.sh/…/?click_id=a23684cbfd5a2915-BTS   CF-RAY: a23684cbfd5a2915-BTS
Location: https://301.sh/…/?click_id=a23684cf493d696b-BTS   CF-RAY: a23684cf493d696b-BTS
Location: https://301.sh/…/?click_id=a23684d2ddcf1948-BTS   CF-RAY: a23684d2ddcf1948-BTS
Location: https://301.sh/…/?click_id=a23684d64c0a46d5-BTS   CF-RAY: a23684d64c0a46d5-BTS

Three properties, all visible in the output. Every request got a different id. Each id is identical, byte for byte, to the CF-RAY header of the same response — which means the click id in your destination's logs joins directly against Cloudflare's own logs and dashboard. And the substituted value is the full form with the data center suffix (-BTS here), not just the sixteen hex characters, so parse accordingly.

The preserve_query_string trap

The obvious next step is to keep the campaign parameters the click arrived with. The rule has a switch for that, and combining it with a target expression that already carries a query is where it breaks — measured, not guessed:

Setup	Incoming request	`Location` actually sent
`preserve_query_string: true`	`/go?utm_source=tg&gclid=abc123`	`…/?utm_source=tg&gclid=abc123` — click_id gone
`preserve_query_string: true`	`/go`	`…/` — no query at all, even the target's own
manual merge, flag off	`/go?utm_source=tg&gclid=abc123`	`…/?click_id=a2368ff0…-BTS&utm_source=tg&gclid=abc123`

preserve_query_string does not merge the incoming query into your target. It replaces the target's query entirely — including when the incoming query is empty, which deletes the click_id you just built. The two features are mutually exclusive.

The working form leaves the switch off and does the merge in the expression:

concat("https://destination.example/?click_id=", cf.ray_id, "&", http.request.uri.query)

One cosmetic edge: when the incoming query is empty, the result ends in a bare &. Every query parser we care about ignores it, but it is in the URL, so know it is there before you diff logs.

A 301 will replay yesterday's id

The same rule with status 301 substitutes a fresh ray ID per request at the edge — we measured that too. The problem is in front of the edge: the 301 comes back with no Cache-Control header, and a permanent redirect without explicit freshness information is exactly what browsers are allowed to cache heuristically. A repeat visitor can then be redirected by their own cache, carrying the click id from their first visit, and the request never reaches Cloudflare at all — a duplicate id in your logs and an undercounted click. For this pattern the status you want is 302 or 307.

Where it breaks

Nothing on Cloudflare's side records the id. Redirect is a terminating action in the first request phase; no analytics product ever sees the request, and the rule cannot write anywhere. The id exists only in the Location URL. If the destination does not log its query string, the id evaporates in flight.

A ray ID is an identifier, not a secret. It is unique, but it is not random in any adversarial sense — do not use it as a token that authorizes anything. Join key: yes. Capability: no.

Every fetch gets an id, not every human. Link prefetchers, scanners and preview bots follow redirects too, and each gets its own perfectly valid click id. The rule cannot tell them apart; dedup and filtering stay the destination's job.

The quota is real but roomy. Ten Single Redirect rules per zone on the free plan — per zone, not per account — then 25 on Pro, 50 on Business, 300 on Enterprise (checked 30 July 2026). One tracking rule with a wildcard covers a whole path family, so ten goes further than it sounds. Regular expressions need Business; this pattern does not need them.

When you need more than a stamp

If the destination is yours, this rule plus your own analytics reading click_id may be the whole system: no Worker, no code, nothing to maintain, and the id joins against Cloudflare's logs by construction.

The pattern stops being enough exactly where the attribution article starts: the destination is not yours, or you need the click recorded even when the destination logs nothing, or you run this across a portfolio of domains rather than one zone. Recording at the redirect side is precisely the thing a terminating rule cannot do — that side needs to be operated, which is what 301.st is for: it owns the redirect end, mints and records the id there, and hands the same id downstream, so the join works whether or not the destination cooperates.

Every job your VPS does, and what Cloudflare's free plan does with it

301ST — Wed, 05 Aug 2026 14:00:26 +0000

The fear of leaving a VPS is rarely about any one feature. A small server quietly does ten jobs at once — serves a site, renews certificates, answers DNS, redirects old URLs, runs a cron script, forwards mail, keeps a database, stores uploads, hosts a small API, rate limits a scraper — and the migration question is really ten questions asked as one. Ask "can Cloudflare replace my VPS" and you get advocacy in both directions. Ask it per job and you get answers you can check.

So here is the job by job mapping, every number read off the live documentation on 29 July 2026, with the allowance, the price of lifting it, and the honest rows where the answer is "keep the server." At the end: two systems that already live this way, one of them a production SaaS.

The mapping

VPS job	On the free plan	The allowance	Where it bites
Serve a static site	Workers static assets	asset requests "free and unlimited"; 20,000 files, 25 MiB each	paths routed through Worker code count against 100,000 requests a day
TLS certificates	Universal SSL	90 day certs, auto renewed from 30 days out	proxied hostnames only
DNS	free, with unmetered DDoS protection	200 records per zone (zones created since September 2024; older free zones keep 1,000)	nameservers must move to Cloudflare
Redirects	Single + Bulk Redirects	10 rules; 10,000 bulk URLs	the bulk quota may lag in your account
Cron scripts	Cron Triggers on a Worker	5 per account documented, minimum interval 1 minute	see the next section
Small APIs, dynamic bits	Workers	100,000 requests a day, 10 ms CPU each	computing breaks the CPU budget; serving does not
Key value storage	Workers KV	1 GB, 100,000 reads / 1,000 writes a day	1,000 writes is less than it sounds
A real database	D1 (SQLite)	5 GB, 5 million reads / 100,000 writes a day	daily caps error out, not throttle
Object storage	R2	10 GB, free egress	free tier covers Standard storage only
Mail forwarding	Email Routing	free on all plans; 200 rules, 200 destinations	forwarding, not sending
Firewall, rate limits	WAF free tier	5 custom rules, 1 rate limiting rule	one rate limit means choosing what to protect
Request logs	Workers Logs, Analytics Engine	logs with sampling; 100,000 data points a day	Logpush is Enterprise; Workers Trace Events unlock at $5

Three of those rows deserve more than a cell.

The cron entry that should not fire, and does

The documentation says the free plan allows 5 Cron Triggers per account. The account this blog runs on executes 7, every day, across five distribution Workers — and has for a week, posting to five platforms on schedule. We did not negotiate anything; the limit simply is not enforced against this account.

That is not a loophole to build on. It is the same phenomenon we documented when the Bulk Redirects quota said 10,000 and dashboards enforced 20: Cloudflare's documented numbers and per account entitlements drift apart, in both directions, sometimes for months. Read the number, then test the number. On a migration that habit costs you an afternoon and saves you an architecture built around a limit that was never real for you — or one that assumed an allowance you do not actually have.

Certificates are the quiet argument

On a VPS the TLS routine was a yearly renewal, or a certbot timer. That era is ending on a schedule: since 15 March 2026 the CA/Browser Forum rules cap public certificates at 200 days, in March 2027 the cap drops to 100 days, and in March 2029 to 47 days with domain validation reuse down to 10 days. Manual renewal stops being a viable habit and becomes an incident generator — a portfolio of parked domains on a VPS meets that wave at its first short renewal this autumn.

Behind the proxy, Universal SSL already issues 90 day certificates and renews them starting 30 days out, which sits below every step of that schedule. Of everything in the table, this is the row where the free plan is not a cheaper version of the VPS job but a categorically better one.

The ceiling is real, and it is measurable

The 10 ms CPU budget is the free plan's one hard wall, and we have measured both sides of it on this site. A Worker that serves — our MCP server answering from static assets — spends 0 to 2 ms of the budget, because waiting on I/O does not count as CPU. A Worker that computes — the template engine we measured in the agent readiness audit — blew through the same budget by a factor of eight. That is the honest split for a migration: routing, redirecting, serving, forwarding all fit with room to spare; parsing, rendering and hashing at volume do not.

Per this site's house rule, the price of the lift sits next to the limit: the Workers Paid plan at $5 a month raises the per request cap to 30 seconds by default and includes 10 million requests and 30 million CPU milliseconds a month.

What honestly stays on the server

Long running processes. Anything that holds a socket open for hours, speaks a protocol that is not HTTP, or needs SSH. Arbitrary TCP proxying exists (Spectrum) but only as an Enterprise extra — that is not a migration, that is procurement.
Heavy compute, per the measurement above, unless $5 and 30 seconds cover it.
The paid tier gaps. Snippets are absent from Free entirely, Logpush is Enterprise, Load Balancing and Argo are paid extras. If your VPS job maps to one of these, the free plan answer is "no", not "yes with effort".
Control you did not know you had. On Cloudflare Registrar you cannot change nameservers at all, and renewal is an instruction, not a guarantee. A migration hands real levers to one vendor; that is a decision, not a detail.

And there is a bridge for the undecided: Cloudflare Tunnel is available on all plans, so the VPS can stay exactly where it is, hidden behind the edge with no open ports, while jobs migrate off it one row at a time. Nothing about this table is all or nothing.

Two systems that already live like this

This blog is the small case: six Workers — the site plus five distribution posters — seven cron firings a day, a shared KV namespace, 317 static files, an MCP server, at a running cost of exactly zero, with the measurements published as articles.

The larger case is 301.st, the platform this blog belongs to: a production SaaS for domains, redirects and traffic distribution, built as a serverless application on Cloudflare Workers with D1 as the source of truth and KV for cache and sessions. Its architecture documentation states the design goal plainly: customers do not need a paid Cloudflare plan — everything runs on free Workers, and Workers Paid is the growth path, not the entry fee. A platform whose job is other people's domains chose the same table you just read. That is as honest an endorsement of the free plan as we can offer. And where a portfolio outgrows the rows you can run yourself, taking that work over is exactly what the platform exists for.

An MCP server on Cloudflare's free plan, measured against the 10 ms CPU limit

301ST — Tue, 04 Aug 2026 14:00:54 +0000

Two things happened this week that turn "can I run an MCP server for free" from a compromise into a plain yes, with one measurable condition. Today the Model Context Protocol shipped its 2026-07-28 revision, and the headline change is that the protocol core went stateless: sessions, the Mcp-Session-Id header, and the initialize handshake are gone. The release post states the consequence outright:

Any request can now land on any server instance behind a plain round-robin load balancer without needing shared storage.

And yesterday, one day ahead of the release, Cloudflare's own documentation flipped. The McpAgent class — the official path that backed every MCP server with a Durable Object because the transport needed somewhere to keep its session — is now marked deprecated and feature frozen, with a stateless request handler as the recommended replacement for new servers.

Those two moves close the same gap from both ends. A Worker on the free plan was always a natural place for a small MCP server except for one thing: the transport demanded state, and state meant a Durable Object and a sticky instance. Now the protocol itself promises that every request is self contained. What remains is the free plan's one hard ceiling — 10 ms of CPU per request — and whether a real server fits under it is not a question you argue about. It is a question you measure. So we built one, on this site, and measured it.

What the revision actually removed

The old lifecycle opened every connection with an initialize round trip, minted a session id, and required the client to carry it on every call. All of that is deleted. Version, client identity, and capabilities now travel inside each request's _meta fields, and the one thing a server must implement is server/discover, which reports its supported versions and capabilities to anyone who asks.

The transport got stricter in exchange. Every POST must carry an MCP-Protocol-Version header that matches the version inside the body, plus an Mcp-Method header mirroring the JSON-RPC method — and Mcp-Name on tool calls — so load balancers and gateways can route without parsing bodies. A mismatch is a hard 400. Batching stays gone, ping is removed entirely, an unknown method is now an HTTP 404, and the 2024 era HTTP+SSE transport is formally classified as deprecated. A server that never pushes messages may answer every request with plain JSON and refuse the streaming path with a 405.

For a server that only reads, the protocol surface left over is small: server/discover, tools/list, tools/call, and the header discipline. That is the whole list.

The server this site now runs

This blog already publishes an agent surface — Markdown mirrors of every article and a posts.json feed. The MCP server is those same files behind two tools: list_articles returns the feed, get_article returns an article's full Markdown. It lives at https://301.sh/mcp on the same Worker that does the site's content negotiation, with zero dependencies — after the revision, the remaining protocol surface is short enough to write out by hand. Cloudflare ships an SDK route for the same job (createMcpHandler plus the protocol SDK), which is the right answer the moment you need resources, prompts, or elicitation; a two tool read only server does not.

The dispatch, condensed to its shape:

switch (message.method) {
  case 'server/discover':
    return reply(id, { resultType: 'complete', supportedVersions: ['2026-07-28'],
      capabilities: { tools: {} }, ttlMs: 3_600_000, cacheScope: 'public' });
  case 'tools/list':
    return reply(id, { resultType: 'complete', tools: TOOLS, ttlMs: 3_600_000,
      cacheScope: 'public' });
  case 'tools/call': {
    // Mcp-Name header must equal params.name, or 400 + HeaderMismatch.
    const mirror = await env.ASSETS.fetch(new URL(`/${slug}.md`, origin));
    return reply(id, { resultType: 'complete',
      content: [{ type: 'text', text: await mirror.text() }], isError: false });
  }
  default:
    return fail(id, 404, -32601, `Method not found: ${message.method}`);
}

Nothing in it computes. Every answer is an already deployed static asset fetched through the assets binding, and that choice is exactly what the measurement rewards.

The measurement

Cloudflare's definition of the limit is the part most people skip past:

CPU time measures how long the CPU spends executing your Worker code. Waiting on network requests (such as fetch() calls, KV reads, or database queries) does not count toward CPU time.

So the 10 ms budget is spent on parsing, validating, and assembling JSON — not on fetching the article body. We sent 40 requests at the production endpoint and read the per invocation cpuTime that Workers Logs record:

Method	CPU, ms (min / median / max)	Wall, ms (min / median / max)
server/discover	0 / 0 / 1	0 / 1 / 2
tools/list	0 / 0 / 0	0 / 1 / 2
list_articles	0 / 1 / 1	10 / 13 / 23
get_article, largest article	0 / 1 / 2	6 / 10 / 88

The worst case spends 2 ms of the 10 ms budget, and the slowest response — 88 ms of wall time serving the longest article on the site — is almost entirely waiting on the asset fetch, which the meter ignores. A serving tool runs at a fifth of the free ceiling with room to spare, and the free plan's other number, 100,000 requests a day, is a different class of problem entirely for an endpoint agents call a few times per conversation.

Where 10 ms actually bites

The ceiling is real; it just lives somewhere else than the transport. When we audited this site's agent surface, we measured a template engine we considered exposing as a service, and it blew through the same 10 ms by a factor of eight. That is the honest division: a tool that serves bytes costs one or two milliseconds; a tool that computes — parses documents, renders templates, hashes at scale — eats the budget almost immediately. Cloudflare does allow occasional overruns ("Each isolate has some built-in flexibility"), but a Worker that exceeds the limit consistently is terminated with error 1102, and burst tolerance is not a plan.

The lift has a price tag, and per this site's house rule it belongs next to the limit: the Workers Paid plan at $5 a month raises the per request cap to a default of 30 seconds (configurable up to 5 minutes) and includes 30 million CPU milliseconds and 10 million requests a month. If your tools compute, that is the number to compare against, not the free tier's 10 ms.

Try it, and what this does not need

The endpoint is live, and one request shows the whole new shape of the protocol:

curl https://301.sh/mcp -X POST \
  -H 'Content-Type: application/json' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: server/discover' \
  -d '{"jsonrpc":"2.0","id":1,"method":"server/discover",
       "params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}'

No session to open, no state to hold, no Durable Object on the bill. If your site already publishes Markdown mirrors or a feed — and after the agent readiness audit ours did — the distance from "static files" to "MCP server" is one route on a Worker you may already be running. The spec finally matches what a small read only server always wanted to be: a plain HTTP endpoint that answers questions about content you have already built. The free plan carries that easily. It is the computing tools that were never going to be free, and now you know the number that decides.

The conversion fires on someone else's domain. Here is how to attribute it.

301ST — Mon, 03 Aug 2026 14:00:53 +0000

You buy the traffic, the sale happens on a domain you cannot touch. An affiliate offer, a product page on a marketplace, a partner's checkout, any program where the "thank you" page belongs to the platform. You cannot place a pixel there, and the ad platform is optimizing blind: the network dashboard shows dozens of conversions, the ad account registers a handful, and the algorithm steers toward clicks, because clicks are all it can see.

The question surfaces in PPC and affiliate communities year after year, asked about Meta traffic to marketplaces, about ClickBank offers, about white label programs, and the public answers have not moved in a decade. They come in two kinds: "you cannot implement anything on their side", which is true, and "buy a tracker", which starts at three figures a month. At least one asker gave up and publicly put a €100 bounty on any working idea. Nobody collected.

The fallback everyone lands on instead is counting clicks on the outbound link as stand in conversions. It rots, because a click is not a sale and bots click too — that €100 was in fact offered for a way to filter bots out of exactly this surrogate metric. Money on the symptom, because the cure was not written down anywhere.

The "nothing on their side" answer is correct, and it is also not the end. Everything you need can live on yours, in the one place every click still passes through: a redirect hop you own. That pattern is what this article builds — with what it costs, where it breaks, and what the ad platforms allow, checked against their live documentation on 27 July 2026.

The loop: click_id out, postback in

The mechanics have been standard in affiliate networks for a decade. What is missing in every one of those threads is someone laying the loop out end to end.

The click leaves your page through a redirect you host: /go. The hop generates a click_id, stores it alongside everything you know about the click — the gclid from the ad, the source, the timestamp — and sends a 302 to the network link with the click_id in the network's subid parameter.
The network carries your subid through to the sale. When the conversion happens on their side, their system fires a postback: a server to server request to a URL you registered, carrying the subid back, usually with a payout amount.
Your postback endpoint looks the click_id up, and now the conversion is joined to the exact click, campaign, and creative that produced it — on your infrastructure, from server logs, with no pixel anywhere.

Note what this does not depend on. No JavaScript on the conversion page, because you have no JavaScript there. No cookies surviving anything, because the join key travels inside URLs and server calls. No consent banner in the path, because nothing runs in the visitor's browser beyond the redirect itself. The hop is server side by construction, which is also why ad blockers never see it: the click is a request to your own host before the browser goes anywhere else.

Why the hop must not be your ad's final URL

The tempting shortcut is to point the ad directly at /go and skip the landing page. On Google Ads that shortcut is closed twice over, and knowing exactly how saves you a policy strike.

First, tracking templates do not carry the user anymore. Parallel tracking is mandatory for Search, Shopping, Display, Video, and Performance Max, and Google's description of it is unambiguous:

Parallel tracking sends customers directly from your ad to your final URL while click measurement happens in the background (without sending them to the tracking URLs first).

The template URL still gets requested — as a background ping from the browser — so a hop in the tracking template can count the click. But it cannot route the visitor, rewrite where they land, or hand the network a subid on the visit that actually converts.

Second, making the hop the final URL is a listed policy violation. Google's destination requirements name it directly: "Redirects from the final URL that take the user to a different domain" is a destination mismatch. That is the rule that gets affiliate accounts suspended for direct linking.

So the compliant shape on Google Ads is a bridge: the final URL is a real page on your domain, and the hop is the outbound link on that page. Make sure the page passes its own query string through to the hop link — the gclid arrives on the landing page URL thanks to auto tagging, and a redirect that drops it ends attribution before it starts. Meta does not run parallel tracking, but the same bridge shape is where community answers converge for Meta traffic too: a page you own, your pixel on it, subids outbound.

Closing the loop back into the ad platform is the step everyone skips. On Google Ads it has an official name: offline conversion import. You stored the gclid next to the click_id at hop time; when the postback lands, you upload the conversion keyed by that gclid. Google retains a gclid for 90 days for this purpose, auto tagging is the only prerequisite, and the feature is current, not legacy. The campaign stops optimizing toward clicks and starts optimizing toward the sales your postbacks confirm.

Building the hop on Cloudflare's free plan

A redirect rule cannot do this job, and it is worth being precise about why. Single Redirects are a terminating action in the first request phase — nothing downstream ever sees the click, and the rule itself cannot write anything anywhere. The expression language cannot even mint an id: uuidv4() exists, but the documentation restricts it to rewrite expressions of Transform Rules. Among every way to redirect on Cloudflare, the only primitive that can mint, store, and answer postbacks is a Worker.

The whole hop is one Worker with two routes and a D1 table:

export default {
  async fetch(req, env) {
    const url = new URL(req.url);

    if (url.pathname === '/go') {
      const id = crypto.randomUUID();
      await env.DB.prepare(
        'INSERT INTO clicks (id, gclid, src, ts) VALUES (?1, ?2, ?3, ?4)',
      )
        .bind(id, url.searchParams.get('gclid') ?? '', url.searchParams.get('src') ?? '', Date.now())
        .run();
      const target = new URL(env.OFFER_URL);
      target.searchParams.set('subid', id);
      return Response.redirect(target.href, 302);
    }

    if (url.pathname === '/postback') {
      if (url.searchParams.get('key') !== env.POSTBACK_KEY) {
        return new Response(null, { status: 403 });
      }
      await env.DB.prepare(
        'UPDATE clicks SET payout = ?2, converted = ?3 WHERE id = ?1',
      )
        .bind(url.searchParams.get('subid'), url.searchParams.get('payout') ?? '', Date.now())
        .run();
      return new Response('ok');
    }

    return new Response(null, { status: 404 });
  },
};

The free plan quotas fit this comfortably, all checked live on 27 July 2026: Workers allows 100,000 requests a day, D1 writes 100,000 rows a day and reads five million — a click and a postback are one row each. Outgrowing them is a billing decision, not a redesign: the Workers Paid plan at $5 a month moves Workers to 10 million requests and D1 to 50 million written rows a month. The one storage choice to get right: this is a lookup workload, not a counting workload, which is why the table is D1 and not Workers KV — KV writes cap at 1,000 a day on Free, a limit that has misled people before. Registering the postback URL with the network is one form field on their side: your /postback address with the key and their subid macro in it.

Where it breaks

The hop is the reliable half of the loop. The other half belongs to the network, and when the join fails, it fails in one of five recurring ways — this list is assembled from a decade of affiliate forum threads asking why the postback never came:

Failure	What it looks like	Check
Token name mismatch	Network expects `{clickid}`, you sent `{click_id}`	Their macro list, character for character
Reserved subids	`sub1` is taken by the network's own tracking	Ask which slot is passthrough
Offer strips subids	Clicks arrive, subid column is empty	Test link, then check their reporting
Postback registered late	Conversions before registration are gone for good	Register before the first paid click
Never tested by hand	Everything "configured", nothing verified	Open your postback URL in a browser with a fake subid

The last row is the one that catches people who did everything else right. A postback URL you have never fired manually is a guess, not a setup: request it once yourself and watch the row update before any money is spent.

Two structural limits are worth naming too. If the program offers no postback and no subid reporting at all, no hop can conjure the loop — the join needs their half, and your fallback is reconciling their dashboard against your click log by time and creative, which is exactly the manual matching those community threads end up settling for. And the offline conversion window is real: a sale confirmed more than 90 days after the click cannot be imported against its gclid, which matters for products with long approval cycles.

When the Worker is enough, and when it stops being

For one offer and one traffic source, the Worker above genuinely closes the €100 question: every click logged with its gclid, every conversion joined server side, the ad platform fed real sales instead of proxy clicks. Run it and stop paying for attribution you can build in an afternoon.

The pattern stops being an afternoon when it multiplies. Ten offers mean ten target URLs and ten postback registrations; three traffic sources mean the hop has to split by source; a dead offer means rerouting yesterday's links without breaking yesterday's subids. At that point the hop is not a script anymore, it is a routing layer with a database behind it — which is the thing 301.st already is: streams that route each click by rules, click_id minted and logged on every hop, postbacks received and matched as the default path, not as your weekend project. For a single campaign, keep the Worker. It is honest work and it is yours.

How to see the redirect chain your browser actually followed

301ST — Sun, 02 Aug 2026 14:00:53 +0000

A link lands somewhere it should not, and you need to know what happened between the click and the final page. The standard first move is curl, and it is the right one: the 60 second gclid test on this site is built on curl -sIL, and for server redirects it tells the truth. Then the chain looks clean in the terminal while the browser still ends up somewhere else, and the tool has quietly run out.

The reason is that only some redirects live in HTTP responses. The rest happen inside the page, or inside the browser itself, and no amount of -L will surface them. This article is about seeing a chain, not building one; every way to create a redirect on Cloudflare is its own comparison.

Three redirects curl cannot show you

A JavaScript redirect is a 200. The server answers with a normal page, the page runs location.replace() or sets location.href, and the browser navigates. curl prints HTTP/2 200, reports no redirect at all, and exits. Every interstitial, every tracking hop built on a script, every "checking your browser" page falls in this class.

A meta refresh is also a 200. <meta http-equiv="refresh" content="0;url=..."> sits in the HTML body, and curl does not parse HTML. Same clean status line, same silent navigation in the browser.

An HSTS upgrade never leaves the browser. After one visit to a site that sends Strict-Transport-Security, the browser rewrites http:// to https:// before any request is made. DevTools shows it as 307 Internal Redirect, a response the server never sent. curl keeps no HSTS state by default, so it hits the http:// URL fresh every time and shows you the server's 301, a hop your returning visitors stopped taking long ago.

On top of the mechanics there is the session. curl carries no cookies, so a chain that branches on login state, a consent cookie, or an A/B assignment sends curl down a different path than the person who reported the problem. The chain you tested is not the chain they followed, even when both are real.

DevTools shows it, if you hold it right

The browser obviously knows the full chain, and the Network panel will show it, with ceremony. Preserve log has to be on, otherwise the panel clears itself on every navigation and the hop you care about erases its own evidence. The Doc filter cuts the noise from the hundred subrequests a modern page makes. Server hops then appear as separate rows with their 301 and 302 statuses.

The client side hops are there too, but unlabeled. A JavaScript redirect is just another document request; nothing in the row says "this was a redirect", and connecting it to the page that triggered it means reading the Initiator column. A meta refresh looks the same. Do this once and it is five minutes of archaeology. Do it for every report and you start wanting the browser to just keep the record.

A recorder instead of a stakeout

That is what Redirect Inspector does. It is our own open source extension (Apache 2.0, code on GitHub), and version 2.3 shipped as its largest update yet, which is the occasion for this article. The extension listens to the browser's own request pipeline and records every chain as you browse: server hops with their status codes, client side navigations (a script or a meta refresh) marked with a JS badge, and the browser's internal upgrades marked HSTS. Chains are grouped by browsing session, tracking pixels and ad beacons are filtered out by default, and each card carries the total chain time with per hop timing in the analysis drawer.

What 2.3 added, briefly:

Check a URL without visiting it. Paste a URL into the dock at the bottom of the panel; it opens in an invisible background tab, the chain is captured through the normal pipeline, and the tab closes itself. The suspicious link from the report gets traced without ever taking over your screen.
Export that fits a bug report. Copy a clean summary, download the raw chain as JSON, or copy a ready curl command that reproduces the server side of the chain, which closes the loop back to the terminal where the investigation started.
A side panel instead of a popup on Chrome and Edge, so the chain list stays open while you browse. Firefox keeps the popup.
Local analysis. Nine checks per chain: loops, hops that bounce back and forth, chain length, mixed redirect types, auth bounces, consent hops, tracking noise, CDN detection, final outcome.
Search across all captured URLs, an undoable Clear, keyboard shortcuts, and full UI translations in seven languages.

The part that matters for a tool watching your traffic: everything runs locally. No accounts, no analytics, no telemetry, and by default no network requests at all; captured chains live in browser storage and never leave the machine. It is on the Chrome Web Store, Firefox Add-ons, and Edge Add-ons.

Which tool sees what

You need	curl -sIL	DevTools Network	Redirect Inspector
Server hops (301, 302, 307, 308)	yes	with Preserve log on	yes, recorded as you browse
HSTS upgrade	no, sees the server 301 every time	shown as 307 Internal Redirect	labeled HSTS
JS and meta refresh	no, both are a 200	an unlabeled document request	captured, marked as a client redirect
The chain your session gets (cookies, login)	no	yes	yes
Timing	one total with `-w`	per request, spread across rows	total per chain, delta per hop
A record you can search and export later	no	cleared when the panel closes	sessions, search, JSON and curl export

Online redirect checkers are missing from the table on purpose: they request the URL from their own datacenter, so a chain that branches on country, language, or cookies shows you the datacenter's version, which is the same blind spot curl has plus somebody else's IP.

Where the extension stops

The extension records what your browser was sent. A chain that branches by geography still shows you the branch for your country and nobody else's, and what Googlebot sees on the same URL is a different question entirely. The URL check is a real navigation in an inactive tab, so your cookies apply and the visit lands in your history; it is a convenience, not an isolation chamber. And it can only look at chains one browser at a time, on the machine where it is installed.

For debugging the link in front of you, that is the whole job, and the extension is free. The point where it stops is the point where the question changes from "what happened to this click" to "which of my domains are redirecting wrong right now". Answering that means sending the same probe to every domain on a schedule and comparing against yesterday, which no browser tool can do. The audit script is the manual version of that answer, and 301.st is the version that runs continuously, across the portfolio, with an alert when a chain changes. For the tab you have open, install the extension and read the chain.

Redirecting domains you own to one site, without tripping Google's spam rules

301ST — Sat, 01 Aug 2026 14:00:16 +0000

You own a small pile of domains — an old brand you moved away from, a couple of typo variants you grabbed so nobody else would, a name from a project that folded — and you want them all pointing at your current site. Then you read that redirecting domains is a spam signal now, that Google's latest update torched sites for doing exactly that, and you stop with your hand on the button.

Two different things are being run together under one scary headline. One of them Google is actively penalizing. The other Google names, in its own policy, as a legitimate reason to redirect. The whole question is which one you are doing — and the line is clearer than the headlines make it sound. This is the SEO side of the parked-domain runbook and of every way to redirect on Cloudflare: the same 301, and whether Google honours it.

What Google actually went after

The thing that got hit has a name in Google's spam policies:

Expired domain abuse is where an expired domain name is purchased and repurposed primarily to manipulate search rankings by hosting content that provides little to no value to users.

That is the play: buy a dropped domain that still carries ranking signals from its old life, point it at your site, and inherit authority you never earned. Google's March 2026 spam update did not invent a rule for this — expired domain abuse was codified back in 2024 — it enforced the existing one harder and faster. The market felt it. The advice in the expired-domain trade has visibly moved from hunting aged domains to starting fresh ones, and the sites that leaned hardest on authority-by-redirect are the ones that lost traffic. If the plan was to buy a stranger's old authority and 301 it into your rankings, that plan is done.

What Google still blesses

Now the other thing. Redirecting a domain you own to a site you own, because the two belong together, is not on any spam list. It is the opposite: Google's own policy on sneaky redirects lists consolidating pages among the legitimate reasons to redirect, right next to moving to a new address. What makes a redirect sneaky is intent.

When examining if a redirect is sneaky, consider whether or not the redirect is intended to deceive either the users or search engines.

There is no deception in sending an old brand's domain to that brand's current home. The mechanics agree: a 301 to a topically related destination still passes its signals, the way it has for years. Where it stops working is relevance. A 301 from an unrelated domain gets treated like a soft 404, and Google ignores the equity rather than handing it over. That is the tell for the whole distinction — a relevant consolidation is a redirect Google honours, an unrelated authority grab is a redirect Google declines.

Which one are you doing

The line, as a handful of questions:

	Consolidation — do it	Authority grab — dead
Whose domain	yours, related to the target	bought for its old rankings
The link between them	same brand, product, or topic	unrelated to your site
What the redirect is for	keeping your own traffic and name	inheriting a stranger's authority
Where it points	the page that replaces the old one	your homepage, to pass equity
Google's verdict	legitimate, passes signals	expired domain abuse, or ignored

If every answer sits in the left column, you are doing the thing Google's policy names as fine, and the spam update is not about you.

Doing it cleanly on Cloudflare

Being on the right side of the line is most of the job. Doing it cleanly is the rest, and a few Cloudflare-specific choices keep a legitimate consolidation from reading like a lazy one.

Point each old URL at the page that replaces it, not at your homepage. A blanket redirect of everything to the root is what muddies your anchor-text profile and looks like a link grab even when it isn't; where the old domain had real pages, map them to their real equivalents. The parked-domain runbook has the Cloudflare pattern for a domain with no server behind it — a proxied A record on 192.0.2.1 and a redirect rule — and Bulk Redirects is where a whole portfolio lives: one account-level list across every domain, rather than a rule per zone.

Keep it a single 301. Redirect chains — the old domain to a second domain to the site — leak signal at every hop and are slower for the visitor, and there is no reason to build one when the destination is fixed. One permanent hop, straight to the relevant page.

One honest aside, for the case this guide is not about: if what you actually want is to take over a dropped domain's ranking, a redirect was always the fragile way to do it, and Google just made it fragiler. The durable version is a real site on that domain, standing on its own. That is a different project from this one, which is about domains that already belong to you.

Where this is less tidy than it looks

A domain's past comes with it. If the name you own spent an earlier life inside a link scheme, a 301 carries that history into your site too, and a clean consolidation can still inherit a dirty reputation — worth reading the backlink profile of an acquired domain before you wire it up.

Relevance is not binary either. A domain only loosely related to your site sits in the grey zone where Google may pass some of the signal, all of it, or none, and no dashboard tells you which ahead of time. The safe reading is that an unrelated 301 is a waste rather than a punishment: the equity you hoped to move never arrives, while the redirect sits there doing nothing for anyone. The Google policy wording here was checked on 25 July 2026.

What one setup does not give you

For a handful of domains you own, the whole job is the runbook and one Bulk Redirects list, pointed at the right pages and checked once. That is genuinely all of it, and you should start there.

At the scale where a portfolio is dozens of names funnelling into one site, the work is staying on the right side of the line continuously: every redirect relevant, every one a single hop to a live page, and none quietly turned into a chain or a homepage dump as the site changes underneath them — plus a re-check each time Google tightens the screws. That standing watch across the whole portfolio is the part 301.st runs for you. For a few owned domains, a Bulk Redirects list and the runbook are enough.

Auto-renew was on and the domain expired anyway

301ST — Fri, 31 Jul 2026 14:00:17 +0000

The domain is on auto-renew. You set it years ago and stopped thinking about it, which was the whole point. Then one morning it returns NXDOMAIN, and everything riding on it is gone at once: the site, the email on that domain, and every redirect pointed through it. Auto-renew was the one thing that was supposed to make this impossible.

It isn't, and it fails people who register domains for a living, not only the careless. The setting sits there looking healthy while the three things it quietly depends on rot out of your sight. Knowing where the net has holes — and what actually catches a domain falling through them — is the difference between finding out on a schedule and finding out from a customer.

Auto-renew is a standing instruction, not a guarantee

Auto-renew is one sentence: charge this card, file this renewal, on this date. It inherits every way those two things quietly rot.

The card expires or is declined. Auto-renew is a card on file for a domain you registered in 2019, and a card from 2019 has almost certainly been reissued since. The instruction is intact; the payment behind it is not.

The notification you were counting on never arrives. It goes to an address you no longer read, or a filter files it under a tab you never open, or it is simply misrouted to spam. The single message that would tell you the charge failed is the message you don't see, and its absence looks exactly like everything being fine.

And you have stopped looking. Renewals you automate are renewals you take off your desk — that is the appeal and also the failure. You might have renewed the domain's TLS certificate in the spring and half-filed the registration under the same mental heading, so the date never stood out. The domain drops out of your attention on the day you trust a machine to hold it, and when the machine misses there is no second reader.

What Cloudflare Registrar actually does

Cloudflare Registrar is better than most on the mechanics, and it is worth knowing the real schedule instead of assuming a single make-or-break charge. From its documentation:

Cloudflare Registrar enrolls your domain to auto-renew by default.

Cloudflare attempts to renew these domains automatically 30 days before their expiration date. Several more attempts are made if the first attempt fails. The last attempt to renew is made on the day before expiration.

That is a month of retries, not one roll of the dice. And if every attempt in that window fails:

If you do not renew your domain before the expiration date, your domain will enter a Redemption Grace Period (RGP) for 30 days.

So a Cloudflare-registered name that lapses is not gone the next morning. It can be restored during redemption. For domains actually on Cloudflare Registrar this is a genuine net, and it costs nothing — checked against Cloudflare's documentation on 25 July 2026.

Where the net has holes

The schedule is good. The things it still depends on are the same three that rot out of sight.

It still needs a card that works. Thirty days of retries against a declined card end where a single failed charge does — on the day before expiration — and then you are counting redemption days instead of holding a domain. The retries buy time only if someone notices them.

It only covers domains registered with Cloudflare. A portfolio is rarely all in one place. Names accrete over years across three or four registrars, each with its own renewal timing and its own notification habits, most of them worse than Cloudflare's. The one you forgot you owned is the one no auto-renew setting is watching.

And renewed is not the same question as resolving. NXDOMAIN is what a lapsed registration returns, but it is also what a zone hold, a nameserver that drifted to an account nobody can find, or a never-activated zone returns. "Did it renew?" is answered in a billing page you have to remember to open. "Is it resolving?" is answered only by asking the domain.

What actually catches it

The lesson is not "check your card." It is that every signal pointing inward — the charge, the email, your own memory — can fail quietly and at the same time. The only signal that can't is the one pointing at the result: does the name still resolve, and did that answer change since yesterday.

Line up the failures against the things that might catch each one, and only one column is filled all the way down:

What fails	Auto-renew	Registrar email	A reminder you keep	Probing the domain
Card declined	✗	if you read it	the date, not the failure	✓
Notification misrouted or ignored	✗	✗	✓	✓
Domain at a registrar you forgot	✗	✗	✗	✓
Renewed, still `NXDOMAIN`	—	—	✗	✓

The last row is the one no renewal-tracking method can catch by definition: the registration is fine and the domain still does not answer. A spreadsheet with =DATEDIF() counting down to a renewal date — the advice that has not changed in ten years — tracks the date you typed in, not the domain. If the name lapses early because a charge failed, or the date in the sheet was wrong, the sheet stays green while the domain is dead.

Probing the domain is the same loop as the audit script, with the one column that matters here: whether a name that resolved last time returns NXDOMAIN now. Run it on a schedule, compare each answer to the last, and a name that quietly lapsed raises a flag while it is still inside the redemption window, instead of after a customer emails to say the site is down.

When this is worth setting up, and when it isn't

For domains on Cloudflare Registrar, the free path is genuinely good: auto-renew by default, a month of retries, and a redemption window if all of them miss. Turn it on, keep a working card, and for a handful of names that is the whole job — a calendar reminder you control, kept somewhere other than the registrar's own email, covers the rest.

Where it runs out is a portfolio spread across registrars, where no single renewal setting sees all of it and the only thing that does is a probe asking every domain, on every registrar, whether it is still there — and comparing today's answer to yesterday's. That cross-registrar watch, on a loop, with an alert when a name changes, is the part 301.st runs for you. Auto-renew keeps the domains it owns; this keeps track of the ones nobody remembered to look at. For a dozen names at one registrar, auto-renew and a reminder on your own calendar are genuinely enough.

Your redirect is configured and still returns 522, 525, or a parking page

301ST — Thu, 30 Jul 2026 14:00:46 +0000

You built the redirect. The dashboard shows the domain active, the cloud is orange, and the rule is sitting in the list where you left it. Then someone opens the domain and gets a 522, or a certificate warning, or a page offering to sell them the name. None of those is your 301.

The redirect did not fail loudly. It is simply not the thing answering, and the dashboard is the wrong place to notice. Three different misconfigurations produce this, each with its own signature, and one request separates them. This is the failure column of the audit script seen up close, and the underside of every way to redirect on Cloudflare: the same methods, and the ways each one goes quiet.

The rule never ran, so Cloudflare called an origin that is not there

A redirect on a parked domain is two parts that look like one. There is a DNS record, an A record on the apex proxied through Cloudflare, and there is a rule that does the redirecting. The runbook for parked domains points that record at 192.0.2.1, and Cloudflare's own note explains why an address that goes nowhere is the right choice:

This address does not route traffic to an origin server but allows Cloudflare to apply rules, redirects, and Workers to incoming traffic.

The rule is what makes the pattern work. A redirect rule runs at the edge and answers the request there, so Cloudflare never opens a connection to 192.0.2.1. Take the rule away, scope it to a hostname that does not match, upload the list to the wrong account, or proxy the record before the rule exists, and Cloudflare does exactly what the orange cloud tells it to. It proxies the request to 192.0.2.1. Nothing is listening there, on purpose.

What the visitor gets is a 522. Cloudflare's definition is literal:

Error 522 occurs when Cloudflare times out contacting the origin web server.

The wait is not instant. Cloudflare sends a SYN and, in the documented case, gives up when the origin web server does not return a SYN+ACK within 19 seconds, retrying on a backoff of 1,1,1,1,1,2,4,8. So the domain hangs for the better part of half a minute and then shows a Cloudflare error page. The A record is present, the proxy is on, everything on the DNS tab looks done, and the one piece that was missing left no mark there.

Swap the dummy address for a real origin and the same missing rule shows up as a different code from the same family: 521 when the origin refuses the connection, 523 when it is unreachable, 524 when the connection opens but no response comes back in time. The cause does not change. The request reached an origin because no edge rule caught it first.

That gives you the tell. A redirect rule that fires never touches the origin, so it cannot time out against one. Any 52x on a domain that is supposed to redirect is proof that the redirect did not run for that request.

Full (Strict) turns a redirect at the origin into a certificate error

Not every redirect lives at the edge. Plenty of them are a 301 sent by the origin web server, with Cloudflare proxying in front. That arrangement only works if Cloudflare can reach the origin over TLS and accept the certificate it presents, and the SSL/TLS encryption mode decides how strict it is about that.

Set the mode to Full (Strict) and the certificate has to be one Cloudflare trusts. When the handshake itself does not complete, the visitor gets a 525:

This error indicates that the SSL handshake between Cloudflare and the origin web server failed.

Cloudflare lists the usual reasons: no valid certificate installed, port 443 closed, no SNI support, or a cipher mismatch. When the handshake does complete but the certificate does not check out, the code is 526 instead:

Cloudflare cannot validate the SSL certificate at your origin web server.

That one is paired with Full (Strict) specifically, and it fires on a certificate that has expired, been revoked, carries the wrong name, is missing part of its chain, or was signed by nobody a browser would trust. The redirect the origin wants to send is fine. The visitor never sees it, because the connection that would carry it never finishes.

There is a gentler version of the same problem on a domain you just added. Universal SSL takes time to issue, and it covers one level of subdomain, not two. A request that arrives before the certificate is active, or to a name the certificate does not cover, gets a browser TLS error before any redirect has a chance to run.

The domain never moved, so Cloudflare is not even in the path

The third failure has no Cloudflare error code, because Cloudflare is not involved. You added the zone, you wrote the rule, and the nameservers at the registrar were never changed to the pair Cloudflare assigned. The zone sits pending. Everything you configured is real and none of it is live.

There is a quieter way to land in the same place. Presetting nameservers in bulk before creating the zones, which is the instinct at scale, now backfires:

To prevent domain hijacking, you can no longer preset Cloudflare nameservers at your registrar before creating the respective zone in Cloudflare.

Do it anyway and the zone is assigned a different pair, the registrar points at nameservers that do not serve it, and the domain never activates. Nothing in either interface says why.

While the domain is pending, whatever the registrar serves is what the visitor sees. Often that is a parking page, sometimes one offering the name for sale, and it usually answers with a 200. A check that only asks whether the domain is up will pass, because something did answer. It just was not you, and the redirect you wrote is asleep behind a zone that never woke.

One request tells the three apart

Each mode answers a curl differently, which is why the audit reads the status line before anything else:

curl -sI "https://the-domain/"

A 52x on the first line means Cloudflare is in the path and the rule did not fire. A TLS error before any HTTP status means the handshake to the origin failed, or the edge certificate is not ready. A 200, or a 302 whose location points at a registrar rather than a 301 to your target, means the domain is not on Cloudflare at all. The audit script puts exactly this in its CODE and DESTINATION columns, which is how you find these across a portfolio instead of one domain at a time.

Where this is less tidy than it looks

A 522 against a real origin can be intermittent rather than constant, usually when the origin firewall blocks some Cloudflare IP ranges and not others, so the same domain passes and fails by the hour. On the 192.0.2.1 pattern there is no such ambiguity: the address is reserved and never answers, so the 522 is every time.

A pending zone is the one case the dashboard actively hides from you, because from inside the account nothing is broken. The rule is valid, the record is valid, the zone is waiting. The evidence only exists outside, in what the domain returns to a request that does not go through Cloudflare.

And a registrar parking page does not always sit still on a 200. Some registrars answer with a 302 to their own parking host, which is a redirect, just not yours. The audit script catches that by reading where the location points, not merely that a redirect happened. The codes and definitions here were checked against Cloudflare's documentation on 23 July 2026.

What one look does not give you

All three of these are green at a glance and only visible from outside, so catching them is a matter of asking every domain the same question on a schedule rather than trusting the dashboard. For a handful of domains, the loop from the audit script on a cron entry is the whole answer, and you should start there.

At the scale where a portfolio carries a long tail of names nobody has opened in months, the question has to be asked continuously, and the answer compared against the last one so a domain that quietly changed raises a flag. That is the part 301.st runs for you: the same probe across the whole portfolio, on a loop, with an alert when a row changes. For twenty domains, the cron entry and the script are genuinely enough.

Which of your 300 domains still redirect? One script, and what to fix first

301ST — Wed, 29 Jul 2026 14:00:31 +0000

Someone asked on r/Domains in March 2025 how to identify all the domains currently redirecting to their main website. The thread has no answers. A company monitoring hundreds of domains asked something similar on r/selfhosted in 2024, and the best reply admitted the gap rather than closing it: for monitoring WHOIS changes, it said, "the situation is even worse". The closest thing to a canonical answer is a Server Fault question from 2013 whose accepted reply is to "double check your current DNS and your future DNS, just to be sure".

Meanwhile people keep rebuilding the tool. Uptime Kuma has had requests for domain expiry checks open since November 2021, and GitHub carries a steady supply of one-off clones.

The question deserves a better answer than a spreadsheet. Here is a script that gives one, and a second column that decides what you actually do with the output.

Why the dashboard cannot tell you

Cloudflare's interface is organised by zone. Everything worth knowing here is a property of the set of zones, and there is no screen for that.

The raw logs that would answer it are Enterprise only: Logpush lists Free, Pro and Business as No. Per-rule statistics never arrived either — a feature request for Page Rule statistics was opened in May 2017, raised again by its author twice, and closed in June 2025 without being implemented.

So the cross-domain view is something you assemble yourself. The good news is that the API gives you the list for free.

Start from the account, not from your spreadsheet

The list of domains you think you own and the list Cloudflare is actually serving are different lists, and the difference is the first finding of any audit.

curl -s -H "Authorization: Bearer $CF_API_TOKEN" \
  "https://api.cloudflare.com/client/v4/zones?per_page=50&page=1" \
| jq -r '.result[] | "\(.name)\t\(.status)"'

A zone's status is one of initializing, pending, active or moved. Anything that is not active is a finding on its own: a pending zone is a domain whose nameservers never switched at the registrar, which means every rule you wrote for it has never once run. On a portfolio built in batches, that is the long tail the runbook warns about, showing up months later.

Mind the pagination. The endpoint pages, and a portfolio of three hundred will not arrive in one response — loop page until you get fewer rows than you asked for.

What to check, and why each check is a different failure

Three questions, three different ways a domain can be quietly broken.

Does it answer at all? A dead domain and a domain that answers wrongly look identical in a spreadsheet and nothing alike in a browser.

Does it go where you think? A redirect that works and points at last year's landing page is worse than a broken one, because nothing will ever alert you.

Is the certificate current? Cloudflare's Universal SSL certificates "have a 90-day validity period" and "the auto renewal period starts 30 days before expiration". Read that carefully before you set a threshold: on a healthy proxied domain, fewer than 30 days remaining is normal, not an alarm. What matters is a certificate that is already expired, or one on a domain that left Cloudflare and has nobody renewing it.

And the failure that no HTTP check catches: the domain simply stopped existing. A domain on auto-renew can still go NXDOMAIN — a card that quietly expired, a renewal notice lost to spam — because auto-renew is the advice everyone gives and the thing that fails before anyone notices. Why it is not the safety net it looks like is its own subject.

The second column: what is worth fixing

Three hundred rows of findings is not an answer, it is a new problem. Nobody fixes three hundred domains. You fix the ones that carry weight, and until recently working out which those were meant a subscription.

That changed. Ahrefs' Domain Rating endpoint is now open, and its documentation is explicit: "Requests to this endpoint are free and do not consume any API units."

Checked today, it answers without a subscription:

$ curl -s "https://api.ahrefs.com/v3/public/domain-rating-free?target=cloudflare.com&output=json"
{"domain_rating": {"domain_rating": 94.0, "license": "...", "warning": "..."}}

Three conditions come with it, and all three belong in this article rather than in a footnote.

A free key is required from 10 August 2026. The endpoint currently answers unauthenticated and tells you so itself, in a warning field in its own response: "Unauthenticated access to this endpoint will be removed on 2026-08-10." The script below sends a key already. Generating one is free, and doing it now costs less than debugging the script in three weeks.

Attribution, if you display the number. The licence grants the right to "use, display, publish or integrate DR Data" and requires the credit "Domain Rating by Ahrefs" with a working hyperlink that "shall not be hidden, obscured or removed". A private terminal report is one thing; a dashboard your team reads is a place where that line has to appear.

Your own domains, at a civil pace. The same licence prohibits scraping or harvesting DR data "in bulk or systematically". Walking the portfolio you own, once, with a pause between requests, is the use the endpoint exists for. Sweeping other people's domains to build a DR dataset is the thing it forbids. Ten sequential requests spaced by 0.3 seconds went through without a complaint; the limits are not documented and Ahrefs reserves the right to change them without notice, so pace it and do not assume the ceiling is high.

One caveat on the metric itself: DR is Ahrefs' number, not Google's. It is a good relative scale for "which of these domains carries more weight than the others", and it says nothing about rankings.

The script

Needs curl, openssl and jq. The date arithmetic is GNU; on macOS use date -j -f '%b %d %T %Y %Z'.

#!/usr/bin/env bash
set -uo pipefail
: "${AHREFS_KEY:?export AHREFS_KEY — free key from ahrefs.com}"

printf '%-34s %-5s %-32s %-6s %s\n' DOMAIN CODE DESTINATION CERT DR

while read -r domain; do
  [ -z "$domain" ] && continue

  head=$(curl -sI --max-time 10 "https://$domain/" 2>/dev/null)
  code=$(printf '%s' "$head" | awk 'NR==1{print $2}')
  dest=$(printf '%s' "$head" | awk 'tolower($1)=="location:"{print $2}' | tr -d '\r')

  until=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null \
          | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  days=""
  [ -n "$until" ] && days=$(( ( $(date -d "$until" +%s) - $(date +%s) ) / 86400 ))

  dr=$(curl -s --max-time 10 -H "Authorization: Bearer $AHREFS_KEY" \
       "https://api.ahrefs.com/v3/public/domain-rating-free?target=$domain&output=json" \
       | jq -r '.domain_rating.domain_rating // "-"')

  printf '%-34s %-5s %-32s %-6s %s\n' \
    "$domain" "${code:-DEAD}" "${dest:--}" "${days:+${days}d}" "$dr"
  sleep 0.3
done < domains.txt

A real run, against this site and two others, on 22 July 2026:

DOMAIN                             CODE  DESTINATION                      CERT   DR
www.301.sh                         301   https://301.sh/                  89d    8
301.sh                             200   -                                89d    8
spintax.net                        200   -                                85d    56
this-domain-does-not-exist-9f3.com DEAD  -                                       0

Four rows and four different states. The www form redirects to the apex, which is what it is supposed to do. Two domains answer directly. The last one does not resolve at all, and the script says DEAD rather than pretending to have an opinion about it.

Note the certificate column: 89 and 85 days. That is Universal SSL at the start of its 90-day life, which is what healthy looks like. A row reading 4d on a domain nobody is renewing is a different matter, and a row with no number at all means the handshake never happened.

Two shapes worth recognising that are not in that sample. A 522 means Cloudflare answered but your origin did not, so visitors are getting an error page where you think a redirect lives. And a 200 on a domain that is supposed to forward means the redirect is simply gone: a rule deleted, or one that never applied because the zone is still pending. Each of these is a redirect that is configured and still failing, and the CODE column is where they surface.

The rule that turns the table into decisions

Sort by broken first, then by DR descending, and the top of that list is your afternoon. A dead domain with real authority is the most expensive row in the table: every link pointing at it is value you already paid for and are currently throwing away. A dead domain with a DR of zero is a renewal invoice you can stop paying.

That second conclusion is worth as much as the first, and no health check alone can reach it.

What one pass does not give you

It gives you a snapshot, and portfolios do not break on the day you look at them.

A certificate expires in ninety days. A registrar's auto-renew fails silently one Tuesday. A rule gets edited on a zone nobody has opened in a year, and the redirect starts landing on the wrong page while returning a perfectly healthy 301. The script above finds all of these — the next time somebody remembers to run it.

That is the difference between an audit and a system, and it is the honest place to say what 301.st is for: it runs this continuously across the portfolio and tells you when a row changes. For twenty domains, a cron entry and the script above are genuinely enough, and you should start there.

Domain Rating by Ahrefs.

An agent readiness audit scored our docs site 21 out of 100

301ST — Tue, 28 Jul 2026 14:00:32 +0000

Cloudflare runs a scanner at isitagentready.com that grades a domain on how ready it is for AI agents. Twenty one checks across five categories: discoverability, content accessibility, bot access control, protocol discovery, and commerce.

We pointed it at spintax.net, a documentation site that had shipped a full llms.txt surface the week before. A curated index, eighteen clean Markdown mirrors of the documentation pages, and a concatenated llms-full.txt for a single fetch. The score came back 21 out of 100, Level 1, "Basic Web Presence". Content accessibility scored zero out of one.

That gap is the interesting part. The score is not a measure of how readable your site is to a model. It is a measure of which HTTP mechanisms you implement. Those are different things, and only one of them is what most sites think they are buying when they publish an llms.txt.

Here is what the audit actually measures, which four checks were worth implementing, and why eight of the failures were correct.

Why a complete llms.txt scores zero on content accessibility

The check is not looking for a file. It sends a request with Accept: text/markdown and reads the Content-Type that comes back. If the response is text/html, the check fails, no matter how much Markdown you publish at other URLs.

This is HTTP content negotiation, and it has been in the specification since before anyone was building agents. One URL, several representations, the client states a preference in a header. llms.txt is a convention: a file at a known path that a client has to know about in advance. Content negotiation is a mechanism: any client that already speaks HTTP gets the Markdown by asking for it, without knowing your site exists.

We had eighteen Markdown files sitting on disk and no way for a client to reach them except by reading the index first. The audit was right.

Doing content negotiation on Pages, on the free plan

Cloudflare sells the easy version of this. A zone level setting called Markdown for Agents intercepts responses when the request carries Accept: text/markdown and converts the HTML to Markdown on the fly. It is one toggle in AI Crawl Control, or one PATCH to the content_converter zone setting.

It is available on "Pro, Business and Enterprise plans, and SSL for SaaS customers at no cost". The site is on Free.

The toggle would also have been the worse option even if it were available. Our mirrors are generated at build time from the same HTML, through a turndown configuration with custom rules for the card grids that would otherwise convert into unreadable blocks nested inside links. An automatic conversion at the edge cannot know about those. Hand tuned output beats generic output when you already build it.

So: a Pages Function. Note that _headers and _redirects cannot do this job at all, because neither can branch on a request header. Content negotiation needs code.

// functions/_middleware.ts
export const onRequest = async (context) => {
  const { request, env, next } = context;
  const url = new URL(request.url);

  if (request.method === 'GET' && wantsMarkdown(request.headers.get('Accept'))) {
    const mirror = await env.ASSETS.fetch(
      new Request(new URL(mirrorFor(url.pathname), url.origin)),
    );
    if (mirror.ok) {
      return new Response(mirror.body, {
        status: 200,
        headers: {
          'Content-Type': 'text/markdown; charset=utf-8',
          'Vary': 'Accept',
          'X-Robots-Tag': 'noindex',
          'Link': `<${url.origin}${url.pathname}>; rel="canonical"`,
        },
      });
    }
  }

  const response = await next();
  const out = new Response(response.body, response);
  out.headers.append('Vary', 'Accept');
  return out;
};

Three details in there earn their place.

env.ASSETS.fetch reads the already deployed static file. The Function does no conversion and holds no copy of the content.

Vary: Accept goes on both branches. One URL now has two representations, and a cache that does not key on the header will serve the Markdown to a browser.

The fallback is a miss on the mirror, not an error. If env.ASSETS.fetch returns 404, the code falls through to the HTML. Adding a page that has no mirror yet degrades quietly.

Detecting the preference deserves more than a substring match. Browsers never send text/markdown, so presence is enough signal, but a client can write Accept: text/markdown;q=0 to mean the opposite:

function wantsMarkdown(accept) {
  if (!accept) return false;
  for (const entry of accept.split(',')) {
    const [type, ...params] = entry.split(';');
    if (type.trim().toLowerCase() !== 'text/markdown') continue;
    const q = params.map(p => p.trim()).find(p => p.toLowerCase().startsWith('q='));
    return !q || Number.parseFloat(q.slice(2)) > 0;
  }
  return false;
}

The result is checkable from any terminal, which is the point of using a mechanism rather than a convention:

$ curl -sI -H 'Accept: text/markdown' https://spintax.net/
HTTP/1.1 200 OK
Content-Type: text/markdown; charset=utf-8
Link: <https://spintax.net/>; rel="canonical"
Vary: Accept
X-Robots-Tag: noindex

Keeping a static site static

A root _middleware matches every request by default. On a site of 116 pages plus assets, that turns a fully static deployment into one where every request invokes a Worker, to serve Markdown on nineteen of them.

_routes.json in the build output fixes it:

{
  "version": 1,
  "include": ["/", "/docs/", "/docs/syntax", "/docs/variables/"],
  "exclude": []
}

We generate that file from the same list that generates the mirrors, so the routed paths and the negotiable paths cannot drift apart. Ninety seven localized pages, the 404 and every asset are served from static storage and never reach the Function.

Two Pages traps we hit on the way

Overlapping _headers rules concatenate

This one cost real time. The site already served its Markdown mirrors with a wildcard:

/*.md
  Content-Type: text/plain; charset=utf-8
  X-Robots-Tag: noindex

Adding skill files under /.well-known/agent-skills/ meant adding a more specific rule for them, with text/markdown. Both rules match /.well-known/agent-skills/spintax-syntax/SKILL.md. The result:

Content-Type: text/plain; charset=utf-8, text/markdown; charset=utf-8

Pages merged the two rules by appending the values. It did not let the specific rule win. The output is not a valid Content-Type and nothing warns you.

The fix was to delete the wildcard and generate one explicit rule per mirror from the build. Eighteen rules instead of one pattern, well under the limit of 100. If two _headers rules can match the same path and set the same header name, assume they will both apply.

wrangler pages dev parses _headers once

The local dev server reads _headers at startup and logs how many rules it parsed. It does not reparse after a rebuild. We fixed the wildcard, rebuilt, retested, and saw the same broken Content-Type because the server was still holding the rules it read two builds ago.

Restart the dev server after any change to _headers. The rule count in the startup log is the quickest confirmation that it picked up the new file.

The three cheap checks

Content Signals. A directive in robots.txt that states how the content may be used by AI systems. It goes inside the User-agent group, under a preamble from contentsignals.org that carries the legal weight:

User-agent: *
Content-Signal: ai-train=yes, search=yes, ai-input=yes

Allow: /

Three signals, three values each: search for indexing, ai-input for retrieval and grounding, ai-train for model training. A documentation site that publishes Markdown mirrors for machines has an obvious answer to all three. Keep the preamble. It is what turns the line from a preference into a reservation of rights under Article 4 of the EU copyright directive.

Link response headers. RFC 8288, and the audit accepts only registered relation types. describedby for machine readable descriptions, alternate for a different representation of the same page, service-doc for the documentation entry point:

Link: </llms.txt>; rel="describedby"; type="text/plain",
      </docs/variables.md>; rel="alternate"; type="text/markdown",
      </docs/>; rel="service-doc"; type="text/html"

An agent that lands on any page can find the rest from the response headers, without parsing HTML and without knowing about llms.txt. This one costs nothing at runtime: it is static _headers output, no Function involved.

Agent Skills. A discovery index at /.well-known/agent-skills/index.json listing skill documents that an agent can install. This is the only one of the four with product value rather than audit value. A skill is a condensed, imperative document addressed to a machine that is about to do something, which is a different artifact from a documentation page written for a person.

The index entries carry a SHA256 digest of each artifact. Generate the index, never write it by hand. A digest written by hand is wrong the first time anyone edits a skill, and a wrong digest tells a client the file was tampered with. We read the name and description from each skill's own frontmatter and hash the bytes as served, so there is one source for the metadata and no second list to maintain.

Eight failures that were correct

The checks still failing are DNS for AI Discovery, API Catalog, OAuth discovery, OAuth Protected Resource, Auth.md, MCP Server Card, A2A Agent Card and WebMCP. Five commerce checks sit alongside them, and the audit marks those neutral rather than failed, because it can tell the site sells nothing.

A documentation site has no API, no authentication and nothing to sell. Publishing an empty OAuth discovery document to raise a score advertises an authorization server that does not exist. Every one of those documents is a promise to a client about what it will find. A promise you cannot keep is worse than a missing file, because the client that reads it wastes a round trip and then has to guess whether you are broken or lying.

Three of them are worth more detail, because the reasoning generalizes.

The MCP Server Card points at a path the specification abandoned

The audit probes three locations for an MCP Server Card: /.well-known/mcp.json, /.well-known/mcp/server-cards.json, and /.well-known/mcp/server-card.json.

The proposal behind it, SEP-2127, is open and unmerged, status Draft, on the Extensions Track. The normative wire format does not live in the specification repository at all. It lives in a repository named experimental-ext-server-card. The discovery path has moved at least three times, and the current canonical one is /.well-known/ai-catalog.json, with media type application/ai-catalog+json, a catalog that indexes cards rather than being one.

None of the three paths the audit probes is the path the specification now uses. Passing that check today means publishing to an address the spec has already left.

DNS-AID: the check its own author does not pass

This one is worth the most, because it is the cleanest example of why you read the failures instead of clearing them.

DNS for AI Discovery asks you to publish SVCB records under an _agents namespace so agents can find your agent endpoints through DNS. It is a pure DNS record: no Worker, no runtime, no cost, and Cloudflare supports SVCB on the free plan. By the usual arithmetic it is the cheapest check on the entire list.

Three things say otherwise.

The specification is an individual Internet-Draft. Version 02, updated 27 May 2026, not adopted by any working group, no formal standing in the standards process, and it expires on 28 November 2026. That is not a reason to ignore it. It is a reason to know what you are building on.

The scanner probes labels the draft does not define. It queries _index._agents, _mcp._agents and _a2a._agents. The draft defines the entry point at _index._agents and selects protocols through the alpn service parameter, not through per-protocol underscore labels. _mcp and _a2a are the checker's, not the specification's — the same mismatch as the MCP Server Card above, from the same cause.

Nobody publishes it. Not a rhetorical nobody. Checked over DNS-over-HTTPS on 22 July 2026:

Domain	`_index._agents`
isitagentready.com	NXDOMAIN
cloudflare.com	no records
agents.cloudflare.com	no records

The audit site itself, and the company that wrote the audit.

And the conclusion that follows: point the scanner at itself. isitagentready.com comes back Level 4, Agent-Integrated, with dnsAid among its own failures — the same level this blog reached, by a tool that fails its own check.

To be fair to the draft, one objection against publishing does not hold. It is tempting to say we have no agents to index, but the draft puts the content of the index endpoint out of scope: it can be a live service or a static document, and there is a well-known service parameter pointing at RFC 8615 metadata. We could honestly point _index._agents at the Agent Skills index we already publish.

We are not going to, and the reason is not honesty. It is that a record satisfying a check that its own author does not implement, against a draft expiring in four months, in a namespace whose labels the checker invented, buys a number and nothing else.

An A2A Agent Card names a live endpoint

The A2A Agent Card requires a url for the A2A service. It describes an agent that other agents can hand work to. We do not run one. Publishing the card would advertise a service that answers nothing.

This also puts a ceiling on the score. Level 5 requires Auth.md, an MCP Server Card, an A2A Agent Card and an API Catalog. A content site can honestly reach maybe one of those. Level 4 is the top of the range for a site that only publishes documents, and that is a property of the ladder rather than a failing of the site.

The MCP server we did not build, and one number that decided it

The one item on the list with genuine value for us is an MCP server: give an agent a validate tool that returns structured diagnostics with line and column, and the loop from "model writes a template" to "model fixes the template" closes without a human in it.

Two findings pushed it out of this week.

The protocol is mid break. The 2026-07-28 revision makes Streamable HTTP stateless. The Mcp-Session-Id header "and the protocol-level session that came with it are also removed", the initialize/initialized handshake is removed, and the transport "now requires Mcp-Method and Mcp-Name headers so load balancers, gateways, and rate-limiters can route on the operation", with a new server/discover method for capabilities. Upstream calls it the largest revision of the protocol since launch. Building against the current shape means rewriting in a week.

The second finding is a number. Cloudflare's documentation is clear that a stateless MCP server needs no Durable Objects and no paid plan, which sounds like the free tier is enough. Then you check what the free tier gives you: 10 ms of CPU per request. We measured the engine we would be wrapping, on Node, so treat it as an order of magnitude rather than a measurement of the target:

Work	CPU
400 byte template, one render, warm	0.13 to 0.28 ms
400 byte template, twenty variants	3 to 6 ms
First call on a cold isolate	about 12.5 ms
16 KB template, twenty variants	about 85 ms

The cold isolate alone is over budget before any template is parsed. A 16 KB template overruns by a factor of eight. A dependable server on the free plan would need caps tight enough to be annoying, around 4 KB of template and five variants. The Workers Paid plan at five dollars a month raises the limit to 30 seconds of CPU and removes the question.

That is a design decision to make before writing code, not after.

Where the score landed, and where this site sits

Three checks passing became seven, and the level went from 1 to 4, "Agent-Integrated". Six more are marked neutral because they do not apply, and the eight that fail are the eight that should.

The useful output was not the number. It was being told that a week of work on llms.txt had produced files no client could negotiate for, which is a specific and fixable thing that no amount of reading our own documentation would have surfaced.

For the record, this blog scored Level 1 when the article was written, three of twenty one: exactly where the other site started. Running the same four checks against it the same day produced a different answer, and the difference is worth more than the score.

All four went in, and it now reads Level 4, the same as the site this article is about. Content Signals, Link headers, an Agent Skills index, and a Markdown mirror of every article indexed in llms.txt. The interesting part is the fourth one, because the shape of the site changes what it costs.

This site is not on Pages. It is a Worker serving static assets, and until today it had no script at all, which is why "requests to static assets are free and unlimited" covered every page view. Negotiation needs code in front of those assets, and any page that runs that code becomes an ordinary Worker request against the free plan's 100,000 per day.

So the code runs on as little as possible: run_worker_first lists the apex and single-segment paths, nothing else. Stylesheets, images, the mirrors themselves, robots.txt and the sitemap never reach it and stay free.

One detail is worth stealing. Cloudflare's cache key does not include Vary unless a Cache Rule puts it there, so one URL with two representations can serve Markdown to a person out of cache. The fix is not a zone rule: it is Cache-Control: no-store on the Markdown branch only. Agents are a trickle, the HTML keeps its normal caching, and the failure mode disappears.

The other one is embarrassing and cheap. Handle HEAD, not just GET. RFC 9110 says a HEAD must answer with the headers a GET would send, and the first version of this did not — which curl -I reported immediately, that being exactly how anyone would check it by hand.

Same four checks, same day, two different sites, and the work was different on each. That is the actual lesson of running an audit: the checks are generic and your infrastructure is not.

Run it against your own domain. Then read the failures and decide which ones describe a site you are actually running:

curl -sS -X POST https://isitagentready.com/api/scan \
  -H 'content-type: application/json' \
  -d '{"url":"https://example.com"}'

The JSON endpoint returns every check with its status, message and the requests it made, which is faster than the browser and easier to diff after a deploy. It reports the level rather than the score; the number out of 100 is the web interface's.

A redirect runs no JavaScript. Here is how to count the click anyway.

301ST — Mon, 27 Jul 2026 14:00:12 +0000

The question is older than most of the tools people suggest for it. A feature request titled "Page Rule statistics" was opened on the Cloudflare Community on 23 May 2017, raised again by its author in 2018 and in 2019, and closed on 6 June 2025 without ever being implemented. In between, someone running short links on printed material asked whether there is a way to know how many hits a redirect rule got in a given timeframe, and received no substantive answer at all before the thread auto closed.

The advice that does exist is to put a page in front of the redirect so that JavaScript has somewhere to run. That is not a workaround. That is switching the redirect off.

Here is why nothing you already have can see the click, and what actually counts it.

Why every analytics tool you own is blind to this

Not a gap in any particular product. A structural fact about what a redirect is.

Every privacy friendly analytics tool in common use — Cloudflare Web Analytics, Plausible, Umami, Counterscale — works the same way: a small script on the page reports that the page was viewed. Cloudflare's own installation instruction is the clearest statement of the problem:

Add the JS snippet to any of your website's HTML pages before the ending body tag.

A 301 response has no HTML page. It has no body tag. There is nowhere to put the beacon and nothing to run it, so the visitor is counted at the destination, if the destination is yours, and not at all if it is not.

A Cloudflare employee said as much in 2023, answering someone who wanted Web Analytics on a domain that only redirects: Web Analytics captures the metric from the client side, and when the source returns a redirect to a third party rather than a page, that cannot be tracked.

Plausible has the same hole, reported in April 2022, answered with a roadmap promise, and still open.

The phase order, which is the real explanation

Cloudflare publishes the order in which its request phases run, and reading it answers the question completely.

Single Redirects run in http_request_dynamic_redirect, the first application layer phase. Bulk Redirects run in http_request_redirect, fifteenth. Snippets run in http_request_snippets, nineteenth. And the rules documentation is explicit about what happens on a match:

For terminating actions (Block, Redirect, or one of the challenge actions), rule evaluation will stop and the action will be executed immediately.

So a redirect that matches produces the response there and then. Everything later in the pipeline never runs, which includes the one place you could have written a log line. Even paying for Snippets does not help: they sit four phases after Bulk Redirects and never see a request that already left.

This is the whole reason the problem has no configuration answer. The thing that counts the click has to be the thing that issues the redirect.

What the built in answer costs

Cloudflare does have a product that hands you raw request logs, and its availability table is short:

Plan	Logpush
Free	No
Pro	No
Business	No
Enterprise	Yes

That is the honest reason this article exists. On any plan below Enterprise, the log you want is something you have to write.

Not KV, and this is worth being specific about

The suggestion you will find in older threads is to write each click into Workers KV, one key per click or one counter key, and read it back with a list. Both shapes are wrong, for different documented reasons.

The free plan allows 1,000 writes per day. A redirect that gets any real traffic exhausts that before lunch, and then silently stops recording.

More fundamentally, KV limits you to one write per second to the same key, on every plan. A single counter key is exactly the access pattern KV is built to refuse. Paying more does not change that number.

The thing that does work: a Worker and Analytics Engine

Workers Analytics Engine is built for exactly this shape of data, and it is on the free plan:

	Free
Data points written	100,000 per day
Read queries	10,000 per day
Retention	three months

Compared with KV's thousand writes, that is a hundred times the room, and the write path is designed for one event per request rather than a mutable counter.

Bind a dataset:

# wrangler.toml
[[analytics_engine_datasets]]
binding = "CLICKS"
dataset = "redirect_clicks"

Then let the Worker issue the redirect and record it on the way past:

export default {
  fetch(request, env) {
    const url = new URL(request.url);
    const target = "https://example.com/offer";

    env.CLICKS.writeDataPoint({
      indexes: [url.hostname],
      blobs: [
        url.pathname,
        url.searchParams.get("gclid") ?? "",
        request.headers.get("referer") ?? "",
        request.cf?.country ?? "",
      ],
      doubles: [1],
    });

    return Response.redirect(target, 301);
  },
};

Four details in those twenty lines matter.

Do not await the write. Cloudflare's guidance is explicit that writeDataPoint is non blocking and returns immediately, with the runtime persisting the data in the background. Awaiting it would add latency to a hop whose entire job is to be fast.

The index is the sampling key, and the limits are one index per call, at most 96 bytes. Put something low cardinality there — the hostname, the campaign — not the full URL. Blobs are where the high cardinality detail goes: up to twenty of them, 16 KB in total, with 250 data points per invocation.

Read the click ID here, at the only hop that is guaranteed to see it. This is the same parameter that a misconfigured Bulk Redirect quietly deletes; if your own Worker is the redirect, you decide what survives instead of choosing between two halves of a query string.

Response.redirect(target, 301) is a real 301. No interstitial, no meta refresh, no JavaScript. Search engines see a permanent redirect, and the visitor sees one hop.

Reading it back

Analytics Engine has a SQL API. One curl, one token with Account Analytics Read:

curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/analytics_engine/sql" \
  --header "Authorization: Bearer $CF_API_TOKEN" \
  --data "SELECT blob1 AS path,
                 SUM(_sample_interval) AS clicks
          FROM redirect_clicks
          WHERE timestamp >= NOW() - INTERVAL '7' DAY
          GROUP BY path
          ORDER BY clicks DESC"

SUM(_sample_interval) rather than COUNT() is not a stylistic choice. At volume the data is downsampled, and each stored row then stands for several real ones:

_sample_interval indicates what the sample rate is for this row (that is, how many rows of the original data are represented by this row)

Count the rows and you will under report, by a factor that changes with traffic. Sum the interval and the number is right at any volume.

What this gives you, and what it does not

It gives you a count of requests, with whatever dimensions you chose to write, on a hop that happens before the browser goes anywhere. Nothing to consent to, nothing for a blocker to block, no cookie, because the click is a request to your own hostname rather than a script loaded from someone else's.

It is not attribution. Every request is counted, including bots and preview fetchers, and nothing here ties a click to a conversion that happens on a page you do not own. That is a harder problem and a different article.

And it changes what your redirect is. A Redirect Rule is configuration: no deploy, no code, no one to maintain it. A Worker is software, with a rollback and a person who has to understand it later. For one link that trade is usually worth it. For the full list of ways to redirect and what each one costs, the comparison is worth reading before you move a working rule into code.

Where this stops being twenty lines

One redirect, one Worker, one dataset: an afternoon, and the numbers are yours.

The shape changes when the redirects are a portfolio. Every link that needs counting needs the Worker in front of it, every domain needs the route, and the dataset needs someone to query it on a schedule rather than when somebody wonders. At that point you are maintaining a small analytics product as a side effect of wanting to know how many people clicked. That is the job 301.st does by default. For a single link, the Worker above is the whole answer, and it is free.