What evidence should back an AI readiness finding

Clients hear "AI readiness" and imagine a trophy. I want a packet. SlaySlop's Answer-engine readiness check "reviews signals that help AI crawlers access and understand public content." Evidence has to show which signal failed on which public URL.

Outcome

You can explain the finding in one breath: this route blocked access, or this route lacked enough public context to understand/cite, according to the scan evidence. After remediation, the same packet shape clears on rescan.

Boundaries

Read-only public scan. Permission required. Not a pentest. Evidence does not prove you will be cited by any particular answer engine tomorrow. It does not replace Security or Accessibility work. Sibling SEO findings may hold the real blocker, keep them linked, not merged into mush.

Happy path packet

check: Answer-engine readiness
glossary: https://slayslop.com/glossary/ai-readiness
definition: reviews signals that help AI crawlers access and understand public content
target_url: https://www.example.com/docs/getting-started
observed:
 robots: reachable / rule summary
 sitemap: reachable or not
 title: present / weak / missing
 description: present / weak / missing
 structured_data: present / missing / incomplete
 notes: "Rendered browser observation if JS template"
non_claims:
 - not a chatbot ranking guarantee
 - not a pentest
 - not private CMS visibility

Smoke beside the packet on a host you own:

curl -sL "https://www.example.com/robots.txt" | head -n 40
curl -sL "https://www.example.com/docs/getting-started" | rg -n "<title>|meta name=\"description\"|application/ld\+json" | head

If curl and the scan disagree on a JS-rendered template, trust the rendered evidence and say so in the notes.

What good evidence looks like

Good: "/docs/getting-started is disallowed in robots while sitemap still lists it." Good: "Flagship guide ships empty description and no structured context after render." Bad: "Need more AI content." Bad: a screenshot of ChatGPT answering something vaguely related.

Portal copy should stay boring. Answer engines and humans both mishandle hype. Point at access and understanding signals only.

Pitfalls

Stripping URLs from evidence before sending to an agency partner. Mixing Social metadata misses into readiness without labeling them. Declaring victory from a homepage-only sample while docs stay blocked. Pasting fix prompts without the evidence block so agents invent a blog strategy instead of opening robots.txt.

Related next step

Attach the packet to the ticket, fix the cited signal, rescan. For the first capture, use a permissioned scan on slayslop.com and keep the finding evidence with the handoff note.

Portal wording that stays accurate

Prefer "Answer-engine readiness flagged missing description metadata on the getting-started guide after render" over "we are not AI optimized." The first is falsifiable. The second invites a vendor pitch.

When multiple sibling SEO findings fire with readiness, order tickets by access first (robots/sitemap), then titles/descriptions, then structured context. Understanding cannot happen for a crawler that never enters.

Rescan discipline

After robots or metadata changes, wait for CDN cache on the cited route if your edge caches HTML. Then rescan Answer-engine readiness and the sibling row you fixed. If readiness stays red while titles look fixed, read structured data and sitemap next. The evidence packet should gain a "verified_at" note with the new scan time so portal readers do not reuse stale screenshots.

Agencies should keep one packet per URL, not one blob for the whole domain. Answer engines cite pages. Your evidence should too.

Soft handoff line

When you paste the packet into a portal, one soft next step is enough: rescan the cited URL after the fix. Linking SlaySlop SEO and AEO is optional and only if the client asks where the check lives.