In this guide
Set a business goal for the audit
A website audit is most useful when it starts with a decision. Choose the customer action you want to support, such as a relevant enquiry, an appointment request, or finding the right service information. Define what a successful journey looks like before collecting a long list of issues.
Separate observed problems from preferences. A form that does not deliver an enquiry is a functional failure. A heading that someone would phrase differently is an editorial judgment. Both may deserve attention, but they should not receive the same priority automatically.
Inventory the pages and their purposes
List the important pages, their intended audiences, and the question each one answers. Look for duplicate purposes, missing service explanations, and pages that cannot be reached from the rest of the site.
Check actual responses and basic search settings for representative pages. Confirm that titles and main content are available in the initial response where the framework supports it. Record limitations rather than assuming that a browser screenshot proves crawlability.
Walk the customer journey on a small screen
Start from a service page, not only the homepage. Can you understand the offer, find an important qualification, and choose a next step? Check navigation, text size, contrast, focus visibility, and whether a sticky element covers the content.
Use a keyboard as well as a pointer. Open and close menus, move through form fields, and follow important links. Note any point where the next action becomes unclear or difficult to reach.
Test forms all the way to the destination
Use artificial test details and an authorized test destination. Check missing fields, invalid values, duplicate clicks, and a failed backend. A success screen is valid only when the system actually accepts the enquiry.
Verify what happens after acceptance. Confirm the record exists, who owns it, and what happens if a notification fails. Do not send test messages to real recipients without authorization.
Rank findings by effect and effort
Group findings into broken journeys, misleading information, discoverability issues, and polish. Estimate the work and dependencies, then assign an owner. Prioritize a direct customer failure before a cosmetic preference when the evidence supports that choice.
| Finding | Evidence | Owner | Priority | Verification |
|---|---|---|---|---|
| Enquiry destination fails | Test record was not accepted | Form owner | High | Repeat an authorized end-to-end test |
| Service scope is unclear | Reader cannot identify what is included | Content owner | Medium | Review a revised scope with a new reader |
| Menu clips on a narrow screen | Recorded viewport and screenshot | Design owner | Medium | Retest the same width and keyboard flow |
| Duplicate topic pages | Two pages answer the same question | Content owner | Review | Choose one owner and check links |
Verify the fix and preserve the evidence
A finding is not closed because a file changed. Repeat the test that exposed the problem and record the new result. For a content change, confirm the approved facts and the intended reader decision. For a functional change, check both success and failure paths.
Keep the report short enough to operate. Each finding should have a clear next action, owner, and verification method. A smaller set of resolved issues is more useful than a large report nobody can turn into work.