How Can I Tell If Our Pages Are Ready for AI Search?
AI tools like ChatGPT, Perplexity and Google’s AI Mode answer questions by reading web pages. They fetch the raw page and look for facts in the text. If a fact isn’t there as text, it isn’t there at all.
You can check this yourself. Pick a few pages that matter. Fetch each one the way an AI agent does. Then check seven things: can it get in, is the content in the delivered page, do the headings make sense, are the facts stated as sentences, is there an FAQ, is there structured data, and is anything stuck inside images.
We ran that check on our own homepage on 19 October 2026. Of everything an AI agent downloaded, 2.6% was text it could read. The rest was delivery.
One warning. A page that passes every check is readable. That is not the same as being cited. This guide explains the difference, and what to do when a page fails.

The seven checks, pinned to the page an AI agent receives. On 19 October 2026 the siftserve.com homepage delivered 473,817 bytes, of which 12,437 bytes were readable text (2.6%). Measurement method: siftserve.com/blog/how-we-measure-the-capture-stats.
Key takeaways
- Page readiness is a readability question: can an AI agent fetch the page, find its stated facts, and interpret them without rendering JavaScript? No major AI crawler executes JavaScript across 500M+ GPTBot fetches (Vercel × MERJ, December 2024), so the delivered HTML is the whole test.
- Most sites fail the first check. 57% of the top 1,000 sites show AI crawlers a nearly empty page, 403 of the 711 that could be read at all (ModPageSpeed, May 2026).
- Seven diagnostic checks cover the ground: access, content in the delivered HTML, headings, facts as text, FAQ pairs, structured data, and image-locked facts. None of them is a scored certification, and no validated pass mark exists for the set.
- A CORE-EEAT audit score grades 80 checks across eight dimensions, each scored 0–100. It is most useful as a before-and-after pair on the same page (our homepage: 65 → 76). No threshold has been validated as “ready”, and a score cannot prove AI-search visibility.
- Readability and visibility are measured differently. Readability is checked on the page. Visibility is counted in citations and AI referrals over time, against a baseline. Structure, statistics and citations lifted AI visibility 30–40% in the Princeton GEO study (KDD 2024), which is a reason to fix readability, not proof that any one page will be cited.
- SiftServe’s free pilot runs eight weeks on one domain, covers model costs, delivers a before-and-after audit report for every page, and measures citations and AI referrals against unsifted pages.
If you’ve already read our guide to making a website AI-readable without rebuilding it, this is the companion piece. That one is the fix list. This one is the inspection, so you know which fixes a page needs and how to tell whether they landed.
This guide is for the person who owns the website budget: a marketing lead, a founder, an operations head who has been asked “are we ready for AI search?” and wants an answer they can check themselves. It covers how to pick the pages worth testing, how to inspect each one by hand, how to read an audit score without over-reading it, and what to fix first. It doesn’t cover the mechanics of adding schema or rewriting content; the no-rebuild guide does that.
In this guide
- Start by checking what an AI agent can read
- What page readiness means
- Which pages and facts to test
- How to inspect each page
- How to interpret the audit result
- What to fix and how to recheck
- Where SiftServe fits
- Frequently asked questions
- Where to start
Start by checking what an AI agent can read
For each page that matters, fetch it without a browser and answer seven questions about what came back.
| Check | The question | What a fail looks like |
|---|---|---|
| 1. Access | Can the AI crawlers you want get the page? | robots.txt disallows GPTBot, OAI-SearchBot, ClaudeBot or PerplexityBot; the page returns 403 or a redirect loop to a crawler user agent |
| 2. Delivered content | Is your key sentence in the raw HTML? | The sentence exists on screen but not in view-source; the content arrives only after JavaScript runs |
| 3. Headings | Do the headings alone describe the page? | One H1 that says “Home”, H2s that say “Overview” and “Learn more” |
| 4. Facts as text | Is each fact a buyer needs stated in a sentence? | The price lives in a widget, the address in a map embed, the warranty in a PDF |
| 5. FAQ pairs | Are the questions customers ask answered in Q&A form? | No FAQ, or an accordion whose answers load on click |
| 6. Structured data | Is there JSON-LD, and does it match the visible page? | None present, or a marked-up price that differs from the one on screen |
| 7. Image-locked facts | Does any fact exist only inside an image? | A pricing table saved as a PNG, a chart with the numbers in pixels, a menu as a photo |
Seven checks, maybe fifteen minutes a page once you’ve done one. They’re diagnostic. Each one tells you whether a specific kind of fact is reachable, and that’s all it tells you. Don’t add them up into a score. Nobody has validated what a 5-out-of-7 means for your traffic, and we’re not going to pretend otherwise.
What page readiness means
Readiness, for our purposes, means readability: an AI agent can fetch the page, find the facts it states, and interpret them correctly, using nothing but the HTML the server sends on a single request.
That last clause is where most of the trouble lives. When an AI system answers a question, something has to go and get your page. The Vercel × MERJ server-log study watched more than 500 million GPTBot fetches and found zero JavaScript execution (Vercel, December 2024). So whatever your page becomes after scripts run, the agent never sees it. It reads the first response and moves on.
Readability is a property of the page. You can check it on your laptop in a minute, and the result is stable until the page changes.
Visibility is something else. Visibility means an AI system used your page: cited it in an answer, linked to it, sent a visitor your way. That depends on things the page can’t control. Whether the engine fetched you at all for that question. Who else has a page on the same topic. How the engine weighs sources that week. Google’s own documentation says there are no additional requirements to appear in AI Overviews or AI Mode beyond the usual SEO fundamentals (Google Search Central), which is another way of saying readability is necessary and nowhere near sufficient.
| Readability | Visibility | |
|---|---|---|
| What it asks | Can an agent read the page’s facts? | Did an AI system cite or refer to the page? |
| Where it’s measured | On the page, from one fetch | In AI answers, server logs and referral traffic, over time |
| Who controls it | You | Partly you, mostly the engines and your competitors |
| How fast it changes | When the page changes | Continuously |
| What a good result proves | The facts are reachable | The facts were used, this week, for these questions |
Keep the two apart and the rest of this guide is simple. Readability is the thing you can check and fix today. Visibility is the thing you measure afterwards, slowly, against a baseline.
Which pages and facts to test
Don’t audit the whole site. Start with the pages an AI agent would need to answer a buyer’s questions about you, which is usually five to ten URLs.
The homepage first, because it’s where every agent’s picture of you begins. Then the pages that carry a decision: your main product or service pages, pricing, about and contact. Then the two or three articles or resources that already earn the most search traffic, since those are the pages agents are most likely to be pointed at.
For each page, write down the facts a buyer should be able to get from it before you look. That list is your test. If you can’t say what a page should tell an AI agent, the page probably isn’t telling it anything.
| Page | Facts a buyer should be able to retrieve |
|---|---|
| Homepage | What you sell, who it’s for, where you operate, one proof point, how to contact you |
| Product or service page | What it is, what it costs or how pricing works, delivery or onboarding time, what’s included, what makes it different, one measurable claim |
| Pricing | Plan names, prices or the pricing model, what each plan includes, the free or trial option, how to buy |
| About | Legal entity, founding year, location, who runs it, what the company does in one sentence |
| Contact | Address, email, phone, hours, response time |
| Top articles | The direct answer to the title’s question, the numbers it relies on, their sources, the date |
Notice how concrete these are. “Our story” isn’t a fact. “Founded in 2012, roughly 200 installations a year, ten-year hardware warranty” is three. Agents retrieve the second kind and ignore the first.
How to inspect each page
This is the hands-on part. You’ll need a terminal for two of the steps, or a developer who’ll spend ten minutes with you. Everything else is view-source and reading.
Fetch the page the way a crawler does
First, robots.txt. Open yoursite.com/robots.txt and look for Disallow rules aimed at the crawlers that feed AI answers. The vendors publish their names: OpenAI uses GPTBot for training and OAI-SearchBot for ChatGPT search, and says sites that opt out of OAI-SearchBot won’t be shown in ChatGPT search answers (OpenAI). Anthropic lists ClaudeBot, Claude-User and Claude-SearchBot (Anthropic). Perplexity uses PerplexityBot for search results and recommends allowing it (Perplexity). A lot of sites blocked all of these in 2023 as a training opt-out and never revisited it. The block still holds.
Then fetch the page itself with a crawler’s user agent and no browser:
curl -s -A "GPTBot" -o page.html -w "%{http_code}\n" https://yoursite.com/pricing
Copy
You want a 200. A 403 means the access fix hasn’t landed, whatever robots.txt says. Now open page.html, or view-source in your browser, and search for a sentence you know is on the page. If it’s there, the content survives the fetch. If it isn’t, the page is being built in the browser, and to an AI agent it’s close to empty. That’s the failure behind the 57% figure: 403 of 711 readable top-1,000 sites only revealed their content after JavaScript ran (ModPageSpeed, May 2026). Google’s JavaScript SEO documentation covers the fixes, which are server-side rendering or pre-rendering (Google Search Central).
Measure how much of the download is readable
This one takes a minute and tends to be the moment the problem becomes real. Our capture-stats methodology post has a ten-line Python snippet that strips scripts, styles, SVG and tags from a fetched page and counts what’s left. Run it against your homepage.
We ran it against ours this morning, 19 October 2026. The homepage delivered 473,817 bytes. Of those, 12,437 bytes were readable text, 2,026 words. A 2.6% yield. We’ve measured this twice before, on 26 and 31 August, and got 3.2% both times; the page has grown since, and the readable text barely moved. Our own site, mind you, on a clean static build. Yours is probably worse. A low yield doesn’t mean the content is missing. It means an agent on a token budget has to wade through a lot of delivery before it gets to anything it can use.
Read the headings on their own
Pull the headings out of page.html and read them as a list. Nothing else. If the list reads like a table of contents for the page, you’re fine. If it reads “Home / Welcome / Why us / Learn more”, the agent has no map, and neither does a human skimming.
One H1 that names the subject. H2s for each section, H3s under them, no skipped levels. Headings are the cheapest fix on this list and the most often skipped.
Find each fact as a sentence
Take the list of facts you wrote for this page and search the delivered HTML for each one. Search for the fact stated in words, not the bare number. “Plans start at 49amonth“isafactanagentcanliftandattribute.A“49” inside a pricing widget, next to a toggle that changes it to “$490” for annual, is a guess waiting to happen.
Watch for the three usual hiding places: tabs and accordions whose content loads on click, PDFs linked where a paragraph should be, and maps where an address should be. The content is “on the page” for a person and absent for the agent.
Check the FAQ
If the page earns questions, it should answer them in Q&A form, in the HTML, with the answer directly under the question rather than a link to the help centre. An FAQ is also where long-tail questions live, the ones an agent is most often asked and your main copy never addresses. The Princeton GEO study measured 30–40% more AI visibility from added structure, statistics and citations (Aggarwal et al., KDD 2024); an FAQ with sourced answers is the most direct way to add all three to a page you can’t otherwise restructure.
Check the structured data
Search page.html for application/ld+json. If there’s nothing, the agent is inferring your organisation, product and prices from prose. If there is, paste the URL into the Schema Markup Validator or Google’s Rich Results Test and read what it found. Google’s own introduction describes structured data as a standardised format for providing information about a page and classifying its content (Google Search Central), and that’s exactly the job here: labelled fields instead of inference.
Then compare the marked-up values to the visible page. A price in the JSON-LD that differs from the price on screen is worse than no markup at all, because now the agent has two answers and no way to pick.
Look for facts locked in images
List the images on the page and ask one question about each: does any fact live only in here? Pricing tables exported as PNGs. Charts whose numbers exist only in pixels. A restaurant menu as a photograph. Hero text baked into a banner. An AI crawler fetches HTML, not pixels, and even where a vision model is involved later in the pipeline, you don’t want your prices depending on it reading a JPEG correctly.
Alt text helps, but a one-line alt isn’t a pricing table. The fix is to restate the fact as text near the image. The check is whether that text exists.
How to interpret the audit result
If you’ve run a SiftServe audit, or you’re reading one from a pilot, the page comes back with a CORE-EEAT score. This is what that number measures and what it leaves out.
CORE-EEAT is an 80-item content-quality rubric: eight dimensions of ten checks each, every dimension scored 0 to 100. The first four dimensions (Contextual Clarity, Organization, Referenceability, Exclusivity) measure how well AI agents can find, parse and cite a page. The second four (Experience, Expertise, Authority, Trust) are Google’s E-E-A-T framing of credibility for human readers. The weights differ by content type, so a landing page is graded on Authority and Trust (25% each) and a blog post on Contextual Clarity (25%). Every check is public in our scoring methodology post, and the rubric builds on the open-source CORE-EEAT content benchmark.
Three things to know when you read a score.
Read it as a pair. SiftServe scores every page twice, once for the original and once for the AI-readable version, so the result is a measured before-and-after. Our homepage currently sits at 65 → 76 on the agent-experience view. An earlier, rougher version of both the page and the sift scored 33 → 44. The direction and size of the change tell you more than either absolute number, because many of the agent-experience checks assume structure that ordinary pages don’t carry.
No validated readiness threshold exists. We’d like to tell you that 70 means ready. We can’t, because nobody has shown that a page scoring 70 gets cited and a page scoring 60 doesn’t, and we’re not going to invent the line. Use the score to compare a page with itself over time, or with your other pages under the same content-type weights. Don’t use it to compare against a competitor’s site you haven’t scored the same way.
A score can’t prove visibility. The rubric measures what’s checkable on the page: is there a direct answer in the first 150 words, are there five precise numbers with units, is there a table of contents, is there schema. Those are real, and the Princeton study is good evidence they matter. But a score is still a readability measurement. Whether ChatGPT cited you on Tuesday is a visibility measurement, taken in a different place by a different method. Treat a jump from 65 to 76 as “this page now carries more of what agents look for”, not as “this page is now visible”.

What a CORE-EEAT score measures: 80 checks in eight dimensions of ten, each scored 0–100; the first four form the GEO (agent-experience) score and the last four the SEO (human-experience) score. The siftserve.com homepage pair is 65 → 76 (original → sifted, version 10). No threshold has been validated as “ready”; compare pairs, not absolutes. Rubric: siftserve.com/blog/siftserve-scoring-methodology-core-eeat-content-benchmarks.
What the free AI visibility checker does and doesn’t tell you
One more thing to read correctly, because the name invites confusion. Our free AI visibility checker runs two benchmarks against a domain, not a page: CITE, a domain-authority score for the AI-search era (Citation, Identity, Trust, Eminence) reported as one weighted 0–100 score with a SHIP, FIX or BLOCK verdict, and TALE, a narrative-consistency read (Truth, Architecture, Landing, Evidence) reported as two scores that are never averaged. Both rest on public signals only, and every failing item names the evidence behind it.
So: it estimates whether AI systems are likely to trust and cite your domain, and whether your site tells one consistent story. It doesn’t run the seven page checks above, and it doesn’t count citations. The scores are advisory and peer-relative. Run it for the domain-level picture, run the checks in this guide for the page-level one, and measure visibility separately.
How visibility is measured
Two ways, neither of them a score. Server or CDN logs, filtered for the crawler user agents, tell you whether AI systems fetch you at all and what response codes they get; analytics tools filter bot traffic out, so they’ll never show this. And a fixed set of test prompts, asked of ChatGPT, Perplexity and Gemini on a schedule, tells you whether you appear in answers and what they say. Write the baseline down before you change anything. A single snapshot proves nothing; a weekly series over two months shows a trend. The no-rebuild guide has the detail.
What to fix and how to recheck
When a page fails a check, fix in the order the checks are listed, because each one gates the next. Schema on a page GPTBot can’t fetch helps nobody.
- Access and delivered content first. A robots.txt edit is minutes. A client-side-rendered page is a developer conversation about server-side rendering, pre-rendering, or serving AI traffic a parallel version. Until this passes, nothing below it is reachable, so don’t spend a week on headings for a page agents can’t read.
- Missing and hard-to-extract facts next. Go back to your fact list. Every fact that isn’t a sentence in the HTML gets written as one, near where it belongs: a price line above the pricing widget, the address as text beside the map, the key figures from the chart in the paragraph under it. This is the highest-value work on the list and it’s editing, not engineering.
- Then headings and FAQ. Rename vague headings to say what the section contains. Add four or five questions customers ask, with direct answers, as visible text.
- Then structured data. Add or fix JSON-LD for the organisation, product or article, and make it agree with the page. Validate it.
- Images last. Restate image-locked facts as text; improve alt text while you’re there.
Then recheck. Run the identical seven checks on the updated page, with the same curl command and the same fact list, and write the results next to the originals with the date. Same method, same page, two dates. That’s a before-and-after you can trust. Changing the method between runs, or checking different facts, gives you two unrelated readings and a false sense of progress.
Set a reminder to run it again whenever the page meaningfully changes, and quarterly regardless. Prices change, templates get rebuilt, a new plugin starts injecting the price into a widget. Readiness drifts as the site changes.
Where SiftServe fits
SiftServe is web infrastructure for AI agents. It exists for the case where the checks above fail and fixing them in place isn’t practical: the design is heavy, the front end is a JavaScript framework, or nobody has the hours to restate every fact on forty pages and keep them current.
It works in this order. A page-translation agent rebuilds each page as semantic HTML with structured headings, plainly stated facts, FAQ pairs and Schema.org structured data, and runs a vision pass over the page’s images so that facts which existed only in a chart or a pricing graphic are restated as text. Every page gets a before-and-after CORE-EEAT audit score, the original and the sifted version graded on the same 80 items. You review and approve every draft before it ships, and each claim in the sifted page traces back to the original page, so nothing is invented and nothing is dropped without your sign-off. Once approved, an edge worker serves the sifted page to AI traffic. Human visitors keep seeing your site exactly as it is.
What SiftServe doesn’t do is promise citations. Our working hypothesis is that sifted pages earn about 20% more citations and AI referrals than their unsifted baseline. We state that before the data, and every pilot tests it. The free pilot runs eight weeks on one domain, covers the model costs, delivers a before-and-after audit report for every page, and measures citations and AI referrals against the pages left unsifted. At week eight you see the readability result and the visibility result side by side, and you decide. Readability you can check today, visibility you measure against a baseline, and no score standing in for either: that’s what “ready for AI search” means in practice.
Frequently asked questions
If a page passes all seven checks, will ChatGPT cite it?
Not necessarily, and nobody can promise it will. Passing the checks means an AI agent can fetch the page and read its facts. Whether it cites them depends on the question asked, which other pages answer it, and how the engine ranks sources that week. Readability is the part you control. Treat a clean result as “nothing on this page is stopping us”, then measure citations separately with scheduled test prompts and server logs.
What CORE-EEAT score counts as ready for AI search?
There is no validated threshold, and we don’t publish one. CORE-EEAT scores 80 checks across eight dimensions, each 0–100, weighted by content type. It’s most useful as a pair on the same page: our homepage scores 65 on the original and 76 on the sifted version. Compare a page with itself over time, or with your other pages under the same weights. A score describes what the page carries; it can’t prove the page is being cited.
Does the free AI visibility checker test whether my pages are readable?
No. It runs two domain-level benchmarks from public signals: CITE, a 0–100 domain-authority score with a SHIP, FIX or BLOCK verdict, and TALE, a narrative-consistency read reported as two scores that are never averaged. It estimates whether AI systems are likely to trust and cite the domain and whether the site tells one consistent story. The seven page checks in this guide are a separate, manual inspection, and actual visibility is counted in citations and referrals, not scored.
Do I need a developer to run these checks?
No. Five of the seven are view-source and reading: headings, facts as text, FAQ, structured data (paste the URL into a free validator) and image-locked facts. The crawler fetch and the readable-yield count use a terminal, and a developer can run both in ten minutes if you’d rather not. You will need a developer for one fix: a page that only shows its content after JavaScript runs needs server-side rendering, pre-rendering, or a parallel AI-readable version.
Can AI agents read facts inside images?
Assume not. AI crawlers fetch the HTML document, and no major AI crawler executes JavaScript, let alone interprets your pricing graphic (Vercel × MERJ, December 2024). Some AI systems do run vision models later in their pipelines, and SiftServe’s own translation agent uses a vision pass to recover image-locked facts, but you shouldn’t make your prices depend on a model reading a PNG correctly. State the fact as text near the image.
How often should we re-run the readiness check?
Whenever a tested page changes in a way that matters: a price, a product, an address, a template or plugin change. Quarterly otherwise. Use the same fetch command and the same fact list every time and date each run, so the results form a series rather than a set of unrelated snapshots.
Where to start
Can you tell whether your pages are ready for AI search? Yes, in an afternoon, without a tool. Pick the five to ten pages a buyer’s questions would land on. Write down the facts each one should deliver. Fetch each page as a crawler, run the seven checks, and record what you find with the date.
Then fix in order: access, delivered content, missing facts, headings and FAQ, schema, images. Recheck with the same method. And keep “readable” and “cited” in separate columns of your notes, because the first is something you fixed this week and the second is something you’ll be measuring for the next two months.
If the readable column is red on pages you can’t practically change, that’s the gap the eight-week pilot is built to measure: an AI-readable version of each page, approved by you, with a before-and-after audit score on every one and citations counted against the pages you leave alone.
- AI crawlers
- AI search readiness
- ai-readable
- core-eeat
- structured data