A technical SEO audit checks whether search engines can crawl, render, index and understand your website, and whether your pages load and display well for users. You crawl the site the way a search engine does, compare that with what Google reports in Search Console, and fix the problems in order of impact. The steps below cover everything a thorough audit needs.
Technical SEO is the foundation for everything else. Great content cannot rank if Google can't reach it, chooses the wrong version of it or sees a broken page.
What is a technical SEO audit?
A technical SEO audit reviews the parts of a site that affect how search engines access and process it: robots.txt, indexing, canonical tags, redirects and status codes, internal links, URL structure, page speed, mobile display, JavaScript rendering, structured data and sitemaps.
It is not the same as an on-page or content audit, which looks at the content itself, such as topics, titles, headings and quality. A complete SEO audit usually combines three parts:
- Technical audit: can search engines access and understand the pages?
- Content audit: are the pages useful, up to date and well targeted? Remove or merge thin and outdated pages, and fill gaps.
- Backlink audit: which sites link to you, and are there problems? Google says most sites will not need its disavow tool; it is meant for sites with many spammy or artificial links that have caused, or are likely to cause, a manual action.
What tools do you need?
- Google Search Console: the Page indexing report, the URL Inspection tool and the Core Web Vitals report show how Google sees your site.
- A site crawler: a tool that visits every page and records status codes, titles, canonicals, links and more. Sitebulb is one example of a crawler built for technical audits, and SEO suites have their own, as our guide to the Semrush site audit shows.
- PageSpeed Insights for speed and Core Web Vitals on individual pages.
- Google's Rich Results Test for structured data.
Step 1: Crawl your site
Start with a full crawl. Compare the number of pages the crawler finds with the number in your sitemap and the number Google reports as indexed. Big gaps point you to the problems: pages that can't be reached through links, pages Google ignores, or URLs you didn't know existed, such as filtered or parameter versions.
Step 2: Check crawlability
Crawlers need to reach your pages before anything else can happen.
- robots.txt: check that your robots.txt file doesn't block important pages, CSS or JavaScript. Remember what it is for: robots.txt manages crawler traffic. Google warns not to use it to hide pages from search results, because a blocked URL can still be indexed if other pages link to it. Use a noindex tag or password protection instead.
- Crawlable links: Google can generally follow links only when they are
<a>elements with anhrefattribute that resolves to a real URL. Links that only work withonclickor other scripts may be missed. - JavaScript: Google crawls a page, renders it in a headless Chromium browser and indexes the rendered HTML. Google still recommends server-side rendering or pre-rendering, because it is faster for users and crawlers and not all bots run JavaScript. Use the URL Inspection tool's live test to see the rendered page.
Step 3: Check indexing
Open the Page indexing report in Search Console. It shows which URLs are indexed and groups the others by reason. Common reasons include:
- blocked by robots.txt
- excluded by a noindex tag
- duplicate, with Google choosing another URL as canonical
- redirects
- not found (404) or soft 404
- server errors (5xx) or blocked access (401 or 403)
- crawled or discovered, but currently not indexed
Some of these are expected. Focus on important pages that should be indexed but aren't. The URL Inspection tool shows the details for a single page, including the canonical Google selected.
Step 4: Find duplicate content and canonical issues
Duplicates are easy to create: http and https versions, with and without "www", trailing slashes, upper and lower case, tracking parameters and printer-friendly pages. Google says some duplicate content is normal and not a spam violation, but it groups duplicates and picks one version to show, which can split signals and make performance harder to track.
For each piece of content, choose one preferred URL and support it consistently with 301 redirects, a canonical tag, internal links and your sitemap. Google treats these as hints and may pick a different canonical if your signals conflict.
Step 5: Review your site's technical health
- HTTPS: every page should be served securely, with http redirecting to https.
- Status codes: important pages return 200, removed pages return 404 or 410 (Google treats them the same), and moved pages redirect with a 301, which Google treats as a strong signal that the target should be indexed.
- Redirect chains and loops: point redirects straight to the final URL.
- Server errors: when pages return 5xx errors, Google slows down crawling, and pages that keep failing are eventually dropped from the index.
- Platform: make sure your CMS, theme and plugins are up to date and supported.
Step 6: Analyse internal linking
Internal links help both users and crawlers find your pages and understand which ones matter most. Check for:
- broken links to pages that no longer exist
- orphan pages that no internal link points to
- important pages buried many clicks from the home page
- links that go through redirects instead of to the final URL
Google recommends descriptive anchor text that makes sense on its own, rather than "click here", without keyword stuffing.
Step 7: Review URL structure
Google's URL guidance recommends readable, descriptive words, hyphens rather than underscores to separate words, as few parameters as possible, no session IDs and consistent letter case, because Google treats "/APPLE" and "/apple" as different URLs. Don't change existing URLs just for neatness, though. If you do, redirect the old ones.
Step 8: Check mobile display and Core Web Vitals
Google uses the mobile version of a page's content for indexing and ranking, so check that mobile pages show the same content, structured data and metadata as desktop.
Then check Core Web Vitals in Search Console and PageSpeed Insights. Google's "good" thresholds are:
| Metric | Measures | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Responsiveness | Under 200 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability | Below 0.1 |
Google's page experience guidance also lists secure HTTPS serving, good mobile display, no intrusive interstitials, not too many ads and main content that is easy to find. Read more in our guide to Core Web Vitals.
Step 9: Validate structured data
Structured data tells Google what a page is about in a standard format and can make it eligible for rich results. Google recommends JSON-LD. Test key templates with the Rich Results Test and check the enhancement reports in Search Console for errors.
Step 10: Check sitemaps and on-page tags
- Sitemaps: list only canonical, indexable URLs that return 200, and submit the sitemap in Search Console. Google says a sitemap matters most for large sites, new sites with few links and sites with lots of video, images or news.
- Titles and descriptions: check for missing, duplicate or truncated title tags and meta descriptions.
- Meta keywords: skip them. Google says the meta keywords tag is not used by Google Search and has no effect on indexing or ranking.
How do you prioritise the fixes?
An audit can produce hundreds of warnings. Sort them by impact and effort:
- Critical: important pages that are blocked, noindexed, broken or redirected the wrong way.
- High: duplicate and canonical problems on key templates, poor Core Web Vitals on high-traffic pages, broken internal links.
- Medium and low: long redirect chains, missing descriptions, minor structured data warnings.
Fix template-level problems first, because one change can repair thousands of pages. Then check Search Console over the following weeks to confirm Google has picked up the changes.
How often should you audit?
Run a full technical audit before and after a migration, redesign or platform change, and a lighter check every few months. In between, keep an eye on the Page indexing and Core Web Vitals reports, which flag new problems early. For the wider marketing picture, see our guide to conducting a marketing audit.
Frequently asked questions
What is a technical SEO audit?
A technical SEO audit is a review of how well search engines can crawl, render, index and understand a website. It covers things like robots.txt, indexing status, canonical tags, redirects, status codes, internal links, page speed, mobile display, structured data and sitemaps.
What tools do you need for a technical SEO audit?
At a minimum, Google Search Console for indexing and Core Web Vitals data, and a site crawler that visits every page the way a search engine does. PageSpeed Insights and Google's Rich Results Test help with speed and structured data.
How often should you do a technical SEO audit?
Run a full audit before and after any site migration, redesign or platform change, and a lighter check every few months. Search Console's reports help you spot new problems between audits.
Is a technical SEO audit the same as an on-page SEO audit?
No. A technical audit looks at whether search engines can access and process your pages. An on-page or content audit looks at what is on the pages, such as the topics, titles, headings and quality of the content. A full SEO audit usually includes both, plus a backlink review.