Why does my audit score disagree with Lighthouse?
Two tools measuring genuinely different things — and why expecting them to agree is the actual mistake.
Lighthouse measures how a page renders and performs in a real browser. A server-side audit measures how a site is configured — headers, transport, DNS, crawler access. The overlap is small, so agreement would be surprising. Use both, for different questions.
What each one actually measures
| Lighthouse | Server-side audit | |
|---|---|---|
| Runs in | A headless browser | An HTTP client and a DNS resolver |
| Sees | The rendered page | The delivered response |
| Performance | LCP, CLS, TBT — rendering metrics | Response time, caching, compression |
| Security | A small number of in-page checks | Every response header, TLS, disclosure |
| DNS and email | Not covered | MX, SPF, DMARC, CAA, NS |
| Crawler access | Basic robots checks | Per-crawler resolution against the rules |
| Accessibility | Computed contrast, rendered ARIA | Markup-level: alt, labels, headings, landmarks |
| Content quality | Not covered | Structure, readability, filler signals |
Look at the middle rows. One tool covers areas the other does not touch at all. Two numbers summarising different sets of checks are not comparable, and neither is wrong.
Where they genuinely overlap
The overlap is essentially accessibility markup and a handful of SEO basics — titles, descriptions, alt attributes, heading structure. Even here they diverge, because Lighthouse evaluates the rendered DOM and a server-side audit evaluates delivered HTML.
That divergence is informative rather than annoying. If Lighthouse reports good heading structure and a server-side audit reports none, your headings are being created by JavaScript — which means Lighthouse sees them, a person sees them, and most AI crawlers do not.
Which to trust for which question
| Question | Use |
|---|---|
| Is my page fast for real users? | Lighthouse, and field data from real visitors |
| Are my security headers right? | Server-side audit |
| Can AI assistants read my site? | Server-side audit — it sees what they see |
| Is my layout shifting on load? | Lighthouse |
| Can someone forge email from my domain? | Server-side audit |
| Is my contrast accessible? | Lighthouse — contrast requires computed styles |
| Is my markup accessible? | Either; they catch different subsets |
| Is my certificate about to expire? | Server-side audit |
Two more reasons for a mismatch
- Lighthouse results vary between runs. It measures timing in a real browser under real conditions, so network variance, CPU throttling and cold caches all move the number. Configuration checks do not vary this way. If you want a stable Lighthouse figure, run it several times and take the median.
- You may be measuring different URLs. Lighthouse run on a page after redirects, and an audit run against the URL you typed, can be looking at different hosts entirely — apex versus www being the usual pair.
A reasonable combined workflow
- Configuration, transport, DNS and crawler access: server-side audit, run on every deploy.
- Rendering performance and computed accessibility: Lighthouse, run on your key page templates.
- Real-world speed: field data from actual visitors, which neither tool provides.
- When they disagree on something both claim to measure, check whether the difference is rendered versus delivered. That gap is usually the real finding.
What our audit reports about this
Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.
- Everything observable without rendering — headers, TLS, DNS, robots resolution, delivered markup — measured directly.
- How much of your content is present in the delivered HTML versus added by JavaScript, which is what explains most disagreements.
- An explicit statement that PageSpeed, Lighthouse and field Core Web Vitals are not covered, rather than an approximation of them.
- Deterministic results, so repeated runs on an unchanged site do not vary the way timing-based measurement does.
For agents and scripts, the same measurement is at
/api/v1/summary?url=yoursite.com —
see the API documentation.
Related questions
Which score should I care about more?
Whichever matches the question you have. For "is it fast and does it render well", Lighthouse. For "is it configured correctly and can machines read it", a server-side audit. Neither generalises to the other.
Why does Lighthouse give me a different score every run?
Because it measures timing in a real browser, and network conditions, CPU contention and cache state all vary. Run it several times and take the median. Configuration checks do not have this property.
Can one tool do both?
Only by running a full browser, which is a different infrastructure commitment and a different set of trade-offs. Rather than partially render and imply otherwise, rendering-dependent checks here are declared out of scope with the reason.
My Lighthouse SEO score is 100 but AI cannot find me. Why?
Almost certainly rendering. Lighthouse evaluates the rendered DOM, so client-built markup scores perfectly. Most AI crawlers never render, so they see the empty container that was delivered.
Read next
What can't be measured without a browser?
The honest boundary of server-side analysis — what needs JavaScript execution, and why saying so beats guessing.
ReadWhy do two SEO tools give my site different scores?
Different checks, different weights, different definitions of failure — and why comparing scores across tools is meaningless.
ReadDoes JavaScript hurt AI crawlers?
Yes, more than it hurts search engines. If your content only exists after JavaScript runs, most AI crawlers see an empty page.
ReadDoes page speed affect SEO?
Yes, modestly and as a tie-breaker. It affects whether people stay far more than it affects where you rank.
Read