How to Do a Technical SEO Audit in 2026 (Step-by-Step)

Technical SEO issues are silent ranking killers. Great content can't rank if Google can't crawl or index it correctly. A technical audit surfaces the problems your content strategy can't solve — and most of them have clear, fixable causes.

What a technical audit covers

Technical SEO is the foundation everything else rests on. Content quality, backlinks, and on-page optimisation all depend on Google being able to access and index your pages correctly. A technical audit systematically checks whether that foundation is solid.

Technical issues cluster into four categories:

• Crawlability: can Google's bots access your pages? Are important pages accidentally blocked?
• Indexation: which pages are in Google's index? Which aren't, and why?
• Architecture: are URLs clean and consistent? Are redirects correct? Are canonicals set? Is internal linking effective?
• Experience: do pages load fast enough? Are they usable on mobile? Is structured data correct?

Tools you need

Free tools:

• Google Search Console: the authoritative source for indexation, coverage errors, Core Web Vitals, mobile usability, and structured data. If you haven't set it up, follow the GSC setup guide first.
• Screaming Frog SEO Spider (free up to 500 URLs): crawls your site like Googlebot, finding broken links, redirect chains, missing tags, duplicate content, and more. Download from screamingfrog.co.uk.
• Google PageSpeed Insights: measures Core Web Vitals and gives specific performance improvement recommendations for each URL.
• Google's Rich Results Test: validates structured data and previews how rich results would appear.
• Mobile-Friendly Test (now part of GSC's Mobile Usability report): checks if specific pages pass mobile usability requirements.

Optional paid tools:

• Screaming Frog paid (£149/year): removes the 500 URL limit, adds JavaScript rendering, custom extraction, and deeper reporting.
• Ahrefs Webmaster Tools (free for verified site): adds backlink data and a site audit crawler to your toolkit.

Step 1: Crawlability

Before anything else, confirm Google can access your site correctly.

Check robots.txt

Visit yourdomain.com/robots.txt in a browser. Read through it carefully. Look for Disallow: rules that might block important sections of the site — a misconfigured robots.txt is one of the fastest ways to accidentally block your entire site from Google. See the robots.txt guide for how to read and write these rules correctly.

Test your robots.txt in GSC: Settings → robots.txt → Open the tester. Enter specific URLs to verify whether they're blocked or allowed.

Crawl with Screaming Frog

Open Screaming Frog, enter your domain, and crawl. For sites under 500 URLs (most small business sites), the free version handles this completely.

Once the crawl finishes, check:

• Response codes: filter for 4xx (client errors — 404 Not Found is the most common) and 5xx (server errors). Any pages returning errors should be fixed or redirected.
• Blocked by robots.txt: the "Blocked by robots.txt" filter shows any pages the crawler couldn't access. Verify these are intentionally blocked.
• Blocked by noindex: pages with a noindex meta tag or header. Verify these are intentionally excluded from search.

Step 2: Indexation

In Search Console, go to Indexing → Pages. This shows the full picture of what Google has indexed and what it hasn't.

Work through each non-indexed state:

• Crawled — currently not indexed: high-priority for investigation. Google has assessed these pages and chosen not to index them. Click through to see which URLs and review the actual pages — thin content, near-duplicates, and low-quality pages commonly land here. Either improve the content or add a noindex tag if the page genuinely shouldn't be indexed.
• Not found (404): set up 301 redirects from the 404 URLs to the most relevant surviving page. Or, if the URL is correct and the page should exist, restore it.
• Page with redirect: pages that redirect to another URL. Google won't index the redirecting URL — check that it's redirecting to the right destination and that the destination is indexed.
• Alternate page with proper canonical tag: Google is indexing your canonical URL rather than this one. This is usually correct behaviour — verify the canonical is pointing where you intend.

Also do a spot-check: search "site:yourdomain.com" in Google. The approximate number of results shown is a rough estimate of indexed pages. Compare to the number of pages you believe should be indexed. A large discrepancy (far fewer results than expected) suggests an indexation problem.

Step 3: Redirects and canonical URLs

Audit redirects

In Screaming Frog, filter response codes for 3xx. Check for:

• 302 redirects where 301 was intended: permanent moves should always use 301. See the redirect guide for when each type applies.
• Redirect chains: A→B→C instead of A→C. These add latency and slightly dilute link equity. Consolidate by pointing the first URL directly to the final destination.
• Redirect loops: A→B→A. These cause errors for users and crawlers. Usually caused by conflicting redirect rules — investigate and resolve the conflict.

Audit canonical tags

In Screaming Frog, look at the "Canonical" tab. Check for:

• Missing canonicals: every indexable page should have a self-referential canonical tag. Pages without one are vulnerable to Google choosing the "wrong" canonical if duplicate or near-duplicate versions exist.
• Non-self-referential canonicals: a page pointing its canonical elsewhere tells Google to index the destination, not this page. Verify this is intentional — sometimes these are set incorrectly on pages that should be indexed themselves.
• Canonical chains: A canonicals to B, B canonicals to C. Should be A canonicals directly to C.
• Canonicals pointing to 404s or redirects: the canonical destination should be a live, 200-status URL.

Also verify that HTTP and www variants redirect to the canonical version. If your canonical domain is https://bisyri.co, then http://bisyri.co, https://www.bisyri.co, and http://www.bisyri.co should all redirect to https://bisyri.co (with the correct URL path appended).

Step 4: Page speed and Core Web Vitals

In GSC, go to Experience → Core Web Vitals. This shows which URLs are "Good", "Needs Improvement", or "Poor" for both mobile and desktop. The three Core Web Vitals Google measures are:

• LCP (Largest Contentful Paint): how long until the largest visible element loads. Good: under 2.5s. Caused most often by large images, slow servers, or render-blocking resources.
• INP (Interaction to Next Paint): how quickly the page responds to user interactions. Good: under 200ms. Caused by heavy JavaScript execution.
• CLS (Cumulative Layout Shift): how much the page layout shifts unexpectedly during load. Good: under 0.1. Caused by images without dimensions, late-loading ads, or dynamically injected content.

For each failing URL, run it through PageSpeed Insights for specific diagnostics. The "Opportunities" and "Diagnostics" sections tell you exactly what to fix. See the page speed guide for solutions to each common issue.

Step 5: Mobile usability

In GSC, go to Experience → Mobile Usability. Any URLs listed here have specific mobile usability problems that Google has identified. Common issues:

• Text too small to read: font size below 12px. Fix by increasing body text size.
• Clickable elements too close together: buttons or links with less than 8px spacing. Fix by adding padding or margin.
• Content wider than screen: horizontal scrolling required. Fix by using percentage-based widths and overflow:hidden on containers. See the web design mistakes guide for common causes.
• Viewport not set: missing <meta name="viewport"> tag. Add it to the <head> of every page.

Step 6: Structured data

In GSC, go to Search results → Enhancements (if your site has any structured data detected). This shows any structured data errors or warnings across your site.

Run individual pages through the Rich Results Test (search.google.com/test/rich-results) to:

• Verify the structured data is valid
• Preview how rich results would appear in search
• Identify any missing required fields or warnings

Common structured data issues: missing required properties, incorrect data types, marked-up content not visible on the page, and conflicting schema types. Fix errors before warnings — errors prevent rich results eligibility; warnings are improvements.

Use the schema generator to create valid JSON-LD markup for the schema types your pages need.

Step 7: On-page technical elements

In Screaming Frog's Page Titles and Meta Description tabs:

• Missing title tags: every page must have a unique title tag. Pages without one let Google choose — often pulling from on-page text, frequently suboptimally.
• Duplicate title tags: each page needs a unique title. Filter for duplicates and rewrite.
• Title tags over 60 characters: longer titles get truncated in search results. Aim for 50–60 characters.
• Missing meta descriptions: Google will write one if missing, but yours will typically be better targeted.
• Duplicate meta descriptions: each page should have a unique description.

In the H1 tab in Screaming Frog:

• Missing H1: every page should have exactly one H1. Google uses it as a strong signal for what the page is about.
• Multiple H1s: each page should have only one H1. Multiple H1s dilute the signal.
• H1 that doesn't match the title tag: H1 and title tag don't have to be identical, but they should be closely aligned. A completely different H1 creates confusing signals.

See the full on-page SEO guide for all the elements and how to optimise each.

Step 8: Internal linking

In Screaming Frog, the Inlinks tab shows how many internal links each page receives. Look for:

• Orphan pages: pages with zero internal links from other pages on the site. If Google can only reach them via the sitemap, they receive no link equity from your internal structure. Add relevant contextual links from other pages.
• Pages with very few inlinks: your most important pages (service pages, key blog posts, contact) should have multiple internal links pointing to them. A page with one inlink is poorly supported.
• Broken internal links: links pointing to 404 or redirected URLs. Fix the link destination to point directly to the correct live URL.

Check anchor text in the Anchor tab. Generic anchor text ("click here", "read more") provides less context to Google than descriptive anchors ("web design SEO mistakes"). Update where practical. See the internal linking guide for the full strategy.

Step 9: HTTPS and security

HTTPS is a confirmed (minor) Google ranking signal, and — more importantly — browsers mark non-HTTPS sites as "Not Secure", which destroys trust with visitors.

• Verify your SSL certificate is valid and not expiring soon: check the padlock in your browser on your own site
• Ensure all pages are served over HTTPS — Screaming Frog will flag any HTTP internal links or resources
• Verify HTTP redirects to HTTPS at the server level, not just via a plugin (server-level redirects are faster)
• Check for mixed content warnings: a page served over HTTPS but loading resources (images, scripts, fonts) over HTTP. Fix by updating resource URLs to HTTPS.

Prioritising fixes

A technical audit typically surfaces more issues than you can fix at once. Prioritise by impact:

1. Blocking issues (fix immediately): robots.txt blocking important pages, site-wide noindex tag, HTTPS not working, site returning errors
2. High impact (fix this month): pages not indexed that should be, 404 errors on pages with backlinks, Core Web Vitals failures on key pages, missing or duplicate title tags on top pages
3. Medium impact (fix over next quarter): redirect chains, missing canonicals, structured data errors, orphan pages with potential value, Core Web Vitals improvements on secondary pages
4. Low impact (fix opportunistically): missing meta descriptions on low-traffic pages, generic anchor text, title tags slightly over 60 characters

Document everything you find in a spreadsheet — issue type, affected URLs, priority, and fix status. A technical audit without a fix tracker often results in the same issues being re-discovered next year.

After implementing fixes, submit the affected URLs for recrawling in GSC (URL Inspection → Request Indexing) and resubmit your sitemap. Monitor the Coverage report over the following 2–4 weeks to confirm the issues are resolving.