Agent readiness

Agent readiness is the shape of a domain’s static agent surface: the files and endpoints an arriving AI agent — or a static, HTML-only crawler that never runs JavaScript — can discover without cooperation from the site. Sill offers a public scan of that surface at sill.so, sends a per-signal report by email when you sign up with a domain, and gives you three ways to make your domain statically agent-ready.

The public scan on sill.so

The hero on sill.so accepts a domain and, in a few seconds, checks eight independent ecosystem signals from that domain’s public surface. The scan is anonymous, unauthenticated, and rate-limited; nothing is installed or changed on the target site.

What the scan checks

The scan runs eight probes in parallel against the domain you typed. Every probe reads a public file or endpoint — the same files an AI agent or static crawler would read.

Group	Signal	What is checked
Discovery	Agent card	Whether the domain (or Sill on its behalf) publishes a card at /.well-known/agent-card.json.
Discovery	llms.txt	Whether /llms-full.txt or /llms.txt is served — a plain-text description of the business for language models.
Discovery	Sitemap	Whether /sitemap.xml answers with a well-formed sitemap.
Access	AI access	Whether robots.txt allows or blocks a pinned list of named AI crawlers — GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot, and more.
Access	Content signals	Whether robots.txt declares Content-Signal: directives per contentsignals.org.
Protocols	MCP server	Whether an MCP server card is served at /.well-known/mcp/server-card.json (SEP-1649) or the earlier /.well-known/mcp.json.
Protocols	API catalog	Whether /.well-known/api-catalog per RFC 9727 is served.
Content	Structured data	Whether the homepage carries schema.org JSON-LD blocks.

If a Sill install is detected for the domain — from the edge-side store-discovery oracle or from markers on the fetched homepage — a Sill install: Live row is shown above the others. That row is not counted in the score: the score is a measure of the ecosystem-signal surface, not of Sill’s own product.

How results are shown

Results render as a boxed, grouped report with one row per signal. Each row is tap- or click-expandable and reveals:

• What the signal is — one line explaining what an agent uses it for.
• A one-line fix — shown only when the signal is missing. For surfaces Sill itself publishes (the agent card and the per-site MCP server) the fix names Sill; for surfaces Sill does not publish (llms.txt, structured data, sitemap) the fix names the underlying file or generator.
• At most one external resource link — e.g. llmstxt.org for llms.txt, contentsignals.org for Content Signals.

The overall verdict is a single sentence driven by the real signals — e.g. “yourdomain.com is partly agent-ready — 4 of 8 signals live.” — with a SHOPIFY STORE / WOOCOMMERCE STORE / WORDPRESS kicker when the homepage identifies the platform.

Honesty rules

The scan is designed to under-claim, not over-claim. Three invariants:

• Signals only, no fabricated guarantees. Every row derives from an actual probe result; a probe that could not read the origin renders as an em dash under a SCAN FINISHED · LIMITED SIGNAL header, not as “absent”. A signal is only “absent” when the origin was reached but the file was not there.
• Sill-friendly forcing is bounded. The agent card and MCP rows are marked present when either the direct probe finds them OR a Sill install is detected — Sill publishes both when installed. The API catalog is not forced on: the Sill install proves card + MCP, not catalog contents.
• AI access is interpreted, not counted. A robots.txt that root-disallows every listed AI crawler is AI BOTS BLOCKED (amber); some blocks is SOME BOTS BLOCKED; none blocked is OPEN. A missing but reachable robots.txt is OPEN by the Robots Exclusion Protocol default-allow rule.

The follow-up report email

When you enter a domain on the sill.so hero and continue to the email step, Sill sends a second email at sign-in — separate from the sign-in link — containing your full agent-readiness report.

The report runs the same probes and the same interpretation as the scan on the hero. It goes further only in what it includes in each row:

• Per-signal evidence — the specific URL that was checked, and (for AI access) the exact pinned AI-crawler tokens your robots.txt blocks.
• Why it matters — one line on what agents lose when the signal is missing.
• Fix guidance — one line on how to add the signal. For surfaces Sill publishes, the fix names finishing your Sill install.

The report carries no authentication link. Its call-to-action is a plain link to your dashboard; the one-time sign-in link lives only in the sign-in email. This split is deliberate — a report is a report, not a credential.

Delivery is deduped so it does not become a mail stream: sending the same email address the same domain within a short window suppresses a duplicate report. If a report cannot be generated (the target origin was fully unreachable, or an internal budget elapsed), no report email is sent and no error is surfaced on the sign-in path — the sign-in itself always completes.

How to become statically agent-ready with Sill

The scan measures the static surface — files an HTML-only crawler can read without executing JavaScript. Sill installs on any site with a one-line script tag (see Embed script), but the script tag injects the discovery <link> tags at runtime: an agent that never runs JavaScript sees nothing at /.well-known/agent-card.json unless the file is also served statically.

Sill offers three ways to serve the static agent card at your domain. Each pairs with the same ownership proof (see Domain verification) and each publishes the same signed agent card from your own origin.

The Sill WordPress plugin

For WordPress sites, the dashboard’s Install tab hands you a downloadable .php file, pre-configured with your site’s identifiers. Installed as a WordPress plugin, it does two things:

• Serves /.well-known/agent-card.json from your own origin, proxied from Sill’s edge so the card is always the current, signed card.
• Serves /.well-known/sill-proof.txt — the per-site proof token Sill’s origin fetches to confirm domain ownership.

Because the plugin proxies the live signed card at request time, the card never goes stale as you change skills in the dashboard.

The Cloudflare Worker

For any domain fronted by Cloudflare, the dashboard’s Install tab includes a Cloudflare Worker path. You provide a scoped API token; Sill deploys a Worker to your zone that does the same two things as the WordPress plugin (proxies the live agent card and serves the proof token), plus a fire-and-forget log of AI-crawler visits. The Worker is a small, self-contained script generated fresh per site so its identifiers match yours.

The downloadable static agent card

For everything else — a static host, a custom stack, any site where you can upload a file at /.well-known/agent-card.json — the dashboard exposes a Download agent-card.json button. The downloaded file is a pure pointer, not a snapshot:

{
  "schemaVersion": "v1",
  "name": "Your site",
  "url": "https://yourdomain.com",
  "provider": { "name": "Sill", "url": "https://sill.so" },
  "endpoints": {
    "agentCard": "https://edge.sill.so/v1/agent-card/<site_key>.json",
    "mcp": "https://edge.sill.so/v1/mcp/<site_key>",
    "mandate": "https://edge.sill.so/v1/m/<site_key>/mandate"
  }
}

An agent that reads this file follows endpoints.agentCard to the live, signed card at Sill’s edge and gets your current skill set. Because the downloaded file carries no capabilities or skills array of its own, it cannot go stale when you change your skills: upload it once, never re-upload.

Why the script tag alone is not enough for static crawlers

The embed script is CSP-safe, cookie-free, and takes one line to install. When it runs it injects two <link> tags into <head> — one for the agent card and one for the ARD catalog — so DOM-parsing agents discover the signed manifests immediately.

But a static crawler that fetches your homepage’s HTML and never executes JavaScript will not see the injected <link> tags, and hitting /.well-known/agent-card.json directly on a site that only has the script tag returns nothing. To be discoverable to those static tools, the well-known file needs to be served — from the plugin, the Cloudflare Worker, or the downloaded static file. On Shopify, the OAuth-driven install pairs the script tag with a Cloudflare Worker deploy for exactly this reason.

See also

• Embed script — the one-line script tag install.
• Agent card — what the signed card contains and how signing works.
• Domain verification — the ownership proof each install path satisfies.
• Sites and onboarding — the four-step shell that runs the install and verify.
• MCP server — the per-site MCP endpoint the scan’s MCP server row covers.
• Verify a signature — how a third party verifies any Sill-signed surface.