Technical SEO audit: the five checks that catch 80% of problems

A comprehensive technical SEO audit can run to dozens of checks and take days to complete properly. Most sites, though, have their real problems concentrated in a much smaller set of issues. These five checks, run in about twenty minutes, catch the large majority of what actually needs fixing before anything more exhaustive is worth the time.

We run this exact sequence on every new client before proposing any larger audit, because it's a fast way to tell whether the account has a genuine structural problem or just needs the usual ongoing optimization work. More than once, the twenty-minute version has surfaced the single issue actually suppressing a site's rankings, making the longer, more expensive audit unnecessary until this smaller list of problems gets fixed first.

Check robots.txt for accidental disallow rules and check that key pages return a 200 status, not a soft 404 or an unexpected redirect chain. We've found production sites accidentally blocking their own blog from crawlers after a staging robots.txt file got deployed by mistake, silently costing months of visibility before anyone noticed.

This check takes under a minute and it's astonishing how often it catches something real. A single misplaced `Disallow: /` line, copied from a staging environment's configuration and never removed before launch, can quietly zero out a site's organic visibility for months while every other metric looks normal, because nothing about the site itself is broken, it's simply invisible to the crawler.

Duplicate or conflicting canonical tags, often from URL parameters, staging subdomains, or pagination, split ranking signals across multiple versions of what should be one page. This is a common and easy-to-miss issue on eCommerce sites with faceted filtering in particular.

A product page reachable through six different filter-combination URLs, each treated as a separate page with its own thin ranking signal, performs worse in aggregate than the same page consolidated under a single canonical. Fixing this is rarely more than a template change, but finding it requires actually spot-checking canonical tags across a sample of filtered URLs rather than assuming the platform handles it correctly by default.

Confirm the sitemap only lists canonical, indexable URLs, not a stale export full of redirected or removed pages. A sitemap padded with dead URLs doesn't just look untidy, it actively wastes crawl budget on pages that don't need it, at the expense of newer pages that do.

Run the site through Google's mobile-friendly test even if it looks fine on your own phone, since real device rendering issues are common and invisible without checking. Tap targets sized for a desktop cursor, text that requires zooming, and content that overflows its container on narrower viewports all show up here, and all of them are Core Web Vitals and ranking factors independent of desktop performance.

Compare the number of pages actually indexed in Search Console against the number you expect: a large gap in either direction usually points to a crawlability or duplicate content issue worth digging into further. Fewer indexed pages than expected suggests a crawl or canonical problem; far more than expected often means duplicate or low-value pages, like tag archives or filtered URLs, are getting indexed when they shouldn't be, diluting the site's overall quality signal in the process.

We calculate the "expected" number simply: count the genuinely unique, valuable pages a site should want indexed, product pages, category pages, blog posts, core marketing pages, and compare that against what Search Console's coverage report actually shows. A site with 400 expected pages but 1,200 indexed usually has a faceted navigation or parameter problem generating thousands of thin duplicate URLs the crawler dutifully indexed, none of which help rankings and some of which actively hurt the site's aggregate quality signal.

Finding an issue in this checklist doesn't mean it needs fixing immediately at any cost. We triage by estimated impact: a robots.txt block on the entire blog gets fixed same day, since it's actively costing visibility every day it's live. A handful of duplicate canonicals on a rarely visited archive page can wait for the next scheduled maintenance window. Treating every finding as equally urgent burns goodwill with a development team fast, and it's not actually necessary, since the checks vary hugely in how much they're costing the site per day left unfixed.

We also use the results of this check to decide whether a deeper audit is worth commissioning at all. A site that passes all five checks cleanly rarely has a technical SEO problem big enough to justify a multi-day audit, and telling a client that honestly, even though it means less billable work for us, is part of what keeps the relationship trustworthy over the long run.

This checklist works best as a recurring habit rather than a one-time diagnostic. We run it monthly on every retainer account, not because we expect to find something every month, but because catching a robots.txt regression or a canonical mismatch a week after it happened is a five-minute fix, while catching the same issue three months later means unwinding months of lost visibility that a competitor may have quietly picked up in the meantime. Automating the parts that can be automated, a scheduled crawl comparing robots.txt and canonical tags against last month's snapshot, for instance, turns this from a task someone has to remember into a check that happens whether anyone remembers or not, which matters most on accounts where the person who used to remember to run it manually has since moved to a different role entirely, taking that institutional knowledge with them.

We walk every retainer client through this exact checklist at least once, live, on a screen share, rather than keeping it as something only we run behind the scenes. A client who's watched the process once can sanity-check our reporting later and, just as usefully, can run a quick gut check themselves the week after a big site change ships, well before our own next scheduled review would have caught a problem. That kind of shared visibility tends to build more trust than any dashboard we could hand over on its own, and it costs us nothing but twenty minutes of screen-sharing time.