What an SEO audit actually checks, and what a useful report looks like

An SEO audit answers one question in four parts: can a search engine or an assistant reach your pages, read them, understand what they are about, and quote them? Everything a real audit checks sits under one of those four, and the order matters, because a failure early in that chain makes everything after it irrelevant.

The four gates, in the order they fail

Reach. Can the crawler fetch the page at all? robots.txt rules, HTTP status, redirect chains, noindex, canonical tags pointing somewhere else, a sitemap that does not list the page, a firewall answering 403 to anything that is not a browser. Nothing downstream matters until this passes.

Read. Is the content in the HTML the crawler received? This is the gate that changed most in the last three years. A page that renders beautifully in a browser and returns an empty shell to a fetcher without JavaScript is invisible to a large part of the retrieval ecosystem, and the failure is silent.

Understand. Titles, meta descriptions, heading structure, internal links, structured data, image alt text, content depth, and whether the page has a date and an author attached in the markup rather than only on screen.

Quote. New, and specific to AI search. Can a clean passage be lifted out of this page that answers one question and makes sense on its own? Assistants cite passages, not pages.

The full list, grouped by what breaks

Our own engine runs 36 checks, and every audit tool worth using covers roughly the same ground under different names.

Group	What is checked	What a failure means
Crawl and index	robots.txt, AI crawler access, indexability, canonical, sitemap, HTTP status, redirects	The page is unreachable or ineligible. Highest severity, cheapest fix.
Rendering	Content visible without JavaScript, render gap markers, blocked resources	A fetcher sees an empty page where a browser sees the article.
On page	Title, meta description, heading order, internal links, image alt, content depth, keyword focus	The page is readable but its subject and structure are ambiguous.
Structured data	Schema presence and validity, Organization, Article, FAQ, breadcrumbs	Machines have to infer what a marked up page could have stated.
Trust signals	Author attribution in the markup, publish and modified dates, HTTPS, security headers	The page reads as unattributed and undated, which is exactly how it gets treated.
Speed and stability	Core Web Vitals, response time, page weight, image formats	Users leave, and the ranking effect is real but smaller than most reports imply.
AI readiness	Extractable passages, answerability, chunk quality, llms.txt	The page can be read and cannot easily be quoted.

What audits actually find, measured rather than guessed

We publish the measurements instead of describing them, so the failure rates below are from our own crawls rather than from a vendor blog.

Access failures are more common than people expect. In our study of 1,048 of the most visited websites, 28.3% of those with a robots.txt block at least one major AI crawler, and 145 of them block a crawler whose job is fetching pages to answer live questions. Almost none of that looks deliberate when you read the files: it is old rules and pasted lists.

The render gap is real and it is not rare. In the same crawl, 21.4% of homepages carried fewer than 200 words of text with no JavaScript executed, and among pages showing single page application markers in the HTML, 27.8% were under 200 words.

Trust signals fail quietly. In our audit of 98 agencies selling AI visibility, 28 of the 88 sites we could fetch published pages carrying no date at all, and 22 named no author in the markup. Those are the two signals that category sells, failing on its own sites, which is a good illustration of why an audit is worth running against yourself rather than assumed.

What a useful report looks like

Most audit reports fail in the same way: they are complete and unusable. Four hundred rows, sorted by category, every row weighted equally, delivered as a PDF. The hard part of an audit is deciding what matters, and a report like that hands that part back to you with more work attached.

A useful finding has four things:

1. The URL. Not the site. The page.
2. The evidence. The actual title tag, the status code, the word count of the rendered response. Something you can verify without trusting the tool.
3. The consequence. What this costs, in terms of a page not being indexed, not being quotable, or loading slowly for a real user. If a finding has no consequence you can state, it does not belong in the report.
4. The fix, and who does it. A developer ticket, an editor task or a one line change in a template, named as such.

And the list should be ordered by expected impact, not by section. In practice that ordering is nearly always the same: access problems first, because they invalidate everything else. Rendering second. Then the small set of on page and trust signals that affect many pages at once through a template. Everything else after that, and most of it never gets done, which is fine, because most of it was never going to change anything.

An example, on a single page

Here is a real one, lightly trimmed: the report our own engine returned for the first article this site published, before anybody had run the audit on it. It is a fair example precisely because it is unflattering.

URL /blog/example-article/ Score 92 of 100, grade A

1. Title is 83 characters (evidence: the tag itself). Search results truncate near 60, so the distinguishing words are cut. Fix: rewrite to under 60, front loading the phrase people search. Owner: editor.
2. Meta description is 208 characters. Same truncation problem, one line change. Owner: editor.
3. No author in the markup. There is a visible byline, but no meta[name=author] and no Person schema, so a machine reads the page as unattributed. Fix: emit both from the template. Owner: developer, once, for every article.
4. Freshness warning. article:published_time is present, article:modified_time is not, so an updated page still reads as its original date. Owner: developer, template level.

Four findings, and fixing them took the page from 92 to 97. Two of the four were template properties, so the same fix applied to every article published afterwards, which is the highest return work in most audits.

The score is worth reading twice: 92 out of 100 with four real findings. A high score does not mean there is nothing to do, and a low score is usually one or two systemic problems repeated across every page rather than a site that is broadly bad.

One finding type deliberately not in that list: Core Web Vitals. Our own pages still carry a mobile warning on it, and the measured value swings enough between runs on an identical page that acting on a single reading is guesswork. Measure it three times before you spend a sprint on it, and treat any audit that reports one simulated run as a fact with suspicion.

The recommendations most audits should make

Across every site we have run this engine over, the same handful of recommendations come up, in roughly this order.

Unblock what you did not mean to block. Read your robots.txt line by line and check every user agent rule against what that agent actually does. The most common finding in our crawler study was a site blocking a crawler it had no reason to block, usually inherited from a list somebody pasted in.

Make the content exist without JavaScript. Server render, static generate or prerender the content that matters. This is a development project rather than a checkbox, and it is the single highest value one on this list for any site built as an application.

Fix the template, not the page. Titles, dates, author markup, heading order and schema are template properties. One change touches every page, and a report listing them per URL is padding a list you could have kept to five rows.

Answer questions in liftable passages. Sub headings phrased as the question, answered immediately underneath in about forty to sixty words that make sense in isolation. This is the cheapest editorial change available and it is what makes a page quotable by an assistant.

Then stop. The tail of an audit report has a real cost and almost no return. Fixing 200 low severity findings on a site with a render gap is a way of being busy.

How to run one on your own site

The mechanical half is free and takes a minute. Our free audit runs all 36 checks against any URL and returns the findings in the shape above, with the evidence attached to each one. The individual checks are also published as separate tools if you want to test one thing: robots.txt, indexability, render gap, title tags, structured data and the rest are on the tools page.

The judgement half is yours, and it is one question asked of every finding: if this were fixed tomorrow, what would be different? Findings that survive that question are the audit. The rest is inventory.