The Technical SEO Audit Playbook

Why Technical SEO Audits Matter

A site can have excellent content and strong backlinks and still underperform in search because of technical issues. Slow page speed, duplicate content, crawl errors, broken redirects — these problems prevent search engines from efficiently indexing your content and distributing ranking signals correctly.

A technical SEO audit finds and prioritizes these issues. This playbook walks through the audit systematically, from the most fundamental checks to the more advanced.

Phase 1: Crawlability Audit

1.1 Check robots.txt

Navigate to yourdomain.com/robots.txt. Verify:

• The file exists and returns a 200 status
• You're not accidentally blocking important pages with Disallow rules
• The sitemap URL is included
• Googlebot is allowed access to CSS and JavaScript files (blocking them prevents rendering)

Common mistakes to look for:

# Accidentally blocking everything
User-agent: *
Disallow: /

# Or blocking JS/CSS which prevents rendering
Disallow: /static/
Disallow: *.js

1.2 Validate the Sitemap

Navigate to your sitemap URL (usually /sitemap.xml). Check:

• It returns a 200 status
• All URLs in the sitemap return a 200 (not 301, 404, or 410)
• The URLs match your canonical URLs exactly
• No pages you want to hide from search are listed
• <lastmod> dates are accurate (not always today's date)

Submit the sitemap in Google Search Console: Sitemaps → Add a new sitemap.

1.3 Crawl the Site

Use a crawl tool (Screaming Frog, Sitebulb, or Ahrefs Site Audit) to crawl your site the way Googlebot does.

Things to find:

• Broken internal links (4xx): Pages that link to non-existent URLs waste crawl budget and create dead ends
• Redirect chains: A → B → C is worse than A → C. Flatten all chains to a single hop
• Orphan pages: Pages in your sitemap but not linked from any other page
• Crawl depth: Pages more than 3–4 clicks from the homepage are rarely crawled efficiently

1.4 Check Crawl Budget Usage

In Google Search Console → Settings → Crawl Stats, you can see:

• Total crawl requests per day
• Response codes distribution
• File type distribution
• Googlebot's crawl rate over time

High percentages of 4xx or 5xx responses indicate your crawl budget is being wasted on broken pages.

Phase 2: Indexation Audit

2.1 Index Coverage Report

In Google Search Console → Indexing → Pages, you'll see:

• Indexed pages: Good
• Not indexed — Excluded by robots.txt: Intentional (verify it's correct)
• Not indexed — Redirect: These are sending signals to the redirect target, not the page itself
• Not indexed — Crawled, currently not indexed: Google crawled the page but chose not to index it (thin content, duplicate, quality issue)
• Not indexed — Discovered, not yet crawled: Google knows the page exists (from sitemap or links) but hasn't crawled it yet

"Crawled, currently not indexed" is the most actionable signal — these are pages that need content improvement.

2.2 Identify Duplicate Content

Duplicate content — the same content available at multiple URLs — dilutes ranking signals. Common sources:

HTTP vs HTTPS: Both versions should serve, with HTTP redirecting to HTTPS. Verify with:

curl -I http://yourdomain.com
# Should return 301 to https://yourdomain.com

www vs non-www: One should redirect to the other. Both must not be independently accessible. Set a canonical:

// next.config.ts
async redirects() {
  return [
    {
      source: '/:path*',
      has: [{ type: 'host', value: 'yourdomain.com' }],
      destination: 'https://www.yourdomain.com/:path*',
      permanent: true,
    },
  ];
}

Trailing slash: /page and /page/ should not both serve content. Pick one, redirect the other.

Query string variations: /products?sort=price and /products may serve identical content. Use canonical tags:

export const metadata: Metadata = {
  alternates: {
    canonical: '/products', // Points to the clean URL
  },
};

Pagination: /blog?page=2 needs either canonical pointing to page 1 (if content is very similar) or unique canonical per page.

2.3 Check for Soft 404s

A soft 404 is a page that returns HTTP 200 but contains no meaningful content. Google penalizes these in indexation.

Common soft 404 scenarios:

• Empty search results: yourdomain.com/search?q=asdfghjkl returns a "No results" page with HTTP 200
• Deleted user profiles that show a generic "User not found" message
• Empty category pages

Fix: return a proper 404 status for truly empty pages, or redirect to a relevant page.

import { notFound } from 'next/navigation';

export default async function SearchPage({ searchParams }: Props) {
  const { q } = await searchParams;
  const results = await search(q);
  
  if (results.length === 0) {
    notFound(); // Returns HTTP 404
  }
  
  return <SearchResults results={results} />;
}

Phase 3: On-Page Technical Audit

3.1 Title Tag and Meta Description Audit

Pull all pages from your sitemap and check:

• Every page has a unique <title> tag
• Titles are under 60 characters
• Every page has a unique meta description
• Descriptions are under 155 characters
• No titles or descriptions are auto-generated duplicates

3.2 Heading Hierarchy

Each page should have exactly one <h1> that contains the primary keyword. The <h2> through <h6> hierarchy should be logical (no skipping levels).

3.3 Image Alt Text

Every <img> element that contains meaningful content should have descriptive alt text. Purely decorative images can use alt="".

Run a Screaming Frog crawl filtered to images to audit alt text at scale.

3.4 Canonical Tag Audit

For every page, verify:

• A canonical tag is present
• The canonical points to the correct URL (not a redirect, not a 404)
• The canonical uses the same protocol and www/non-www as your canonical domain
• Self-referencing canonicals are present (a page's canonical points to itself)

Phase 4: Performance Audit

4.1 Core Web Vitals Field Data

In Search Console → Core Web Vitals, check your real-user data:

• What percentage of pages have "Good" CWV status?
• Which pages have "Poor" status? (Prioritize these)
• Is mobile data significantly worse than desktop? (Usually yes)

4.2 Page Speed Lab Data

Run Lighthouse (Chrome DevTools → Lighthouse tab) or PageSpeed Insights on:

1. Your homepage
2. Your highest-traffic landing pages
3. Your worst CWV pages from Search Console

Prioritize fixing:

• LCP over 4s: Almost certainly a hero image loading issue or slow TTFB
• INP over 500ms: Heavy JavaScript on the main thread
• CLS over 0.25: Images without dimensions, dynamic content insertion

4.3 Server Response Time (TTFB)

Test TTFB with WebPageTest from multiple geographic locations. Target under 600ms from all major regions.

If TTFB is high:

• Check database query performance (slow queries block server response)
• Enable CDN caching for static content
• Consider edge caching for SSR pages (Vercel edge, Cloudflare)

Phase 5: Structured Data Audit

5.1 Validate Existing Structured Data

Use Google's Rich Results Test (search.google.com/test/rich-results) on:

• Homepage (Organization schema)
• Blog posts (Article schema)
• Service pages (FAQPage schema)

Validation errors silently prevent rich results from appearing.

5.2 Check for Missing Schema Opportunities

5.3 Structured Data Coverage

Every page that can rank should have at minimum:

• BreadcrumbList schema (for all non-homepage pages)
• Page-type specific schema (Article for posts, Service for service pages)

Phase 6: Mobile Audit

6.1 Mobile Usability Report

In Search Console → Mobile Usability, check for:

• Touch elements too close together (buttons need 48px minimum tap area)
• Content wider than screen (horizontal scrolling)
• Text too small to read (minimum 16px body text)

6.2 Mobile Page Speed

Test specifically on mobile emulation in Lighthouse. Mobile scores are consistently worse than desktop — optimize for the worst case, not the average.

Audit Output: The Priority Matrix

After completing the audit, rank issues by:

Impact: How much does this issue suppress organic traffic?

• High: Blocks indexation, causes major CWV failures, creates duplicate content
• Medium: Reduces crawl efficiency, missing schema opportunities, moderate CWV issues
• Low: Minor optimization, edge cases

Effort: How long to fix?

• Quick: Under 2 hours (meta description update, adding schema, fixing a redirect)
• Medium: 1–5 days (implementing image optimization, fixing soft 404s systematically)
• High: Weeks+ (major architectural changes, redesign for CWV)

Address High Impact / Quick Effort issues first. Schedule Medium Effort issues. Evaluate High Effort issues against expected ROI.

Ongoing Audit Cadence

Monthly: Check Search Console for new crawl errors, coverage drops, or CWV regressions.

Quarterly: Full crawl with Screaming Frog, structured data validation on key pages.

After major releases: Run URL Inspection on changed pages, check for new redirect chains, validate sitemap accuracy.

Technical SEO is maintenance, not a one-time project. The companies that win in organic search treat it as an ongoing engineering discipline.