AI Search Readiness Report

Free, no signup. A four-stage explanation of whether an AI system can retrieve, use, cite, and accurately represent one page. These are independent stage verdicts — not one invented AI score.

Built by Patrick Stox

Method note: stage weights are provisional and visible. An unavailable check never becomes a pass or a zero; it lowers the stage’s confidence instead. This observation describes the named consumer product at the recorded query time. A model API with search is an execution surface, not a proxy for the provider’s consumer product. Results can correlate, but they are not interchangeable.

General preserves the base readiness run. Named profiles add required page-signal checks; unavailable schema guidance and weights are shown as not evaluated.

Add observed answer evidence and retrieval-path inputs

Checks run from our server; we fetch the URL you enter and don't keep the results. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Ai Search Readiness Report? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
 
 
Sample report Honest output shape
 
Suppose robots.txt and llms.txt are fetchable, while live status, rendering, and AI-probe budgets are unavailable. A faithful report does not fill those gaps with zeros:
 
Retrieve · scored from the crawler evidence that was evaluated · reduced confidence
Use · not evaluated where rendering or additional inputs are required
Cite · evaluated modules shown individually; unavailable modules excluded
Believe · not evaluated when the current run has no supporting module evidence
 
This is a static explanation of state handling, not a captured score for a named site. Live numeric results depend on the entered URL and the modules available during that run.
 
 
 
How to use it
  1. Enter the complete URL of one public page and choose its profile.
  2. Complete the anti-abuse check and select Run readiness report.
  3. Start with the four-stage summary, then expand each stage to see evaluated and unavailable modules.
  4. Fix explicit access or content findings first. Re-run after publishing, while allowing for provider-specific cache lag.
 
 
 
     
     
     
 
What the results mean
  • Retrieve — whether an answer system can discover and fetch the page.
  • Use — whether the available page content is usable by the evaluated modules.
  • Cite — signals related to selecting and attributing a page as a source.
  • Believe — signals related to identity, support, and accurate representation.
  • Confidence — how much of the provisional stage weight was actually evaluated.
  • Not evaluated — unavailable evidence, never an inferred pass or error.
 
How it works
A protected run receives a small request budget, fetches robots.txt and llms.txt through SSRF-guarded endpoints, and checks the exact URL against three recent Common Crawl indexes through a cached, time-bounded adapter. It passes those observations into a registry of stage modules. Each evaluated numeric module contributes its published provisional weight. Informational modules, including Common Crawl presence, do not affect the score. Modules without a working dependency return a reason-coded not evaluated result and reduce confidence.
 
Features
  • Four-stage funnel instead of a universal composite score.
  • Visible per-module weights, findings, and fix links.
  • Per-crawler/model breakdown when a module has that evidence.
  • Reason-specific unavailable states for fetch, render, AI, timeout, and input limits.
  • Protected, bounded network runs and shareable URL state.
 
Limitations
The module registry is intentionally incomplete, and this public page currently supplies no live render, status, or AI-probe implementation to the runner. Weights are provisional. A fetch from this service can differ from a provider’s geography, identity, cache, or index. The report does not issue prompts to commercial answer products, observe citations, or guarantee retrieval, use, attribution, or factual treatment.
 
Frequently asked questions
Why are there four stages instead of one AI readiness score?
Retrieval, use, citationThree distinct states of AI visibility: retrieved (an AI fetched your page as source material), mentioned (your brand appears in the answer text), and cited (your URL is linked as a source). They don't always happen together, and each is measured with a different tool., and accurate representation can each report errors independently. Keeping them separate prevents a strong content signal from hiding an access error or an unavailable module.
What does not evaluated mean?
The module had no usable evidence because it is not live, needs another input, exceeded a budget, timed out, failed to fetch, or does not apply. It is excluded from the stage score and lowers confidence rather than becoming zero.
Does a strong report guarantee AI citations?
No. The report checks observable page and access signals. It cannot see every provider’s index, ranking, generated answer, cache, or source-selection system.
Why can a recent fix take time to appear?
Answer systems may cache fetched pages, retrieval indexes, or generated responses. Re-crawl and regeneration timing varies by provider, so this report can verify the current public page without proving that a provider has refreshed its copy.
What modules does the current public run evaluate?
The public run currently checks crawler accessA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index., recent Common Crawl presence, and modules that can use page and llms.txtllms.txt is a proposed (not adopted) Markdown file at /llms.txt that gives AI systems a curated map of a site's most important pages. Proposed by Jeremy Howard in 2024, it's read mostly by coding agents like Claude Code — not search crawlers — and Google ignores it. fetches. Render, live status, and AI-probe dependencies are passed as unavailable, so their modules must report not evaluated.
 
 
Next stepQuotability & Entity-Preserving Rewriter — generate the corrected version.

Explore more
ToolAI-Crawler Access CheckerToolChunk TesterToolAI Content AuditArticleAI Search OptimizationArticleGenerative Engine Optimization (GEO)ArticleAI Crawlers
 
 
 
Feature requests for Ai Search Readiness Report
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
     
 
            
 
Common issues & how to fix them
 
 
 
 
 
AI Search Readiness Report · one finding
 
Important content depends on rendering
 
Recommended action: Put meaningful title, heading, and primary copy in the server-delivered HTML.
 
Fix principle: Make critical content available in build-time or request-time server output; diagnose browser-only data paths rather than treating framework client-component syntax as proof that initial HTML is missing.
 
 
 
 Implementation for your setup 
 
Confirm first: View source lacks critical content that appears after rendering. A non-rendering fetch receives a shell or materially incomplete page. Critical content, a real navigable link, or the page's true destination or route only exists after a script runs — including content gated behind a click or scroll interaction, a client-side redirect, hash-only routing, or a connection type (such as WebSocket) Googlebot does not support.
 
Do not apply when: Critical content is already present in the initial HTML and only presentation is hydrated. The observed difference comes from personalization that is intentionally unavailable to crawlers. The content, link, or route is reachable without any click, scroll, or persistent client-side connection, and any redirect to it is a real HTTP or meta-refresh redirect rather than a JavaScript-only one.
 
Likely control points: cms-app · server · edge-cdn
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Build pipeline, application server, or origin templates
 
Steps
  1. Choose build-time prerendering for content known at release time or request-time server rendering for content needed per request.
  2. Render the critical title, heading, links, and main content into the response, then hydrate only the interactions that need a browser.
  3. Reveal important content in the DOM without requiring a click, tab switch, or scroll to trigger it — Google Search does not interact with the page, so use CSS or an interaction-independent method (for example IntersectionObserver-based lazy loading) instead of loading content only on user action.
  4. Replace a client-side-only redirect with a real server-side HTTP redirect (or, when that is not feasible, a meta refresh); use a JavaScript redirect only as a last resort, since a rendering failure can mean Google never observes it.
  5. Replace hash-only routes (for example /#/products) with real, individually navigable URLs served through the History API or server-side routing, so each state has its own crawlable address.
  6. If content depends on a WebSocket or WebRTC connection established client-side, provide an HTTP-reachable equivalent or fallback for that same critical content, since Googlebot only retrieves content over HTTP.
  
Verify on this platform
 
  • Fetch the final public response without executing JavaScript and compare its critical content with the rendered page and Search Console live test.
  • Confirm important content and primary navigation links are present in the rendered DOM without simulating a click, tab switch, or scroll, and that the page's real destination and individual routes resolve to distinct HTTP-fetchable URLs rather than only a hash fragment or a WebSocket-delivered update.
 
Rollback
  1. Restore the prior renderer, redirect method, or routing approach while retaining the confirmed working response path if the change breaks user functionality.
 
Caveats
  • Do not default to user-agent-based dynamic rendering; Google describes it as a workaround rather than a recommended long-term solution.
  • Trace data loaded only in effects, browser-only APIs, disabled SSR, or an app shell before changing the rendering architecture.
  • A rendered page that looks like a soft 404 is usually the same underlying defect at its most severe: confirm whether content is simply late, hidden behind interaction, or genuinely absent, and apply the matching step above rather than treating it as a distinct problem.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: App Router Server/Client Component boundaries or Pages Router rendering method
 
Steps
  1. In the App Router, keep critical fetching and document content in server-rendered output; isolate only interactive code behind Client Component boundaries.
  2. In the Pages Router, use static generation or request-time server rendering for critical content instead of loading it only after mount.
  3. Remove an unintended dynamic import with ssr: false, useEffect-only fetch, browser-only guard, or app-shell dependency from the critical path.
  
Verify on this platform
 
  • Inspect the deployed response without executing JavaScript, then rerun Render Gap and the Search Console live test on the same production URL.
 
Rollback
  1. Revert the affected route or component boundary if the deployment causes a functional regression.
 
Caveats
  • A Next.js "use client" directive does not by itself mean missing initial HTML: Client Components are prerendered on the first load.
  • Skipping SSR with ssr: false is supported only for Client Components and can intentionally remove their server-rendered output.
  • A client-side router.push() redirect, hash-only route, or client-established WebSocket is a code-level defect independent of the App/Pages Router choice — apply the generic-http-html guidance above (server-side redirect, History-API routing, HTTP fallback) at the component that owns that behavior.
 
Official sources
 
 
Vue / Nuxt
 
Status: supported · Location: Nuxt route rendering and deployment preset
 
Steps
  1. For Nuxt 4, keep universal rendering enabled for the route or prerender the route when its content is known at build time.
  2. Deploy with the Nuxt preset that matches the real host and verify the server or static output is being served.
  3. For plain Vue, select and verify the actual SSR architecture and host before applying implementation steps.
  
Verify on this platform
 
  • Fetch the deployed route without browser execution and confirm the critical content exists in the response; then rerun Render Gap.
 
Rollback
  1. Restore the prior Nuxt route rule, prerender list, or deployment preset if the route regresses.
 
Caveats
  • Plain Vue implementation is not verified by this recipe unless the site’s real SSR setup and deployment host are identified.
  • Client-only data fetching can still create a gap even when the application uses an SSR-capable framework.
  • A router-only (hash mode) route, a client-side redirect, or a client-established WebSocket is a Vue Router or application-code defect independent of Nuxt's rendering mode — apply the generic-http-html guidance above at the component or router configuration that owns it.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Native classic/block theme template and post-content output
 
Steps
  1. For a classic theme, render the intended entry content through the selected template and the_content().
  2. For a block theme, keep the Post Content block in the applicable template and verify the template hierarchy selects it.
  
Verify on this platform
 
  • View the logged-out public response and confirm the native template emits the critical content before browser scripts run.
 
Rollback
  1. Restore the prior native template or template part if the published layout or content regresses.
 
Caveats
  • These steps cover native classic and block themes only.
  • A page builder or headless WordPress frontend is owner-managed; use that rendering system’s verified workflow instead of assuming core theme controls own the output.
  • Content gated behind a click/tab/accordion, a JavaScript-only redirect, or hash-only navigation added by a theme or plugin script is a separate defect from template output — apply the generic-http-html guidance above at the script that owns that behavior.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Online Store Liquid or JSON theme templates
 
Steps
  1. Duplicate the active theme and make the rendering correction in the duplicate Liquid or JSON template.
  2. Preview representative product, collection, and content routes before publishing the corrected theme.
  
Verify on this platform
 
  • Inspect the preview and then published storefront response without browser execution and confirm the critical content is present.
 
Rollback
  1. Republish the previous theme if the new theme regresses storefront content or functionality.
 
Caveats
  • These steps apply only to Shopify Online Store Liquid/JSON themes.
  • An app-owned storefront or Hydrogen implementation is owner-managed and needs its own verified rendering workflow.
  • Content gated behind a click/tab, a JavaScript-only redirect, or hash-only navigation added by a theme script or app embed is a separate defect from template output — apply the generic-http-html guidance above at the script that owns that behavior.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned renderer, page builder, or hosted storefront
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to demonstrate the uncached initial HTML returned to crawlers and users.
  
Caveats
  • Escalate when the platform cannot expose or configure its rendering mode.
  • Require one production-URL response comparison rather than accepting a claim that the browser eventually renders the content.
  • Ask the vendor to confirm content is not gated behind interaction, redirects are not JavaScript-only, and routes are not hash-only.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch the public URL without JavaScript.
  2. Compare initial HTML and rendered DOM for the same title, H1, primary links, and content.
  3. Confirm important content and links are reachable without simulating a click, tab switch, or scroll, any redirect resolves at the HTTP or meta-refresh layer rather than only via JavaScript, and routes are individually fetchable rather than hash-only.
  4. Rerun Render Gap after deployment.
 
Escalate when
 
Escalate when the rendering layer is vendor-controlled, server rendering changes routing or authentication, or the raw and rendered views cannot be reproduced consistently.
 
 
 
 
 
 
 
AI Search Readiness Report · one finding
 
AI crawler access is blocked
 
Recommended action: Remove or narrow the matching robots.txt rule for AI crawlers you intentionally allow to access this content.
 
Fix principle: Crawler access is a policy decision, not a score optimization. Identify the exact current user-agent token from the operator, decide whether that crawler may fetch each path class, and test the complete robots.txt group selection so wildcard and specific rules do not create an accidental outcome.
 
 
 
 Implementation for your setup 
 
Confirm first: A named AI crawler is blocked or partially blocked contrary to the site owner's documented policy. Wildcard and crawler-specific groups produce a result different from the author's intention. Generated robots.txt output blocks search crawlers, exposes sensitive paths, or introduces contradictory group definitions.
 
Do not apply when: The owner has an explicit allow/block decision for each crawler class and path class, using operator-documented current tokens. A standards-conformant parser selects the intended group and result for representative URLs, with no reliance on rule order or unsupported directives.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The single robots.txt source served from the origin root
 
Steps
  1. Document the business policy first: which crawler operators and product uses are allowed, partially allowed, or blocked, and which path classes contain public versus sensitive material.
  2. Confirm each current crawler token from that operator's official documentation; do not infer policy from a display name or stale third-party list.
  3. Consolidate duplicate groups for the same token and make the wildcard group independently safe. Specific and wildcard groups may not combine the way the author expects.
  4. Use only supported allow/disallow path rules for access control, keep sensitive systems protected by authentication rather than robots.txt, and preserve sitemap declarations as absolute URLs.
  5. Test representative public, blocked, and borderline paths for every named token before publishing.
  
Verify on this platform
 
  • Fetch the production robots.txt and confirm it is reachable, parseable, and the exact reviewed revision.
  • Evaluate representative URLs with the exact crawler token and a wildcard token using a standards-conformant parser.
  • Re-run AI-Crawler Access Checker and manually confirm any intentional blocks remain described as policy, not defects.
 
Rollback
  1. Retain the prior robots.txt revision.
  2. If the new file accidentally blocks important search or service crawlers, restore the prior revision immediately and re-author the affected groups offline.
 
Caveats
  • robots.txt is publicly readable and is not an access-control system for confidential data.
  • Allowing a crawler does not guarantee crawling, training, citation, ranking, or referral traffic.
  • Different operators and products may use different tokens; a generic “AI bots” rule can overreach.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor robots.txt generator or edge policy
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor how custom and generated groups are merged and whether updates can overwrite owner rules.
  • Fetch and test the final public robots.txt rather than relying on the admin preview.
  
Caveats
  • Escalate when the vendor cannot preserve an explicit crawler policy or export the active file.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Record the owner-approved policy and operator-documented current user-agent tokens.
  2. Test each representative path against the exact specific and wildcard group selection.
  3. Fetch the final public file after deployment and rerun the checker.
  4. Keep sensitive content behind authentication regardless of the robots result.
 
Escalate when
 
Escalate when the operator token or intended product use cannot be confirmed, generated and custom robots rules conflict, or the requested policy could expose confidential content.
 
 
 
 
  
 
 
     
  •  Needs review Readiness module has insufficient evidence Fix: Provide the missing crawl, content, or authority evidence and rerun the module before drawing a readiness conclusion. 
  •  Warnings Content is not answer-ready Fix: Lead with a direct answer and add visible author and freshness evidence where relevant. 
  •  Warnings Entity evidence is weak Fix: Name the primary entities consistently, reconcile them to stable identifiers, and support them with explicit facts. 
  •  Warnings Citation evidence is insufficient Fix: Place a direct primary source beside each factual claim and recheck aging evidence. 
    •