What Moves Your AI Readiness Score, and What Doesn't

You run an AI readiness audit, get a score and a list of findings, and then you have a choice about where to spend the next week. The instinct is to either fix everything at once, or fix the thing that's easiest to explain in a status update. For a lot of teams that second thing is page speed, because "we improved our Core Web Vitals" sounds like progress everyone understands.

The score is not spread evenly across the work, though. A small number of fixes carry most of the points that are actually available to you, and several things that feel like AI-readiness work carry none at all. This post is the map: where the points are, in what order to go after them, and what to stop worrying about.

The score, by the numbers

An AI readiness score is 100 points split across four pillars, and the split is lopsided on purpose:

Understand is nearly half the score, and it isn't one measurement. It breaks down again, roughly like this:

• Is your business identity declared at all? About 40 percent of the Understand pillar, which works out to roughly 18 points of the whole score.
• Do your pages carry markup that identifies what they are? About a quarter of the pillar, roughly 11 points.
• Does your schema graph actually connect? About a fifth of the pillar, roughly 9 points.
• Do you have basic trust pages? The remaining sliver, roughly 7 points.

That first number is the one worth sitting with. Whether an AI system can find a clear statement of who runs your business, in a form it can read, is worth about 18 points on its own. That's more than the entire Discover pillar or the entire Read pillar. It is the single largest lever in the whole score, and most sites are barely touching it.

The fixes that move the score, in order of return

1. Declare your business identity properly. (~18 points.)

One Organization or LocalBusiness entity for your company, declared once, with a real name, a logo, an address, a phone number, a founder, and links to the profiles you actually control (your Google Business Profile, your LinkedIn company page, a Wikidata entry if you have one). Not scattered across the page as text a reader can see, declared as structured data a machine can read as a stated fact.

Most sites fail this in one of two ways. Either the identity is never declared in machine-readable form at all, so an AI reading the site has to infer your company from your page copy and hope. Or it's declared more than once, by the theme and by an SEO plugin, with different details, so a machine finds two versions of your company and can't tell which is real. Building the entity profile properly is a real piece of work, not a checkbox, and it's the highest-return work on this list by a wide margin.

2. Connect the schema you already have. (~9 points.)

This is the graph. Every reference in your structured data should resolve to something that actually exists: your articles name a publisher, and that publisher is the same organization your homepage declares, pinned by the same identifier everywhere. Your services name a provider. Your products name a brand.

A site with valid schema on every page can still score badly here, because validity is a property of one block and connection is a property of the whole site. The Understand pillar guide covers the four ways a graph breaks and how to spot each one. The rule to carry into it: a reference that points at nothing scores worse than a reference that was never made, so when you find one that dangles, deleting it is a real fix.

3. Get identifying markup onto the pages that have none. (~11 points.)

Coverage, but a specific kind. It doesn't count how many schema types you use or whether you're eligible for a Google rich result. It counts whether each page carries markup that says what the page is and who's behind it. A page whose only structured data is a breadcrumb barely counts, because a breadcrumb helps a crawler place the page and says nothing about who runs the business.

So the fix is not "add more schema." It's "make sure every page that matters carries the markup that identifies it," which for most sites means the pages that were published before anyone was thinking about this.

4. Add the trust pages you're missing. (~7 points.)

About, contact, privacy, terms. Present, reachable, with real information on them. There's no clever mechanism here: these pages exist on essentially every legitimate business site and are often missing on sites that are thin or abandoned, so their presence is weak evidence on its own and meaningful in aggregate. A contact page with a real address and phone number is a twenty-minute job that helps this score and every human who wanted to reach you.

5. Stop blocking your own indexing. (~4 points, and a cliff for the pages it hits.)

A stray noindex in a meta tag or an X-Robots-Tag header, usually left over from a staging build, tells crawlers to ignore the page entirely. It's a small number of points across the whole score, but for any page it's actually on, it removes that page from consideration completely. Fast to find, fast to fix, worth doing first precisely because it's cheap.

6. Fix crawler access and rendering. (Up to ~10 points across Discover.)

Declare your sitemap in robots.txt and keep it current. Remove any blanket crawler block left over from an old project. Make sure your real content is in the HTML your server sends rather than painted in afterward by JavaScript, which you can check by loading a key page with scripts disabled and seeing what survives. The Discover pillar guide has the checks. Most of these are config changes that re-audit clean the same day.

7. Clean up the Read-pillar basics. (The rest of the 15.)

One H1 per page, headings that nest in order, a canonical tag that points at the page itself with the right protocol, image alt text, a filled-in meta description. Individually each of these is worth a point or less. Together they're a few points, and they're quick, so they belong in the same-day batch alongside the crawler-access fixes above.

A note on the Answer pillar (25 points): you don't fix Answer directly. It's a test of whether a machine can describe your business using only your site, and when it scores badly the cause is almost always upstream: the crawler couldn't reach the page, or the page was unreadable, or the identity was never declared. Fix the first three pillars and Answer tends to improve on its own. Trying to move it directly, by writing identity facts into a paragraph aimed at passing the test, treats the symptom and leaves the cause.

What this looks like on one report

Take a composite example, built from patterns that recur rather than one real site: a fifteen-person B2B software company, eight years old, a marketing site of about sixty pages on a modern JavaScript framework, rebuilt last year.

The audit comes back at 58, a grade C. The pillar breakdown is where the plan is. Discover is at 74: the sitemap is fine, but a third of the pages need JavaScript to render their real content, so a plain crawl sees a shell. Read is at 82: mostly clean, a handful of pages with no H1 and one section of the blog missing canonical tags. Understand is at 41, and that's the whole story: the company is declared as an Organization by the framework's SEO integration and again as a SoftwareApplication with different details on the homepage, the two never reference each other, the team page connects to nothing, and about half the pages carry only a breadcrumb. Answer is at 44, dragged down by everything above it.

Sorted by return, the plan is short. The same afternoon: fix the missing H1s and the blog canonicals, worth two or three points. The next sprint: the rendering fix, so the pages ship their content in HTML, worth most of the remaining Discover points. Then the real project, three to four weeks: collapse the two company declarations into one entity with a stable identifier, point every page at it, model the team as connected people, and get identifying markup onto the pages that only have a breadcrumb. That last project is worth more than everything else on the list combined, because it's almost entirely Understand, and Understand is where this site's points went.

Nobody had to guess at any of that. The pillar breakdown said the score was an Understand problem wearing a Discover and Read costume, and the point values said which week to spend where.

The work that doesn't move the score at all

Some of this is genuinely worth doing for other reasons. None of it changes your readiness score, and it's worth knowing that before you spend a sprint on it.

Page speed and Core Web Vitals. The readiness score deliberately doesn't look at them. This is the one that surprises people most, so it's worth being clear about the reasoning. Page speed is a real concern with a real tool built for it, and that tool is Lighthouse, not this. More to the point, speed and comprehension are different problems. A fast page that renders its content with JavaScript a crawler doesn't run is still an empty page to that crawler. A slower page that ships its content and its entity graph in plain HTML reads perfectly. Making an unreadable page load faster produces a fast unreadable page. If a "readiness" finding turns out to be a page-speed complaint in disguise, it belongs in a different backlog.

Adding more schema types. Coverage counts pages that carry identifying markup, not the variety of types on a page. Putting ten schema types on your homepage is one covered page, the same as putting one. Breadth of vocabulary isn't the thing being measured; whether each page says what it is and who runs it is.

Chasing Google rich results. Rich results are one narrow Google surface with their own eligibility rules. Whether Google draws a star rating or an FAQ dropdown next to your listing has no direct bearing on whether an AI system can identify your business, and Google's own guidance says its AI features need no special markup and run on the same index as regular Search. FAQPage and HowTo both lost their Google rich results and are still useful for AI. The score tracks comprehension, not badges.

Site-wide broken-link and redirect-chain cleanup. Worth doing for site health. Not an AI-legibility problem, and not scored. (Pages that return a genuine error when a crawler hits them do cost you under Discover, but that's a different thing from auditing every internal link on the site.)

Keyword work and content volume. Publishing more, or targeting more terms, is a traffic strategy. "Is this page well optimized for a keyword" isn't machine-checkable as a readiness signal, so it isn't scored as one.

Publishing an llms.txt file. It's reported by the audit but not scored, because adoption isn't widespread enough yet to treat its absence as a fault. Whether it's worth publishing alongside your schema is a separate question with a real answer, but it won't move the number.

Anything with an invented probability attached. No "citation odds," no "73 percent chance of being mentioned." Those numbers can't be sourced, so they're not part of the score, and a tool showing you one made it up.

Why the ranking looks backwards

The uncomfortable part of that list is that the highest-return fixes are the slow ones and the lowest-return fixes are the fast ones.

Declaring and connecting your entity graph is worth roughly 27 points combined and takes weeks, because it's real modelling work and, for the external-validation half of it, months of waiting for things like a Wikidata entry to settle. Removing a stray noindex is worth about four points and takes ten minutes. Everything about how work usually gets prioritized pushes you toward the ten-minute job.

The way through it is to do both, in the right order. The cheap fixes (the noindex, the canonical, the sitemap line, the missing contact page) get done immediately, precisely because they're cheap and they re-audit clean the same day. Then the real time gets committed to the entity work, because that's where the points are and that's the part that stays fixed. The work that feels productive but isn't (the speed pass, the extra schema types, the rich-result chase) is the work to consciously not spend the week on.

There's also a dependency order underneath the point values. A fix upstream makes downstream problems disappear on their own, so you can't purely cherry-pick by points. Work in pillar order: Discover, then Read, then Understand, and watch Answer follow.

Common Mistakes

Fixing the cheap findings and calling it done. If your score has a 40-point hole and you recover 6 of it by clearing the quick technical items, you've done the easy 15 percent. The report still has the other 34 points in it, mostly in one pillar.

Treating page speed as AI-readiness work. It's worth doing. It is not this. Keep the two backlogs separate so the readiness work doesn't get quietly swapped for the more familiar task.

Adding schema types instead of connecting the ones you have. A pile of valid, unconnected blocks is not an entity graph, and coverage doesn't reward variety. Connect first, then extend.

Writing identity facts into prose to move the Answer score. That's optimizing the test. The Answer pillar is low because the fact was never declared; declare it properly and the score moves for a real reason.

Declaring things you can't back up. A founding date that's a guess, a sameAs link to a profile that isn't yours, an award that wasn't given. A dangling or fabricated claim scores worse than an honest gap, so this actively costs you.

Optimizing the number instead of the site. The score is a proxy. If a change raises the number without making your site more legible to a machine, you've found a gap in the proxy, not an improvement.

AI Schema Gen scores all four pillars, shows you the point value behind every finding, and builds the entity graph that carries most of the score, generated from your actual page content. See where your points are, free at aischemagen.com.