Example scenario
A mobile form opens, but the error is off-screen
A visitor opens an enquiry form from a service page. A required field is missing, and the form stops, but the error is outside the visible area.
How would we approach it?
We record the page and device and recommend displaying the error beside the relevant field, with focus moved to the first error. The acceptance check repeats the same task on a phone.
Start with the pages that matter to the business
A useful audit starts with the work the site needs to do. For one team that may mean getting a qualified enquiry from a service page. For another it may mean helping a customer find the right product and complete checkout. We agree the important pages and common visitor tasks first, then review the steps a person takes to complete them.
Each finding includes the relevant URL, the device or conditions where it occurs and the evidence behind it. If a problem only appears on a smaller phone or after an error, the team should be able to reproduce it. Where useful, we include a screenshot or the exact path through the site.
Review discovery, use, performance and measurement
For discovery, we inspect internal links, redirects, sitemap coverage and canonical addresses. Where Search Console access has been agreed, we can compare the URLs the site publishes with the ones Google reports. In usability review, we try important actions such as navigating a menu, completing a form or moving through checkout.
Performance work looks at visible bottlenecks such as oversized images, delayed content or slow interaction. We also review basic accessibility issues, including labels, visible focus and keyboard navigation. For measurement, we check whether meaningful actions are being recorded correctly where the available access and consent permit it. A recorded click and a completed submission answer different questions.
Make the recommendation specific enough to assign
Suppose a visitor follows a link to an enquiry form and loses the service selection when correcting a required field. We record the starting page, selected service and action that causes the problem. The recommendation then includes the behaviour the developer should be able to demonstrate, such as preserving the selection after validation and showing a useful error message.
We consider likely impact alongside implementation effort. A group of inconsistently sized images can become a single task with representative files and target dimensions. A navigation problem can be scoped around the actual routes affected. Where a finding needs a decision on copy, design or development, the report makes that dependency visible.
A report for the owner and the implementation team
The owner receives a concise decision summary. The team receives a page-level list with recommended fixes and acceptance criteria. Your current developer can use it to plan the work, or we can scope implementation and follow-up checks separately. If account data is unavailable, the audit can start with public evidence and identify the specific questions that need access later.
Questions before you start
What is the difference between a free review and a paid website audit?
The initial review identifies the site’s main objective and a sensible starting point. A detailed audit records examples, potential impact, priority and how to verify a fix for each finding on the agreed URLs. The output is specific enough to share with your team.
Do you review every URL or work with sample pages?
For a small site, the scope may include the full homepage, service and contact journeys. For larger sites, we select representative pages for shared templates and key conversion steps. The proposal specifies the URL coverage and which tasks will be tested manually.
What can you assess without GA4 or Search Console access?
We can review mobile usability, links, example speed measurements and visible search signals from outside. Questions about actual click trends, recorded conversions or Google’s selected canonical require account data. The report identifies the source behind each finding.
Can I give the report to my own developer to implement?
Each item includes a sample URL, what triggers the issue, the expected behaviour and an acceptance check. For example, it can specify whether a mobile contact form keeps the selected service. Your team can take the item and verify the fix under the same conditions.
Can you check the changes after the audit is delivered?
The audit and implementation can be scoped separately. Once your team has made changes, we can plan a follow-up against the original findings. Confirming a fixed user journey on the live site and watching search performance evolve are separate checks.