PageSpeed shows a quarter of the picture

Checking a site usually looks like this: paste the address into PageSpeed Insights, look at four circles, feel good about green or bad about red. It is a useful tool and it is free. The problem is that people read it as a diagnosis when it is a thermometer.

What PageSpeed actually measures

Load speed - well and honestly. Three Core Web Vitals with thresholds Google publishes openly: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Here it can be trusted completely.

After that it gets murkier. The Accessibility circle is a set of automated checks, and Lighthouse's own documentation says automation catches the smaller share of accessibility problems. The SEO circle checks a dozen technical details: is there a title, is the page closed to indexing. That is not an SEO audit, it is a half-page checklist.

A site can score 96 for accessibility and still have seven form fields a screen reader cannot announce.

Markup: what stays invisible until it breaks

HTML has nesting rules. A <div> cannot live inside a <button>: the specification allows only phrasing content there. The browser will not reject such a page - it repairs it silently, each engine in its own way. This is where the bugs that “only reproduce on the client's iPhone” come from: the code is the same, but the repaired document tree is not.

None of this affects the PageSpeed score. It does not look for it - that is not its job. These are found either by a validator or by a person reading the HTML.

• A block element inside a button or a heading - the button may not respond to the first tap
• Duplicate ids - usually one SVG pasted several times; scripts and labels attach to the wrong element
• An <li> outside a list - a screen reader will not announce “list, five items”
• A form inside a form - the browser discards the inner one and its fields silently never submit

Accessibility is not only contrast

Automation measures text contrast well, because it is arithmetic. The rest is harder. A form field without a <label> looks fine and passes half the checks, but a screen reader cannot say what to type in it, and browser autofill does not work - people type it by hand and abandon the form more often.

The same goes for icon buttons. A burger menu, a magnifier, a close cross - without an aria-label each is just “button” to a screen reader. A site where every control is called “button” cannot be used, and no circle will warn you.

Whether ChatGPT can see you

This is a new item that was not on anyone's list two years ago, which is exactly why almost nobody has done it. People increasingly ask an assistant rather than Google, and the assistant answers with links to its sources. Getting into those sources is possible, and it is technical work rather than magic.

The most common finding is AI crawlers blocked in robots.txt by accident. Somebody once added a rule against scrapers, it landed under a blanket User-agent: *, and along with the junk it cut off GPTBot, PerplexityBot and Google-Extended. The site still indexes perfectly in ordinary Googlebot, so there is no way to notice until you open the file.

The second is content that is not in the HTML. If the page text is drawn in by JavaScript in the browser, Google mostly copes, while most AI crawlers do not run scripts at all. They see an empty shell. The site exists for people and does not exist for the machine deciding whom to quote.

The third is missing machine-readable company data. Schema.org markup is a passport: who you are, where, what you do, how to reach you. Without it an assistant paraphrases the page and gets details wrong.

The order to work through it

Order matters more than completeness. First what breaks the site, then what costs money, then cosmetics.

• The page closed to indexing, or crawlers blocked - five minutes to fix, costs you all of your traffic
• Forms that do not submit and buttons that do not fire - those are lost leads directly
• Unlabelled fields and unnamed buttons - half the accessibility work in an hour
• Speed: images and fonts first, then scripts, and only then caching
• Schema.org and access for AI crawlers - while competitors have not done it
• Markup validity - cheapest to do alongside the next redesign

And one general rule: do not trust advice you cannot verify. Plenty of tools still recommend adding a title attribute to links and images - Google does not use it, screen reader support is unreliable, and the W3C explicitly advises against relying on it. Advice that changes nothing is worse than no advice: it is paid for in time.

You can check your own site against every one of these points here, free and without signing up - the audit form is on the home page. A run takes about a minute and shows which of this list applies to you.