Technical SEO Audit: A Step by Step Guide for 2026

A technical SEO audit checks whether search engines can crawl, render and index your site, and whether real visitors get a fast, stable, secure experience once they land. You run it in five passes: indexing, crawl controls, site structure, page experience (Core Web Vitals) and on-page signals, then fix issues in order of how much traffic they block. This guide walks through each pass using the reports and thresholds Google publishes today.

What a technical SEO audit covers

Think of the audit as a health check on everything that sits underneath your content. Good writing cannot rank if Google never indexes the page, and a page that indexes fine can still lose visitors if it shifts around while loading. The table below is the scope we work to.

Before you start: goals and access

Decide what the audit is for. "Find out why new product pages take weeks to index" leads to different priorities than "improve mobile experience for paid landing pages". Write the goal down, then make sure you have:

• Google Search Console access, ideally a Domain property so you see every subdomain and protocol together.
• Analytics data so you can weigh each issue by the traffic and revenue of the pages it affects.
• Server access logs if the site is large. They show what Googlebot actually requests, not what you assume it requests.
• A crawler that can render JavaScript, so you see links and content the way a browser does.
• PageSpeed Insights for field data and lab diagnostics on individual URLs.

How to perform a technical SEO audit, step by step

Step 1: Read the Page indexing report

Start in Search Console with the Page indexing report. It lists every URL Google knows about and, for those not indexed, the reason. The reasons tell you where to look next:

• Discovered, currently not indexed: Google knows the URL but has not crawled it yet. On large sites this often points to weak internal linking or a server that responds slowly.
• Crawled, currently not indexed: Google fetched the page and chose not to index it. Check whether the page is thin or near identical to another one.
• Duplicate without user-selected canonical: Google sees the page as a copy and picked a different URL as the main version. Set canonicals deliberately.
• Excluded by noindex, blocked by robots.txt, soft 404, server error (5xx), redirect error: usually configuration mistakes, and usually the fastest wins.

Use the URL Inspection tool on a sample of affected pages to see the rendered HTML, the canonical Google selected and when it last crawled.

Step 2: Check robots.txt, noindex and sitemaps together

These three controls are often set by different people at different times, so they contradict each other. Check them as one system.

robots.txt. Google is clear that robots.txt manages crawler traffic and is not a way to keep a page out of Google. A blocked URL can still show in results if other pages link to it. Make sure it blocks only low value paths such as internal search results or cart steps, and never CSS or JavaScript that pages need to render.

noindex. Search the templates for noindex tags left over from staging. Then check the reverse problem: a noindex only works if Google can crawl the page and read it. Google states that a page with noindex must not be blocked by robots.txt, and that a noindex line inside robots.txt is not supported.

XML sitemaps. List only canonical, indexable URLs that return a 200 status. Google's sitemap rules are worth knowing because many plugins still generate fields it ignores:

• Each sitemap file can hold up to 50,000 URLs or 50 MB uncompressed. Split larger sets and group them under a sitemap index.
• Google ignores the priority and changefreq values.
• Google uses lastmod only when it is consistently accurate, so update it for real content changes, not on every deploy.

Submit the sitemap in the Sitemaps report and compare the number of submitted URLs with the number indexed. A wide gap sends you back to Step 1.

Step 3: Review site structure and internal links

Crawl the whole site and look at three things:

• Click depth. Pages that matter commercially should be reachable within a few clicks of the homepage. Deep pages get crawled less and earn less internal link value.
• Orphan pages. Compare the crawl against the sitemap and analytics. A page that appears in the sitemap but has no internal links pointing to it is hard for crawlers and users to find.
• URLs. Keep them readable, lowercase and stable. Avoid parameters creating endless duplicate versions of the same listing page.

Then check broken internal links (4xx), redirect chains (A to B to C) and redirect loops. Point every internal link straight at the final URL. If the site has been through a redesign or platform change, compare old URLs against the redirect map; missing redirects after a site migration are one of the most common causes of lost rankings.

Step 4: Run a page speed SEO audit with Core Web Vitals

Speed is now measured with Core Web Vitals, and one change matters if you are working from an older checklist: Interaction to Next Paint (INP) replaced First Input Delay (FID) as the responsiveness metric on 12 March 2024. FID is deprecated, so any audit template that still reports it is out of date.

The current thresholds, published on web.dev, apply at the 75th percentile of page loads, measured separately for mobile and desktop:

Work from field data first. The Core Web Vitals report in Search Console groups URLs by template, which tells you whether a problem lives in the product template, the blog template or the whole site. Then open a representative URL in PageSpeed Insights for the diagnostics.

Fixes that consistently move these numbers:

• Images: serve modern formats (WebP or AVIF) at the displayed size, give every image width and height, and do not lazy load the LCP image.
• Caching and CDN: set long cache lifetimes on static assets and serve them from a CDN close to your users.
• JavaScript: remove unused scripts, defer what is not needed for first render, and break up long tasks so the page can respond to taps quickly. This is where most INP problems are solved.
• CSS and HTML: minify, inline the small amount of critical CSS, and load the rest without blocking render.
• Server: a slow first byte delays everything after it. Check hosting, database queries and full page caching.

How much does this matter for rankings? Google says good Core Web Vitals align with what its core ranking systems seek to reward, and that there is no single page experience signal. Treat speed as one factor among many: it rarely lifts weak content, but it can decide close contests and it directly affects conversions.

If you need hands-on help here, our Core Web Vitals optimization service covers diagnosis and fixes at the template level.

Step 5: Check mobile experience and HTTPS

Google finished moving to mobile-first indexing in 2024; after 5 July 2024 it crawls sites with the smartphone Googlebot. What Google indexes is what your mobile page shows, so compare mobile and desktop versions for missing content, missing structured data or links that only exist in the desktop menu.

Two tools from older checklists are gone. Google retired the Mobile-Friendly Test and the Search Console Mobile Usability report on 1 December 2023. Use Lighthouse in Chrome DevTools to test mobile layout, tap targets and font sizes instead. You can also skip AMP: a fast responsive page does the same job without maintaining a second version.

For security, open the HTTPS report in Search Console. Every page should load over HTTPS, HTTP URLs should redirect to HTTPS in one hop, and no page should load mixed content such as images over HTTP. While you are in the page experience mindset, check for intrusive pop-ups that cover the main content on mobile.

Step 6: Check on-page technical signals

This overlaps with on-page SEO, but the checks are mechanical and belong in the audit:

• Every indexable page has a unique, descriptive title and meta description.
• One clear main heading per page, with a logical heading order below it.
• Canonical tags point to the correct, indexable, 200 status URL.
• Structured data validates in the Rich Results Test and matches what is visible on the page.
• Duplicate or near duplicate pages are merged, redirected or canonicalised.
• For multilingual sites, hreflang tags are reciprocal and point to indexable URLs.

Step 7: Check crawl activity on larger sites

For sites with thousands of URLs, open the Crawl Stats report (under Settings in Search Console). It shows total crawl requests, average response time, response codes and host problems such as failed robots.txt fetches or DNS errors. A rising response time or a spike in 5xx responses is a server problem before it is an SEO problem. Google notes that sites with fewer than a thousand pages usually do not need this report.

Prioritising what you find

An audit typically produces dozens of findings. Rank them by how much traffic they block, not by how many URLs a tool flags:

After each fix, use URL Inspection to request indexing for the most important pages and watch the matching Search Console report. Core Web Vitals field data uses a rolling 28 day window, so expect improvements to show gradually.

Common technical SEO mistakes

• Using robots.txt to hide pages. It stops crawling, not indexing. Use noindex or authentication.
• Still tracking FID. INP is the responsiveness metric; dashboards built before 2024 often still show FID.
• Testing only on a fast office connection. Field data from real users is what Google reports, and it is usually slower than lab tests on a developer laptop.
• Launching a redesign without a redirect map. Every old URL with links or traffic needs a one hop redirect to its closest new match.
• Auditing once. New plugins, scripts and templates reintroduce problems. A light monthly check of Search Console and a full audit after any major release keeps the site healthy.

Where Codeeo fits

Codeeo carries out technical audits as part of its digital marketing services, and because the same team builds websites and apps, the fixes are made in the code and templates rather than left as a report. Core Web Vitals work is handled through our dedicated Core Web Vitals service. If you would like a second opinion on your site, get in touch.