A technical SEO audit checks whether search engines can find, crawl, render and index the pages that matter to your business, and whether anything on the site is getting in the way. A good audit ends with a short, prioritised list of fixes, each backed by evidence and an estimate of the work involved, not a 200-page export of tool warnings.
Here's what a technical audit should cover, which Google tools it should use, and what to ask before you pay for one.
What is a technical SEO audit?
Technical SEO deals with the site itself, rather than the words on each page or the links pointing to it. A technical audit is a structured review of that foundation, and often the first paid piece of work in an SEO engagement.
The baseline comes from Google. Its Search Essentials set out three minimum technical requirements for a page to be eligible for indexing: Googlebot isn't blocked, the page works (Google receives an HTTP 200 status code), and the page has indexable content. Google adds that meeting them doesn't guarantee a page will be indexed. Almost everything in a technical audit traces back to those requirements. For a refresher, see the Academy lesson on how search engines crawl, index and rank.

What should a technical SEO audit include?
A thorough audit covers these seven areas.
1. Crawling and access
Can Google reach the pages you care about? The auditor should review your robots.txt file, server errors and internal links, looking for two common mistakes:
- Using robots.txt to hide pages. Google says robots.txt is not a mechanism for keeping a web page out of Google. A blocked URL can still be indexed if other sites link to it, and because Google can't read the page, it may build the result's title from other text, such as the anchor text of those links. To keep a page out of results, use noindex or password protection instead.
- Links that aren't really links. Google can generally only crawl a link if it's an
<a>HTML element with an href attribute. Menus built another way can leave whole sections undiscovered.
On very large sites, the audit may also cover crawl budget. Google's crawl budget guide is aimed primarily at sites with more than a million unique pages that change about once a week, or 10,000+ pages that change daily. For most other sites, it says keeping your sitemap up to date and checking the Page Indexing report regularly is adequate. If an auditor spends pages on crawl budget for a 40-page business site, ask why.

2. Indexing
Which pages are indexed, which aren't, and why? The auditor should work from the Page indexing report in Search Console, which lists the reasons URLs weren't indexed. Google stresses that "not indexed" isn't necessarily bad: pages you've blocked on purpose, set to noindex, duplicates and removed pages are expected to be left out. The audit separates intended exclusions from mistakes, such as a noindex tag left on live pages after a redesign. Our guide to fixing pages Google hasn't indexed explains what each of those reasons means.
For noindex to work, the page must not be blocked by robots.txt, because the crawler has to be able to see the rule, and Google doesn't support a noindex rule placed in robots.txt itself. Our free Google Index Checker tests a single URL for these conflicts.

3. Status codes, redirects and duplicates
Every page you want found should return a 200 status code. If one returns 200 but looks like an error or an empty page, Search Console reports it as a soft 404.
When a page moves for good, Google recommends a permanent server-side redirect (a 301 or 308) whenever possible. Permanent redirects tell Google to show the new URL in search results; temporary ones tell it to keep showing the old one. The Redirect Checker shows every hop a URL takes.
The audit should also look for duplicate content, such as the same page reachable at several URLs. Google lists redirects and rel="canonical" annotations as strong signals for choosing a canonical URL and sitemap inclusion as a weak one, and it says not to use robots.txt for canonicalisation. Our guide to whether duplicate content hurts SEO explains what's worth fixing and what Google handles on its own. Check those tags against our guide to canonical tags and when you need them.
4. Mobile and JavaScript rendering
Google uses the mobile version of a site's content, crawled with its smartphone agent, for indexing and ranking. The audit should confirm the mobile version carries the same primary content as desktop.
If your site relies on JavaScript, the audit should check what Google actually renders. Google processes JavaScript web apps in three main phases: crawling, rendering and indexing. Content or links that only appear after scripts run need testing in the URL Inspection tool, not just a browser.

5. Page experience and Core Web Vitals
Core Web Vitals measure loading, responsiveness and visual stability. For a good user experience, Google suggests aiming for Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1.
The Core Web Vitals report in Search Console is based on real-world usage data from the Chrome UX Report, so it reflects what visitors actually experienced. A good audit groups problems by page template, because one slow template can affect thousands of URLs. Our guide to whether Core Web Vitals affect rankings explains how much weight Google gives these scores.

6. Structured data
Schema markup helps Google understand a page and can make it eligible for rich results. The audit should check that markup is valid and matches what's on the page: Google's guidelines say not to mark up content that isn't visible to readers, and Google doesn't guarantee rich results even when markup passes the Rich Results Test. Our Academy lesson on structured data basics explains more.
7. Sitemaps, international setup and security
- Sitemaps. An XML sitemap should list only canonical, indexable URLs, and a single sitemap is limited to 50MB uncompressed or 50,000 URLs.
- International sites. If you have pages for different languages or countries, each version must list itself as well as all other language versions in its hreflang annotations. Our Hreflang Checker tests a page's set, and our guide to ccTLDs, subdomains and subfolders covers how to structure country versions.
- Security and penalties. The Security issues report shows whether Google has found hacked content, malware or social engineering on your site, and the Manual Actions report shows whether Google's staff have found pages that don't comply with its spam policies, which can see them ranked lower or left out of results.





