If you want to know whether a site is ready for AI search, start with something testable: can a collector fetch your public HTML, split it into understandable passages, and identify specific facts? That is different from asking whether ChatGPT, Claude, Gemini, or Google AI Overviews actually cite you.
Watch the recorded audit replay
Recorded searchd.ai audit replay (22 September 2026). SearchD checks public HTML; Jev adds bounded excerpt assessments. Not a live crawl, runtime benchmark, or citation result.
Here are 18 checks in five layers. When the free SearchD technical AEO audit retains one or more readable pages, it reports all 18 rows with status, evidence, and next action. If it retains zero readable pages, Page Retrieval is UNKNOWN and no technical score is issued. Ten rows contain bounded technical measurements. Eight need deeper or external verification. Jev, when available, assesses supplied page excerpts. Its feedback is supplemental and does not determine the technical score; it is not the crawler or the executor of all 18 tests.
Use example.com below as a placeholder. These commands are spot checks, not an equivalent implementation of the SearchD audit.
Layer 1: Can a collector retrieve useful HTML?
1. AI-bot access signals. Compare root GET responses with representative user agents:
for agent in OAI-SearchBot ClaudeBot PerplexityBot; do
printf '%s: ' "$agent"
curl -sS -L -o /dev/null -w '%{http_code}\n' -A "$agent" https://example.com/
done
SearchD makes analogous root user-agent requests from its own infrastructure. A 200 does not prove official crawler-IP access, every path, or absence of WAF challenges elsewhere.
2. Server-rendered text. Fetch the response without a browser and inspect whether the primary explanation exists before client JavaScript runs:
curl -sSL https://example.com/ > page.html
SearchD measures normalized text length in retained HTML. A browser view alone can hide an almost-empty server response.
3. Root robots.txt. Read the actual agent groups and directives:
curl -sSL https://example.com/robots.txt
The audit's root-level check does not certify path-by-path access or actual crawler behavior.
4. Canonical string. Inspect the <link rel="canonical"> in the raw page and compare it with the fetched URL. SearchD checks the declaration string; it does not fetch the canonical target or decide what Google selected.
Layer 2: Can a page yield a coherent excerpt?
5. One H1 and local H1–H3 order. Check the HTML heading sequence on priority pages. A structurally continuous sequence is not a guarantee of a useful answer beneath it.
6. Semantic fact tables. Put comparable specifications in real <table> markup with headers, not a screenshot or a grid of divs. SearchD detects fact/specification table signals; it does not validate the values.
7. Standalone entity sentences. Ask whether an extracted paragraph still names the subject. “It supports exports” is weak outside its page; “Product X supports CSV exports” survives a short excerpt. This row is not site-wide verified by the technical crawl. Jev may assess a bounded excerpt for self-contained statements, specific facts, and fact-table evidence.
8. Thin retained pages. SearchD flags retained pages below 500 normalized text characters. Review intent before expanding them. A contact page can be correctly short; a decision page may need more evidence.
Jev receives a retained page's URL, title truncated to 70 characters, up to the first 2,500 normalized-text characters, up to six H1–H3 headings, and a table count. It does not visit the URL, execute client JavaScript, or infer what appears beyond that excerpt. Its excerpt feedback is supplemental and does not determine the technical score. For field definitions and scope, see the Jev technical AEO audit guide.
Layer 3: Do links explain page roles?
9. Cannibalization. Group URLs by the same query intent and identify the primary answer. The technical report marks this UNKNOWN because it does not cluster topics or compare target queries.
10. Orphans. Compare a complete indexable-URL inventory with a full internal-link graph. Sitemap/homepage discovery alone cannot prove there are no orphaned pages.
11. Contextual anchors. Look for links within relevant paragraphs or lists, then inspect destination and anchor meaning. SearchD records a structural presence signal that may include external links, not a scored internal-link graph.
Layer 4: Does structured data match visible reality?
12. Parseable JSON-LD. Validate application/ld+json blocks and inspect declared @type values. Parseability is a first check, not proof of correct schema fields.
13. Absolute sameAs URLs. Confirm that entity profile links are valid absolute HTTP(S) URLs, then verify that the profiles are official. SearchD measures URL presence; ownership remains unverified.
14. Visible-schema parity. Compare names, prices, availability, dates, and claims in JSON-LD with the page a visitor sees. This is a separate field-level review, not a PASS inferred from parsing.
Layer 5: Test outcomes outside the HTML audit
15. ChatGPT grounding. Run a dated, repeatable prompt set and save the response and displayed sources. The technical endpoint does not run this probe.
16. Claude/Cursor extraction. Define a source document, task, tool/version, and expected fact; record what was extracted and missed. This is not implied by Jev excerpt feedback.
17. Gemini/Google AI Overview appearance. Log query, date, locale, device context, response, and cited sources over time. Do not call a technical score a citation win rate.
18. Webmaster gateways. Verify sitemap submission, indexing, and errors in Google Search Console and Bing Webmaster Tools. The free audit does not authenticate to either account.
Run the report, then keep two queues
Enter a domain in the free SearchD technical AEO audit. It selects up to 300 same-host candidate URLs from a sitemap or homepage links, retains readable HTML/XHTML, and does not execute client JavaScript. Read the URL-level evidence behind a finding before making a change. The fetched/discovered count applies to that bounded candidate set, not necessarily every URL on your domain.
Keep confirmed technical defects in one queue and UNKNOWN, UNVERIFIED, or NOT RUN questions in another. Fix the former; design actual tests for the latter. That is more useful than treating a technical readiness score as a prediction of citations, rankings, traffic, or revenue.
