A web page is judged by several audiences at once: search engines reading your tags, screen readers announcing your content, browsers painting your layout, and increasingly security and privacy expectations from users and regulators. A page audit is an automated way to check all of them at once — turning vague worries like “is my page good?” into a concrete list of what passes, what fails, and exactly how to fix it.
This article explains what each category of an audit actually checks and why it matters. You can run every check described here, privately in your browser, with the HTML Page Auditor.
The categories of an audit
Modern audits group checks into categories so a long list of rules stays understandable. The four classic ones come from Google’s Lighthouse; a thorough audit adds two more that Lighthouse largely skips on the client side.
| Category | Answers the question |
|---|---|
| SEO | Can search engines understand and index this page? |
| Accessibility | Can people using assistive technology use it? |
| Best Practices | Is the HTML well-formed and standards-compliant? |
| Performance | Will it load fast and stay stable? |
| Security | Is it hardened against common attacks? |
| Privacy | How much visitor data leaks to third parties? |
SEO: what search engines read
Search engines never see your page the way a visitor does — they read the markup. SEO checks confirm the signals they rely on are present and well-formed: a unique <title> that fits the ~600 pixel result width, a <meta name="description"> short enough not to be truncated (around 150–160 characters), a single <h1>, a canonical link to prevent duplicate-content confusion, a valid lang, and that the page is not accidentally set to noindex. Structured data (JSON-LD) and Open Graph tags are checked too, because they control rich results and social-share previews. Thin pages are flagged on word count — both search engines and ad networks reject pages with little real content.
Accessibility: what assistive tech needs
Accessibility (often shortened to “a11y”) checks that the page works for people who cannot see it, cannot use a mouse, or rely on a screen reader. The most common failures are concrete and easy to fix: images without an alt attribute (the screen reader has nothing to announce), form fields without a <label>, buttons and links with no accessible name (an icon with no text), skipped heading levels (jumping from h2 to h4 breaks the document outline), and focusable elements hidden with aria-hidden, which traps keyboard focus on something invisible. The audit also verifies that aria-labelledby and similar attributes actually point at elements that exist — a dangling reference is worse than none.
Performance & Core Web Vitals
Performance splits into two kinds of checks. Static ones read the markup for known slow patterns: render-blocking scripts in the <head>, an oversized or very deep DOM, images in legacy formats instead of WebP/AVIF, missing loading="lazy", and heavy inline data. Live ones can only be measured by actually loading the page — these are the Core Web Vitals:
- LCP (Largest Contentful Paint) — when the biggest element (usually the hero image or headline) finishes painting. Under 2.5 seconds is good.
- CLS (Cumulative Layout Shift) — how much content jumps around during load. Under 0.1 is good.
- Blocking time — how long long-running scripts freeze the main thread, delaying interaction.
CLS is the one people feel as a page that “glitches” on reload. The usual causes are images without a reserved width/height, a web font that re-wraps text when it swaps in, or an ad/embed that loads late and shoves everything down. The cure is always the same idea: reserve the space before the content arrives, so nothing has to move.
Security: hardening the page
Security checks look for markup-level weaknesses an attacker could exploit. Key ones include Subresource Integrity (an integrity hash on third-party scripts so a hacked CDN cannot inject code), sandboxed iframes (so an embedded page cannot reach into yours), forms that submit over plain http:// (credentials in clear text), mixed content (insecure resources on a secure page, which browsers block), and a CSP-friendliness signal that counts inline scripts — each inline block needs a nonce or hash before you can ship a strict Content-Security-Policy. The audit also flags risky JavaScript sinks like document.write and eval(), and the rare but dangerous <base> tag, which silently rewrites every relative URL on the page.
Privacy: who else is watching
Every resource a page loads from another domain can see the visitor. Privacy checks count those third-party origins and name the worst offenders: known analytics and trackers (Google Analytics, Facebook Pixel, Hotjar and friends), third-party web fonts like Google Fonts that leak IP and user-agent on every page view, and social or ad iframes that set cookies. The audit also checks for a referrer-policy, which controls how much of your URL is handed to those third parties. The privacy-respecting answer is usually to self-host — fonts, scripts, and analytics — so visitor data never leaves your server. (Every tool on this site is built that way.)
How the score is calculated
Not every check is equally important, so each one carries a weight — a missing <title> counts far more than a missing theme-color. A category’s score is the percentage of its weighted checks that pass, where a warning counts as a half-pass and a failure as zero. Checks that do not apply (image rules on a page with no images) are excluded entirely so they never drag the number down.
The overall score is the average of the categories, not a raw total — so a page that aces SEO and speed but ships three trackers will see an honest overall, not a perfect one. The point of a score is not to hit 100 for its own sake; it is to surface the handful of real problems worth fixing.
Static, fetched, or live
There are three ways to point an auditor at a page. You can paste HTML directly — useful for a template or a snippet before it ships. You can fetch a same-origin URL, which pulls the live markup and runs the static checks against it. Or you can load and measure, which opens the page in a sandboxed frame and records the real Core Web Vitals — CLS, LCP, page weight, request count, blocking time, and the elements that actually shifted. Cross-origin pages cannot be fetched or measured from the browser (the same-origin policy blocks it), which is exactly the protection that also keeps your data private.
In practice
Treat an audit as a checklist, not a grade. Run it, fix the failures first (they are weighted heaviest), then the warnings, and re-run to confirm. The most valuable habit is the loop: measure, fix one thing, measure again — it turns guesswork into certainty, especially for runtime issues like layout shift that you cannot eyeball reliably. Start with the HTML Page Auditor, generate any missing tags with the Meta Tag Generator and Schema Generator, and see how the pieces fit together in Developer Data Essentials.
Frequently asked questions
What is a web page audit?
A page audit is an automated review of a page’s HTML and runtime behaviour against best-practice rules in several areas — typically SEO, accessibility, performance, and best practices, and increasingly security and privacy. Each rule is a pass/fail (or warning) check; the results show what is wrong, why it matters, and how to fix it. The goal is to catch problems search engines, screen-reader users, and browsers care about before real visitors do.
What is the difference between static and live (runtime) analysis?
Static analysis reads the HTML as text — it can see your tags, attributes, headings and links without ever running the page, so it is fast and works on a snippet you paste in. Live analysis actually loads the page in the browser and measures what happens: how much the layout shifts, when the largest content paints, how many bytes download, and how long scripts block the main thread. Some problems (a missing alt attribute) are only visible statically; others (layout shift, load time) can only be measured live.
What is CLS and why does my page “glitch” on load?
CLS (Cumulative Layout Shift) measures how much visible content jumps around as the page loads. A late-loading image without reserved space, a web font that re-wraps text, or an ad slot that pushes content down all cause shifts. Google considers a CLS under 0.1 “good.” The fix is to reserve space ahead of time — width/height on images, metric-matched fallback fonts, and fixed heights for dynamic widgets — so nothing moves once it appears.
How is the overall score calculated?
Each category (SEO, Accessibility, Best Practices, Performance, Security, Privacy) gets its own score: every applicable check is weighted by importance (a missing title matters more than a missing theme-color), and the category score is the percentage of weighted checks that pass. The overall score is the average of the category scores — not a raw total — so every category counts equally. Checks marked “not applicable” (for example image rules on a page with no images) are excluded so they never penalise you.
What is Subresource Integrity (SRI)?
SRI is an integrity="sha384-…" attribute on a script or stylesheet that pins the exact content you expect. The browser refuses to run the file if its hash does not match — so if a third-party CDN is ever hacked and serves altered code, your page is protected. It matters most for scripts loaded from domains you do not control. For files served from your own origin it is optional.
Why does an audit flag third-party fonts and trackers?
Every resource loaded from another domain — a Google Font, an analytics script, a social embed — sends the visitor’s IP address, user-agent, and the page they are on to that third party, often setting cookies. From a privacy standpoint each one is a leak. Self-hosting fonts and avoiding trackers keeps visitor data on your own server and usually loads faster too.
Does the auditor upload my page or data?
No. The whole audit runs in your browser using the built-in DOMParser and Performance APIs. Pasted HTML never leaves the page, and the live measurement loads same-origin URLs in a sandboxed frame on your own machine. Nothing is sent to a server.