Technical SEO audit: method and checklist

What is a technical SEO audit?

A technical SEO audit examines what helps or prevents search engines from finding, reading and indexing your pages. It covers the server, HTTP status codes, directives, site architecture, performance and JavaScript rendering. It is the first area of a full SEO audit, before semantics and backlinks. It checks how the rules of technical SEO are applied on a real site.

It answers three questions, in this order. Can the site be crawled? Can it be indexed? Is the technical experience up to standard? As long as the first is not settled, the other two are pointless.

Which tools and access should you prepare?

Gather access before launching any crawl. You need Search Console as a domain property, read access to GA4 and the back office. Add server or hosting access for the logs and the list of staging sites to exclude. Also ask for the history of redesigns and migrations.

Need	Tool	What it provides
Site crawl	Screaming Frog, Oncrawl, Sitebulb	HTTP status codes, depth, tags, duplicates, orphan pages
Google data	Google Search Console	Page indexing, crawl stats, Core Web Vitals, URL inspection
Performance	PageSpeed Insights, CrUX, Lighthouse	28-day field data and lab diagnostics
Crawler behaviour	Screaming Frog Log File Analyser, GoAccess	Pages actually visited by Googlebot, frequency, errors
Structured data	Rich Results Test, validator.schema.org	Validity of the markup and eligibility for rich results

Screaming Frog is a desktop crawler, free up to 500 URLs. Beyond that, an annual licence is required (publisher’s pricing page). Set it to Googlebot Smartphone and connect the Search Console, GA4 and PageSpeed Insights APIs. Then run two crawls: one without JavaScript rendering, one with it.

How do you carry out a technical SEO audit, step by step?

1. Rule out the blockers

First look at the Security and Manual Actions report in Search Console. A manual action or a hacked site comes before everything else. Then check that no staging site is indexed (site: query on the test domains). Protect it with a password rather than a noindex tag, which is often forgotten at go-live.

2. Check crawling

The robots.txt file must return 200 at the root and declare the sitemap. It blocks crawling, not indexing. To remove a page from the index, use noindex (Google’s introduction to robots.txt). Check that it does not block any CSS, JavaScript or image resources. The directives are covered in detail in our guide to the robots.txt file.

HTTP code	Expected	Action if present in bulk
200	Almost all linked URLs	None
301	As few as possible in internal links	Point links to the final URL, shorten chains
302	None on a permanent move	Switch to 301
404 / 403	None from an internal link or the sitemap	Fix the source link, or 301 if the page has traffic or backlinks
5xx	None	Urgent: Google slows down its crawling if the server responds poorly

Finally, check depth (in clicks from the home page) and orphan pages. An agency benchmark, not a Google rule: three clicks at most for a strategic page, no orphan strategic page.

3. Check indexing

Compare three counts: the indexable pages in the crawl, the Page indexing report and the pages that are actually useful to you. More indexed pages than expected signals junk URLs (parameters, filters, internal search). Fewer indexed pages signals a block, orphan pages or quality judged insufficient.

• a self-referencing canonical tag on every indexable page;
• a sitemap limited to indexable URLs returning 200, split beyond 50,000 URLs or 50 MB;
• the “Crawled – currently not indexed” and “Discovered – currently not indexed” reasons reviewed one by one;
• paginated pages on distinct URLs, each one canonical to itself: Google no longer uses rel=next and rel=prev (pagination best practices).

The causes of non-indexing and their fixes are explained in our article on Google indexing.

4. Measure performance and mobile

Metric	Good	Poor	Status
LCP (display of the largest element)	2.5 s or less	More than 4 s	Core Web Vital
INP (responsiveness to interactions)	200 ms or less	More than 500 ms	Core Web Vital
CLS (visual stability)	0.1 or less	More than 0.25	Core Web Vital
TTFB (server response time)	0.8 s or less	More than 1.8 s	Diagnostic

The three Core Web Vitals and their thresholds are defined by web.dev (Google); INP replaced FID on March 12, 2024. TTFB is not a Core Web Vital. Above 1.8 s, it is considered poor (web.dev article on TTFB). Rely on field data (CrUX, Search Console) rather than the Lighthouse score, and test a sample for each template.

On mobile, Google completed the switch to mobile-first indexing in October 2023 (Google Search Central announcement). Content missing from the mobile version is missing for Google: compare a mobile crawl with a desktop crawl. The optimisation levers are covered in our guide to Core Web Vitals.

5. Test JavaScript rendering

Compare the two crawls, with and without JavaScript: discovered URLs, content, links, tags. Check that the menu, the breadcrumb and the main content are in the initial HTML. The URL Inspection tool shows the page as Google rendered it. It replaces the old Google cache, removed in 2024.

A JavaScript framework without server-side rendering is a structural indexing risk, not a quick fix. See our article on JavaScript SEO.

6. Read the logs and the crawl budget

Server logs are the only factual data on what Googlebot visits. They become useful above roughly 1,000 pages; below that, Search Console is enough. A user agent can be faked: verify the identity of crawlers with a reverse, then forward DNS lookup. The IP ranges published by Google also help (official procedure).

In practice, crawl budget only concerns very large sites. Google cites three cases. More than a million pages updated every week. More than 10,000 pages that change every day. Many URLs in “Discovered – currently not indexed”. These numbers are rough estimates, not thresholds (Google’s crawl budget guide, updated on July 22, 2026).

7. Secure HTTPS, versions and structured data

All pages must be on HTTPS, with a valid certificate and no mixed content. The site exists in one version only: HTTP, www and trailing slash are unified with 301s. For structured data, validate the core set (BreadcrumbList, Organization or Person, WebSite) with the Rich Results Test and validator.schema.org. Structured data helps understanding and display. It is not a direct ranking factor.

How do you prioritise technical fixes?

Rank each finding by its impact and the effort needed to fix it. An accidental robots.txt block, missing titles or permanent 302s can be fixed in a few days. Internal linking, performance and JavaScript rendering are projects of one to three months.

Do not follow the order suggested by the crawler. It knows neither your strategic pages nor your traffic. Cross-check each alert with Search Console data before scheduling it. Once the technical base is sound, the semantic audit takes over on the content.

The technical SEO audit checklist

• No manual action, no security issue, no indexed staging site
• robots.txt returning 200, sitemap declared, no CSS, JS or image resource blocked
• No strategic page in Disallow or in noindex
• No 404, 403 or 5xx from an internal link or the sitemap
• No 302 on a permanent move, redirect chains shortened
• HTTP, www and trailing slash unified with 301s
• Self-referencing canonical on every indexable page
• Sitemap limited to indexable URLs returning 200, submitted in Search Console
• Gap between indexed pages and expected pages explained
• Strategic pages at three clicks at most, no orphan pages
• LCP, INP and CLS in the green at the 75th percentile, on mobile and desktop
• Identical content, tags and structured data on mobile and desktop
• Menu and main content present in the initial HTML
• Logs analysed and crawlers verified on sites with more than 1,000 pages
• Action plan with a priority, an owner and a deadline for each finding