
What AI accessibility means
AI accessibility is whether large language model systems and the crawlers that feed them can actually reach and parse your content. That covers two separate questions. First, can the bot fetch the page at all, meaning your robots.txt, firewall, and bot-management rules let it through. Second, once it has the response, is the substance present as real text in the HTML, or is it locked inside images, canvas, or JavaScript that the fetcher never executes.
This check fails when content that a human sees in a browser is effectively invisible to a non-rendering fetch. If ChatGPT's browsing tool, Perplexity's crawler, or Google's AI systems pull your URL and get an empty shell, a spinner, or a wall of divs with no words, you are not in the answer.
Why this is the foundation of GEO
Traditional Google rendering is relatively forgiving: Googlebot runs JavaScript, so client-side content often gets indexed eventually. Many AI retrieval pipelines are less patient. A lot of them fetch raw HTML and read it, without a full browser render, and without waiting for your framework to hydrate. If the words are not in that first response, they may as well not exist.
- Retrieval and citation. Answer engines select and quote from pages they can parse cleanly. Clean, text-first HTML is easier to extract, chunk, and cite than a JavaScript app that renders to a blank body.
- Access control. A growing number of AI crawlers identify themselves: GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Google-Extended, and others. If your
robots.txtor WAF blocks them, you have opted out of those surfaces whether you meant to or not. - Structure aids comprehension. Real headings, lists, tables, and semantic HTML give a model the structure to understand relationships. A soup of unlabeled divs makes extraction lossy.
Blocking AI bots is a legitimate business choice for some publishers. The failure this check cares about is the accidental one: you wanted the visibility and quietly locked yourself out.
Where content goes invisible
How to detect it
| Tool | What it reveals |
|---|---|
| curl | Fetch the raw HTML with curl -A "GPTBot". If your body text is missing from that response, non-rendering AI fetchers see nothing. |
| Screaming Frog | Crawl once with JavaScript rendering off. Pages that show near-zero word count with rendering off are JavaScript-dependent. |
| robots.txt review | Check for Disallow rules against GPTBot, PerplexityBot, ClaudeBot, Google-Extended, and OAI-SearchBot. |
| Server logs | See which AI user agents hit you and whether they get 200s or 403s from your firewall or bot manager. |
| Search Console URL Inspection | Compare the raw and rendered HTML to gauge how much of the page depends on JavaScript. |
How to fix it, step by step
- Serve text in the initial HTML. Use server-side rendering, static generation, or prerendering so the main content is present in the first response, not injected after hydration.
- Get words out of images. Text baked into a graphic or canvas is unreadable. Use real HTML text, and where an image is essential, add descriptive alt text.
- Use semantic structure. Real
<h1>to<h3>,<ul>,<table>, and paragraph tags. Structure is what lets a model chunk and understand your content. - Decide your AI bot policy on purpose. If you want the visibility, allow the relevant AI crawlers in
robots.txtand confirm your WAF is not returning 403s to them. If you want to block them, do it deliberately and document it. - Re-test with a bot user agent. Fetch the page as GPTBot with curl and read what comes back. If your content is all there in plain text, you passed.
DO
- Render main content server-side or statically
- Keep body text as real HTML, not baked into images
- Use semantic headings, lists, and tables
- Allow the AI crawlers you want visibility from
- Verify by fetching as a bot user agent
DON'T
- Ship a blank body that only fills in after JavaScript
- Trap key text inside images, canvas, or video
- Block AI bots by accident in robots.txt or your WAF
- Rely on unlabeled div soup with no semantics
- Assume Googlebot rendering means every AI bot renders too
What "good" looks like
Fetch your page with a plain HTTP request as an AI user agent and the full article is right there in the response: headings, paragraphs, lists, and tables as real text. Your robots.txt and firewall let the crawlers you care about through and return 200s. Nothing important lives only inside an image or a client-side render. When a person can read your content with JavaScript disabled, so can the machines feeding AI answers, and you become a source they can quote.
FAQ
If Google can render my JavaScript, why isn't that enough for AI?
Which AI crawlers should I know about?
Do I have to allow AI bots?
My site is a single-page app. Am I stuck?
Not sure whether AI engines can actually read your site?
An audit will fetch your pages the way AI crawlers do, flag JavaScript-only content, and check whether your robots and firewall rules are quietly locking you out of AI answers.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.







