Guides / How-to

How to read a website audit without being blinded by scores

A practical way to read any website audit: sort findings by severity and effort, spot what costs enquiries, and turn it into a one-page summary for your CEO.

· 6 min read · By DGTL

A website audit usually arrives as a PDF with a large number on the front, a traffic-light colour, and forty pages you are expected to do something about. The number gets forwarded to the CEO, who asks why it is not 100, and the forty pages go unread.

There is a better way to read one, and it works on any audit.

Start by ignoring the score

A score is a summary of many unrelated measurements, weighted by whoever built the tool. It is useful for one thing: comparing the same site against itself over time, using the same tool.

It tells you very little about whether the site is winning or losing you business. A site can score well and have a broken contact form.

So skip the front page and go to the findings. For each one, ask a single question: what happens to a real visitor because of this?

Sort by severity and effort

Every finding has two properties that matter.

Severity is how much harm it does. Does it stop people using the site, put them or you at risk, or is it a tidiness issue?

Effort is what it takes to fix. Ten minutes in the CMS (the system you edit the site in), a day of developer time, or a rebuild of the template?

A decent audit gives you both for every finding. If yours does not, add them yourself in a spreadsheet, using high, medium and low. Rough is fine. Then sort.

Low effort High effort
High severity Do this week Plan and budget it now
Low severity Batch into a tidy-up day Leave it, and say so

The bottom-right box matters as much as the others. Deciding in writing not to fix something is a legitimate result of an audit, and it stops the same item resurfacing every quarter.

Fix what hurts visitors first, what is cheap second, and what only moves a score last.

What the five areas mean

Most audits cover some version of these five. Here is what each is really measuring.

Speed

How long pages take to show their content and respond to taps. You will see the Core Web Vitals: LCP (how quickly the main content appears), INP (how quickly the page reacts when you interact) and CLS (how much the layout jumps around). Slow pages lose impatient visitors, particularly on phones. Look for which pages are slow and why. “Homepage hero image is far larger than it needs to be” is actionable. “Performance: 54” is not.

Accessibility

Whether people with disabilities can use the site, measured against WCAG (the Web Content Accessibility Guidelines, currently at version 2.2). Typical findings: text with too little contrast against its background, images with no text description, form fields with no labels, menus that cannot be reached with a keyboard. Be aware that automated tools catch only some accessibility problems. A clean automated result is not proof the site is accessible.

Mobile

How the site behaves on a phone. Text too small to read, buttons too close together, content wider than the screen, pop-ups that cannot be closed. Most of your visitors may well be on mobile, so treat these as mainstream problems and not edge cases.

Security and privacy

Whether the connection is encrypted (HTTPS), whether the software is visibly out of date, whether the standard protective settings are in place, and whether tracking cookies are set before the visitor has consented. UK law requires consent before non-essential cookies, so that last one is a legal matter as well as a technical one. Our security basics guide covers this area in more depth.

Links that lead to missing pages, redirects that hop through several addresses, and links to other sites that have since died. In bulk they make a site feel neglected.

The findings that cost enquiries

Some findings matter more than their category suggests, because they sit between a visitor and the moment they get in touch. Go through the audit and flag anything touching these:

  • The enquiry path. Contact page, forms, phone links, booking tools. A form with unlabelled fields, a button that cannot be tapped on a phone, or a submission that fails silently.
  • Your highest-traffic entry pages. A slow page nobody visits is a low priority. A slow page that most visitors land on is urgent.
  • Trust signals. A browser security warning, an expired certificate, or a “not secure” label will send a cautious buyer away before they read a word.
  • Anything covering the content. Cookie banners, newsletter pop-ups and chat widgets that hide the page on a small screen.
  • Broken links from your own navigation. A 404 (page not found) reached from the main menu is far worse than one buried in a blog post from years ago.

Mark these with a star in your spreadsheet. They jump the queue regardless of what severity the tool assigned.

Turn it into a fix list

Now reduce the audit to something a person can act on. For each finding you intend to fix, write one row:

  1. Page or pages affected. Actual URLs.
  2. The problem in plain words. “Contact form has no labels, so screen reader users cannot tell which field is which.”
  3. Severity and effort. High, medium or low for each.
  4. Owner. You, your developer, your agency, your host.
  5. Evidence. A screenshot or the line from the report.
  6. Done when. A test anyone can run. “Form can be completed using only the keyboard.”

Order it: starred items, then high severity and low effort, then the rest. If the list is longer than about fifteen rows, cut it. A list of sixty does not get finished.

The one-page summary for the CEO

Your CEO does not want the audit. They want to know whether there is a problem, what it will cost, and what you are doing. Give them one page in this shape:

Where we stand. Our website was independently audited on [date]. It is sound in [areas]. It has problems in [areas].

What it is costing us. [Two or three findings, each as a consequence.] For example: visitors on phones cannot easily complete the enquiry form.

What I am fixing this month. [Three to five items, with owners.]

What needs a decision. [Anything needing budget or a supplier, with a rough size.]

What we are leaving. [Low-severity items, and why.]

When we check again. [Date of re-audit.]

Mention the score once, if at all, and only alongside the date so you can show movement next time.

Red flags of a lazy audit

Plenty of audits are a free tool’s output with a logo added. Signs you are holding one:

  • No page-level detail. Problems are described in general with no URLs.
  • Everything is critical. Forty red warnings with nothing ranked means nobody made a judgement.
  • No effort estimates. Severity without effort cannot be prioritised.
  • Boilerplate explanations. The same generic paragraph under each finding, with nothing about your site.
  • Findings that are wrong. It flags a missing page that exists, or a tool you do not use. Nobody looked.
  • Recommendations that all lead to the same purchase. Usually a rebuild.
  • No named person. Nobody you can ask a question of.

That last one is the simplest test. Automated measurement is fast and it also misreads things, so someone who knows websites should have read the output before you saw it. That is what human in the loop means in practice.

Our own Website Audit is built to pass this test: findings ranked worst first with severity and effort, in plain English, checked by a person before it goes out. Whichever audit you use, read it the same way.

Next step

Time for some support?

You do not have to do all of this alone. Tell us what is on your list, and we will tell you honestly where we can help.