# sitesfor.ai — extended

> Websites for AI agents. Adapted to published standards. In code you own.

This document is denser than /llms.txt. It inlines post bodies, FAQ answers,
the studio-vs-saas comparison, the standards we test against, the canonical
signal catalogue, and pricing — for AI bots that prefer a single long-form
document over crawling each route.

## SKU ladder (USD primary)

### Free Checker — $0

Free Checker scans a single URL against 43 published AI-agent-readiness signals and returns a deterministic letter grade, a global and vertical percentile, and the top-3 fixes in seconds.

Features:
- Letter grade A–F, in seconds
- Tested against 43 published, vendor-neutral standards
- Where you stand vs. every other site we've scanned — globally and within your vertical
- Top 3 fixes that move your grade the most
- Evidence for every score — verifiable yourself with `curl`

Not included:
- No JS-rendered DOM scan
- No live MCP / ACP / x402 handshake
- No persistent URL — the report exists in the browser tab

### Setup — from $5,000, one-time

Setup is a one-time engagement that adapts an existing codebase for AI-agent readiness across all relevant signal groups (Discovery, Identity, Agent Contracts, Citation, Rendering, Hygiene, Commerce). It fixes every failing Checker signal, builds out missing coverage, installs server-log crawler analysis, configures GA4 AI-source segmentation, and delivers a baseline citation report and a before/after grade. Fixed-price, scope-based, deliverable is PRs into the customer repository. From $5,000. Contact via mailto or Calendly.

Features:
- Every failing Checker signal fixed — plus the signal coverage your site is missing
- A baseline citation report across ChatGPT, Claude, and Perplexity
- Server-log AI-crawler analysis installed; GA4 AI-source segmentation configured
- Multi-page template audits (catalog, blog, docs) where they apply
- Fixed-price scope agreed up front — no hourly surprises
- 30 days of post-launch support and a validation re-scan documenting the score delta
- Works with whatever your site is built on (Next, Astro, Nuxt, Hugo, WordPress, custom)

Not included:
- No greenfield builds in v1 (existing codebases only)
- No SaaS layer running on our infrastructure
- No self-serve checkout — scope is set on a discovery call

### Retainer — Monitor — $1,500/mo

Retainer (Monitor tier) — $1,500/mo, 3-month minimum. Keeps a site from decaying after a Setup: monthly client report, schema/standards maintenance, a 50-prompt monthly citation panel, and a monthly Checker score delta. Sold after a Setup engagement.

Features:
- Monthly client report — skimmable in 90 seconds
- Schema and standards maintenance as the published specs evolve
- 50-prompt citation panel run monthly across ChatGPT, Claude, Perplexity
- Monthly Checker score delta — what shipped, what is queued
- ~2 hours of consult

Not included:
- No content production
- No off-site co-citation work

### Retainer — Grow — $3,500/mo

Retainer (Grow tier) — $3,500/mo, 3-month minimum. The hero tier. Everything in Monitor plus biweekly reporting, a 150-prompt weekly citation panel, ~4 pages/month of content and entity work, and server-log crawler analysis with action items.

Features:
- Everything in Monitor
- Biweekly reporting
- 150-prompt citation panel run weekly
- ~4 pages/month of content and entity work
- Server-log AI-crawler analysis with action items
- ~4 hours of consult

Not included:
- No off-site co-citation campaign
- No weekly call

### Retainer — Dominate — $7,500/mo

Retainer (Dominate tier) — $7,500/mo, 3-month minimum. Everything in Grow plus weekly reporting, a 300+ prompt daily citation panel, content/entity/off-site co-citation work, and a weekly call.

Features:
- Everything in Grow
- Weekly reporting
- 300+ prompt citation panel run daily
- Content, entity, and off-site co-citation work
- Weekly call

Not included:
- No greenfield builds
- No SaaS layer on our infrastructure

## Studio-vs-SaaS comparison (no vendor names)

- **Lock-in** — Studio: Code in your repo. Cancel anytime — the work survives. · SaaS platforms: Runtime layer served from vendor infrastructure. Cancel and it disappears.
- **Third-party JS on your domain** — Studio: None. Zero third-party scripts — no checkout, no analytics, no CDN fonts. · SaaS platforms: Tracking script + dashboard auth iframe required.
- **Code ownership** — Studio: You own the PRs after the engagement. No license, no SaaS layer. · SaaS platforms: Methodology is proprietary. The "AI layer" is not in your repo.
- **Methodology transparency** — Studio: Standards-only: schema.org, llms.txt, OpenAPI 3.1, MCP, ACP, AP2, x402, ... · SaaS platforms: Closed dashboard. Trademarked "AI Position Intelligence™"-style scoring.
- **Recommendations** — Studio: Deterministic — top-3 fixes from a fixed table, not LLM-generated. Never contradicts the evidence panel. · SaaS platforms: LLM-generated. Frequently recommends fixes the evidence panel shows are already in place.
- **Transactability (buyer agents)** — Studio: Commerce group graded: ACP feed, AP2 mandates, x402 challenge, schema.org Offer. · SaaS platforms: AEO discoverability only. Buyer-agent commerce layer ungraded.
- **How you pay** — Studio: A one-time Setup, then an optional monthly retainer you can cancel after 3 months. · SaaS platforms: An indefinite subscription billed from day one. Stop paying and the layer goes dark.

*A studio, not a platform. Your repo, not our domain. A retainer you can cancel, not a subscription you cannot.*

## Standards we test against

- **schema.org** (W3C / WHATWG community) — https://schema.org/ — last checked 2026-06-15
- **JSON-LD** (W3C) — https://www.w3.org/TR/json-ld11/ — last checked 2026-06-15
- **schema.org Offer** (schema.org) — https://schema.org/Offer — last checked 2026-06-15
- **llms.txt** (llmstxt.org) — https://llmstxt.org/ — last checked 2026-06-15
- **OpenAPI 3.1** (OpenAPI Initiative) — https://spec.openapis.org/oas/v3.1.0 — last checked 2026-06-15
- **MCP** (Anthropic / community) — https://modelcontextprotocol.io/ — last checked 2026-06-15
- **IndexNow** (Microsoft + community) — https://www.indexnow.org/ — last checked 2026-06-15
- **robots.txt** (IETF / community) — https://datatracker.ietf.org/doc/html/rfc9309 — last checked 2026-06-15
- **ACP** (OpenAI + Stripe) — https://github.com/agentic-commerce-protocol/agentic-commerce-protocol — last checked 2026-06-15
- **AP2** (Google + community) — https://ap2-protocol.org/ — last checked 2026-06-15
- **x402** (Coinbase + community) — https://www.x402.org/ — last checked 2026-06-15

*We test against published, documented, vendor-neutral standards. We do not score sites against proprietary or unpublished protocols.*

## Signal catalogue (43 signals, weighted to 100)

### discovery

- **1.** /robots.txt exists — 2 pts
- **2.** AI bot policy explicit per UA (GPTBot, ClaudeBot, OAI-SearchBot, Google-Extended, PerplexityBot, Bingbot, Applebot-Extended, CCBot) — 5 pts
- **3.** /sitemap.xml valid — 4 pts
- **5.** /llms.txt parseable — 3 pts
- **6.** /llms-full.txt extended summary — 1 pts
- **7.** IndexNow key file present — 3 pts
- **8.** Markdown variant for AI UAs (<route>.md) on every route — 2 pts
### identity

- **9.** JSON-LD parses cleanly via ajv — 6 pts
- **10.** Organization complete — 5 pts
- **11.** Person (founder) linked from Organization.founder — 2 pts
- **12.** Reciprocal sameAs verification cross-domain — 3 pts
- **13.** WebSite schema present — 2 pts
- **14.** BreadcrumbList on inner pages — 2 pts
- **15.** OG + Twitter card present — 1 pts
- **16.** Favicon SVG variant + hreflang where multilingual — 1 pts
### agent-contracts

- **18.** OpenAPI 3.1 document valid — 5 pts
- **21.** MCP discoverable at /.well-known/mcp.json — 5 pts
- **22.** MCP initialize handshake completes + tools/list returns ≥1 tool — 6 pts
- **23.** OpenAPI server URLs respond — 2 pts
### rendering

- **24.** SSR detection — raw fetch vs. headless DOM diff acceptable — 1 pts
- **25.** Canonical consistent — 3 pts
- **26.** Strong ETag / Last-Modified headers — 1 pts
- **27.** Brotli on machine-readable resources — 1 pts
- **28.** HTTP/2 or HTTP/3 — 1 pts
- **29.** No JS-required navigation — 1 pts
### citation

- **30.** Definitional sentence density — 1 pts
- **31.** Stable claim anchors — 1 pts
- **32.** Fact card block — 1 pts
- **33.** Heading hierarchy clean — 1 pts
- **34.** Image alt density ≥85% — 1 pts
- **35.** FAQPage schema if FAQ detected — 1 pts
- **36.** Article + dateline on blog — 1 pts
- **37.** Statistics tables annotated — 1 pts
### hygiene

- **38.** HTTPS + HSTS, no mixed content — 4 pts
- **39.** Last-Modified within 12 months — 2 pts
- **40.** No noindex on root + privacy policy present — 2 pts
- **41.** security.txt present — 2 pts
- **42.** Robots.txt does not unintentionally block AI bots needed for discoverability — 2 pts
### commerce

- **43.** ACP feed valid (/sitesfor.acp.json or claimed in OpenAPI servers) — 2 pts
- **44.** ACP checkout endpoint reachable + capability-negotiated — 2 pts
- **45.** AP2 mandate-verifier endpoint resolves a test Intent Mandate — 2 pts
- **46.** x402 challenge on at least one paid endpoint — 2 pts
- **47.** schema.org Offer with price/currency/availability on commercial pages — 4 pts
- **49.** WebMCP manifest present (W3C Web Machine Learning CG draft) — 1 pts (preview, weighted 0)
- **49.** Google WebMCP manifest present — 1 pts (preview, weighted 0)

## FAQ

### What is "AI-agent readiness"?

It is the property of a website that allows three distinct kinds of
software readers — crawlers, assistants, and buyer agents — to use it
fluently against published, vendor-neutral standards. The Checker grades
a catalog of deterministic signals across seven groups and returns a
letter grade plus a global percentile.

### How is this different from SEO?

SEO grades pages against ranking signals for Google's index. AI-agent
readiness grades pages against the standards three different software
audiences need: crawlers (`/robots.txt`, `/llms.txt`, sitemaps), assistants
(JSON-LD identity, OpenAPI 3.1, MCP handshake), and buyer agents (ACP, AP2,
x402, schema.org Offer). The overlap with SEO is in the Hygiene group and
parts of Citation — perhaps a third of the catalogue. The rest is new
surface area.

### What does a Setup engagement include?

Setup is the studio's one-time engagement. We adapt your site so AI agents
— crawlers, assistants, and buyer agents — can use it fluently. Scope is
agreed on the discovery call; the engagement fixes every failing Checker
signal and builds out the signal coverage your site is missing (Discovery,
Identity, Agent Contracts, Citation, Rendering, Hygiene, Commerce),
including multi-page template audits (catalog, blog, docs) where they
apply. It also includes a baseline citation report, server-log crawler
analysis installed, GA4 AI-source segmentation configured, and a
before/after Checker grade. Fixed-price scope agreed up front, 30 days of
post-launch support, and a validation re-scan after launch. Deliverables
are pull requests or commits into your repository — the code is yours
after the engagement, no runtime dependency on the studio. Afterwards, an
optional monthly Retainer keeps the score from decaying as the standards
move. The studio adapts existing websites only in v1 (no greenfield
builds) and works with whatever your site is built on (Next, Astro, Nuxt,
Hugo, WordPress, custom).

### Is the AI-bot markdown variant cloaking?

No. Cloaking is serving substantively different content to bots versus
humans to manipulate ranking. We serve the same content to both, in two
encodings: HTML for humans, a denser markdown variant for AI bots that
benefit from it. The text, claims, and structure are identical; only the
encoding differs. This is documented on `/policy.txt`, and the markdown
variant is grepped on every build to verify content parity.

### Do you grade on a curve, or compare me against my industry?

No curve. The Checker grades against universal published standards, so your
letter grade is absolute — it never softens because your industry's average
is also low. But the report does show you a map. Alongside the absolute
grade you get a global percentile against the whole corpus, a vertical
percentile against your self-classified peers ("among SaaS sites, your 67 is
the median"), and a per-signal corpus-wide pass rate. The vertical number is
a sales and prioritisation map, not a comfort blanket: it tells you how far
the realistic frontier is, while the per-signal rarity tells you which fixes
are table-stakes and which are genuine competitive moats.

### What data do you store about my site?

One row per scan in a SQLite corpus on a single VPS — the URL, scan mode,
score, signal results, and timestamp. No PII (websites are public
information; the privacy framework that applies to user data does not
apply to scan inputs). No cookies set on visitors. Reports themselves are
ephemeral — returned inline as the HTTP response body and discarded after
the request.

### Can AI agents call the Checker themselves?

Yes. The site is itself agent-callable. The Checker is exposed as a tool
via an MCP server at `/.well-known/mcp.json` and `/api/mcp`. The studio's
catalogue is published as an ACP feed at `/sitesfor.acp.json` so buyer
agents can discover purchasable SKUs and complete a Stripe Checkout flow
on a user's behalf. The reference implementation is the proof.

## Blog posts (inline)

### An AI-readiness score is not the point. Fixing it is.

*Published 2026-06-07 · tags: essay · https://sitesfor.ai/blog/ai-readiness-score-is-not-enough*

Free AI-readiness scanners are everywhere now. We scanned 97 leading B2B SaaS sites — 84 of them (87%) scored an F. The score was never the hard part. Shipping the fix into your codebase is.

import FactCard from '~/components/content/FactCard.astro';
import ClaimAnchor from '~/components/content/ClaimAnchor.astro';

<FactCard
  about="AI-readiness scores vs. fixes"
  body="A growing number of free tools will score how ready a website is for AI agents. A score is now a commodity. In a scan of 97 leading B2B SaaS sites against published, vendor-neutral standards, 84 of them (87%) scored an F and none scored above 53/100 — so the score itself rarely surprises anyone. The work that moves the needle is implementing the missing standards in the site's own codebase: llms.txt, machine-readable identity, an agent-callable surface, schema.org Offer hygiene."
/>

In the last year, checking whether your website is "ready for AI" went
from novel to commodity. There are now a dozen free scanners that will
take your URL and hand back a grade. A large infrastructure vendor ships
one. We ship one too — it's the free Checker on this site.

So let's be honest about what a score is worth: not much, on its own.

## The score is the easy 5%

We pointed our Checker at 97 well-known B2B SaaS companies — the kind of
teams with real budgets and good engineers — and graded each against
published, vendor-neutral standards for the three audiences a modern site
serves: crawlers, assistants, and buying agents.

<ClaimAnchor id="benchmark">
84 of the 97 — 87% — scored an F. Not one scored above 53 out of 100.
Around 91% gave AI crawlers no specific instructions at all; roughly half
had no `/llms.txt`; none exposed a machine-readable catalogue a buying
agent could act on.
</ClaimAnchor>

Read that again: companies you've heard of, almost uniformly failing. Which
tells you the diagnosis is not the bottleneck. If nearly everyone scores an
F, a tool that simply *reports* the F is telling you something you could
have guessed. The score is the easy 5% of the problem. The hard, valuable
95% is the part every scanner stops short of: actually changing the site.

## Why the fix is the hard part

The fixes aren't exotic. They're published standards most teams just
haven't gotten to — a parseable `/llms.txt`, complete `Organization` and
`Person` schema, an `ai-plugin.json` and OpenAPI description if you have an
API, `schema.org` `Offer` markup if you sell something. Nothing here
requires inventing technology.

What it requires is engineering time inside *your* codebase: someone who
understands your Astro or Next or Rails app well enough to add the markup
to the right templates, wire the build to emit the right files, and not
break anything. That's the work a score can't do for you. A dashboard that
tells you "you're missing llms.txt" has handed you a ticket, not a
solution — and that ticket competes with your roadmap and loses, quarter
after quarter. That's exactly why 86% are still failing.

## A score you rent vs. code you own

This is the line that matters when you compare the options. Most of the
AI-readiness tools are SaaS dashboards: you pay monthly, you get a number
and a checklist, and the implementation is still your problem. The number
lives on their domain; the work, if it ever happens, lives on yours.

We do it the other way around. The diagnosis is free — run the Checker,
get the grade, no sign-up. The implementation is a fixed-scope engagement
that ships as pull requests into *your* repository. You own the code after.
No SaaS layer running on someone else's infrastructure, no monthly fee to
keep seeing your own score, nothing to rip out if you part ways.

<ClaimAnchor id="own-it">
A score is something you rent. The fix is something you own. Only one of
them changes whether an AI assistant cites you next quarter.
</ClaimAnchor>

## What to do with this

Run the [free Checker](/check) — get your grade in seconds, same as the 97
sites above. If you land where most do, the number won't shock you. The
useful question is the next one: who's going to implement the fixes, and
where will that code live?

If the answer is "us, eventually, when the roadmap allows," history says
that's a no. If you'd rather have it shipped into your repo now, against a
fixed scope, with a before/after grade to prove it moved — that's the
engagement. [Talk to the studio.](/#contact)

The scanners aren't wrong. They're just the first 5%.

---

*How we tested: we attempted 122 well-known B2B SaaS companies and
successfully scanned 97 (the other 25 block non-browser traffic outright —
itself a readiness problem, since several AI crawlers identify as bots).
Each site was graded with our light-path Checker against published,
vendor-neutral standards — schema.org, llms.txt, OpenAPI 3.1, MCP, ACP,
robots.txt and others — scored to 100. No site was named; the numbers are
aggregate. Run the same check on your own site at [/check](/check).*

---

### Build-time JSON-LD vs. runtime JSON-LD

*Published 2026-05-14 · tags: essay · https://sitesfor.ai/blog/build-time-vs-runtime-jsonld*

Three failure modes of hand-rolled structured data — and the build-time fix that ships in your repo, not someone else's.

import FactCard from '~/components/content/FactCard.astro';
import ClaimAnchor from '~/components/content/ClaimAnchor.astro';
import DefinitionBlock from '~/components/content/DefinitionBlock.astro';

<FactCard
  about="JSON-LD strategy"
  body="Hand-rolled JSON-LD has three real failure modes: drift between schema and visible content, coverage gaps across pages, and silent invalid graphs. Two responses exist. Runtime APIs generate JSON-LD on every request from a vendor-hosted service — they solve the failure modes by creating a runtime dependency. Build-time generation derives JSON-LD from typed data at compile time, validates with ajv in CI, enforces coverage via layout slots — same outcomes, code lives in your repo, no subscription. Build-time first; runtime only when the data genuinely cannot go through a CI cycle."
/>

There's a thread of category-leading marketing that argues: hand-rolled JSON-LD drifts,
has coverage gaps, ships invalid graphs, and therefore you should subscribe to a runtime
schema-generation API. The first half of the claim is correct. The conclusion is a
non-sequitur. The same failure modes are solvable at build time, in your repo, with no
runtime dependency on anyone.

<DefinitionBlock>
**Build-time JSON-LD is** structured data generated from typed source code during the
build, validated against `schema.org` shapes in CI, and embedded as static
`<script type="application/ld+json">` blocks in the deployed HTML. The vendor is not in
the request path; the customer's CI is.
</DefinitionBlock>

## The three failure modes are real

<ClaimAnchor id="drift">
**Drift** is when the JSON-LD says one thing and the page renders another.
</ClaimAnchor>
The `Article.headline` declares *"How we ship in 8 weeks"* but the `<h1>` reads *"How
we ship a product in 8 weeks."* The `Organization.name` is *"Acme, Inc."* but the
visible brand is *"Acme."* The `Offer.price` says *"$99"* but the cart shows *"$89"*
because the team forgot to update the schema after a sale.

AI assistants quoting the JSON-LD — and humans reading the page — disagree about what
the site actually said. The model that cites the page now has a citation that doesn't
match its source.

<ClaimAnchor id="coverage">
**Coverage gaps** are when *some* pages have JSON-LD and others don't.
</ClaimAnchor>
The homepage emits `Organization` and `WebSite`. The pricing page emits `Offer`. The
blog has `Article` on three of seven posts because the engineer who set them up
finished four and ran out of time. The product pages have nothing because the schema
was never wired into the catalog template.

A crawler that builds an entity graph from your site comes away with a partial picture.
Every page that should have schema and doesn't is a row missing from the dataset the
crawler is trying to assemble.

<ClaimAnchor id="invalid">
**Invalid graphs** are silent failures.
</ClaimAnchor>
The `Organization` is missing a required `name` field. The `Article.author` is a
string instead of a `Person` object. The `BreadcrumbList` numbers its items starting
from `0` instead of `1`. The page parses fine in the browser — no JS error, no visible
broken layout — and ships. A strict parser quietly drops the bad block; a permissive
one tries to use a malformed graph. Either way, the content is invisible to whatever
was supposed to read it.

These failure modes compound. A site that's been live for three years with hand-rolled
JSON-LD pasted into Liquid templates has all three problems by default.

## Response A: runtime JSON-LD APIs

One answer goes: install a runtime service that inspects each URL's rendered content
and emits a fresh, valid JSON-LD graph on every request. Because the service generates
the graph dynamically, it doesn't drift; because it runs against every URL it
configures coverage; because it validates before emitting, it can't ship invalid.

All three failure modes — solved.

The cost is what the service costs you.

<ClaimAnchor id="runtime-cost-lock-in">
**Cancel, and the schema disappears.** The structured data is rendered by a service
running on someone else's infrastructure. When the subscription ends, every page that
relied on the runtime emission has no JSON-LD. The fix is also the lock-in.
</ClaimAnchor>

The schema-generation service is a third party doing work on the customer's domain at
request time. That means:

- **A single point of failure on every page load.** If the schema API has an outage,
  the structured-data `<script>` tags are empty on every page request during the
  outage. Crawlers that hit your site during the window see a site with no JSON-LD.
- **Request-time latency.** Every page either waits for the schema service or renders
  without it on cold cache. Either choice has a cost.
- **A third-party scraper on your domain.** The service has to fetch every URL to
  inspect content. That's outbound bandwidth and processing time bookmarked against
  the vendor's plan tier.
- **A procurement objection.** For any buyer running a security review — regulated
  industry, large enterprise, security-conscious infra team — a third-party service
  rendering content into the production HTML triggers DPA review, sub-processor list
  updates, and a sign-off cycle that takes weeks.

The runtime API isn't wrong about the failure modes. It's wrong that you need a vendor
in your request path to fix them.

## Response B: build-time JSON-LD with typed source

The build-time approach is older, plainer, and structurally stronger. It works like
this.

### Drift — fixed by typing the data source

Define the structured data the page is going to render as a typed TypeScript object
that *is the source of truth for both the JSON-LD block and the visible content*:

```typescript
// pricing.ts
export const SETUP_SKU: Sku = {
  name: 'Setup',
  priceUsdCents: 500000,
  description: 'One-time engagement. Adapts an existing codebase for AI-agent readiness.',
};
```

The pricing page reads this object to render its visible content. The JSON-LD builder
reads the same object to emit the `Offer`:

```typescript
buildOfferJsonLd({
  name: SETUP_SKU.name,
  price: SETUP_SKU.priceUsdCents / 100,
  priceCurrency: 'USD',
});
```

The JSON-LD cannot drift from the visible content, because both are derived from the
same source. Update the source, both update at the next build. If the source is wrong,
the page is wrong and the schema is wrong identically — which is at least honest.

### Coverage gaps — fixed by layout-level enforcement

Make JSON-LD a layout-level concern. In Astro:

```astro
---
// Base.astro
interface Props {
  jsonLd: Record<string, unknown>[];
}
const { jsonLd } = Astro.props;
---
<head>
  {jsonLd.map((block) => (
    <script type="application/ld+json" set:html={JSON.stringify(block)} />
  ))}
</head>
```

Every page that uses the Base layout is required to pass `jsonLd`. The build fails if
a key page tries to render without one. CI is enforcing what humans cannot reliably
enforce.

### Invalid graphs — fixed by CI validation

Run `ajv` against the JSON-LD blocks during the build. Use `schema-dts` types to
get TypeScript-level validation before the JSON ever serialises. Either fails the
build before merge.

```typescript
import { validateJsonLd } from '@sitesforai/shared/validators';

const result = validateJsonLd(JSON.stringify(jsonLd));
if (!result.ok) {
  throw new Error(result.errors.join('\n'));
}
```

Invalid graphs don't reach production because the CI gate doesn't let them. Same
outcome as the runtime API's "the API refuses to emit invalid" guarantee — without
the runtime API.

## What the studio actually ships

A Setup engagement that includes the JSON-LD layer ships, in PRs into your
repository:

- **Typed data sources** for each schema type the site uses (`Organization`, `Person`,
  `Article`, `BreadcrumbList`, `Offer`, `FAQPage`, `WebSite`).
- **Layout slot** in the base template that requires JSON-LD on every key page.
- **ajv + schema-dts CI validation** that fails the build on invalid graphs.
- **A failing-test fixture** for any specific JSON-LD shape that the team can extend
  when the schema needs to change.
- **The day-30 re-scan** documenting that the JSON-LD coverage, validity, and
  alignment with visible content all moved measurably.

The customer ends up with structured data that lives in their repo, validates in
their CI, and doesn't disappear if anyone goes quiet.

## When runtime is genuinely OK

There's one case where the runtime argument has some weight: sites with a hundred
thousand products and daily price changes that cannot realistically go through a
build-and-deploy cycle for every update. There, on-the-fly schema generation has
a cost case.

Even then, the answer isn't necessarily a third-party API. Most modern frameworks
support incremental static regeneration (ISR) or on-demand revalidation: change a
product, the page regenerates, the JSON-LD updates with it. Build-time semantics,
runtime freshness, no vendor in the request path. Same outcome, code still in your
repo.

The Setup-scope flavour of *"runtime is OK"* is rare and architecturally
distinctive. For the typical B2B SaaS marketing site, the catalog page, the blog,
the pricing page, the docs — build-time JSON-LD covers everything.

## What the Checker tells you

Run the [Free Checker](/check) on your site. The relevant signals:

- **Signal #9** — JSON-LD parses cleanly via `ajv`. Fails if any block in your HTML
  is invalid.
- **Signal #10** — `Organization` complete. Fails if name, url, logo, or sameAs are
  missing.
- **Signal #11** — `Person` (founder) linked from `Organization.founder`. Fails if
  the identity chain isn't reciprocal.
- **Signal #12** — Reciprocal `sameAs` verification across domains. Fails if LinkedIn,
  GitHub, or other linked profiles don't link back.
- **Signal #13** — `WebSite` schema present.
- **Signal #14** — `BreadcrumbList` on inner pages.
- **Signal #35** — `FAQPage` schema if the page has Q&A blocks.
- **Signal #36** — `Article` with dateline on blog posts.

That's seven signals across the Identity and Citation groups testing exactly the
"hand-rolled JSON-LD has problems" claim. If your site fails them, that's a
diagnostic. The fix isn't a subscription; the fix is the build-time pipeline above,
shipped as code in your repo.

The studio's internal headless engine adds one more check the light-path Free Checker
can't do: a comparison of JSON-LD field values to visible page content. *Does
`Article.headline` match the `<h1>`? Does `Organization.name` match the visible brand?
Does `Offer.price` match the price the customer would actually see?* That drift check
needs a rendered DOM, so it runs as part of a Setup audit and the retainer's monthly
scan, alongside the AI-bot UA diff — not in the free light-path scan.

## The studio recommendation

Build-time first. Code in your repo. Validated in CI. Audited annually.

Whichever approach you pick, run the Free Checker first. Then decide whether the
fixes look like work you want to do yourselves or work you want shipped as PRs.

[Run free check →](/check)

[Talk to the studio →](/#contact)

---

### Studio, not platform

*Published 2026-05-13 · tags: essay · https://sitesfor.ai/blog/studio-not-platform*

Why the GEO layer should ship into the customer's repository, not run on someone else's domain — and why a retainer can stay on the right side of that line.

import ClaimAnchor from '~/components/content/ClaimAnchor.astro';

The SaaS GEO platforms sell you a layer that runs on their infrastructure
and renders into your domain at request time. Cancel the subscription and
the layer disappears — the JSON-LD they injected, the AI-sitemap they
maintained, the manifests they served from `/.well-known/*`. The work
survives only as long as the contract.

<ClaimAnchor id="studio-thesis">
A studio engagement is the opposite trade: the work ships as commits into
the customer's repository, the customer owns the code after the
engagement, the studio is not in the request path.
</ClaimAnchor>

## What Setup is

The studio's one-time engagement is **Setup**. It is a fixed-price,
scope-locked piece of work that ends with pull requests merged into the
customer's main branch. There is no runtime dependency on the studio's
infrastructure. There is no API key the customer holds against the studio.
The deliverables are reviewable as diffs and survive the studio going
quiet, raising prices, or pivoting to something else.

Setup's job is to translate the Checker's findings into changes the
customer's stack accepts, and to build out the signal coverage the site is
missing. Next, Astro, Nuxt, Hugo, WordPress, custom — the studio adapts to
the codebase, not the other way round. It ends with a before/after grade
that proves the result.

## What a SaaS GEO platform is

A SaaS GEO platform sells you a recurring subscription that runs structured
data, manifests, and crawl-monitoring from its infrastructure into your
domain. The customer's domain becomes a thin client of the platform. The
platform owns the methodology, the dashboard, and the rendering layer; the
customer owns the subscription invoice.

The trade is convenience for lock-in. The platform handles the work; the
customer pays $129–$299 per month indefinitely; the moment the customer
cancels, the layer disappears and the AI assistants that were citing the
site stop citing it again.

<ClaimAnchor id="lifetime-cost">
The math: $299 a month for 36 months is $10,764, and at the end of those
36 months the customer owns nothing. A $5,000 Setup leaves the customer
owning the code on day one — and a retainer on top of it is still cheaper
per month than the platform, while the code keeps accruing in the
customer's own repository rather than evaporating at cancellation.
</ClaimAnchor>

## Recurring revenue without becoming a platform

There is a real objection to a one-time-only studio: the work decays. AI
standards move — ACP, AP2, x402, the Apps SDK and WebMCP are all young and
shifting. The customer's own site keeps changing. A site graded 92 in
March drifts by autumn. So the studio offers a **Retainer**.

That sounds like the platform model returning through the back door. It is
not, and the distinction is worth being precise about.

<ClaimAnchor id="platform-test">
The line that separates a studio from a platform is not recurring versus
one-time. It is *where the work lives.* A platform's layer runs on the
vendor's infrastructure and renders into your domain; cancel and it
vanishes. A studio retainer maintains code that already lives in your
repository; cancel and every line of it stays.
</ClaimAnchor>

The retainer is a monitoring-and-judgement engagement, not a dashboard
subscription. Each month it ships a report you can read in 90 seconds —
the Checker score delta, AI-crawler server-log analysis, a citation
prompt-panel, AI-source referral traffic — and the maintenance work goes
into the customer's repo as PRs, exactly like Setup. There is no login
habit to form, no layer in the request path, nothing that disappears at
cancellation. It is sold *after* a Setup, on the proven result, with a
three-month minimum because AEO results take 60–90 days to land.

So the ladder has three rungs:

- **Free Checker** — diagnose for free. Letter grade in seconds.
- **Setup** — from $5,000 one-time, scope-based, fixed-price. Adapts an existing codebase for AI-agent readiness; PRs into the customer's repository; before/after grade.
- **Retainer** — $1,500–$7,500/mo, sold after a Setup. Keeps the score from decaying and tracks whether AI citations are moving. A monthly report, not a dashboard.

The retainer is recurring revenue. It is also, strictly, still the studio
model: it maintains and extends code in the customer's repository — it
does not move that code onto the studio's infrastructure.

## What this means for AI-agent readiness

Two things follow from the studio model, both load-bearing.

First, **standards-only testing**. We grade against published,
vendor-neutral standards: schema.org, llms.txt, ai-plugin.json, OpenAPI
3.1, MCP, IndexNow, ACP, AP2, x402, OpenAI Apps SDK, Google WebMCP, robots.txt.
We do not test against proprietary protocols, invented well-known files,
or trademarked methodologies. The standards-disclosure line on every
report is the permanent rebuttal to platforms that do.

Second, **deterministic recommendations**. The Quick Wins panel is
generated from a static failure → fix lookup table, not from an LLM. A
recommendation never contradicts the evidence panel. If the evidence panel
shows `/.well-known/ai-plugin.json` returning 200 OK with valid content,
the Quick Wins panel does not say *"deploy ai-plugin.json."* This sounds
trivial. It is the single biggest accuracy bug in the category, and we
position against it directly.

Both properties — standards-only and deterministic — are easy to maintain
in a studio funnel where the report is the product and the report is true.

## Talk to the studio

The Free Checker is the entry point. If you want the failing signals fixed
in your repository, Setup starts at $5,000 and scopes to the stack. If you
want the result to keep holding as the standards move, the Retainer keeps
it ahead. There is no portal, no log-in, no layer running on your domain
that disappears if we go quiet. The code is yours — on day one, and after
every month of the retainer.

[Run free check →](/check)

[Talk to the studio →](/#contact)

---

### What does "AI-agent-ready" mean?

*Published 2026-05-13 · tags: explainer · https://sitesfor.ai/blog/what-does-ai-agent-ready-mean*

A website is AI-agent-ready when crawlers, assistants, and buyer agents can each use it fluently against published, vendor-neutral standards.

import FactCard from '~/components/content/FactCard.astro';
import ClaimAnchor from '~/components/content/ClaimAnchor.astro';
import DefinitionBlock from '~/components/content/DefinitionBlock.astro';

<FactCard
  about="AI-agent readiness"
  body="A website is AI-agent-ready when three distinct audiences — crawlers (GPTBot, ClaudeBot, PerplexityBot), assistants (ChatGPT, Claude, Perplexity in answer mode), and buyer agents (ACP, AP2, x402, MCP, Apps SDK) — can each use it fluently against published, vendor-neutral standards. Readiness is measured against a catalog of deterministic signals scored to 100, with letter grade A 90+ / B 75+ / C 60+ / D 45+ / F under 45."
/>

<DefinitionBlock>
**AI-agent readiness is** the property of a website that allows three
distinct kinds of software readers to use it without human intervention:
crawlers that index it, assistants that answer questions about it, and buyer
agents that transact with it on behalf of users.
</DefinitionBlock>

<ClaimAnchor id="three-audiences">
The first move is recognising that "AI traffic" is not one audience. A
website now serves three.
</ClaimAnchor>

## Three audiences, three jobs

A modern website is read by three categories of software, each with a
different job and a different set of standards it expects you to support.

### Crawlers

The bots that build the indexes — `GPTBot`, `ClaudeBot`, `PerplexityBot`,
`OAI-SearchBot`, `Google-Extended`, `Bingbot`, `Applebot-Extended`, `CCBot`.
Their job is to pull your content into a training corpus or a
search index. They need clean HTML, a parseable `/robots.txt` that tells
them what they may and may not crawl, a `/sitemap.xml` listing every
canonical URL, and ideally a markdown variant of each page so they can read
denser content.

<ClaimAnchor id="crawler-signals">
Crawlers are graded by the Discovery, Citation, and Hygiene signal groups
of the Checker.
</ClaimAnchor>

### Assistants

The user-facing answer-mode products — ChatGPT, Claude, Perplexity, and the
search results that increasingly look like one of these. Their job is to
answer a question by citing or quoting your content. They need verifiable
identity: a complete `Organization` JSON-LD, a `Person` for the founder
linked from `Organization.founder`, reciprocal `sameAs` verification across
LinkedIn, GitHub, and other platforms. They also need an `/llms.txt`
summary so a model can build a mental map of your site in one fetch, and an
`/.well-known/ai-plugin.json` if you have an agent-callable surface.

<ClaimAnchor id="assistant-signals">
Assistants are graded by the Identity and Agent Contracts signal groups.
</ClaimAnchor>

### Buyer agents

The newest and least-served audience. These are agents acting on behalf of
a user with a credit card and an intent: *"book this flight," "buy this
product," "subscribe me to that newsletter."* They speak emerging
protocols — the Agent Commerce Protocol (ACP), the Agent Payments Protocol
(AP2), `x402`-style metered payment challenges, the Model Context Protocol
(MCP) for tool calls, the OpenAI Apps SDK manifest for ChatGPT-embedded
apps. They need a machine-readable product catalogue, a callable checkout
endpoint, and `schema.org Offer` markup on every commercial page.

<ClaimAnchor id="buyer-signals">
Buyer agents are graded by the Commerce signal group — signals covering
ACP, AP2, x402, MCP handshakes, the OpenAI Apps SDK manifest, Google
WebMCP, and schema.org Offer hygiene.
</ClaimAnchor>

## What "ready" means concretely

Ready does not mean *"discovered by AI assistants once in a while."* Ready
means *"correctly described in the answer when a relevant question is
asked."* The bar is observable and verifiable.

You can check it yourself in under ten seconds:

```
open chatgpt.com, claude.ai, perplexity.ai in fresh signed-out tabs
paste: "what is <your-domain>? what does <your-domain> do?"
read the verbatim response in each
```

That is the bar. A ready site gets an accurate, useful, three-sentence
answer with a citation. A not-ready site gets *"I don't have specific
information about your-domain"* — the most common opening on launch day
for any new brand.

Closing the gap is what GEO ("generative engine optimisation"), AEO
("answer engine optimisation"), and the freshly-named buyer-agent stack
exist to solve. The Checker at `/check` grades a catalog of deterministic signals
across the three audiences and returns a letter grade in seconds. A Setup
engagement implements the Quick Wins as pull requests against your
repository — the code is yours after the work — and a Retainer keeps the
grade from decaying as the standards keep moving.

## Signal groups in one paragraph each

The catalog spans seven groups, weighted to 100 points total. The
breakdown below is the same one the Checker emits, abridged.

### Discovery (30 pts)

The signals that decide whether your site is even *findable* by AI bots:
`/robots.txt` exists and lists each AI-bot user-agent explicitly,
`/sitemap.xml` validates, an AI-sitemap variant exists, `/llms.txt` and
`/llms-full.txt` are parseable, an IndexNow key file is present, and every
public route has a `<route>.md` companion served to AI UAs.

### Identity (15 pts)

The signals that decide whether AI assistants can describe *who* you are
with confidence: clean JSON-LD via `ajv`, a complete `Organization`, a
linked `Person` for the founder, reciprocal `sameAs` to LinkedIn / GitHub /
other surfaces, `WebSite` schema on the homepage, `BreadcrumbList` on inner
pages, OG / Twitter cards, an SVG favicon, hreflang if multilingual.

### Agent contracts (20 pts)

The signals that decide whether your site is *callable* by agents — not
just describable: `/.well-known/ai-plugin.json` validates, OpenAPI 3.1 is
linked and valid, operations carry `x-llm-tool` annotations,
`/.well-known/agent-actions.json` lists high-value actions, MCP is
discoverable at `/.well-known/mcp.json` and a live `initialize` handshake
completes, OpenAPI server URLs respond.

### Rendering & access (10 pts)

The signals that decide whether AI bots can *retrieve* what your humans
see: server-side rendering or pre-rendered HTML (the raw fetch matches the
headless DOM acceptably), consistent canonical, strong ETag / Last-Modified
headers, Brotli compression on machine-readable resources, HTTP/2 or 3,
navigation that works without JavaScript.

### Citation (10 pts)

The signals that decide whether an assistant will *quote* your content
accurately: high definitional-sentence density, stable claim anchors, a
fact-card block on every key page, clean heading hierarchy, alt text on at
least 85% of images, `FAQPage` schema where Q&A is present, `Article` with
dateline on blog posts, statistics tables annotated.

### Hygiene (5 pts)

The boring-but-mandatory base layer: HTTPS with HSTS and no mixed content,
freshness within 12 months, no accidental `noindex`, a privacy policy,
`security.txt`, and a `/robots.txt` that doesn't accidentally block the AI
bots you want indexing your content.

### Commerce (10 pts)

The newest group, and the wedge: an ACP feed at the origin root, a working
ACP checkout endpoint, an AP2 mandate-verifier that resolves a test Intent
Mandate, `x402` challenge on at least one paid endpoint, `schema.org Offer`
with price/currency/availability on every commercial page. Two further
preview signals — the OpenAI Apps SDK manifest and Google WebMCP manifest —
are graded but weighted zero until their underlying specs stabilise.

## Why this is a category, not a feature

Three years ago "AI-agent readiness" wasn't a category. SEO covered
crawlers, content marketing covered assistants by accident, and buyer
agents didn't exist. Today each of these audiences uses your site
differently, expects different signals, and rewards different work. A
single Checker that grades all three in one pass — against published,
vendor-neutral standards, not invented "AI Position Intelligence™"
trademarks — is the closest thing to a category-defining diagnostic that
exists.

That is what the Free Checker is. A Setup engagement is the studio that
ships the fixes into your repository, whatever the stack — Next, Astro,
Nuxt, Hugo, WordPress, custom — and leaves you owning the code afterwards.
A Retainer keeps that grade from decaying as the standards keep changing.

## What's next

Run the [Free Checker](/check) on your site, read the evidence panel,
compare your global and vertical percentile against the corpus, and decide
whether the top-three Quick Wins are work you want to do yourselves or work
you want to hand to the studio. A Setup engagement (from $5,000,
scope-based) ships the fixes as PRs into your repository with a before/after
grade; a Retainer ($1,500–$7,500/mo, sold afterwards) keeps the score from
decaying and tracks whether your AI citations are actually moving.

There's no portal, no dashboard to log into, no layer running on your
domain that disappears if we go quiet. The code is yours — Setup ships it
into your repo, and the retainer maintains it there rather than moving it
onto ours. That is the studio model, and it is structurally different from
the SaaS GEO platforms.

---