Website audit example: deciding what to fix first
How I turn website checks, search data and analytics into a short backlog, with a worked findings table you can copy.
If your audit gives a broken contact form and a missing image description on an old page equal space in a 400-line spreadsheet, what do you fix first? That's the decision I'd want the audit to help with.
I use technical checks, search data, analytics and page reviews to build one backlog. The example below is deliberately simple, so you can see how the method works without assuming your site has the same problems.
The output in one sentence
Fix journeys that can lose enquiries, improve pages already close to search demand, then address the publishing problems behind repeated errors.
Start with the website's job
Before opening a tool, I'd want to be clear about the website's job. That might be qualified enquiries for a service business, or sign-ups, activation and booked demos for a product. Then each finding has a question attached: could this stop that job happening?
A short baseline might include:
- The primary conversion and the pages that lead to it
- The audiences and search problems those pages need to answer
- The current conversion rate or best available proxy
- The people who publish, approve and maintain the site
- Known launches, migrations or campaigns that change the order of work
An example findings table
The table takes an observation and turns it into a decision. The scores are rough on purpose. They're there to help discuss impact, confidence and effort, rather than make a judgement look like maths.
| Finding | Evidence | Commercial risk | Next action |
|---|---|---|---|
| Demo form fails after a validation error | Reproduced on mobile and visible in form error events | High | Fix and release this week, then test every field state |
| Maintenance guide ranks near page one but has no service path | Search impressions, position data and no contextual CTA | High opportunity | Add a useful calculator and link to the relevant service |
| Service page does not explain what happens after launch | Page review and repeated sales questions | Medium | Add scope, working rhythm and a realistic example |
| Three old images have empty descriptions | Crawl report | Low | Fix during the next content edit, unless the images carry meaning |
Four places to look for evidence
1. Customer journey
I'd begin by walking through the main journeys on a real phone and desktop: navigation, forms, booking, checkout, errors and what happens after conversion. When something fails, record where it happened and the evidence behind it. The screenshot is useful, but it won't establish priority on its own.
2. Search and content
Pages that already have impressions, useful rankings or links give you somewhere to start before deciding what else to write. Are they answering the query, offering something original and giving the reader a sensible next step? That's what I'd try to improve, without repeating phrases just because a tool suggests them.
3. Technical quality
Important pages need to be crawlable, renderable and indexable. Check canonicals, redirects, duplicate routes, status codes and performance where it affects people using the site. Issues that block discovery, damage trust or make releases risky come first. My technical SEO implementation work covers releasing and checking those fixes.
4. Publishing and ownership
If the same errors keep returning, the way the site is managed may be part of the problem. That means looking at the CMS model, shared components, approvals, analytics ownership and release process. Fixing the cause where you can saves repairing the same symptom each month.
An audit template to copy
Use one row for each decision, with these columns:
- Page or journey: the exact place where the issue occurs.
- Observation: what is happening, written without a solution.
- Evidence: analytics, search data, testing, customer feedback or a reproducible check.
- Impact: the customer or business outcome at risk.
- Confidence: high, medium or low.
- Effort: a rough delivery size, not a fake estimate.
- Owner and next action: one person and one clear step.
What not to do
- Do not order the backlog by the audit tool's severity label.
- Do not give every page the same checklist regardless of its purpose.
- Do not bury broken revenue journeys below easy technical tasks.
- Do not recommend a redesign when a smaller change can test the idea.
- Do not call a finding complete until the fix is released and checked.
Frequently asked questions
What should a useful website audit produce?
A short backlog in priority order, with evidence, an owner and a check for each recommendation. Screenshots and measurements need to explain a problem. More pages in the report don't make it more useful.
How do I prioritise website audit findings?
Broken journeys and important measurement gaps would come first for me. After that, I'd compare likely impact, confidence and effort, then group related fixes into work the team can deliver and check together.
Do I need a redesign to address an audit?
Not necessarily. You may be able to fix content, navigation, forms, performance or measurement without replacing the site. Use the evidence to choose between a focused change and a wider rebuild.
.jpg)
