A useful website audit finds the few problems that prevent visitors from understanding the offer, trusting the business, or completing the next step.
Begin with the most important visitor journey and produce an ordered repair list with evidence, owners, and retest dates.
Conversion Leak Triage Worksheet
Use this worksheet to record the current evidence, the next action, its owner, and the condition that would change the decision.
Choose the visitor journey before opening the checklist
A broad audit becomes useful only after you name the journey that matters most: understanding a service, requesting a quote, booking a call, or buying a product. Write that outcome at the top of the audit and test the path as a new visitor. This keeps minor visual preferences from outranking a broken enquiry or an unclear offer.
Spend the first two hours where visitors can get stuck
Give the homepage, the highest-traffic service page, and the contact or booking path twenty minutes each on a phone and desktop. Record the first confusing sentence, doubtful interaction, and point where the visitor must guess what happens next. Use the remaining time to fix one high-impact issue and assign owners for development, accessibility, privacy, or legal review.
A small audit is successful when it produces a short ordered repair list, not a large score. Put conversion blockers first, then trust gaps, then visual polish. Recheck the repaired journey in a private browser so cached pages, remembered logins, and familiarity do not hide the visitor experience.
Turn observations into reproducible findings
For every finding, record the affected URL, device, browser, evidence, visitor consequence, owner, and retest date. “Button looks odd” is not actionable. A note that the booking button sits below three testimonials on a narrow phone screen gives the team something it can reproduce and verify.
Rank findings by consequence and confidence. A confirmed failed enquiry belongs above a colour preference. A confusing label observed in several sessions belongs above a speculative rewrite. Label weak evidence as a test instead of presenting it as fact.
Test the complete enquiry, not only the visible page
Start from a search result or direct visit and complete the main task without an administrator login. Confirm the title matches the promise, the opening explains the offer, forms validate clearly, confirmation appears, and follow-up email reaches the expected inbox. Repeat on a phone and desktop in a private browser window.
A form can display a confirmation yet lose the enquiry after submission. Send a test from an address outside the business domain, confirm the notification reaches the right inbox, and check that reply-to works. If a booking tool is involved, verify the time zone, both participant emails, and the cancellation path.
Compare a weak result such as “form worked” with a reproducible note: “Mobile Safari, 10:15, service-page form delivered to sales in 42 seconds; confirmation named the expected response window.” The second note creates a baseline and makes a later regression visible.
Check accessibility and performance with human context
Use the keyboard alone, zoom to 200 percent, check visible focus, and look for sticky elements that cover content. The W3C accessibility guidance frames the review, but automated scores do not replace a person completing the task.
Record the date, device, connection, and test location for performance checks. Google’s Core Web Vitals guidance explains loading, responsiveness, and visual stability; field data is preferable when available. Close a finding only after the visitor consequence is removed and the same journey passes again.
Use evidence to choose the first repair
Suppose the audit finds a vague homepage headline, a slightly misaligned testimonial, and a contact form that fails on a phone. Repair the form first because it prevents the main action and has direct evidence. Clarify the headline next because it affects comprehension. Leave the alignment issue until those changes have been retested.
Assign each repair one owner and an observable completion condition. For the failed form, completion means a visitor can submit on the affected phone, sees a clear confirmation, and the business receives the message. “Developer investigated” is activity, not evidence that the visitor problem has disappeared.
Close the audit with owners and retest dates
Set a short retest after high-impact fixes and a broader review after meaningful site changes, campaigns, plugin updates, or new booking tools. Keep the audit record beside the change log so the next reviewer can distinguish a known tradeoff from an accidental regression.
The final handoff should name unresolved risks, their owners, and the date each one will be reconsidered. Privacy notices, consent controls, terms, and sector obligations belong with the organisation’s legal or compliance owner; a website audit should record that boundary rather than assume one generic template fits every jurisdiction.
A two-hour audit worksheet with firm stopping points
Use four timed blocks so the review stays proportionate. Spend fifteen minutes defining the visitor, starting page, desired action, and evidence you will accept. Spend forty-five minutes completing the journey on a phone, then thirty minutes repeating it on desktop and checking the confirmation or follow-up. Reserve the final thirty minutes for ranking findings, assigning owners, and setting retest dates. Stop when the timer ends; unresolved ideas belong in a later investigation, not in an unranked pile.
For each finding, use a compact record: URL and step, device and browser, expected result, observed result, visitor consequence, evidence, owner, and retest date. A useful example is: “On the pricing page at 11:20, iPhone Safari hid the enquiry button behind the cookie control; screenshot attached; three taps were required; owner: web support; retest Friday.” That record is specific enough for another person to reproduce without guessing.
When two issues compete, score consequence before effort. A broken submission with clear evidence outranks a vague headline even if the form repair takes longer. A headline that misstates the service outranks a decorative spacing problem. If evidence is uncertain, create a short test rather than claiming certainty: compare two customer calls, inspect search terms, or watch a colleague attempt the journey without coaching.
Close the session by choosing no more than three repairs. Name the first change, the person responsible, the completion condition, and the date of the retest. This constraint protects the audit from becoming a redesign wishlist and gives the business a visible result before the next review begins. Before closing the record, attach the screenshot, form receipt, performance trace, or test email that supports each high-priority finding. Evidence lets the owner retest the exact fault and prevents the next audit from reopening a resolved debate.
Continue with the page that owns the next decision
After the audit, use the focused guides on homepage clarity, contact-form delivery, and booking-link paths for the repair that reached the top of the queue.
Finish by assigning each accepted fix an owner and a verification date. A change is complete only after someone checks the live page on a phone and desktop, confirms the form or link works, and records the result for the next audit.