How to Do a Technical SEO Audit, Step by Step

A technical SEO audit is a structured check of whether search engines can crawl, render and index your site, and choose the right URL for each page. Work in a set order: indexing first, then robots.txt and sitemaps, crawl errors, canonicals, mobile rendering, page experience and structured data. Log each issue with an example URL and a priority. This guide is part of our technical SEO guide.

You'll need owner or full access to the site's Search Console property and a site crawler. A spreadsheet works as the audit log: one row per issue, with the affected URLs, the cause and who fixes it.

What a technical SEO audit checks

The audit follows the order Google works in. A page has to be found and crawled before it can be indexed, and it has to be indexed before anything else matters. Checking in that order stops you from polishing pages that Google never sees.

Steps

1. 01
   Confirm your key pages are indexed.

   List the pages that matter most, such as the homepage and service pages. Search Google for site: followed by each URL, then inspect each one in Search Console's URL Inspection tool. Note any that show "URL is not on Google". These are your top priority, because everything else in the audit is wasted on a page Google can't index.

2. 02
   Check robots.txt.

   Open yourdomain.com/robots.txt and read every Disallow rule. Make sure none blocks an important section or the CSS and JavaScript files your pages need to display. Google says robots.txt manages crawling and isn't a way to keep pages out of search. Our robots.txt and sitemap guide covers the rules in full.

3. 03
   Check your XML sitemap.

   In the Sitemaps report, confirm the sitemap shows the status Success. Then check what it lists. It should contain only full, canonical URLs that return a 200 status and are meant to be indexed. Redirected, noindexed and duplicate URLs send mixed signals. Remember that a sitemap is a hint to Google, not an instruction.

4. 04
   Crawl the site like a search engine.

   Run a crawler from the homepage and export every URL with its status code. Flag 4xx broken links, 5xx server errors and redirect chains, which Google says hurt crawling. Compare the crawl with your sitemap: pages in the sitemap but not found by the crawl have no internal links. On very large sites, also read about crawl budget.

5. 05
   Read the Page indexing report.

   Open the "Why pages aren't indexed" table and focus on reasons with the source "Website", since those are the ones you can fix. Decide for each reason whether it is expected, such as an intentional noindex, or a problem. Our guide to fixing indexing issues explains each status.

6. 06
   Check canonicals and duplicate URLs.

   Make sure each page can be reached at one address only. Test the HTTP and HTTPS versions, with and without www, and with and without a trailing slash. Each variant should redirect to the version you want. In URL Inspection, compare the user-declared canonical with the Google-selected one. Our explainer on canonical tags and duplicate content covers the signals.

7. 07
   Test mobile rendering and JavaScript.

   Google indexes the mobile version of your content, crawled with a smartphone crawler, and it renders pages by running their JavaScript. Run a live test in URL Inspection on each main template and view the tested page. Check that the main text, headings and internal links appear in the rendered HTML, and that nothing important exists only on desktop.

8. 08
   Check page experience and structured data.

   Open the Core Web Vitals report and note which page groups are flagged as poor or needing improvement. Confirm every page loads over HTTPS without mixed-content warnings. Run your main templates through the Rich Results Test, and check that any structured data matches what is visible on the page. Mark anything that fails as a fix, not a note.

Our schema markup guide shows which types fit a service business.

If you'd rather have the audit run and the fixes made for you, our in-house SEO team handles technical SEO, from site structure and metadata to structured data and performance. Every project is custom-quoted, and we'll send a quote within 24 hours.

How to prioritise what you find

An audit usually finds more issues than you can fix at once. Sort them by impact on the pages that matter, not by how many URLs are affected. Hundreds of thin tag pages with a minor warning matter less than one service page that can't be indexed.

A useful order is: first, anything that stops important pages being crawled or indexed. Second, anything that sends Google to the wrong URL, such as broken canonicals or redirect chains on key pages. Third, anything that wastes crawling at scale, such as endless filter URLs. Last, improvements such as page speed and markup errors on pages that are already indexed.

How often to audit

Our own practice is a full audit after any launch, redesign or migration, and lighter checks every quarter. Most technical problems are introduced by changes: a new template, a plugin update, a staging rule left in robots.txt. Checking soon after each change catches them before they spread.

Between audits, Search Console does much of the watching for you. It sends alerts when Google finds indexing or other issues on your site, and the Page indexing report shows trends over time. Our Search Console guide explains which reports to check and how often.

Troubleshooting

Important pages show 'URL is not on Google'

Cause: the page is blocked by robots.txt, carries a noindex rule, redirects elsewhere, is treated as a duplicate of another URL, or simply hasn't been crawled yet. The Page indexing section of the URL Inspection result names the reason.

Fix: open the inspection result and read the crawl and indexing details. If crawling is blocked, change the robots.txt rule. If indexing is blocked, remove the noindex tag or header. If Google chose another canonical, compare the two pages and strengthen your signals. Once fixed, run a live test to confirm the page is now indexable, then request indexing. Keep in mind that "URL is on Google" means the page is eligible to appear, not that it will rank.

The crawler and Search Console disagree

Cause: they measure different things at different times. A crawler fetches your site now and follows only the links it finds. Search Console reports what Google saw at its last crawl, including URLs it found elsewhere, such as old links from other sites. Search Console's live test also skips some checks, including duplicate detection.

Fix: check the last crawl date in URL Inspection. If you fixed the issue after that date, the report is simply out of date: run a live test and request indexing for the key URLs. If Search Console lists URLs your crawler never found, they are being discovered outside your internal links. Decide whether each should redirect, return 404 or be linked properly.

The crawl finds far more URLs than you have pages

Cause: your site creates new URLs for the same content. Common sources are filter and sort parameters, tracking parameters, calendar pages that go on forever, session IDs and printer-friendly versions. Each combination looks like a new page to a crawler, and Google may spend time crawling them instead of your real pages.

Fix: find the patterns in your crawl export by grouping URLs by parameter. Link internally only to the clean version of each page, and give the variants a canonical tag pointing to it. Where variants have no value in search at all, block that URL pattern in robots.txt, rather than relying on noindex, which Google still has to crawl to see. Then recrawl to confirm the count drops.