Technical SEO Audit Checklist: How to Check Your Site Step by Step

Published October 16, 2026 · Last updated October 21, 2026 · By the WebSolutions LLC team

Great content cannot rank if search engines cannot find, crawl or understand the pages it sits on. A technical SEO audit checks the plumbing behind your website: which URLs exist, which ones Google can reach, which ones it chooses to index, and whether anything in the code, server or site structure is getting in the way. This checklist walks through a technical audit in the order we work through it, so a business owner or marketer can follow along and a developer can act on the findings.

You do not need paid tools to start. Most of the checks below use Google Search Console, your browser and a free crawler. Where a check overlaps with routine upkeep, we point to our website maintenance checklist so the fix becomes part of your normal schedule rather than a one-off project. If you are new to SEO, read our SEO basics for small business first; this checklist assumes you know how crawling, indexing and Search Console work.

What is a technical SEO audit?

A technical SEO audit is a structured review of the parts of a website that affect how search engines crawl, render and index it. It does not judge whether your copy is persuasive or whether you target the right keywords; that belongs to a content audit. Instead it answers practical questions: can Googlebot reach every important page, does each page have one clear address, does the site work on a phone, is it served securely, and does the code describe the page accurately? Google's own SEO Starter Guide is a good reminder that most of these basics are about making a site easy to understand, not about tricks.

Step 1: Collect your URL list

  • Crawl the site. Run a crawler over the live site to list every URL reachable through links, with its status code, title, meta description, canonical tag and H1.
  • Export what Google knows. In Search Console, open the Page indexing report and note how many pages are indexed and the reasons others are not.
  • Compare the two lists with your sitemap. Pages in the sitemap but not reachable by links are orphans. Pages Google indexed that you never meant to publish, such as test pages, filtered URLs or old campaign pages, need a decision: improve, redirect or remove.

Step 2: Crawling and robots.txt

  • Open /robots.txt. Make sure it is not blocking important sections, CSS or JavaScript files. A single stray Disallow: / left over from a staging site can hide an entire website.
  • Use robots.txt for the right job. Google explains that robots.txt manages crawler traffic and is not a mechanism for keeping a page out of Google. To keep a page out of search results, use a noindex rule or password protection, and do not block that same page in robots.txt, otherwise Google cannot see the noindex.
  • Check server errors. Look for 5xx responses and timeouts in your crawl and in the Crawl stats report. Repeated server errors slow down crawling and can be a sign that hosting needs attention.

Step 3: XML sitemap

  • List only canonical, indexable pages. Leave out redirects, error pages, noindex pages and duplicates. Every URL in the sitemap should return a 200 status.
  • Stay within the limits. Google's documentation sets a limit of 50MB uncompressed or 50,000 URLs per sitemap file; larger sites split into several sitemaps (Build and submit a sitemap).
  • Reference it and submit it. Add a Sitemap: line to robots.txt and submit the file in Search Console. If the sitemap is a static file, add each new page to it when you publish.

Step 4: Indexing and canonical URLs

  • One page, one address. The same content is often reachable at several URLs: with and without www, over HTTP and HTTPS, with tracking parameters or with a trailing slash. Pick one version, redirect the others and declare it with a canonical tag (Google: consolidate duplicate URLs).
  • Check that canonicals point to themselves. A common template bug makes every page canonicalise to the homepage, which tells Google that the inner pages are duplicates. Each page should normally reference its own URL.
  • Inspect key pages. Use the URL Inspection tool on your homepage and main service pages to see the Google-selected canonical, the last crawl date and whether the page is indexed.

Step 5: Redirects, broken links and status codes

  • Fix internal 404s. Update links in menus, footers and body copy so they point straight to the live page.
  • Shorten redirect chains. A link that passes through two or three redirects before landing wastes crawl time and slows visitors down. Point links and redirects at the final URL.
  • Use permanent redirects for permanent moves. When a page or a whole site moves, use 301 or 308 redirects. If you are changing host, domain or platform, follow our website migration checklist.

Step 6: Titles, descriptions and headings

  • Unique, descriptive titles. Google generates title links mainly from the <title> element, and recommends titles that are descriptive, concise and unique to each page (Influencing title links). Look for duplicates, empty titles and titles that just repeat the brand name.
  • Meta descriptions that summarise the page. They do not directly affect ranking, but a clear description can improve the snippet. Duplicate descriptions across many pages are a sign of a template problem.
  • One H1 per page. Logos and template elements are sometimes coded as H1 headings. Make the main page heading the H1 and use H2 and H3 for sections.

Step 7: Mobile, speed and rendering

  • Mobile parity. Google uses the mobile version of a site for indexing and ranking (mobile-first indexing), so content, links and structured data must be present on mobile, not only on desktop. A responsive design keeps the same content and URLs on every device, which avoids most parity problems.
  • Core Web Vitals. Check the Core Web Vitals report in Search Console and run key templates through PageSpeed Insights. Our website speed optimization guide covers how to fix slow pages.
  • JavaScript content. If menus, product lists or text only appear after scripts run, confirm with URL Inspection that the rendered HTML contains them. Google's JavaScript SEO basics explains how rendering works and which patterns to avoid.

Step 8: HTTPS and security signals

  • Serve every page over HTTPS with a valid certificate, and redirect HTTP to HTTPS.
  • Check for mixed content, where an HTTPS page loads images or scripts over HTTP.
  • Review the Security issues report in Search Console. Hacked content and malware warnings hurt both rankings and trust; our small business website security guide covers prevention and recovery.

Step 9: Structured data

Structured data, usually written as JSON-LD, helps search engines understand what a page is about: an article, an organisation, a breadcrumb trail, a product. Google's introduction to structured data explains the supported types and stresses that markup must describe content that is actually visible on the page. Validate your markup with the Rich Results Test and fix errors before adding new types.

Step 10: Accessibility overlaps

Many accessibility fixes also help search engines: descriptive link text, alt text on meaningful images, a logical heading order and real HTML buttons and links rather than clickable div elements. Our website accessibility checklist covers these in detail.

Turning findings into a fix list

An audit is only useful if it ends with a prioritised list. We sort findings into three groups. First, anything that blocks crawling or indexing of important pages, such as robots.txt mistakes, wrong canonicals or noindex on live pages. Second, issues that waste crawl effort or split signals, such as duplicate URLs, redirect chains and broken internal links. Third, quality improvements like titles, structured data and speed. Fix the first group immediately, schedule the second, and fold the third into your monthly routine. After changes go live, re-crawl the site and watch the Page indexing report over the following weeks, because Google needs time to recrawl and update its index.

If you would like a second pair of eyes, our SEO and web development services include technical audits and the fixes that follow. You can also read our FAQs or send us your website address.

Technical SEO Audit FAQs

Quick answers to common questions about technical SEO audits.

01

What is a technical SEO audit?

A technical SEO audit is a review of how search engines crawl, render and index a website. It checks robots.txt, sitemaps, status codes, redirects, canonical tags, mobile usability, page speed, HTTPS and structured data, and ends with a prioritised list of fixes.

02

How often should I run a technical SEO audit?

Run a full audit at least once a year and after any major change such as a redesign, a platform change or a move to a new domain or host. Between audits, check the Search Console indexing and Core Web Vitals reports monthly as part of normal maintenance.

03

Can I do a technical SEO audit myself?

Yes, for a small site. Google Search Console, PageSpeed Insights, the Rich Results Test and a free crawler cover most checks. Fixing what you find, such as template, server or redirect issues, often needs a developer.

04

Does robots.txt stop a page from appearing in Google?

No. Google states that robots.txt manages crawling and is not a way to keep a page out of search results. Use a noindex rule or password protection instead, and do not block that page in robots.txt or Google will not see the noindex.

05

What is the difference between a technical SEO audit and a content audit?

A technical audit checks whether search engines can access and understand your pages. A content audit checks whether the pages themselves answer the right questions, target the right topics and are accurate and up to date. Most sites benefit from both.