How to Run a Technical SEO Audit: A Practical Guide
A technical SEO audit checks that search engines can crawl your site, that the right pages are indexed and that pages load quickly for visitors. However good your content is, a page Google cannot reach will never rank. This guide covers the order to work in, the tools to use and how to prioritise what you find.
Preparing for the audit
An audit moves quickly when you know what you are looking for. Start by deciding which pages matter most: service pages, product categories, the contact page and your best-performing blog posts. That list makes it much easier to tell which problems are urgent.
These are the core tools you need:
- Google Search Console: indexing, crawl errors and performance data.
- PageSpeed Insights: real-user speed data and recommendations.
- A site crawler: to list every URL, status code and tag.
- Rich Results Test: to validate structured data.
Google's SEO starter guide briefly explains which question each of these tools answers. Reading it once clarifies the concepts you will use throughout the audit.
Crawlability: can Google reach your pages
The first question is simple: can search engine bots move around your site? Start with the robots.txt file. One wrong "Disallow" line can hide the whole site or an important folder.
Google's robots.txt introduction explains what the file does and does not block. One key detail: robots.txt blocks crawling, not indexing. To keep a page out of the index, use a noindex tag instead.
Next, look at internal linking. Orphan pages that receive no links from anywhere are hard to find, even if they appear in the sitemap. Give every important page at least one link from the main menu or from related content.
Indexing: are the right pages in Google
The page indexing report in Search Console is the most valuable data in the audit. It shows which pages are indexed and why the others are not. The most common statuses are:
- Crawled, currently not indexed: Google saw the page but did not find it valuable. The content may be thin or duplicated.
- Duplicate, Google chose a different canonical than the user: two pages are very similar and Google picked the one you did not want.
- Excluded by noindex tag: fine if intentional, urgent if it was added by mistake.
- Not found (404): pages that were deleted or moved.
If one of your important pages appears in these lists, inspect it with the URL Inspection tool. It shows when Google last crawled the page and which canonical it selected.
Canonical tags and duplicate content
When the same content is reachable at several addresses, Google decides for itself which one to show. This often happens with www and non-www versions, trailing slashes or filter parameters.
The fix is to declare your preferred address on each page with a canonical tag. Google's guide to consolidating duplicate URLs explains which method sends the stronger signal in each case. A permanent redirect is a stronger signal than a canonical tag.
On multilingual sites, each language version's canonical should point to itself. If the Turkish page's canonical points to the English page, the Turkish version can drop out of the index. We cover this in detail in our hreflang guide.
Redirects and status codes
Use the crawler to list status codes for every URL. These are the problems to look for:
- Redirect chains: if page A redirects to B and B to C, point A straight at C.
- Temporary (302) redirects: use 301 for permanent moves.
- Internal links to 404 pages: fix the link or redirect to the right page.
- Soft 404s: empty pages that still return a 200 code.
After a migration or redesign, make sure every old address redirects to its own matching new address. Sending everything to the homepage throws away most of the value the old pages had built up.
Mobile parity, HTTPS and structured data
Google crawls and evaluates sites using their mobile version. Content hidden on mobile may not count, even if it shows on desktop. Check that the mobile and desktop versions carry the same headings, text and structured data.
HTTPS is now a baseline expectation. Confirm the certificate is valid, that every HTTP address redirects permanently to HTTPS and that no page triggers mixed content warnings. If images or scripts still load over HTTP, browsers may show a security warning.
Structured data tells search engines plainly what a page is about. Check types such as Organization, LocalBusiness, Article and FAQ with the Rich Results Test. Broken markup will not usually harm you, but it does cost you the chance of a rich result.
Speed and Core Web Vitals
Core Web Vitals are the measurable part of page experience. The report in Search Console uses real-user data to show which groups of pages are slow. PageSpeed Insights gives both field data and lab recommendations for a single page.
The issues we find most often are oversized images, unnecessary third-party scripts and layout shifts caused by images without set dimensions. Our Core Web Vitals guide explains how to improve each metric.
Sitemaps
An XML sitemap tells Google which pages you care about. It should list only pages you want indexed, that return a 200 code and whose canonical is themselves. Remove redirected, noindexed and deleted addresses.
After submitting the sitemap in Search Console, compare the number of submitted and indexed pages. If the gap is large, find out which pages are being left out and why.
Prioritising your findings
An audit usually ends with a long list of issues. Rather than fixing everything at once, rank them by impact and effort:
| Priority | Example issue | Why first |
|---|---|---|
| Urgent | Wrong noindex or robots block on a key page | The page cannot rank at all |
| High | Canonical errors, redirect chains | Signals split and value leaks |
| Medium | Slow pages, missing structured data | Affects rankings and click-through |
| Low | Missing alt text, long titles | Fix in bulk, gradual impact |
After each fix, request recrawling with the URL Inspection tool in Search Console. Do not close an item until you have seen the fix live.
Metrics to track after the audit
An audit is not a one-off job; the real value appears when you track the effect of each fix. Once a month, record the number of valid indexed pages, impressions and clicks for key pages and the share of good URLs in the Core Web Vitals report.
For a quick start, scan your site with our free SEO checker. It reports titles, descriptions, canonical tags, schema and speed in one place. To get more out of the indexing and performance reports, read our Google Search Console guide.
Frequently asked questions
How often should I run a technical SEO audit?
For small sites that rarely change, two thorough audits a year are usually enough. Sites that publish often, sell online or are moving to a new design need a quick check after every major change. In between, reviewing the page indexing report in Search Console once a month catches problems before they grow. Comparing crawls before and after a redesign is especially valuable.
Do I need paid tools for an audit?
Not to get started. Google Search Console, PageSpeed Insights and the Rich Results Test are free and reveal most problems. On sites with hundreds of pages, a desktop crawler that lists every URL saves a great deal of time. What matters is not the tool itself but prioritising the findings properly and confirming afterwards that each fix actually went live.