Website audit

An audit makes sense in two situations. The first: you have a site but no results — traffic arrives, enquiries don't, and nobody can say where people are being lost. The second: you inherited a project and need to know what's inside before taking it on or investing in it.

The point of an audit isn't to send you a hundred observations sorted alphabetically. That report gets filed and forgotten. A useful audit answers a different question: which of these findings actually affect revenue, what to fix first, and what it will cost. Everything else is background. That's why we fit the audit into a single working day — stretching it over two weeks adds nothing if you work from a checklist and don't pad the writing.

How we work

1. Agree the goals. We establish what you expect from the site and which numbers you judge it by. Auditing a store and auditing a corporate site look at different things.
2. Technical layer. Speed and Core Web Vitals, console and server errors, response codes, mobile rendering, indexing, certificate and hosting status.
3. SEO layer. Metadata, headings, structure and depth, duplicate pages, canonical URLs, robots and sitemap, structured data. We look for whatever stops a search engine understanding the site.
4. Code and infrastructure. We read the code, assess dependency health, check whether backups and version control exist, and look for obvious security exposure.
5. User behaviour. Using your analytics we find where journeys break: which pages lose people, where form conversion drops, what happens on mobile.
6. Report and priorities. Findings go into a list where every item carries an estimate of impact and effort. Whatever pays back fastest sits at the top.

What you get

A clear picture of the site's condition and a plan of action, instead of a nagging sense that something is off. The problem list is ordered by effect on results rather than by whatever caught the eye first: some fixes pay back within a week, some are long-term investments, and some genuinely aren't worth doing at all.

The audit stands alone — you're under no obligation to have us implement anything. If you do continue, the findings are naturally closed out under technical support. For inherited projects an audit is usually the first step before custom-built site support.

Timeline

The audit takes one working day. We get access in the morning, the work runs through the day, and the report is with you by the end of it. That pace is possible because an audit is a practised procedure with a checklist rather than open-ended research — we know where to look first.

We'll be straight about what doesn't fit into a day. Deep analysis of user behaviour over a long period needs accumulated data: if analytics isn't installed or the sample is thin, that section will be shallow, and we'll say so in the report rather than pretending otherwise. Load testing and a full code audit of a large application also sit outside a single day and are quoted separately. Price follows the size of the site — we quote after a short conversation about what's worrying you.

A typical scenario

Consider a store with steady traffic and falling sales. The owner suspects the design and is preparing to commission a redesign. The audit shows something else: the mobile catalogue loads far too slowly, and the delivery step asks for fields most customers simply cannot complete. A redesign wouldn't have solved either problem, and would have cost many times more than fixing the form and compressing the images.