In short
Audit in order of consequence: things preventing indexing entirely, then things preventing conversion, then things degrading performance, then everything else. Check the blocking issues first — robots.txt, noindex, canonicals — because a site that cannot be indexed has no other SEO problems worth discussing. Report findings ranked by impact, not by category.
Start with what could be blocking everything
These take ten minutes and occasionally explain the entire situation.
Fetch /robots.txt. Look for Disallow: /, blocked CSS or JavaScript, and whether the sitemap is declared.
Check for site-wide noindex. Inspect the meta tags and the HTTP headers on a few pages, including the homepage. A staging setting deployed to production is a genuine and recurring cause of collapsed traffic.
Check canonicals. View source on several pages and confirm each declares itself rather than the homepage. Everything canonicalising to the homepage will deindex a site quietly.
Confirm one address. Check that http, https, www and non-www all resolve to a single canonical version with 301s.
Check indexing. In Search Console, compare indexed pages against what you intended to publish. A large gap in either direction is the finding.
If any of these is wrong, stop and fix it. Nothing else matters until the site can be crawled and indexed.
Then the things that cost conversions
Work through the main journeys as a user, on a phone.
Does the primary journey work? Homepage to enquiry, or to purchase. Complete it. This finds broken forms, which are more common than anyone expects and produce no error anyone sees.
Do forms actually deliver? Submit one and confirm it arrives. A silently failing contact form can run for months, and it is the highest-cost defect on most small sites.
Is the phone number tappable, the address linked, the email a real link?
Does the site work with a keyboard? Tab through the main journey — a quick accessibility check that also finds interaction bugs.
What happens on a slow connection? Throttle the network and reload. Many sites are unusable at this point and nobody has looked.
Then performance, measured properly
Use field data, not lab scores. Search Console's Core Web Vitals report shows what real visitors experienced. A perfect Lighthouse score on your laptop tells you about your laptop.
Find the heaviest thing. Usually images that were never resized, an unnecessary font, or third-party scripts. Open the network panel and sort by size.
Count third-party requests. Analytics, tag managers, chat widgets, embeds. On many sites these exceed the first-party payload entirely.
Check server response time. If the server is slow, nothing on the front end compensates.
Then content and structure
Titles and descriptions. Are they unique, do they contain terms anyone searches, are they within length? A templated section where every title follows one internal pattern is worth flagging — we have found sections where none of 134 titles contained a single search term.
Heading structure. One h1 per page, sensible hierarchy.
Thin and duplicate pages. Group URLs by template and count. A pattern repeated hundreds of times with little unique content is a scaled content risk worth raising before it becomes a traffic problem.
Internal linking. Are important pages linked from anywhere other than the sitemap? Orphaned pages are common on sites that grew without a plan.
Broken links and redirect chains. A crawl finds these quickly, and internal links pointing at redirects are an easy fix.
What to ignore
Audits become useless through volume. A report with two hundred items gets skimmed and shelved.
Skip: missing meta keywords, which have not mattered for years; minor HTML validation warnings; "low" text-to-code ratios; keyword density; and any tool score presented as a grade. Automated tools generate large numbers of findings with no sense of consequence, and passing them on unfiltered is doing the client's thinking for them badly.
If you cannot say what a finding costs, leave it out.
Reporting it
Rank by impact, not by category. The client should be able to read the first page and know what to do.
Lead with anything actively broken — the form that does not send, the pages that cannot be indexed.
Then the things costing money, with an estimate of what they cost, however rough.
Then improvements, ordered by return relative to effort.
Then a short list of what is fine. It builds trust and prevents the impression that everything is wrong, which makes clients defensive rather than motivated.
For each item: what it is, why it matters in their terms, and what fixing it involves. A finding without a consequence is trivia, and a finding without a fix is a complaint.
The realistic scope
An afternoon gets you the blocking issues, the main journeys, performance from field data, and a structural read on content. That is enough to know whether a site is healthy and what the three most valuable actions are.
What it does not get you: a full accessibility audit, a competitive analysis, or a content strategy. Those are separate pieces of work, and saying so is more useful than pretending otherwise.
If you have inherited a site and want an outside read on what is actually wrong with it, book a call.
Common questions
What should you check first when auditing a site?
Anything that could be blocking indexing entirely: robots.txt for a site-wide disallow, meta tags and headers for an accidental noindex, canonicals pointing everything at the homepage, and whether http, https, www and non-www all resolve to one address. Nothing else matters until the site can be indexed.
How do you find the issues that actually cost money?
Complete the main journey yourself on a phone, and actually submit the contact form to confirm it delivers. A silently failing form is the highest-cost defect on most small sites and can run for months without anyone noticing, because it produces no visible error.
Should site audits use Lighthouse scores?
Use field data rather than lab scores. Search Console's Core Web Vitals report shows what real visitors on real devices experienced, whereas a perfect Lighthouse score on a developer laptop mostly describes the laptop.
What should be left out of a site audit?
Anything where you cannot state the consequence — missing meta keywords, minor validation warnings, text-to-code ratios, keyword density, and tool scores presented as grades. Audits become useless through volume, and a report with two hundred items gets shelved.
How should audit findings be presented?
Ranked by impact rather than grouped by category, so the first page tells the client what to do. Lead with anything actively broken, then things costing money with a rough estimate, then improvements by return on effort — and include a short list of what is fine.
