The Technical SEO Audit Framework I Use on Every Site

I’ve audited a lot of websites. E-commerce stores, publishers with years of archives, even a government agency’s site.

Every one of them was different. The process I used wasn’t.

This is that process. Not a 200-point checklist. A technical SEO audit framework for finding the problems that actually cost traffic, in the order that matters.

Before You Open a Single Tool

Most audits go wrong in the first ten minutes, because people start crawling before they know what they’re looking for.

Three questions first:

• What’s the business goal? An e-commerce site needs its category and product pages indexed and fast. A publisher needs fresh articles discovered quickly. Priorities follow the goal.
• Has anything changed recently? Redesigns, migrations, CMS updates, new plugins. Most sudden problems trace back to a change someone forgot to mention.
• What does traffic look like over time? A slow decline and a sudden cliff point to very different causes.

Get these answers and the audit has a direction. Skip them and you’ll produce a long report nobody acts on.

Layer 1: Can Google Crawl the Site?

Start at the very bottom. If search engines can’t reach your pages, nothing above this layer matters.

• Robots.txt. Check it by hand. Look for rules blocking important sections, CSS, or JavaScript files. Here’s what robots.txt can and can’t do.
• Server responses. Crawl the site with a tool like Screaming Frog and look for 5xx errors, timeouts, and important pages returning 404. Here’s what each status code means for SEO.
• Crawl stats. Search Console’s Crawl Stats report shows how often Googlebot visits and how your server responds. A spike in errors here is a red flag.
• Crawl traps. Faceted navigation, calendar pages, and session parameters can generate endless URLs that waste crawler attention.

Layer 2: Are the Right Pages Indexed?

This is where most of the damage I’ve found actually lives.

Open Search Console’s Page indexing report and read the “Why pages aren’t indexed” section carefully. Then compare three lists:

1. The pages you want indexed (your sitemap, ideally)
2. The pages Google has indexed
3. The pages your crawler found

The gaps between those lists tell the story. Important pages missing from the index. Junk pages bloating it. Pages that exist but that nothing links to.

Check canonical tags, noindex directives, and redirect chains as you go. One misconfigured canonical can quietly remove an entire template’s worth of pages from search. If you’re already seeing the damage, follow how to diagnose a sudden drop in indexed pages.

Layer 3: Does Google See What Users See?

On sites that rely on JavaScript, the page a visitor sees and the page Google processes can be different things.

Use the URL Inspection tool in Search Console to view the rendered HTML for your key templates. Is the main content there? Are internal links present as real <a href> links? Are titles and canonicals the same as in the raw HTML?

If content only appears after a click, a scroll, or a script that fails, assume Google may miss it.

Layer 4: Is the Architecture Working?

Now look at how the site is organized.

• Click depth. Important pages buried five or more clicks from the homepage tend to get crawled less and rank worse.
• Orphan pages. Pages with no internal links pointing to them. Search engines struggle to find them and treat them as unimportant.
• Internal link distribution. Are your money pages receiving links, or is all the internal link equity flowing to the About page and tag archives?

Internal linking is big enough to deserve its own guide, so I cover it fully in internal linking as a ranking lever.

Layer 5: How Does the Site Perform?

Only now do I look at speed. Not because it doesn’t matter, but because a fast site that isn’t indexed is still invisible.

Check the Core Web Vitals report in Search Console. It uses real-user data, which is what Google actually evaluates. The “good” thresholds, measured at the 75th percentile of visits, are:

• LCP (loading): 2.5 seconds or less
• INP (responsiveness): 200 milliseconds or less
• CLS (visual stability): 0.1 or less

Group failing URLs by template. Fixing one template often fixes thousands of pages at once. The overlap between performance and user experience is covered in where UX and SEO actually overlap.

Layer 6: Enhancements

Structured data, hreflang for international sites, HTTPS consistency, and mobile parity. Important, but these are refinements. Fix layers 1 through 5 first.

The Part That Makes or Breaks the Audit: Prioritization

A finished crawl will hand you hundreds of issues. The audit’s real value is deciding which ones matter.

I score every issue on two things:

• Impact. How many important pages does it affect, and how badly?
• Effort. How hard is it to fix, and who needs to be involved?

High impact, low effort goes first. Always. A noindex tag on a key template might take a developer five minutes and recover thousands of visits. Rewriting 400 meta descriptions might take weeks and move almost nothing.

A short audit that gets fully implemented beats a long one that gets filed away. Six fixes shipped will do more than 180 findings nobody touches.

After the Audit

Record a baseline before any fixes go live: indexed pages, organic clicks, Core Web Vitals status. Then check again four to eight weeks after changes ship. Google needs time to recrawl, and without a baseline you won’t be able to prove anything worked.

New to the discipline? Start with what technical SEO is and what it isn’t, then see how it fits alongside the other three in the 4 pillars of SEO.