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. 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.

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.

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.

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

Which tools should a technical audit use?

Most audits combine a crawl of the whole site with Google's own data, which should carry the most weight:

  1. The Page indexing report, for what is and isn't indexed.
  2. The URL Inspection tool, which shows Google's indexed version of a page, runs a live test, and reports the canonical Google selected.
  3. The Crawl Stats report, which shows Google's requests, your server's responses and any availability problems.
  4. The Core Web Vitals, Security issues and Manual Actions reports, for performance and problems Google has flagged.

Third-party crawlers are valuable for spotting patterns across thousands of URLs, but a "site health" score isn't a Google metric. Google's guidance on hiring an SEO says it doesn't evaluate or endorse third-party SEO tools, which have no access to its internal ranking data. It suggests checking a tool's audit recommendations against official Google guidance before making significant changes.

How should audit findings be prioritised?

Every site has issues; what matters is which ones cost you visibility or enquiries. The same Google guidance says an SEO audit should give you realistic estimates of improvement and an estimate of the work involved. In practice, each finding should come with:

  1. Impact. Which pages are affected and how important they are. A template that has noindexed every service page matters far more than a broken link on an old blog post.
  2. Evidence. Search Console data or example URLs your developer can reproduce.
  3. Effort and owner. Who will fix it (your developer, your content team or the agency) and roughly how long it will take.
  4. How the fix will be confirmed. For indexing issues, that usually means the Page indexing report's Validate fix process, which Google says can take several days or longer.

To weigh fixes against each other in business terms, the SEO ROI calculator can estimate what extra organic enquiries would be worth.

How often should you run a technical audit?

Technical problems usually arrive with change, such as a redesign, new CMS or hosting move. Run a full audit before and after any site migration. Google's site move guidance recommends preparing a mapping of old URLs to new ones and keeping redirects in place for as long as possible, generally at least a year.

Between audits, indexing issues, Core Web Vitals and any security or manual action warnings should appear in your monthly SEO report.

What should you ask before paying for an audit?

  • What's in scope, and roughly how many URLs will you crawl?
  • Will you use our Search Console data? (Google suggests granting only read access at the audit stage; Search Console's restricted and full user permissions let you do that without handing over ownership.)
  • Will every finding be prioritised, with evidence and an effort estimate?
  • Do you implement fixes, or write specifications for our developers?
  • Can we see an anonymised sample audit?
  • Will you re-check the site after the fixes go live?

Our guides to questions to ask an SEO agency and how SEO pricing works, and the Academy lesson on evaluating proposals and red flags, cover the wider conversation.

A technical SEO audit checklist

  • robots.txt allows crawling of every section you want found
  • Important pages return a 200 status code and are indexed, and every exclusion is intentional
  • No stray noindex tags on live pages, and no noindexed pages blocked by robots.txt
  • Moved pages use permanent server-side redirects that point straight to the final URL
  • Duplicate URLs are consolidated with redirects or canonical tags
  • The mobile version has the same primary content as desktop
  • Key content and links appear in the rendered page in URL Inspection
  • Core Web Vitals are reviewed in Search Console by page group
  • Structured data is valid and matches visible content
  • The XML sitemap lists only canonical, indexable URLs
  • hreflang annotations are complete and reciprocal, if you target several languages or countries
  • No security issues or manual actions
  • Every finding has a priority, an owner and an effort estimate

The bottom line

A technical SEO audit should tell you, in plain language, whether Google can crawl, render and index the pages that earn your business money, what's stopping it, and which fixes matter most. Judge it on evidence and priorities, not page count. For a quick first look at a single page, try our free one-page SEO audit. When you're ready for a full review, browse agencies offering SEO audits and technical SEO, start with SEO agencies in Australia, or use Get matched to find a specialist who fits your site.