Technical SEO audit checklist, ordered by what it costs

Most technical SEO audit checklists are inventories. They list everything that can be wrong with a website, sorted by category, and hand you two hundred items with no indication of which three are actually costing you traffic. That is not an audit, it is a shopping list, and it is why so many audit PDFs get read once and filed.

This one is ordered by consequence. It starts with the faults that stop pages existing in Google at all, moves through the ones that cost rankings, and ends with the ones that are only untidy. If you work through it in order and stop when you run out of budget, you will have fixed the expensive things and skipped the cosmetic ones, which is the correct outcome.

How to use this

Work top to bottom. Do not skip ahead to structured data because it is interesting. Section 1 faults make everything below them irrelevant, and a surprising number of sites fail section 1 without anyone noticing, because a page that was never indexed produces no error anyone sees. It just produces nothing.

Three things you need before starting:

• Search Console access. Not optional. It is the only record of what Google actually did with your URLs, as opposed to what a crawler predicts it should have done.
• A crawler. Anything that follows links and reports status codes, canonicals and meta robots.
• A way to fetch a page as Googlebot renders it. Search Console’s URL Inspection does this and it is free.

Notice what is not on that list. No paid suite is going to find a fault this checklist misses. The expensive tools find the same faults faster and present them in a longer report, which is not the same as finding more.

Section 1: is anything blocked

These are binary and they are the only faults on this page that can take a site to zero. Check them first, every time, even on sites where it seems absurd.

• robots.txt does not block anything important. Fetch /robots.txt directly and read every Disallow line out loud. A staging rule that shipped to production is the single most expensive fault in this field and it is one line of text.
• No stray noindex. Check the meta robots tag and the X-Robots-Tag HTTP header, which is the one people forget because it is invisible in the page source. Check them on templates, not just the homepage: archives, paginated pages and filtered views are where a stray noindex usually lives.
• The site is not blocked by authentication. Password protection, IP allowlists and Cloudflare rules that challenge unknown user agents all look fine in a browser and return nothing to a crawler.
• Important pages return 200. Not 301 to something else, not 404, not a soft 404 returning 200 with an empty template.
• The canonical points at itself. A page canonicalised to another URL is telling Google not to store it. Theme and plugin defaults cause this more often than people do.

A failure anywhere here is not a ranking problem, it is an existence problem, and nothing else on this checklist matters until it is fixed.

Section 2: what Google actually did

Section 1 asks what should happen. This section asks what did, and the gap between the two answers is where audits earn their money.

• Read the page indexing report in Search Console. Every status, with counts. If you do not know what each one means, every Search Console indexing status covers all of them in plain language.
• Check the ratio of indexed to not indexed. A site with more excluded than indexed URLs has a structural cause, not a page-by-page one.
• Look at the volume in each excluded status, not just the presence of it. Every site has some. The signal is one status carrying thousands of URLs.
• Crawled, currently not indexed in volume means Google fetched the pages and declined to store them. Sometimes quality, often duplication or a thin template.
• Discovered, currently not indexed in volume means Google knows the URLs exist and has not bothered fetching them. Usually a signal about site-wide value or crawl priority rather than about those pages.
• Spot-check ten real URLs with URL Inspection: the declared canonical, the Google-selected canonical, the last crawl date, and whether the rendered page contains the content you expect.
• Compare the declared canonical with the Google-selected canonical. Where these disagree, Google has overruled you, and that is worth knowing before anything else is changed.

The point of this section is prioritisation. A crawler will hand you two hundred findings with no weighting. Search Console tells you which of them Google noticed.

Section 3: what Google sees versus what you see

• Compare raw HTML against rendered HTML. If the content only exists after JavaScript runs, you are betting on rendering succeeding, and rendering is a queue rather than a guarantee.
• Check that navigation is real links. Menus built from click handlers with no href are invisible as paths. The pages behind them may still be discovered through the sitemap, but they inherit nothing.
• Check the mobile version has the same content as desktop. Indexing is mobile-first, so anything hidden or dropped on mobile is effectively not on the page.
• Check for cloaking by accident. Geolocation redirects, cookie walls and consent gates can serve Googlebot something quite different from what a visitor gets, without anyone intending it.
• Confirm the server responds consistently. Intermittent 5xx during crawl windows suppresses indexing and produces no visible symptom on the site at all.

Section 4: structure and duplication

By this point the pages exist and Google can read them. This section is about whether the site’s shape helps or fights that.

• One URL per piece of content. Check the usual duplicate generators: trailing slash variants, www and non-www, http and https, uppercase paths, session and tracking parameters, and print or AMP variants.
• Pagination is handled deliberately. Page 2 of an archive should either be indexable and self-canonical or excluded on purpose. Canonicalising every paginated page back to page 1 hides the deeper content.
• Faceted navigation is under control. Filter combinations multiply URLs faster than anything else on a site, and each one competes with the page it came from.
• Redirect chains are collapsed. One hop, not four. Check that redirects land on 200s rather than on other redirects or on 404s.
• The sitemap only lists URLs you want indexed. No redirects, no 404s, no noindexed pages, no canonicalised-away duplicates. A sitemap full of URLs Google will reject teaches it to trust the file less. The sitemap health check does this pass automatically.
• Internal links reach everything. Any page reachable only from the sitemap is a page nothing on the site vouches for.
• Orphan pages are found and either linked or removed. Both are valid answers. Leaving them is not.

Structure faults rarely produce a dramatic drop. They produce a site that quietly underperforms its content, which is much harder to notice and much easier to keep paying for.

Section 5: speed, honestly

• Read field data, not lab data. Core Web Vitals in Search Console come from real visitors. A local Lighthouse run tells you about your laptop.
• Check LCP, INP and CLS separately by template, not as one site-wide number. The homepage being fast says nothing about the product template.
• Identify the actual cause before optimising. Usually it is one of four things: unoptimised images, render-blocking resources, third-party scripts, or slow server response. Guessing which is expensive.
• Check whether speed is your bottleneck at all. A site failing Core Web Vitals while ranking fine has a user experience problem worth fixing on its own merits. It does not have an SEO emergency.

Speed sits fifth on this list deliberately. It is real, it is measurable, and on most sites it is not what is holding rankings back. Chasing a perfect score while a template emits a stray canonical is the most common misallocation in this field.

Section 6: structured data

• Validate what exists. Invalid JSON-LD is ignored, silently, so a site can carry broken markup for years believing it is helping.
• Check it matches the visible page. Markup describing content a visitor cannot see is a policy violation, not a clever trick.
• Check it survives template changes. Hand-written schema on individual pages drifts out of validity. Template-generated schema does not.
• Add only what earns something. FAQ, product, article, breadcrumb and organisation markup do work. Marking up everything markable does not.

Section 7: the tidy-up

Everything here is worth doing and none of it is worth doing first.

• Broken internal links.
• Missing or duplicate title tags and meta descriptions.
• Missing alt text.
• Heading hierarchy that skips levels.
• Mixed content warnings.
• Missing or wrong hreflang on multilingual sites, which moves up to section 1 if the site is genuinely multilingual.

Most audit reports lead with this section because it produces the longest list and the most impressive-looking screenshots. It is last here because fixing all of it on a site with a section 1 fault changes nothing.

What to do with the findings

Sort them into two piles rather than one severity list, because the two are bought differently and often by different people.

The first pile is faults: things that are wrong and can be fixed, with a finite cost and a same-day verification. That is the pile this checklist produces.

The second pile is everything the audit reveals about the content: pages competing for the same query, pages with no reason to exist, topics with no page at all. That is a different budget and a different kind of work, and technical SEO vs content SEO covers how to decide which of the two your site is actually short of. If you are unsure whether a specific finding belongs to this checklist or to the writing, on-page SEO vs technical SEO has the test.

Then fix in the order the sections appear, and verify each fix rather than assuming it. A fixed URL goes back through Search Console and gets watched until the status changes. Requesting indexing is part of that, with realistic expectations about what it does and does not do.

What this checklist deliberately leaves out

Every omission here is something that appears on most technical SEO audit checklists and does not survive contact with real sites.

Keyword density and meta keywords. The first is not a ranking factor and never was in the form people mean. The second has been ignored by Google since 2009.

“Fix all 404s”. A 404 for a page that should not exist is correct behaviour. What matters is 404s that are linked to from your own site, and 404s on URLs that used to rank. The rest are noise, and chasing the count is how audits generate busywork.

A crawler’s overall score. It is a weighted average of things that do not weigh the same. A site can score 94 with a blocking fault and 61 with nothing wrong.

PageSpeed 100. The threshold that matters is passing Core Web Vitals on field data. Everything past that is a number for the report.

Anything about crawl budget on a small site. Crawl budget is a real constraint on sites in the hundreds of thousands of URLs. On a site with four hundred pages it is a way to sound technical while recommending nothing.

Two things sit either side of this list. What the work costs, and why nobody quotes it before looking at the site, is covered in SEO audit cost. What the findings look like once written up is in the SEO audit report sample, with a real finding written out in full and a template you can copy.

The short version

Check whether anything is blocked. Check what Google actually did with your URLs, rather than what should have happened. Check that Google sees what you see. Then structure, then speed, then markup, then the tidy-up. Fix in that order, verify each fix in Search Console rather than assuming it, and stop when you reach findings that are true but would not change a number.

If you want this run on your site rather than run by yourself, that is what a site audit is, and technical SEO is the same list with the fixes done rather than handed over. If you already know which URLs are missing from Google and only want them in, indexing is the narrower and faster job.