A free AI search readiness checker should tell you more than whether a URL loads. It should show whether relevant crawlers can reach the page, whether the server delivers usable content, whether index controls match your intent, whether the subject is clear, and what evidence supports the result. Visible Pilot’s automated checker is still in development, so this page gives you the exact manual test and scoring method now—without pretending a non-functional tool is live.
Launch status: The automated Visible Pilot checker is coming soon. No URL field on this page currently runs a hidden scan, stores your data or produces a made-up score. Use the five manual checks below today.
Run the free AI search readiness checker manually
Choose three representative URLs: your homepage, one commercial or product page, and one knowledge article. Test all three so one healthy page does not hide a site-template, firewall or content problem elsewhere. Award each check 0, 1 or 2 points using the evidence rules below.
| Score | Meaning | Evidence standard |
|---|---|---|
| 2 — Pass | The condition is confirmed | Repeatable evidence exists for all three URLs |
| 1 — Warning | Mixed, incomplete or unstable result | At least one URL or test is inconclusive |
| 0 — Fail | A verified barrier exists | The response, directive or delivered content proves the failure |
What the checker tests
Check 1: crawler access
Open https://yourdomain.com/robots.txt and inspect the rules that apply to the crawler you care about. For ChatGPT search discovery, review OpenAI’s current documentation for OAI-SearchBot; do not assume that allowing GPTBot, which has a different purpose, proves search access. Also check wildcard rules because an unnamed bot may inherit the User-agent: * group.
- Pass: intended search crawlers are allowed on all representative paths and no downstream security control blocks them.
- Warning: robots.txt appears permissive, but firewall, CDN or server-log evidence is unavailable.
- Fail: a relevant URL is explicitly disallowed or a verified request receives a block or challenge.
Important: A changed user-agent string is only a simulation. It does not prove a request came from a platform’s verified infrastructure. Use official IP verification guidance and server-side evidence when authenticity matters.
Check 2: HTTP delivery and rendering
Request each URL, follow redirects and record the final HTTP status. A public page should normally resolve to a stable 200 response rather than a redirect loop, timeout, access challenge, soft error or intermittent 5xx. Then compare the raw HTML with the visible page. The title, primary answer and important links should be available without relying entirely on a browser-side application.
- Pass: stable final URL, successful response and meaningful main content in delivered HTML.
- Warning: content is present only after heavy client rendering or varies between requests.
- Fail: timeout, loop, block, server error or empty shell prevents reliable retrieval.
Check 3: index and canonical controls
Inspect the robots meta tag, X-Robots-Tag response header and canonical link. Confirm they point toward the page you actually want surfaced. Google explains that robots.txt manages crawling; it is not a reliable way to keep a web page out of search. A page must be crawlable for a crawler to observe a noindex rule.
- Pass: the page is intended for discovery, has no accidental noindex directive, and uses a sensible self-referencing or intentionally chosen canonical.
- Warning: conflicting tags, duplicate variants or unclear canonical intent exist.
- Fail: the intended page is noindexed, canonicalized to the wrong URL or otherwise ineligible.
Check 4: content and entity clarity
Read only the title, first paragraph, headings and key evidence. Can you identify the page’s subject, audience, answer, organization and supporting sources? Useful content does not need to be written for a machine, but vague claims, missing context and unexplained entities make reliable extraction harder for both people and automated systems.
- Pass: the page states its purpose early, uses descriptive headings, names important entities consistently and supports factual claims.
- Warning: the answer exists but is buried, ambiguous, poorly sourced or mixed with unrelated intent.
- Fail: the page does not provide a usable answer or its main claims cannot be evaluated.
Check 5: observable platform evidence
Run a small, fixed prompt set that reflects real customer questions. Save the full prompt, product surface, date and complete response. Distinguish a brand mention from a linked citation and direct page retrieval. Conventional ranking is useful context, but it is not proof that another AI system discovered or used the page.
- Pass: repeated tests show the intended page can be retrieved or cited under documented conditions.
- Warning: results vary, mention the brand without a source, or cannot be reproduced.
- Fail: a verified technical barrier prevents the platform from reaching the page. Absence alone is not automatically a technical fail.
Readiness is not a citation guarantee. A technically healthy page may still be absent because of relevance, authority, freshness, platform coverage, competing sources or model behaviour. The checker is designed to find removable barriers, not predict a platform’s final selection.
How the free AI search readiness checker score works
Add the five check scores for a maximum of 10. Do not average away a critical failure: a total of 8 with crawler access scored at 0 still means the affected content has a verified access problem.
| Total | Result | Recommended action |
|---|---|---|
| 9–10 | Strong baseline | Preserve the evidence, expand the URL sample and monitor platform observations. |
| 6–8 | Needs targeted work | Fix the lowest-scoring layer first and retest with identical inputs. |
| 0–5 | Material readiness gaps | Prioritize access, delivery and index-control failures before content polishing. |
Keep the five subscores beside the total. A transparent result such as Access 0, Delivery 1, Controls 2, Clarity 2, Evidence 1 is more useful than displaying only “6/10” because it tells the owner where to act.
Example results: healthy page vs blocked page
| Test layer | Healthy page | Blocked/problem page |
|---|---|---|
| Crawler access | Allowed paths; no verified firewall block | Relevant crawler disallowed or challenged |
| Delivery | Stable 200; primary answer in HTML | 403, timeout, loop or empty application shell |
| Controls | Intended page indexable; canonical is coherent | Accidental noindex or incorrect canonical |
| Clarity | Purpose, entity and evidence are explicit | Ambiguous subject or unsupported claims |
| Platform evidence | Dated, repeatable retrieval observation | Technical failure reproduced; selection remains untested |
The healthy example earns 10 only when every condition is supported by evidence. The blocked example should not receive a single generic “invisible” label. Its report should name the exact failing layer, URL, observation and safest next test.
What the future automated checker will report
The planned Visible Pilot check will focus on observable website conditions. Each result should include a status, the evidence captured, why the finding matters, a recommended fix and a retest method. Where the platform cannot verify a condition safely, the result should say inconclusive rather than guessing.
- Requested URL, final URL, redirect path and response status
- Relevant robots.txt rules and the user-agent group applied
- Robots meta, X-Robots-Tag and canonical controls
- Presence of meaningful title, headings and main content in delivered HTML
- Evidence fields for pass, warning, fail or inconclusive results
- Prioritized fixes and a repeatable retest
Privacy and data handling
The live checker’s final privacy policy will be published before automated scans are enabled. The product should request only public URLs, avoid authenticated or private areas, disclose what is stored and for how long, and separate essential diagnostic data from optional analytics or marketing consent. Until that policy and the scanner are live, this page does not accept or scan submitted URLs.
Do not test private, staging or authenticated URLs with a public checker. Use controlled internal tooling and appropriate authorization for systems that are not meant to be publicly accessible.
Troubleshooting common checker results
| Symptom | Likely cause | Next step |
|---|---|---|
| Invalid URL | Missing scheme, malformed host or unsupported local address | Use the complete public HTTPS URL. |
| 403 or challenge page | WAF, CDN bot rule, authentication or geo restriction | Review security events and verify the request identity before changing a rule. |
| Timeout | Slow origin, redirect loop, DNS/network error or resource exhaustion | Test the final URL directly and inspect server timing and logs. |
| Empty or thin HTML | Client-only rendering or failed data request | Ensure the primary answer is delivered reliably and compare raw with rendered output. |
| Inconclusive | Evidence unavailable, unstable response or unverifiable crawler identity | Collect server-side evidence and rerun the same test. |
Related manual checks
- Use Google Search Console URL Inspection for Google-specific crawling, indexing and rendered-page evidence.
- Open the response headers and confirm status, redirects, canonical and robots directives.
- Review CDN, WAF and origin logs for blocked, challenged or rate-limited requests.
- Compare the page source with the rendered page and identify where the primary answer appears.
- Run the same fixed prompts on a schedule and preserve complete results rather than selected screenshots.
For a fuller process, follow the AI search readiness checklist for business websites, learn how to test if a website is ready for AI search, or review the technical issues that affect AI search visibility.
Frequently asked questions
Is this AI search readiness checker live?
The automated Visible Pilot scan is not live yet. The manual five-check framework on this page is available now and uses the same evidence-first approach planned for the product.
Can a checker guarantee that ChatGPT, Google AI Mode or another platform will cite my site?
No. A checker can identify technical and content conditions that help or hinder discovery and use. Platform selection remains dependent on relevance, authority, freshness, coverage and model behaviour.
Does allowing GPTBot make a website visible in ChatGPT search?
Not by itself. OpenAI documents GPTBot and OAI-SearchBot as independent controls with different purposes. Review the current official crawler documentation and test the relevant access path rather than treating one allowance as proof of another.
How accurate is the score?
The score is a summary of documented checks, not a probability of citation. Its usefulness depends on representative URLs, reliable evidence and consistent retesting. Always retain the five subscores and observations.
How often should I retest?
Retest after changes to robots rules, hosting, CDN/WAF configuration, rendering, templates, canonical logic or important content. For ongoing monitoring, use a stable URL sample and a consistent schedule so results remain comparable.
Official references
- Google Search Central: AI features and your website
- Google Search Central: robots.txt introduction
- Google Search Central: robots meta tag specifications
- OpenAI: overview of OpenAI crawlers
- Perplexity: crawler documentation
Run the free Visible Pilot check
The automated free AI search readiness checker is coming soon. In the meantime, use the manual scorecard above to document your baseline. If you want Visible Pilot updates or an evidence-led review of your site’s crawler access, delivery, index controls and content clarity, visit Visible Pilot.
Leave a Reply