How to Do a Technical SEO Audit (Without Wasting 3 Months on a PDF Nobody Reads)

Here’s what happens at most agencies: they run Screaming Frog, export the results into a 120-page PDF, slap their logo on it, and call it a “technical SEO audit.” The document gets emailed. The client skims the executive summary. The PDF goes into a shared drive to collect digital dust forever.

Three months later, nothing has been fixed. The agency bills for another audit.

A real technical SEO audit isn’t a document. It’s a process. It identifies issues, quantifies their impact, prioritises fixes by what will actually move rankings, and translates findings into language that developers can act on. Here’s how to do one properly.

What You Need Before You Start

Tools

You don’t need a $10K enterprise tool stack. These cover 95% of what a technical audit requires:

Screaming Frog SEO Spider (free up to 500 URLs, ~$259/year for unlimited): The core crawling tool. Simulates how search engines crawl your site and reports on every URL, status code, redirect, canonical tag, meta tag, heading, and page resource it finds.

Google Search Console (free): First-party data from Google. Shows which pages are indexed, which are excluded and why, crawl stats, Core Web Vitals field data, and manual actions. This is the closest thing to Google telling you what’s wrong.

Chrome DevTools (free): Built into Chrome. Network tab shows resource loading order and timing. Performance tab reveals rendering bottlenecks. Elements tab lets you inspect live DOM vs. source HTML. You can’t do a serious technical audit without this.

PageSpeed Insights (free): Shows both lab data (Lighthouse) and field data (CrUX) for Core Web Vitals. The field data is what Google uses for ranking, so that’s the number that matters.

Ahrefs or SEMrush (from ~$129/month): For backlink data, keyword ranking baselines, and competitive analysis. You need to understand which pages carry the most SEO value before you can prioritise fixes.

Optional but useful: Screaming Frog Log File Analyser for server log analysis, Google’s Rich Results Test for structured data validation, and a staging environment for testing fixes.

Access

Before you start crawling, make sure you have:

• Google Search Console access (owner or full user level)
• Google Analytics access
• Server log access (or someone who can pull logs for you)
• FTP/hosting access or a developer who can implement changes
• The site’s robots.txt and XML sitemap URLs

Half the reason agency audits take so long is access delays. Get this sorted first.

The Audit Process: What to Check and In What Order

Order matters. Some checks depend on others, and you don’t want to spend an hour diagnosing a rendering issue that’s actually caused by a robots.txt block you’d have caught in step one.

Step 1: Crawl Directives and Access

Time: 15 minutes

Start with the gatekeepers, the files and tags that control whether search engines can access your content at all.

Robots.txt: Fetch your robots.txt (yourdomain.com/robots.txt) and read it line by line. Check for:

• Disallow rules that accidentally block important sections
• Missing Sitemap directive
• Different rules for different user agents (is Googlebot being treated differently?)
• Legacy rules that no longer apply

A single misplaced Disallow can deindex entire site sections. I’ve seen a robots.txt block on /blog that went unnoticed for four months. Four months of content that Google couldn’t crawl.

Meta robots tags: In your Screaming Frog crawl, filter for pages with noindex, nofollow, or none directives. Are any important pages accidentally noindexed? This is especially common after staging-to-production deployments where staging noindex tags come along for the ride.

X-Robots-Tag headers: Same as meta robots but delivered via HTTP header. Harder to spot because they don’t appear in the HTML. Check in DevTools (Network tab > Response Headers) or in Screaming Frog’s HTTP headers report.

Step 2: Indexation Status

Time: 30 minutes

Open Google Search Console > Pages (formerly Coverage). This report shows exactly how Google sees your site:

• Indexed pages: How many and which URLs. Compare this to the number of pages in your sitemap and the number found in your crawl.
• Excluded pages: Check every exclusion reason. The common ones:
  • “Crawled - currently not indexed”: Google found it but didn’t think it was worth indexing. Often a content quality signal.
  • “Discovered - currently not indexed”: Google knows the URL exists but hasn’t crawled it yet. May indicate crawl budget problems.
  • “Duplicate without user-selected canonical”: Google is choosing a canonical for you. You should be choosing it yourself.
  • “Duplicate, submitted URL not selected as canonical”: You specified a canonical, but Google disagrees. This needs investigation.
  • “Blocked by robots.txt”: something in your crawl directives is blocking this page.

The gap between “pages you want indexed” and “pages actually indexed” tells you how healthy your site is. A well-optimised site has 90%+ of its intended pages indexed. If you’re at 50%, you have a fundamental problem.

Step 3: Full Site Crawl

Time: 30-60 minutes (depending on site size)

Configure Screaming Frog to crawl your entire site. Use these settings:

• Respect robots.txt (crawl what Google sees)
• Render JavaScript (if your site uses JS frameworks)
• Crawl all subdomains (if relevant)
• Store HTML for deeper analysis

Once the crawl completes, systematically review:

Status codes: Filter for 4xx errors (broken pages), 5xx errors (server failures), and 3xx redirects. Every broken internal link is a dead end for crawlers and users.

Redirect chains: Any redirect that goes through more than one hop (A to B to C) is wasting crawl budget and diluting PageRank. Flatten them so every redirect points directly to the final destination.

Redirect loops: A to B to A. This crashes crawlers and prevents any of the involved pages from being indexed. Fix immediately.

Canonical tags: Every indexable page should have a self-referencing canonical. Pages with canonical tags pointing to other URLs should be intentional (pagination, parameter variants), not accidental.

Duplicate content: Check for pages with identical or near-identical title tags, meta descriptions, H1s, or body content. Screaming Frog’s “Duplicate” filters make this straightforward.

Step 4: Core Web Vitals and Performance

Time: 30 minutes

Check both lab and field data:

Field data (what matters for rankings): In Search Console > Core Web Vitals, review the pass/fail status across your pages. Google groups pages by similar structure, so a template-level issue (like a slow-loading hero image on all product pages) will show as a pattern.

Lab data (for diagnosing problems): Run your top 10 pages through PageSpeed Insights. For each failing metric:

• LCP > 2.5s: Check for unoptimised images (serve WebP/AVIF, use responsive srcset, lazy load below-the-fold images), render-blocking resources (defer non-critical CSS/JS), and slow TTFB (server response time).
• INP > 200ms: Check for heavy JavaScript execution on interaction. Common culprits: third-party scripts (analytics, chat widgets, ad tags), unoptimised event handlers, and large DOM size.
• CLS > 0.1: Check for images without explicit width/height, dynamically injected content above the fold, and web fonts causing layout shift on load.

Document both the score and the specific cause. “LCP is 4.1 seconds because the hero image is a 2.3MB PNG without responsive sizing” is actionable. “Page speed is slow” is not.

Step 5: Site Architecture and Internal Linking

Time: 30 minutes

Crawl depth: In Screaming Frog, check “Crawl Depth” in the Internal tab. Important pages should be within 3 clicks of the homepage. Pages at depth 5 or deeper get crawled less frequently and receive less internal link equity.

Orphan pages: Pages with no internal links pointing to them. These are invisible to crawlers following link paths. Cross-reference your sitemap URLs against your crawl. Pages in the sitemap but not found during the crawl are effectively orphaned.

Internal link distribution: Your most important pages should receive the most internal links. Export internal link counts from Screaming Frog and compare against your page priority. If your homepage links to a “careers” page more prominently than your primary service pages, your link equity is flowing to the wrong places.

Broken internal links: Every 404 link is a dead end. Fix these by updating the link target or removing the link. Don’t redirect unnecessarily. Update the source.

Step 6: Structured Data

Time: 20 minutes

Check existing schema: In Screaming Frog, review the Structured Data tab. What types of schema exist? Are they valid? Are they complete?

Validate against Google’s guidelines: Use Google’s Rich Results Test on your key pages. Valid schema that doesn’t meet Google’s specific requirements still won’t generate rich results.

Identify opportunities: Are there page types that should have schema but don’t? Common misses:

• Blog posts without Article schema
• Service pages without Service or Product schema
• FAQ sections without FAQ schema
• Local businesses without LocalBusiness schema (especially critical if you’re targeting local Map Pack rankings)

Step 7: Mobile and Rendering

Time: 20 minutes

Mobile usability: Search Console > Mobile Usability report flags pages with mobile issues. Common problems: text too small, clickable elements too close, content wider than screen.

JavaScript rendering: For JS-heavy sites, compare the source HTML (View Source) against the rendered DOM (Inspect Element). If critical content only appears in the rendered DOM, you’re dependent on Google’s rendering queue. Check the “JavaScript” tab in Screaming Frog to identify render-dependent content.

Mobile-first content parity: Does your mobile version contain the same content as desktop? Hidden content (tabs, accordions, “read more” expanders) is treated differently than visible content. Google says it indexes hidden content, but in practice, visible content carries more weight.

Step 8: HTTPS and Security

Time: 10 minutes

SSL certificate: Valid, not expired, covers all subdomains you use. Check with DevTools or an online SSL checker.

Mixed content: Pages served over HTTPS that load resources (images, scripts, stylesheets) over HTTP. Chrome DevTools Console flags these. They trigger browser security warnings and degrade user trust.

HTTP to HTTPS redirects: Every HTTP URL should 301 to its HTTPS equivalent. Test your homepage, a few inner pages, and www vs. non-www versions. All should resolve to a single canonical HTTPS version.

Prioritising Findings

You’ll come out of this audit with dozens of issues. Fixing them all at once isn’t realistic. Prioritise by multiplying two factors:

Ranking impact: How likely is this issue to be suppressing rankings or traffic?

• Critical: Blocking indexation of important pages (noindex errors, robots.txt blocks, canonical issues on money pages)
• High: Degrading crawl efficiency across the site (redirect chains, orphaned pages, crawl budget waste)
• Medium: Affecting user experience metrics (Core Web Vitals failures, mobile usability issues)
• Low: Missing opportunities (no structured data, suboptimal internal linking)

Scale: How many pages are affected?

An issue that affects 10,000 pages is more urgent than the same issue affecting 10 pages, even if the individual page impact is the same.

Create a grid: Critical + High Scale gets fixed this week. High + Medium Scale goes into the next sprint. Everything else gets queued.

Don’t want to run this audit yourself? Get a free teardown - we’ll do the crawl, categorise the issues, and deliver a prioritised fix list your dev team can action.

Presenting Findings to Dev Teams

This is where most audits fail, especially at enterprise scale where SEO recommendations compete with product roadmaps for developer time. A list of SEO problems in marketing language gets ignored by engineering teams. Translate:

Bad: “Optimise page speed on product pages.” Good: “Product page template loads a 2.3MB hero image synchronously. Implement loading='lazy' for below-fold images and serve WebP with responsive srcset. Estimated LCP improvement: 1.8s. Affects 3,200 product pages.”

For each finding, provide:

• What: Specific technical issue
• Where: Exact URLs or templates affected
• Why: Business impact (traffic, revenue, or ranking risk)
• How: Technical fix with implementation details
• Effort: Estimated dev time (S/M/L)

This isn’t extra work. It’s the difference between recommendations that get implemented and recommendations that get filed.

How Often to Audit

A full technical audit should happen:

• Quarterly for sites with active development (new features, content changes, platform updates)
• After every major site change (migration, redesign, CMS update, new feature launch)
• Whenever traffic drops unexpectedly: before blaming a Google update, rule out technical issues

Between full audits, monitor Search Console weekly for new crawl errors, indexation changes, and Core Web Vitals regressions. Most technical SEO problems announce themselves in Search Console before they show up in your traffic.

---

Want the full system? Read our complete Technical SEO guide.