Access, rendering, structure, evidence

The readiness pass: can AI engines actually read your site?

Before an AI engine can recommend you, it has to be able to read you. That's a lower bar than most brands assume - and a surprising number of sites fail it without knowing.

28 Labs · August 2026

A readiness pass checks four things: whether AI crawlers are actually allowed in (access), whether the facts on your page exist before JavaScript runs (rendering), whether your pages state a clear answer under structure an engine can extract (structure), and whether the entity facts about you are consistent enough to cite safely (evidence). It's pass/fail plumbing, not a growth strategy - passing makes you eligible to be read. It doesn't make you the answer.

What are the four checks in a readiness pass?

Each one is a different way a site can be invisible to an AI engine without anyone noticing. A blocked crawler never sees the page. A JavaScript-only fact never reaches the model. An unstructured page gets read but not extracted cleanly. Inconsistent facts get read and extracted, then discarded because the engine can't verify them. Any one of the four can quietly zero out everything downstream of it.

1
Access - is the crawler let in?
2
Rendering - is the fact in the raw HTML?
3
Structure - is the answer extractable?
4
Evidence - is it safe to cite you?
Each stage gates the next. Fixing structure on a page a crawler never fetches changes nothing.

What counts as access, and what silently blocks it?

Access means an AI crawler can reach your page and get a response back before it gives up. Most sites don't deliberately block AI crawlers - they block them by accident, through a robots.txt rule written for a different purpose or a bot-management setting nobody revisited. AI providers actually run two different kinds of crawler, and the access decision is different for each.

Training crawlers
GPTBot, ClaudeBot, Google-Extended, Bytespider, Meta-ExternalAgent. These collect content to train future models. Blocking them opts you out of training - it does not opt you out of being cited.
Retrieval and search crawlers
OAI-SearchBot, ChatGPT-User, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User. These fetch a page in real time because a user asked a question. Block these and you're removing yourself from citation eligibility, whether you meant to or not.
Bot-manager and CDN rules
Cloudflare, Akamai, and similar bot-management layers ship with managed rulesets that can 403 AI user agents by default, independent of what your robots.txt says. This is the most common accidental block we find - the robots.txt file looks fine and the crawler still gets rejected at the edge.

The check isn't "do we have a robots.txt file." It's: pull your server logs, filter for the retrieval user agents by name, and confirm they're getting 200s, not 403s or timeouts. A blanket Disallow: / left over from a staging environment, or a bot-manager rule turned on for a different reason, will quietly zero out every check that comes after it.

Why does rendering decide whether an engine can read you at all?

Most AI crawlers read the HTML that arrives on the first response - they don't run your JavaScript. An analysis of over 500 million GPTBot fetches found zero JavaScript execution. ClaudeBot and PerplexityBot behave the same way: they fetch the page, extract text from the initial markup, and move on. If your price, your service area, or your core claim only renders after a client-side script runs, those crawlers never see it - the page might as well be blank at the point that matters.

The one exceptionGoogle-Extended, which feeds Gemini, inherits Googlebot's rendering pipeline and does execute JavaScript. That means a fact invisible to ChatGPT and Claude can still be visible to Gemini through Google's index - engine-by-engine differences aren't a rounding error, they're a different pass/fail outcome per engine.

The check is simple to run yourself: view the page source (not the browser's inspected DOM) on any page that carries a fact you need an engine to know. If the fact isn't in that raw source, server-render it, or the engines that matter to you won't know it exists.

What does "structure" mean to an engine reading your page?

Structure means a page states one clear answer, near the top, under a heading phrased the way a person would actually ask the question. AI engines lean on headings to judge relevance before they extract the passage beneath - a heading that reads like a marketing label instead of a question makes that job harder for the engine and worse for you.

Structure that extracts cleanly

  • H2s phrased as the reader's actual question
  • First sentence under each H2 answers it directly
  • One primary claim per page, stated in prose, not just a bullet fragment
  • FAQPage schema on Q&A content, Article schema on editorial
  • Unique, descriptive title and meta description per page

Structure that gets skipped

  • Marketing-voice headings ("Our Approach," "Why Choose Us")
  • The actual fact buried three paragraphs after the heading
  • Multiple competing claims on one page with no clear primary answer
  • Schema markup for a type the page doesn't actually match
  • Duplicate or generic titles across pages

What evidence do engines need before they'll recommend you?

Evidence is the set of facts an engine needs to safely name you in an answer without guessing. An engine can find your page, read it, and extract it cleanly, and still decline to recommend you if it can't confirm who you are, where you operate, or what you charge. Citing an uncertain entity is a risk the model has to weigh - give it fewer reasons to hedge.

Identity
Your legal or trading name, what category you're in, and what you actually do - stated plainly, not implied. Organization schema and a real About page both help here.
Location
Where you operate, stated in prose an engine can extract - not only inside a map widget or a contact form that requires interaction.
Pricing
Prices or ranges where you can publish them. Absence isn't neutral - an engine that can't find a number often just doesn't mention you when price is part of the question.
Consistency
The same name, category, and location facts across your own site and the third-party sources engines pull from - directories, review platforms, industry sites. Contradictions read as risk, not nuance.

Which checks do we refuse to score, and why?

A readiness check earns a place on the sheet only if it traces to something an engine has documented or something measurement has actually shown moving an answer. A lot of what gets sold as an "AEO checklist" fails that bar. We don't score it, and we'd tell a client the same thing we're telling you here.

The honest lineIf a check doesn't trace to a documented crawler behavior, a schema.org type an engine actually parses, or something we've watched move a real answer, it doesn't go on the pass/fail sheet. Theater dressed as diligence is still theater.

What we do about it

We run the four-bucket pass - access, rendering, structure, evidence - as the first gate on any engagement, before we touch strategy. It's deliberately narrow: pass/fail plumbing that decides whether you're eligible to be read, not a growth plan. Eligibility isn't visibility - passing the readiness pass gets you in the room, it doesn't get you picked. The demand and evidence layers that decide whether AI engines actually recommend you over a competitor are a separate discipline, covered in how to navigate AEO. If you want a first-party read on how often engines are already reading you, pair this with Microsoft's own citation data, covered in what the Bing Webmaster Tools AI Performance report can and can't tell you.

28 Labs measures how AI engines answer real buyer questions - and what moves the counts. Every number we publish re-derives to specific questions and engines. try28labs.com