Skip to content

24 October 2026 · Sirajia Sol

Technical SEO Audit Checklist: Step by Step

Cover image with the title Technical SEO Audit Checklist: Step by Step on a dark Sirajia Sol background

Good content and strong links cannot help a page that search engines cannot reach, render or index. Many traffic problems that look like content or authority issues turn out to be technical: a stray noindex tag, a redirect loop after a redesign, a sitemap full of dead URLs, or key content that only appears after JavaScript runs.

A technical SEO audit finds those problems before they cost you rankings and enquiries. This guide explains what a technical audit covers, the tools you need, and a step-by-step checklist you can work through in order, from crawl access to monitoring, along with how to prioritise the fixes.

What a technical SEO audit covers

A technical SEO audit checks whether search engines can do four things with your website:

  1. Crawl it: find and request your pages through links, sitemaps and robots.txt rules.
  2. Render it: load the page, including CSS and JavaScript, and see the same content a visitor sees.
  3. Index it: decide to store the page and choose the right version to show in results.
  4. Understand and serve it: work out what each page is about and show it to searchers on a fast, secure, mobile-friendly experience.

The audit does not judge whether your content is persuasive or your keyword targeting is right. That is the job of an on-page and content review. A technical audit makes sure the foundations are solid so that content and links can do their work.

When to run a technical SEO audit

Run a full audit at least once a year, and a focused audit at these moments:

  • Before and after a redesign or migration, including domain changes, HTTPS moves and CMS changes.
  • After a sudden drop in impressions, clicks or indexed pages in Google Search Console.
  • Before a major content or link building push, so new work lands on a healthy site.
  • When you take over a site from another team or agency and need to know what you inherited.
  • After a large release that changes templates, navigation, URL patterns or rendering.

Tools you need

You do not need a large tool stack. Most audits rely on a few free and paid tools:

Tool What it is used for
Google Search Console Indexing status, page reports, sitemaps, URL Inspection, Core Web Vitals, manual actions
Bing Webmaster Tools A second view of crawling and indexing, plus IndexNow submission
A site crawler (for example Screaming Frog or Sitebulb) Status codes, redirects, canonicals, titles, internal links, crawl depth, orphan pages
PageSpeed Insights Field and lab data for Core Web Vitals on specific URLs
Rich Results Test and Schema Markup Validator Structured data errors and eligibility
Server or CDN logs What search engine crawlers actually requested, and how often
Browser developer tools and curl -I Response headers, redirects and the raw HTML a crawler receives

Technical SEO audit checklist: 10 steps

Work through the steps in order. Problems early in the list, such as crawl and indexing blockers, can hide or cancel everything that comes after them.

1. Check crawl access and robots.txt

Start by making sure search engines are allowed to reach the pages you care about.

  • Open /robots.txt and confirm it loads and returns a normal status code.
  • Read every Disallow rule. Block only areas with no search value, such as admin pages, carts and internal search results.
  • Make sure CSS, JavaScript and image files needed to render pages are not blocked.
  • Check the robots.txt report in Search Console for fetch errors.
  • Decide deliberately which AI and search crawlers you allow, and check that your firewall or CDN bot settings match what robots.txt says.

Remember that robots.txt controls crawling, not indexing. A blocked URL can still appear in results if other sites link to it. To keep a page out of the index, allow crawling and use a noindex directive instead.

2. Review indexing in Google Search Console

The Pages report in Search Console shows which URLs Google has indexed and why others were left out. Look for important pages under reasons such as:

  • Excluded by 'noindex' tag: often caused by a CMS setting or a staging rule left in place after launch.
  • Crawled – currently not indexed and Discovered – currently not indexed: Google knows about the page but has not indexed it, which often points to thin or duplicate content, weak internal linking or low perceived value.
  • Duplicate without user-selected canonical and Google chose different canonical than user: signals about the preferred URL disagree.
  • Blocked by robots.txt for pages that should rank.

Use URL Inspection on a sample of key pages, such as service, product and category pages, to see the indexed version and test the live URL. Also check the X-Robots-Tag HTTP header with curl -I, because a server or CDN rule can add noindex without it appearing in the page source.

3. Audit your XML sitemap

A sitemap tells search engines which URLs you consider important. It should be clean enough to trust.

  • Include only canonical URLs that return a 200 status and are meant to be indexed.
  • Remove redirected, broken, noindexed and duplicate URLs.
  • Make sure new pages are added automatically when they are published.
  • Reference the sitemap in robots.txt and submit it in Search Console and Bing Webmaster Tools.
  • Compare the number of URLs in the sitemap with the number indexed. A large gap is worth investigating.

4. Fix status codes and redirects

Crawl the whole site and sort every URL by status code.

  • 4xx errors: fix or remove internal links to broken pages. Pages that are gone for good should return a real 404 or 410, not a 200 "page not found" template, which Google may treat as a soft 404.
  • 5xx errors: server errors waste crawl activity and can lead Google to slow its crawling. Find the cause with your developers or host.
  • Redirect chains and loops: each old URL should reach its final destination in a single 301 hop. Update internal links to point straight to the final URL.
  • Host versions: http, https, www and non-www versions should all resolve to one preferred version.

5. Check canonicals and duplicate content

Duplicate and near-duplicate URLs split signals and confuse search engines. Common causes include tracking parameters, filters and sorting options, printer versions, trailing slash variations, and the same product in several categories.

  • Every indexable page should have a self-referencing canonical tag pointing to its own clean URL.
  • Canonicals should point to live, indexable 200 URLs, never to redirects, 404s or noindexed pages.
  • Internal links, sitemaps, hreflang and canonicals should all name the same preferred URL.
  • In URL Inspection, compare the user-declared canonical with the Google-selected canonical. When they differ, find the conflicting signal.

Search engines discover and weigh pages largely through internal links.

  • Keep important commercial pages within a few clicks of the homepage.
  • Find orphan pages that exist in the sitemap or analytics but receive no internal links.
  • Use descriptive anchor text that tells users and search engines what the target page is about.
  • Make sure navigation and key links are plain HTML links with an href, not elements that only work with JavaScript click handlers.
  • Link from useful guides and blog posts to the service or product pages they support.

7. Test JavaScript rendering

If your site is built with a JavaScript framework, confirm that important content and links are present in the rendered HTML and, ideally, in the initial HTML response.

  • Compare the raw HTML from curl with the rendered HTML shown in URL Inspection's live test.
  • Check that titles, meta descriptions, canonicals, headings, body copy and internal links do not depend on client-side code that might fail.
  • Watch for content that loads only after user interaction, such as clicks, scrolling or tabs that fetch content on demand.

Server-side rendering or static generation removes most of these risks, which is one reason web development choices matter so much for SEO.

8. Measure page speed and Core Web Vitals

Speed affects both users and search. Google's Core Web Vitals measure loading, responsiveness and visual stability. The recommended "good" thresholds are:

Metric What it measures Good
Largest Contentful Paint (LCP) How quickly the main content loads 2.5 seconds or less
Interaction to Next Paint (INP) How quickly the page responds to input 200 milliseconds or less
Cumulative Layout Shift (CLS) How much the layout moves unexpectedly 0.1 or less

Start with the Core Web Vitals report in Search Console, which groups URLs by template using real-user data, then test sample URLs in PageSpeed Insights. Common fixes include compressing and resizing images, serving modern formats such as WebP or AVIF, setting image dimensions, reducing unused JavaScript, deferring third-party scripts, and using caching and a CDN.

9. Check mobile, HTTPS and security

Google mainly uses the mobile version of a page for indexing and ranking, so the mobile experience is the one that counts.

  • Confirm the mobile version contains the same content, links, structured data and metadata as the desktop version.
  • Check that text is readable and tap targets are usable without zooming.
  • Make sure every page loads over HTTPS with a valid certificate, and that there is no mixed content loading over HTTP.
  • Review the Security issues and Manual actions reports in Search Console.

10. Validate structured data and international setup

Structured data helps search engines understand your organisation, articles, products, services and breadcrumbs.

  • Test key templates in the Rich Results Test and the Schema Markup Validator.
  • Make sure markup matches the visible content on the page. Never mark up reviews, prices or details that users cannot see.
  • Keep organisation details, such as name, logo, address and social profiles, consistent across the site.

If your site serves several languages or countries, check that hreflang tags are reciprocal, use valid language and region codes, and point to canonical 200 URLs.

How to prioritise the fixes

An audit that lists hundreds of issues with no order is hard to act on. Score each issue by its impact and the effort needed to fix it:

Priority Typical issues When to fix
Critical Important pages blocked, noindexed, returning errors or redirecting incorrectly; site-wide rendering failures Immediately
High Canonical conflicts on key templates, redirect chains, sitemap errors, poor Core Web Vitals on commercial pages In the next sprint
Medium Orphan pages, weak internal linking, structured data warnings, duplicate titles Within the quarter
Low Minor issues on low-value pages, cosmetic warnings from tools When convenient

Fix problems at the template level wherever you can. One change to a product or blog template can solve thousands of URL-level warnings at once. Give each fix a clear owner, and record what changed and when so you can connect it to movement in Search Console.

Common technical SEO audit mistakes

  • Treating every tool warning as urgent. Crawler scores are a starting point, not a verdict. Focus on issues that affect pages that matter.
  • Auditing without Search Console data. A crawler shows what could be wrong. Search Console shows what Google actually did.
  • Ignoring JavaScript rendering. A page that looks fine in a browser can still be thin or empty to a crawler.
  • Producing a report and stopping there. The value of an audit is in the fixes. Work with developers to ship, test and confirm each one.
  • Skipping checks after releases. Many technical problems are introduced by redesigns, migrations and template changes long after the original audit.

After the audit: monitor and maintain

Technical SEO is not a one-off project. Set up a scheduled crawl, review the Search Console page indexing and Core Web Vitals reports each month, and add an SEO check to your release process so new templates and redirects are tested before they go live.

Once the foundations are healthy, content and authority work has a far better chance of paying off. Relevant links from SaaS link building and digital PR send more value to pages that search engines can crawl, index and understand.

How Sirajia Sol approaches technical SEO audits

Our SEO work starts with technical and on-page audits that prioritise what blocks crawling, indexing and conversion. We review your Search Console data, crawl and test your templates, and turn the findings into a ranked list of fixes with clear owners. Where the fixes involve your codebase, our web development team can ship them alongside your developers, and our content and brand team can strengthen the pages once they are indexable.

If you are comparing providers, our guide on how to choose an SEO agency lists the questions worth asking before you sign. When you are ready, contact our team to talk through a technical SEO audit for your site.

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 your website. It checks things like robots.txt, sitemaps, status codes, redirects, canonical tags, internal links, page speed, mobile rendering and structured data, then turns the problems it finds into a prioritised list of fixes.

How often should you run a technical SEO audit?

Most business websites benefit from a full audit once or twice a year, plus a focused check before and after any redesign, migration, CMS change or large release. Between audits, scheduled crawls and the Google Search Console reports help you catch new problems early.

How long does a technical SEO audit take?

A small brochure site can be audited in a day or two. Larger sites with thousands of URLs, JavaScript frameworks, several languages or a complex history of migrations take longer, because the crawl, log review and testing of each issue all scale with the size of the site.

What is the difference between a technical SEO audit and an on-page SEO audit?

A technical audit looks at the site's infrastructure: whether pages can be crawled, rendered and indexed, and whether they load quickly and correctly. An on-page audit looks at the content of individual pages, such as titles, headings, topic coverage and search intent. Most sites need both, but technical blockers should be fixed first.

Can I do a technical SEO audit myself?

Yes, for a small site. Google Search Console, PageSpeed Insights, the Rich Results Test and a desktop crawler cover most checks. Larger or JavaScript-heavy sites, migrations and sites with unexplained traffic drops usually benefit from a specialist who can read server logs and test fixes with your developers.