How to Read Your AI Readiness Report

If you just ran your first AI Readiness Audit and the report looks like a pile of technical jargon, that's expected. This guide walks through every section so you know what's actually worth fixing and what to tackle first.

One thing upfront: the report is a diagnostic, not a grade. A poor score doesn't mean you're invisible to every AI system. It means there are specific, findable issues. That's more useful than not knowing.

What the Report Covers

Every audit has three sections:

• Performance - Can AI systems fetch your pages without timing out?
• Crawlability - Do robots.txt rules, HTTP Status Check responses, and noindex signals allow reliable access?
• Content Visibility - Do crawlers see your actual content, or a JavaScript shell?

The PDF shows all three at a glance. In the web app, the Performance tab groups TTFB, CLS, and INP together for deeper inspection. Start with the overview to spot where problems exist, then go section by section to understand why.

Start here: use the overview to identify which section is actually causing risk.

Performance: TTFB, CLS, and INP

Performance data comes from Google's Chrome User Experience Report (CrUX) - real visits from real users, not a lab simulation. AI systems fetching your content face the same network conditions your visitors do.

You'll see two numbers per metric: Page (the URL you audited) and Origin (your whole domain). A fast homepage with a slow product page means AI systems might reach some of your content reliably while timing out on others.

TTFB - Time to First Byte

How long it takes your server to respond to a request. It's the most important of the three metrics for AI access.

Many AI systems fetch multiple sources simultaneously under tight time limits. A slow server response - before a single byte of content arrives - can cause a timeout. Your page never gets read.

As an example: both page and origin showing 850ms ("Needs Improvement") means roughly one in four users experiences even slower responses than that figure. If TTFB climbs past 1800ms, fetch failures become a real problem.

TTFB is the highest-leverage performance signal for AI fetch reliability.

Fixes, roughly in order of effort:

• Server-side caching for pages that don't change per request (quick win)
• CDN to reduce latency for users and crawlers querying from far away
• Database and backend query optimization (bigger lift, bigger payoff)

CLS - Cumulative Layout Shift

How much your page jumps around during loading. An image that loads late and pushes content down, an ad that pops in and shifts the layout, a font that swaps and reflows text - all of these increase CLS.

CLS matters less than TTFB for AI access, but high scores correlate with rendering instability. Content that moves during load is harder for extraction tools to capture cleanly. High CLS also suggests late-loading elements, which often means JavaScript-dependent content - more on that in the Content Visibility section.

Fixes:

• Reserve space for images, ads, and embeds in CSS before they load
• Don't inject content above existing elements
• Be careful with font-display: swap if your fallback font is a different size than your web font

CLS indicates layout stability - high scores often correlate with JavaScript-dependent content.

INP - Interaction to Next Paint

How quickly the page responds to user interactions - clicks, taps, keyboard input. High INP usually means the browser's main thread is busy processing JavaScript.

INP is mainly a user experience signal, but poor scores are worth noting here. JavaScript-heavy pages tend to hide content from crawlers that don't fully execute scripts. If INP is poor, check whether your content visibility gap is significant too - they often go together.

Fixes if you're in Poor territory:

• Break up long JavaScript tasks
• Defer non-critical scripts
• Move logic server-side where possible

Poor INP often signals JavaScript-heavy pages that may hide content from crawlers.

When CrUX Data Is Missing

You might see "No data available" for some or all metrics. This isn't a problem with your site - it means the page doesn't have enough real-user traffic for Google to include it in CrUX. Low-traffic URLs hit this often.

When page-level data is missing, we fall back to origin-level data for the whole domain. When that's missing too, we say so rather than guessing. For low-traffic pages, run Lighthouse separately for synthetic performance data.

Crawlability: AI Bot Access

This section combines three crawlability layers: robots.txt policy across 33 AI crawlers (origin-level), HTTP Status Check responses for Browser + GPTBot + ClaudeBot + PerplexityBot (URL-level), and page-level noindex detection.

Here's why robots.txt is still the most binary issue in the report: if it blocks GPTBot, nothing else matters for ChatGPT crawling. Same logic applies to ClaudeBot, PerplexityBot, and other crawlers.

HTTP Status Check adds runtime reality. Even with allowed robots rules, live requests can return non-2xx responses due to WAF rules, anti-bot filters, redirect chains, or overloaded infrastructure.

Fix robots.txt blocks first, then resolve critical HTTP status issues (429/5xx) and noindex conflicts.

Code interpretation: 2xx = reachable, 3xx = redirected (still good), 4xx = warning, 429/5xx = critical, timeout/no response = unavailable. Redirect notes are shown when final URL differs from input, including trailing-slash changes.

All bots allowed + healthy HTTP: No major crawlability blockers. AI systems can request your pages reliably.

Some bots blocked: Could be intentional (you don't want certain systems training on your content) or accidental (a wildcard rule caught more bots than you realized). Check which bots are blocked and confirm it's deliberate.

Major bots blocked: Direct visibility problem. GPTBot, ClaudeBot, PerplexityBot, CCBot blocked means you're likely absent from the most widely used AI systems.

The most common mistake we see: a User-agent: * followed by Disallow: / blocks everything. Developers add this to stop staging sites from being indexed, then forget to remove it when the site goes live. Check yourdomain.com/robots.txt directly to see what's actually there.

One important caveat: robots.txt is advisory. Compliant, well-behaved crawlers - which all major AI providers are - will respect it. But it's not a technical enforcement mechanism. If you need to actually restrict access to content, that requires server-level authentication.

Content Visibility: What Crawlers Actually See

We render your page twice: once with JavaScript fully executed (what a user sees) and once as raw HTML (what the server sends before any scripts run). The report compares word counts between the two, shows the gap, and now pairs that with a Content Diff impact summary plus a prioritized "See Content Invisible to AI Bots" list.

A real example from a recent audit:

The gap size tells you how much content depends on JavaScript; Content Diff tells you which sections matter most.

• Words visible to people: 1,018
• GPTBot sees: 813 words (−205 words, 20.1% gap)
• ClaudeBot sees: 813 words (−205 words, 20.1% gap)
• PerplexityBot sees: 813 words (−205 words, 20.1% gap)

About a fifth of the content only appears after JavaScript runs. That's a moderate gap. The 205 missing words might be navigation elements and supplementary content, or they might be main product copy. The audit tells you the size of the problem - you need to look at the page to understand what's actually missing.

Use Content Diff first to prioritize high-impact missing sections. Then use the Render Pattern card to understand why the mismatch exists. If it looks like CSR, assume the HTML is too shell-heavy. If it looks Hydrated or SSR-like, the issue is usually partial content loss rather than a fully empty shell.

How to read the gap percentage:

• Under 5%: Normal. Minor dynamic elements like timestamps or interactive widgets don't meaningfully affect AI access.
• 5–30%: Worth investigating. Navigation links missing is less critical than main article text being absent. Look at what's in the gap before deciding urgency.
• Over 30%: Priority fix. If your main content only loads after JavaScript runs, most crawlers won't see it.

Most modern sites use JavaScript frameworks (React, Vue, Angular) to render content client-side. Users see a complete page because their browser runs the scripts. Crawlers with limited or no JavaScript execution - which describes many AI systems - see the HTML skeleton.

The fix isn't to stop using JavaScript. It's to make sure critical content exists in the raw HTML response. Use the Content Diff list to pick exactly what to move first, then use the Render Pattern card to choose the implementation path (SSR, SSG, pre-rendering, or progressive enhancement).

Content Structure now also validates semantic heading order and ARIA labels from raw HTML, helping you detect extraction friction even when word counts look acceptable. These checks are structural extraction signals for crawlers and AI agents — not a full WCAG accessibility audit.

What to Fix First

Most sites have issues in one or two areas, not all three. When there are multiple problems, this order works for most sites:

1. Crawlability blockers — fix first, full stop. If major AI bots are blocked in robots.txt or HTTP Status Check returns critical runtime errors (429/5xx), fix this before touching anything else. There's no point optimizing a page that crawlers can't access reliably.
2. Severe TTFB — fix next. If TTFB is over 1800ms, fetch reliability is genuinely at risk. Server response time is the highest-leverage performance fix specifically for AI access.
3. Critical content visibility gaps. If your gap is over 30% - especially if main article text, product descriptions, or key page copy are missing from raw HTML - this is the next priority. Often the hardest fix technically, but direct impact on what crawlers can extract.
4. CLS and INP — fix last. Lower priority than the three above for AI access specifically. Address them once the bigger issues are resolved, or if you're also optimizing for user experience and traditional search.

Lab Experiments (Exploratory)

The audit tool also includes a Lab Experiments tab. These checks cover signals that have been widely discussed — llms.txt detection, JSON-LD Schema types, and an HTML vs Markdown comparison — but none of them have been shown to have any direct impact on LLM visibility.

Think of them as hypothesis-generating diagnostics: useful for investigating structure and readability signals, not as items that belong on a fix-first list. They are intentionally separate from the core checks above to avoid mixing confidence levels.

After You Make Changes

Run the audit again. Compare the new report to the old one.

The numbers should move. TTFB dropping from 1800ms to 700ms shows up clearly. A content visibility gap closing from 30% to 8% is visible in the data. Treat this as an ongoing check rather than a one-time test - site changes like new JavaScript frameworks, updated robots.txt, or server migrations can introduce new problems. A quarterly audit catches regressions before they compound.

If anything in your report isn't clear, the Help page covers each metric in more detail with common troubleshooting steps.

A perfect score isn't the goal. Knowing exactly what's in the way - and fixing it - is.