What is a technical SEO audit?

What a technical audit is, and is not

A technical SEO audit tests the foundations. It asks whether search engines can reach your pages, understand them and store them, and whether visitors get a fast, secure, usable experience. It does not judge your copy or your offer. Those are separate checks.

The point is to find what blocks results. A beautiful, well-written service page does nothing if it carries a noindex tag by mistake, or sits behind a redirect chain that wastes crawler time. Technical problems are often invisible to the owner because the page looks fine in a browser.

Run an audit before a major SEO push, after a redesign or migration, and then at least once a year. A redesign is the moment most technical SEO damage happens.

Step one: set the baseline

Before changing anything, record where you stand. Verify the site in Google Search Console, export the Page indexing report, and note how many pages are indexed against how many you expect. Record your Core Web Vitals status and your top pages by clicks.

Then crawl the site with a tool such as Screaming Frog, Sitebulb or a platform crawler. A crawl lists every URL it can reach with its response code, title, canonical, indexability and internal links. Compare the crawl to Search Console: pages found by one and not the other are your first clues.

Step two: access and indexing checks

Work through the three technical requirements in Google's Search Essentials. Is Googlebot blocked? Check robots.txt for rules that disallow important folders, scripts or styles. Does the page work? Look for 4xx and 5xx responses and soft 404s, where a missing page returns a success code. Does it have indexable content?

Next check the rules that remove pages from the index on purpose. A noindex tag or header tells Google to drop a page. It is easy to leave one on after a staging launch. Remember that Google cannot see a noindex tag on a page that robots.txt blocks.

Finally check your XML sitemap. It should list only canonical, indexable, working URLs. Google says a sitemap does not guarantee crawling, but a clean one helps discovery. See crawlability and indexation for the detail.

Step three: structure, duplicates and links

Check how URLs are organised. Each page should have one preferred address. Variants with or without "www", with trailing slashes, with tracking parameters or with filter settings can create duplicates. Choose a canonical URL for each and redirect or declare accordingly, as Google's documentation on consolidating duplicate URLs describes.

Review internal links. Every page you want found needs at least one crawlable link, meaning an anchor element with an href. Look for orphan pages, long redirect chains and links that point to redirected or broken URLs. Google also advises descriptive anchor text over "click here".

For sites with millions of pages, check crawl budget. Google says its guidance applies to sites with about a million pages that change weekly, or about ten thousand pages that change daily. A small business site rarely needs to worry about it.

Step four: speed, mobile and security

Test the real-user numbers for Core Web Vitals: LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less. Google says field data is the one that counts, so use Search Console's report or PageSpeed Insights (both draw on the Chrome User Experience Report) before relying on a lab score. Our Core Web Vitals guide explains each metric.

Confirm the site works on a phone, uses HTTPS everywhere, and does not show intrusive pop-ups. Google's page experience guidance lists these as things to check, while stating that page experience will not outrank much more relevant content.

Check structured data too. Valid schema markup makes pages eligible for special display features, though Google says it does not guarantee them.

Step five: prioritise and fix

An audit that returns 300 issues helps no one. Sort findings by a simple rule: does it stop a valuable page from being indexed, ranked or converting? A blocked service page comes first. A missing alt text on a decorative image comes last.

Assign each fix to an owner with a date: developer, content editor or you. Group fixes into batches so you can see their effect. After each batch, re-crawl and check Search Console.

Write down what changed and when. Google says changes can take from a few hours to several months to show, so a dated log is the only way to connect cause and effect later.

Measuring and repeating the audit

Measure the audit by outcomes at the index level first: pages indexed, errors cleared, vitals improved. Business results follow more slowly, so treat them as a six-month question.

Set a monthly check of Search Console for new errors, and a full audit annually or after any platform change. Technical health decays quietly as pages, plugins and teams change.