Can AI Actually Make Sense of Your Page? The Read Pillar Explained

Getting an AI crawler to your page is only half the problem. The other half, easy to overlook precisely because it sounds less dramatic than "invisible to crawlers," is whether the page makes sense once the crawler is standing in front of it. Read is the second of the four AI Readiness pillars: Discover asks whether AI can reach a page at all, Read asks whether it can actually make sense of the page once it gets there.

It's worth 15 of the 100 total points in an AI Readiness score, the same weight as Discover, and the two pillars fail in similar ways: quietly, invisibly to a human visitor, and usually by accident rather than by design. Nobody sets out to write a page with three H1 tags or a canonical link pointing at the wrong URL. It happens during a redesign, a CMS migration, or a page builder's default settings, and then just sits there until something checks for it directly.

What Read Actually Checks

Read looks at the structure and the behind-the-scenes information on a page, the parts that tell a machine what it's looking at rather than just what it says. Specifically:

Heading presence and hierarchy. Is there exactly one H1, does it accurately describe the page, and do the headings underneath it nest in a sane order, H2 then H3 then H4, rather than jumping around or skipping levels?

HTML that says what it is, not just how it looks. Does the page use tags that carry real meaning, an actual article tag, a navigation tag, a table, a real list for a list, or is everything a plain, unlabeled box that looks identical in a browser but tells AI nothing about what kind of content it's looking at?

Canonical tag accuracy. Does the page declare which URL is the "real" one, and does it point at the right place, itself, in the normal case, rather than a different page, an old staging domain, or the wrong protocol?

Complete, deliberate metadata. Is there a meta description, a language tag, Open Graph tags (the fields that control how a link looks when it's shared)? These aren't decorative, they're some of the clearest, most direct signals a page can offer about what it's about and how it should be presented.

The robots tag and X-Robots-Tag header. Is the page accidentally telling crawlers not to show it in results, a setting that's invisible in a browser and easy to leave in place after a staging environment goes live?

Image alt text. Do meaningful images carry a text description, or is that visual information simply missing from the version of the page a machine can read?

Freshness signals. Does the page show when it was last updated, an accurate published or updated date, something that tells a system whether this content is current or years stale?

How much of the page is actual content. Is the real substance of the page a reasonable share of what's there, or is it buried under navigation, sidebar widgets, and repeated footer text relative to the real writing?

None of these individually are exotic. Most of them are the same fundamentals technical SEO has cared about for over a decade. What's different is the tolerance for messiness. A human skimming a confusing page fills in gaps automatically, guesses what a badly-nested heading probably meant, assumes a missing canonical tag isn't a big deal. A system reading many pages in a structured, step-by-step way doesn't have that same slack, it either finds a clean signal or it doesn't.

The Heading Hierarchy Problem: Structure Carries Meaning, It's Not Just Decoration

It's tempting to treat heading levels as a font-size choice, H2 is medium-big, H3 is a bit smaller, pick whichever looks right on the page. That's exactly backwards from how AI reads them.

A heading hierarchy is the outline of the page. An H1 states what the whole page is about. Each H2 underneath it is a major section of that topic. Each H3 underneath an H2 is a sub-point of that specific section, not of the page overall. When that nesting is followed correctly, AI can reconstruct an accurate table of contents without reading a single sentence of body text, just from the headings alone.

When a page skips straight from an H2 to an H4, or has three separate H1s because a page builder auto-generated one per section, that outline breaks. AI either gets the structure wrong, treating an important section as a minor aside, or gives up trying to figure it out at all and just treats the page as one big undifferentiated block of text.

This matters more for how AI reads a page than it ever did for a human reader, because a lot of what an AI system does with a page, summarizing it, pulling out a specific fact, deciding which section actually answers a given question, depends on that structural map being accurate.

A single, correct H1 followed by a clean, logically nested set of H2s and H3s is one of the cheapest, highest-value fixes available in the entire Read pillar, and one of the easiest to check yourself: look at any page and just list its headings in order. If that list alone doesn't read as a sensible outline, AI is going to have the same trouble making sense of it.

Canonical Tags: A Hint That Gets Treated Like a Verdict

A canonical tag exists to solve one specific problem: when the same or near-identical content is reachable at more than one web address, which version should count as the real one. Google's own documentation is explicit that a declared canonical is "a hint, not a rule," it weighs the signal alongside others (whether the page is served securely, redirects, whether it's listed in the sitemap) and can override it if the declared canonical doesn't match what its own crawl actually finds. But in practice, a wrong or missing canonical is still one of the more damaging Read-pillar mistakes, because of what it implies: the content worth paying attention to lives somewhere else.

A few specific ways this goes wrong, all more common than they should be: a canonical left pointing at a staging or "www" version of the site after a migration; a canonical on a filtered or paginated version of a page pointing back at the plain, unfiltered version, which is correct, versus one that's missing entirely, which just leaves things ambiguous; and, less obviously, a canonical that technically points at itself but uses the wrong protocol, the old insecure "http" instead of "https," which used to be a routine oversight and still shows up on older sites that switched over at some point without updating every reference.

The practical fix is almost always the same: for a page that's genuinely the one true version of its own content, the canonical tag should point at itself, exactly, protocol included. Anything else needs a specific, deliberate reason.

The Silent noindex: A Page Can Be Perfect and Still Invisible

Here's a mistake that's easy to miss because it doesn't look like a mistake at all, the page looks completely normal, loads fine, reads fine. But a noindex setting, whether placed in the page's own code or sent as a server header, tells search engines and AI systems specifically: don't show this in results. Google's own documentation is precise about what this does and doesn't do: it doesn't stop the page from being crawled, the content can still be fetched and read, but it explicitly removes the page from search results, from Google Discover, and from AI Overviews.

The most common way this happens by accident: a staging or test version of a site is set to hide from results globally, a sensible default while the site isn't ready for the public, and that setting survives the move to the live site because nobody remembered to turn it back off. A second common cause is a plugin or theme default that hides a specific type of page (search-result pages, certain archive templates) more broadly than intended, catching real content pages that happen to share that template.

The fix here isn't complicated, it's finding it that's the hard part, because nothing about the page's normal appearance gives any sign something's wrong. Checking the actual page code and server response on your important pages for a hidden noindex setting, especially after any migration or redesign, is one of the highest-value five-minute checks in the entire Read pillar.

Common Mistakes

Treating heading levels as a visual choice instead of a structural one. If a heading is picked because of how big it looks rather than what level of the outline it represents, the visual result and the real structure of the page can end up saying two different things.

Assuming a canonical tag "probably" points where it should. After any site migration, redesign, or domain change, this is one of the first things worth checking directly rather than assuming it carried over correctly.

Never checking for an accidental "hide from results" setting after moving from staging to live. This is invisible from every normal browsing check and only shows up if you look at the actual page code or server response.

Filling in a meta description with boilerplate text, or letting the site's software auto-generate one from the first sentence of the page. A meta description is one of the more direct summaries a page can offer, an auto-generated one is often a poor substitute for one written on purpose.

Ignoring image alt text on meaningful, content-bearing images. A purely decorative image not having alt text is a minor gap; a product photo, a diagram, or an infographic carrying real information without any text version of it is a real content gap, not just an accessibility one.

How to Check and Fix Read Issues on Your Own Site

• List out the headings on your most important pages, in order, and check whether that list alone reads as a sensible outline: one H1, logically nested H2s and H3s underneath it, no skipped levels.
• Check your canonical tags directly, especially on any page touched by a recent migration, redesign, or domain change, and confirm each one points at itself, correct protocol included, unless there's a specific reason it shouldn't.
• Search your page code and server response for a hidden noindex setting, particularly on pages that were ever part of a staging environment, to catch a setting that survived into production by accident.
• Confirm a meta description and Open Graph tags actually exist and are written on purpose, not auto-generated boilerplate, on every page you'd want represented accurately if it were shared or summarized somewhere.
• Check that meaningful images carry real alt text, not a filename or a generic placeholder.
• Re-check after any redesign, migration, or software update, the same events that tend to introduce Discover-pillar problems are just as likely to quietly break heading structure, canonical tags, or metadata.

This is exactly the layer a proper AI readiness audit checks second, right after confirming a crawler can reach the page at all. AI Schema Gen's audit tool checks heading structure, canonical accuracy, and hidden "don't show this" settings automatically across a whole site, rather than requiring a page-by-page manual check.