How to Do a Technical SEO Audit (With a Checklist That's Actually Useful)

Have you ever been handed a “technical SEO audit” that was really just a 400-row spreadsheet?

Missing meta descriptions flagged as critical. Every image over 100KB listed as an error. Three hundred rows of “title too long”, and not a word about the fact that half the product pages were canonicalised to the homepage.

I’ve seen a lot of those over 15+ years, and they’re the reason technical audits have a bad name. A tool export isn’t an audit. An audit is the judgement applied to the export.

So in this guide, I’ll walk through exactly how I do a technical SEO audit: what to check, in what order, which tools I actually use, and how to prioritise what you find so your developers fix the things that move rankings first. There’s an interactive checklist near the end that you can tick off as you go - and I promise it doesn’t treat meta descriptions as a site-critical emergency.

Let’s dive right in.

What is a technical SEO audit?

A technical SEO audit is a review of everything that affects whether search engines can find, crawl, render, index and rank your pages - as opposed to what those pages say.

The way I see it, technical SEO is the foundation the rest of your SEO sits on. You can have the best content in your industry and the strongest link profile, and if Google can’t render your pages, or is spending its crawl on 50,000 filter URLs instead of your money pages, none of it counts.

What a technical audit is not: a content audit (that’s about quality and intent), a backlink audit, or a list of everything that’s technically imperfect. Reason being, “imperfect” and “holding back rankings” are two very different lists, and confusing them is how audits end up ignored.

Why most technical SEO audits are useless

Three reasons, and they all come back to prioritisation.

1. They’re tool exports with a logo on the front. Every crawler and every site audit tool will happily produce hundreds of “issues”. Most of those are cosmetic. A good audit reads the export and tells you the six things that actually matter.

2. They confuse severity with volume. 300 missing meta descriptions looks scary in a chart. It has no effect on rankings. Meanwhile, one wrong canonical tag on a category template can quietly de-index your best pages - and it’s a single row.

3. They never get implemented. If the output is a spreadsheet rather than tickets a developer can pick up, the audit dies in a shared drive. The goal is changes shipped, not documents delivered.

Keep those three failures in mind, because the whole process below is designed to avoid them.

What you need before you start

You don’t need expensive software. You need:

• A crawler. I use Screaming Frog - it’s the industry standard for a reason, and the free version handles up to 500 URLs.
• Google Search Console. Non-negotiable. It’s the only place you get Google’s own view of what’s indexed and why things aren’t.
• PageSpeed Insights or the CrUX data in Search Console for real-user Core Web Vitals.
• Google Analytics 4 (or whatever holds your conversion and revenue data). An audit prioritised by traffic alone misses the point - you want to know which pages actually deliver enquiries and sales, so those get fixed first.
• A browser with the inspector open. A surprising amount of technical SEO is just looking.
• A list of your money pages - the templates and URLs that actually drive revenue. Everything gets prioritised against this list.

Server logs are a bonus for large sites, but you can do a thorough audit without them.

How to do a technical SEO audit, step by step

This is the order I work in. Each step feeds the next, so I’d resist jumping straight to the part that looks most interesting.

Step 1: Define the money pages and benchmark them

Before you crawl anything, open Search Console and note the clicks, impressions and average position for your most important templates: the homepage, your key categories or service pages, your top products or posts.

This is your baseline. It’s how you’ll prove the audit worked, and it’s the lens for every decision that follows. An issue on a template that drives 40% of revenue is critical; the same issue on a page nobody visits is housekeeping.

Step 2: Crawl the site (properly)

Run a full crawl with JavaScript rendering turned on, respecting robots.txt, with your XML sitemap connected so the crawler can compare what you’ve told Google exists against what it actually finds.

Two numbers matter immediately: how many URLs the crawler found and how many of those are indexable. If your site has 800 real pages and the crawl finds 40,000 URLs, you’ve already found your first major problem before opening a single report.

Step 3: Check crawlability

Can search engines reach the pages you want them to reach, and are they wasting time on the ones you don’t?

Start with robots.txt. Make sure it isn’t blocking CSS, JavaScript or image directories Google needs to render the page, and isn’t blocking whole sections by accident. My free robots.txt tester lets you check specific URLs against your rules.

Then look for crawl waste: parameter URLs, faceted navigation, internal search results, session IDs, calendar pages that go on forever. On ecommerce sites this is where the biggest wins usually hide - I explain the faceted navigation problem in under a minute here:

In Search Console, the Pages report is your friend. A large and growing “Crawled - currently not indexed” or “Discovered - currently not indexed” count is Google telling you it’s finding more URLs than it thinks are worth indexing.

Step 4: Check indexability

Now the opposite question: are the pages you want indexed actually indexable?

Check for stray noindex tags (in the HTML and in the X-Robots-Tag header - crawlers often miss the header). Check that canonical tags point where you intend: self-referencing on unique pages, and never pointing at a redirected, 404ing or noindexed URL. Canonicals are a hint rather than a directive, so Google ignores the ones that don’t make sense - and then picks its own:

While you’re here, make sure the site resolves on one host and protocol. Try http://, https://, with and without www - three of the four should 301 to the fourth. It’s a five-minute check that a surprising number of sites fail.

Step 5: Check rendering

This is the step most audits skip, and it’s the one that catches the nastiest problems.

Take your key templates and compare the raw HTML with the rendered HTML (Screaming Frog can do both; Search Console’s URL inspection shows you the rendered page as Google sees it). If your main content, internal links or product data only exist after JavaScript runs, you’re relying on Google’s second-pass rendering - which is slower, less reliable, and sometimes doesn’t happen at all.

If content is missing from the raw HTML, that’s not a medium-priority note. That’s near the top of the list.

Step 6: Check architecture and internal links

Three questions:

• How deep are your important pages? Anything that matters should be within three clicks of the homepage. Crawl depth reports show you what’s buried.
• Are there orphan pages? Compare the crawl, the sitemap and Search Console. Pages in the sitemap that the crawler never reached have no internal links pointing at them - and Google treats that as a signal about their importance.
• Are internal links broken or redirected? Every internal link to a 404 is wasted, and every internal link through a redirect is a small, needless leak. Fix them at source.

This is also where you’ll spot keyword cannibalisation - several pages competing for the same intent - though I’d log it and deal with it as part of your content strategy rather than inside the technical audit.

Step 7: Check speed and Core Web Vitals per template

Field data beats lab data. Use the Core Web Vitals report in Search Console (or CrUX) to see how real users experience each template type, then use PageSpeed Insights to diagnose why a template is slow.

The mistake here is auditing individual URLs. Speed problems are almost always template problems: a heavy hero image on every category page, a render-blocking script in the theme, an unsized ad slot causing layout shift on every article. Fix the template and you fix thousands of pages at once.

Step 8: Check duplicates, redirects, sitemaps and structured data

The “everything else” pass:

• Duplicates. Trailing slash variants, uppercase URLs, product variants with their own URLs, printer-friendly pages. Consolidate with canonicals or redirects.
• Redirects. Permanent moves should be 301s, not 302s, and no redirect should chain through more than one hop. If the site has ever migrated, check that the old URLs still resolve - my SEO migration checklist covers the full process.
• XML sitemap. It should contain only indexable, canonical, 200-status URLs. A sitemap full of redirects and noindexed pages tells Google your signals can’t be trusted.
• Structured data. Valid, complete, and matching what’s on the page. Search Console’s enhancement reports will show you errors.
• Hreflang, if you serve multiple countries or languages: every tag needs a return tag, and every page needs to reference itself. My hreflang generator produces the tags correctly if you’d rather not hand-write them.
• Images. Alt text, modern formats, sensible dimensions - there’s a full image SEO guide on this.

Step 9: Prioritise by impact and effort

You’ll now have a long list. This is the step that separates an audit from an export.

Score each finding on two things: how much it affects the pages that matter (the money pages from step one), and how hard it is to fix. A wrong canonical on your category template is high impact, low effort - it goes to the top. Recompressing 2,000 legacy blog images is low impact, high effort - it goes to the bottom, or off the list entirely.

I had a great conversation about exactly this with Kristina Azarenko on my podcast, and it’s still one of the clearest explanations of prioritising technical work I’ve heard:

The output should be a short list ordered by that score - and page one of it should be genuinely where the developers start on Monday.

Step 10: Write it up for developers, then validate

Write each priority as a ticket: what’s wrong, where (with example URLs), what “fixed” looks like, and why it matters. Developers don’t need the SEO theory; they need something specific enough to ship without a meeting.

Then, after it ships, re-crawl and re-check Search Console. Validation is half the value of an audit, and it’s the half most people skip.

The technical SEO audit checklist

Here’s the checklist I promised. It’s grouped by how much each item actually matters, not by how many rows it produces in a crawler. Tick items off as you work through them - your progress saves in your browser so you can come back to it.

How often should you run a technical SEO audit?

A full audit once or twice a year is plenty for most sites, plus a lighter check whenever something changes: a redesign, a platform move, a big content launch, a new developer. Migrations get their own process - never treat one as “just an audit”.

Between audits, the Search Console Pages report and Core Web Vitals report are your early warning system. If the “not indexed” counts jump or a template goes red, don’t wait for the next scheduled audit.

Technical SEO audit tools: what you actually need

You’ll see plenty of “site audit” tools promising to do all of this automatically. They’re useful for monitoring, and they’re genuinely helpful on very large sites. But be careful: they score by volume, which is exactly the meta-descriptions-as-critical problem this whole guide is about.

The combination I keep coming back to is simple: a crawler for what’s on the site, Search Console for what Google thinks of it, and a browser for looking. Add PageSpeed Insights for speed and, on big sites, log files. Everything else is a nice-to-have.

Technical SEO audit FAQ

What is a technical SEO audit?

A review of everything that affects whether search engines can crawl, render, index and rank your pages - crawlability, indexation, rendering, site architecture, speed, duplicates, redirects and structured data - prioritised by how much each issue affects the pages that matter to your business.

How do you conduct a technical SEO site audit?

Benchmark your key pages in Search Console, crawl the site with JavaScript rendering on, then work through crawlability, indexability, rendering, architecture, speed and the “everything else” checks in that order. Score what you find by impact and effort, write the top items as developer tickets, and validate after they ship. The ten steps above are the process I use.

How long does a technical SEO audit take?

For a typical business site, one to three days of work for the audit itself, depending on size and how many templates it has. Very large ecommerce or enterprise sites take longer, mostly because the crawl itself and the log analysis take longer.

What’s the difference between a technical SEO audit and an SEO audit?

A technical audit covers the infrastructure: can Google reach, render and index the pages. A full SEO audit adds content (is it the right content for the right intent) and off-page (links, brand, authority). If you only have budget for one, start technical - content and links can’t perform on a broken foundation.

What are the best tools for a technical SEO audit?

Screaming Frog for crawling, Google Search Console for Google’s own data, PageSpeed Insights and CrUX for Core Web Vitals, and your browser’s inspector. Site audit platforms like Semrush, Ahrefs and SE Ranking are good for ongoing monitoring once you know what matters.

How much does a technical SEO audit cost?

In the UK, a professional technical SEO audit typically costs between £1,000 and £5,000 depending on the size and complexity of the site - I’ve published a full breakdown in how much does SEO cost. A cheap audit that’s really a tool export costs less and is usually worth exactly that.

Final thoughts

A technical SEO audit is only as good as its prioritisation. The crawler will always give you hundreds of things to fix - the skill is knowing which six matter, explaining them so they get shipped, and proving they worked.

Use the checklist, start at the top, and be suspicious of anyone who puts meta descriptions there.

And if you’d rather have a second pair of eyes on it, a technical audit is the first thing I do on every SEO audit - you can read more about my approach on the technical SEO page, or just get in touch with your friendly neighbourhood SEO consultant 🙂