Technical SEO Audits: The Checklist Most Sites Fail

Technical SEO · Field Guide

A 180-point audit is a sales document. The failures that actually cost traffic cluster in about six places — and half of them are invisible in the tools people run first.

Updated August 2026 · 15 min read · Thresholds checked against Google’s current documentation

Every agency has a technical SEO audit template, and almost every one of them opens with a page count of findings. One hundred and eighty issues. Two hundred and forty. The number is the product. It justifies the invoice, it looks thorough in a slide deck, and it reliably terrifies the client into a retainer.

I’ve written a few of those documents, and I’m not proud of all of them. The uncomfortable truth is that on most sites, the number of technical issues genuinely suppressing organic traffic is somewhere between zero and four. Everything else on the list is real, in the sense that the crawler correctly detected it, and irrelevant, in the sense that fixing it will change nothing.

So this is a checklist built the other way round. It starts with the things that can take a site off Google entirely, moves through the things that quietly cost you a share of traffic, and ends with a list of items that appear in every audit template and deserve to be ignored. The ordering is the point. If you work through it top to bottom and stop when you run out of time, you’ll have fixed the things that mattered.

The Hierarchy Nobody Draws Why order matters more than completeness

Search is a pipeline, and each stage depends entirely on the one before it. A page must be discoverable before it can be crawled; crawled before it can be rendered; rendered before it can be indexed; indexed before it can rank; and only then does anything about speed, structured data or user experience come into play.

This means a Core Web Vitals score is meaningless on a page that’s blocked in robots.txt. It means alt text optimisation is irrelevant on a page carrying a stray noindex tag. And it means that an audit which presents all findings as a flat list of two hundred items, sorted by category rather than by pipeline stage, has actively obscured the only information that mattered.

Every issue below is tagged by where it sits in that pipeline. Fix upstream first. Always.

Tier One: Indexation Severity: Site-ending · Check first, always

This is where the genuinely catastrophic failures live, and they’re almost always accidents rather than mistakes of understanding.

The staging noindex that shipped

The single most expensive technical SEO failure I have ever seen, on any site, was a <meta name="robots" content="noindex"> tag that came across from a staging environment during a redesign and sat there for eleven weeks. In WordPress it’s a single checkbox — Settings, Reading, “Discourage search engines from indexing this site” — and I have personally watched a developer tick it during a rebuild and forget.

Check it first. Every time. View source on your homepage and search for “noindex.” Then check the Pages report in Google Search Console, which explicitly separates indexed pages from those excluded and tells you why. If your indexed count is a small fraction of your actual page count, stop reading this article and go find out why.

robots.txt overreach

A single misplaced Disallow: / removes an entire site from crawling. More common and more insidious: blocking /wp-content/ or a JavaScript and CSS directory, which prevents Google from rendering pages properly and makes a perfectly good site look broken to the crawler. Google needs to fetch your CSS and JS. Blocking them is a habit left over from 2011 and it does active harm now.

Test your file in the robots.txt report inside Search Console. And remember what robots.txt actually does: it prevents crawling, not indexing. A blocked URL that has external links pointing at it can still appear in results, as a bare URL with no description. If you want something out of the index, use a noindex tag on a crawlable page — the two directives are frequently confused, and using both together is self-defeating, because Google can’t read the noindex on a page it isn’t allowed to fetch.

Canonical tags pointing somewhere strange

Self-referencing canonicals on every page is the boring correct answer for most sites. The failures are: canonicals pointing to the homepage from every page (surprisingly common with badly configured plugins), canonicals pointing at a staging domain, canonical chains, and paginated series where page two canonicalises to page one, hiding everything after the first twenty items.

Search Console’s Pages report has a category for pages Google considers duplicates where it chose a different canonical than you declared. That report is the highest-signal indexation diagnostic Google gives you for free, and it’s three clicks from the front page of the interface.

Sitemap hygiene

Your XML sitemap should contain exactly the URLs you want indexed. Not redirects, not 404s, not noindexed pages, not canonicalised duplicates. A sitemap full of junk isn’t merely untidy — it’s a signal to Google that your declarations aren’t trustworthy, and it wastes crawl attention on a site large enough for that to matter.

Tier Two: Crawl Efficiency and Site Structure Severity: High on large sites, low on small ones

Here’s a distinction most audits blur: crawl budget is a genuine constraint on sites with tens of thousands of URLs and essentially a non-issue below a few thousand. If you run a 300-page blog, you can skip most of this section with a clear conscience. If you run an e-commerce catalogue with faceted navigation, this section is where your traffic is being lost.

Orphan pages

A page with no internal links pointing to it is functionally invisible. It may be in the sitemap, it may even be indexed, but it receives no internal link equity and Google has no structural reason to consider it important. Finding orphans requires cross-referencing a crawl against your sitemap or analytics — the free version of Screaming Frog handles this on sites under 500 URLs, which covers a lot of blogs.

Click depth

Count the minimum number of clicks from your homepage to any given page. Anything beyond four is being told, structurally, that it doesn’t matter much. On blogs this happens through pure chronological pagination: your best article from two years ago is now eleven pages deep in an archive and nothing links to it directly. Category hubs, related-post modules and contextual in-body links are the fix, and they’re content work rather than developer work, which is why they get deferred forever.

Redirect chains and loops

A single redirect is fine. A chain of four is wasteful and slow. A loop is fatal for that URL. Chains accumulate silently across site migrations — each one adds a hop, and after two or three migrations you find URLs bouncing through five hops before landing. Rewrite the rules to point directly at the final destination rather than layering new redirects over old ones.

Soft 404s and parameter bloat

A soft 404 is a page returning HTTP 200 while displaying “no results found” or equivalent. Google flags these in the Pages report. They’re worth fixing because they teach the crawler that your 200 responses can’t be trusted.

Parameter bloat is the e-commerce killer: ?color=blue&size=m&sort=price combinations generating tens of thousands of near-identical URLs, each consuming crawl capacity that should be going to your actual product pages. Handle it with canonicals to the clean URL, noindex on filtered combinations that nobody searches for, and robots.txt disallow on genuinely infinite parameter spaces like calendars.

Tier Three: Core Web Vitals Severity: Moderate · Universally over-reported

Three metrics, three thresholds, and a measurement model that almost every article gets subtly wrong.

Largest Contentful Paint (LCP) measures loading. Good is under 2.5 seconds. Interaction to Next Paint (INP) measures responsiveness. Good is under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability. Good is under 0.1. INP replaced First Input Delay in March 2024 — if a guide you’re reading still lists FID, it’s out of date and probably wrong about other things too.

Now the part that matters more than the numbers. Google grades these on field data, from the Chrome User Experience Report, at the 75th percentile, over a rolling 28-day window. Three consequences follow, and almost nobody acts on them:

Your perfect Lighthouse score means nothing. Lighthouse is a lab simulation on your machine. Google grades you on real visitors, many of them on mid-range Android phones over patchy mobile data. I have seen sites score 98 in Lighthouse and fail Core Web Vitals outright in Search Console.

The 75th percentile means you pass only when three quarters of real page views hit the good threshold. Optimising for your median user is optimising for the wrong user.

The 28-day rolling window means you cannot deploy a fix on Tuesday and check on Wednesday. Give it three to four weeks before drawing conclusions, and resist the urge to make three changes at once, because you’ll never know which one worked.

Of the three metrics, INP is the one most sites fail, and it’s also the hardest to fix. LCP is usually a resource problem — compress the hero image, preload it, sort out server response time, put a CDN in front. CLS is usually a dimensions problem — set explicit width and height on every image, iframe, video and ad slot, reserve space for anything injected after load, and use font-display: swap carefully. But INP is an architecture problem. It measures the full round trip from a user’s tap to the next painted frame, across every interaction in the session, and reports the worst one. You fix it by shipping less JavaScript, breaking long tasks, and yielding to the main thread — none of which is a plugin you install.

“You cannot compress your way out of an INP problem. It is not a file size issue. It is a question of what your JavaScript is doing while the user is waiting.”

A word specifically for publishers running display ads: your CLS and INP problems are very often the ad stack, not your theme. Reserved ad slots with fixed dimensions, lazy-loaded below-the-fold units, and a hard look at how many header bidding partners you’re calling will do more than any front-end optimisation. This is an uncomfortable conversation to have with a revenue team, but it’s the real answer.

Tier Four: Duplication and Thin Content Severity: Moderate · Frequently misdiagnosed

Duplicate content is not a penalty. It never was. What it does is split signals between two URLs that should have been one, so neither ranks as well as a consolidated page would have.

The usual sources are dull and fixable: HTTP and HTTPS both resolving, www and non-www both resolving, trailing-slash and non-trailing-slash variants, uppercase and lowercase paths, print versions, and tag or category archives that reproduce full post content rather than excerpts. Pick one canonical form of your URLs, 301 everything else to it, and check that your internal links use the canonical form rather than relying on redirects to clean up after them.

Thin content is a different animal and gets over-diagnosed by tools that count words. Word count is not the metric. Usefulness is. A 200-word page that answers a specific question completely is not thin. A 2,000-word page that restates the same paragraph five ways is. Where tools are genuinely useful here is finding the pages nobody visits: cross-reference your crawl against Search Console impressions, and any page with meaningful crawl cost and near-zero impressions over six months is a candidate for merging, improving, or removing.

Tier Five: Structured Data and International Severity: Low, except when it isn’t

Structured data doesn’t improve rankings. It can win you rich results, which improves click-through rate, which is a different and often larger benefit. Validate whatever you implement in Google’s Rich Results Test and watch the Enhancements reports in Search Console for errors after deployment.

The main failure mode is marking up things that aren’t there — review schema on pages with no visible reviews, FAQ schema on pages with no visible FAQ. That’s a policy violation, not a clever trick, and Google has become considerably less tolerant of it.

Hreflang, if you run multiple languages, is its own category of pain. The rules are strict: tags must be reciprocal, every version must list every other version including itself, and language and region codes must be valid. Get one of those wrong and Google ignores the whole cluster. If you don’t run multiple languages, skip this entirely and enjoy your good fortune.

The Checklist, Ordered by What It Costs You

What to Ignore, No Matter How Red the Tool Turns It

Every crawler ships with a scoring system, and the scoring systems are tuned to find problems, because a tool that reports “your site is fine” doesn’t renew. Here’s what I skip without hesitation.

Multiple H1 tags. Google confirmed years ago that this is fine. HTML5 permits it. It sits in every audit template because it once mattered, in roughly 2009.

Keyword density. Not a thing. Has not been a thing for well over a decade. Any tool reporting an optimal density percentage is selling nostalgia.

Meta keywords. Google stopped using them in 2009 and said so publicly.

The overall “SEO score” out of 100. An arbitrary composite invented by the vendor. Two tools will give the same site scores thirty points apart. It’s a marketing device for creating urgency, and I’ve watched clients chase a score from 68 to 91 with zero traffic change.

Alt text on decorative images. Alt text matters for accessibility and for image search on meaningful images. Spacer graphics, background flourishes and icons should have empty alt attributes, which is correct practice and which crawlers will nonetheless flag as an error by the hundred.

Title tags a few characters over the recommendation. Google rewrites a large share of titles anyway. Getting truncated in the SERP is a click-through problem worth fixing on your top pages; it is not a ranking factor worth spending a sprint on across five thousand URLs.

How to Actually Run One

The tooling is less important than the sequence, but for completeness: Search Console first, always, because it’s Google telling you directly what it thinks. Then a crawl — the free Screaming Frog licence covers 500 URLs per crawl, which is a complete audit for most blogs, and the paid licence at £199 a year removes the cap and adds JavaScript rendering. Then PageSpeed Insights for Core Web Vitals, reading the field data section rather than the lab score at the top.

If you have server access, log files are the most underused technical SEO resource in existence. They tell you what Googlebot actually crawled, how often, and what it got back — not what a crawler simulated. On a large site, an afternoon with log files will teach you more about crawl behaviour than a month of tool reports.

Then write your findings in pipeline order, not category order. And be honest in the document about which items are theoretical. A client who is told “these four things are costing you traffic and these forty are cosmetic” will trust you considerably more than one handed a red-and-green wall of two hundred rows.

Core Web Vitals thresholds and Search Console report behaviour verified August 2026 against Google’s current documentation. Screaming Frog pricing checked against the vendor’s own pricing page. This article contains no affiliate links.