How to audit a website
and what each number proves.

A website audit is a structured reading of a page against named criteria, each of which states its source. That definition matters more than it looks. If a report cannot tell you where a threshold came from, you cannot tell whether the threshold applies to your site, and you end up arguing about the score instead of the page.

What does a website audit actually measure?

Morphos reads seven dimensions from one HTTP response. The weights are fixed and sum to 100, so the same number means the same thing across site types:

Weights are editorial. They say a marketing page lives or dies on how it looks and reads more than on its headers, which is a judgement, not a law. The reference band each score is compared against changes with the site type, because a portfolio and a store should not be held to the same numbers.

Why is a faster page not automatically a better page?

Speed decides whether a page gets read at all. It does not decide whether the page is worth reading. Nielsen Norman Group puts the three limits at 0.1 seconds for a response that feels instant, 1.0 second for an uninterrupted flow of thought, and 10 seconds for attention to stay on the task at all.

Those are human limits, not server benchmarks. A page can answer in 300 ms and still lose the visitor, because the headline runs to 24 words, the first action sits below three screens of copy, or the only way to enquire is a nine-field form. That is why delivery is 14 of 100 here and not 40: a fast page with nothing to say is still a page with nothing to say.

The honest split: time to first byte and document weight are measured. Whether a first screen holds someone is modelled from the shape of that screen — headline length, how early an action appears, how much copy precedes it — and is labelled as a model everywhere it appears.

How do you audit visual design without a screenshot?

You read what the stylesheet declares instead of what the browser paints. A design system leaves fingerprints in text: how many distinct colours are written, how many font sizes and weights, how many spacing values, how many border radii, whether grid, flex and clamp() appear at all, how many media queries exist, and whether :focus-visible and prefers-reduced-motion are written down.

• A page with 31 colour literals and 19 font sizes has no scale; it has accumulation.
• A page with 4 radii and 0 focus rules has decoration where it needed state.
• A page with 0 media queries is not responsive, whatever the viewport tag says.

What this cannot do is tell you whether the result is beautiful. Craft is judged by people, and any tool that scores taste is scoring its own taste. The practical use of the CSS read is narrower and more useful: it tells you whether a system exists before anyone argues about which system.

What can one HTTP request tell you about security?

A great deal about configuration, and nothing about exploitability. From the response alone you can read whether Strict-Transport-Security exists and how long its max-age runs, whether a Content-Security-Policy is present and how permissive its directives are, whether framing is restricted, whether cross-origin isolation headers are set, whether the server banner leaks a version, whether cookies carry Secure, HttpOnly and SameSite, and whether cross-origin scripts carry Subresource Integrity hashes.

The distinction is worth stating plainly: a missing CSP is a fact about the response. “This site is hackable” is not, and no single-request tool is entitled to say it. Morphos fuzzes nothing, executes nothing, and sends no request beyond the page and its same-origin stylesheets.

How do you check readiness for AI answer engines?

Generative engine optimisation (GEO) is the practice of writing a page so an answer engine can lift a sentence and cite it. Four properties make a sentence liftable:

1. A heading phrased as the question a buyer actually types, so there is an answer slot to fill.
2. A definition-shaped sentence — “X is a Y” — that stands alone without its paragraph.
3. A figure with a unit attached: 14 days, 4.5:1, 90 checks. A bare number is not quotable.
4. Structured data, so the machine reading the page does not have to infer what it is about.

The limit is real and should be said out loud: a page can hold all four and never be cited, and a page with none of them can still be cited. Quotability is a property of the page as delivered. It is not a measurement of visibility, and this guide is not evidence that any engine will choose it.

What happens in the first ten seconds?

Three things decide whether a visitor stays past the first screen, and all three are visible in markup: whether the headline resolves in one read, whether an action appears before the visitor has to scroll, and whether the copy before that action is short enough to scan. A 6-word headline with an action at 6% of the document is a different proposition from a 24-word headline with the first link below the fold.

Real hold rate depends on traffic source and intent, neither of which a single request can see. So the output is a band, not a percentage, and it is labelled modelled · not measured on every line.

Where do most audits go wrong?

• Unlabelled estimates presented as measurements. If a report says “you lose 43% of visitors”, ask which instrument measured it. Without analytics, the honest output is a range and the word model.
• Thresholds with no source. “Line length should be 60 characters” is a house style until you name the source; Butterick’s range is 45–90 characters, which is a far wider target.
• Ninety findings and no order. A list sorted by category is an inventory. A list sorted by impact and then by cost is a plan.
• Scoring what cannot be seen. A cross-origin stylesheet, a bundled framework and a server-side render are invisible to one request. Reporting them as absent is a false negative dressed as a finding.
• Ignoring the cheap fix. Adding rel="noopener", labelling an input and sending Referrer-Policy cost minutes and close real findings. They should not sit at rank 40 behind a redesign.

How do you turn findings into a fix list?

Rank by impact, then by how cheap the change is, and keep the top five to seven. That is the whole method, and it is the part most reports skip. In practice it produces a list that looks like this:

1. Fix the thing that is broken, not the thing that is ugly. A page returning 500 or posting a form to plain HTTP outranks any spacing decision.
2. Fix what costs a visitor an action. Unlabelled inputs, dead links and a nine-field form are direct losses.
3. Fix what stops the page being read. A blocking script in the head, a 512 KB HTML document, or a title that says “Home”.
4. Then the craft work: the type scale, the spacing scale, the focus states.

The free page check applies exactly this order to any public URL, prints the reason next to each item, and lets you download the result as Markdown before deciding anything. If the numbers come back clean, that is also a useful answer: it usually means the problem is the offer or the proof, not the page.

What can this method not tell you?

Four things, and they are the four that decide most outcomes:

• Rendering. Nothing is executed, so Core Web Vitals, layout shift and mobile layout are outside the read.
• Behaviour. No analytics, no scroll depth, no form completion, no drop-off point. A funnel problem is diagnosed from the shape of the page, not from a session recording.
• What is behind a login, behind a cross-origin stylesheet, or inside a bundle that never arrived.
• Causation. Closing a gap does not guarantee traffic. The projection is a model over the gaps below the reference band, and it is labelled as one.

Where those four matter more than the page itself, the next step is a human diagnostic rather than a deeper automated read — that route is here.

Where every threshold comes from

Thirteen families of source, each used for one kind of claim and never mixed:

• WCAG 2.2 (W3C Recommendation) — normative contrast, focus, reflow and labelling criteria. The numbers are quoted, not approximated.
• WHATWG HTML and CSS specifications — element semantics, viewport, doctype, image dimensions.
• RFC 9110 and RFC 6265 — HTTP semantics and cookie attributes as observed on the wire.
• OWASP Secure Headers Project — header hardening guidance; configuration audit only.
• W3C Subresource Integrity — a fetched file must match a declared hash.
• Nielsen Norman Group, “Response Times: The 3 Important Limits” (Jakob Nielsen, 1993) — 0.1 s, 1.0 s and 10 s. Our thresholds are set stricter than the research limit.
• NN/g, “Scroll Fading 101” (Sara Paul, 2023) — qualitative usability testing on scroll-triggered fades; used to judge motion, never to project traffic.
• arXiv 2502.16038 — Cao & Cao, “How Does Emotion Affect Information Communication” (IEEE, 2025), on attention, encoding and memory in animated interfaces.
• Frederick et al., JUX 10(2):87–95 (2015) — a controlled parallax study: a gain in fun, no significant gain in usability. Cited precisely because it limits what motion may claim.
• Awwwards evaluation system — Design 40, Usability 30, Creativity 20, Content 10. What a jury rewards, not what causes traffic.
• Practical Typography (Matthew Butterick) — line length 45–90 characters, read as a declared CSS constraint.
• 8-point spacing convention — an industry convention with no single canonical source, so it is counted, never judged.
• Google Search Central documentation — title, snippet, canonical and structured-data guidance for one crawler; lengths are approximate house style.

Two of those entries come from this project’s own research notes and are labelled project-rules in the report rather than presented as freshly quoted. Practice sources are never used to project traffic.