Most guides on how to conduct a technical SEO site audit hand you a 200-item checklist and call it a day. That’s the problem. A 200-item list produces a 40-page PDF that lands in a Slack channel, gets three thumbs-up emojis, and never becomes a single deployed change. A real audit isn’t a scan — it’s a diagnosis that ends with a ranked list of fixes tied to traffic and revenue. The scan is the easy 20%. Knowing which three findings out of ninety are actually costing you rankings is the job.
The failure mode of most audits is uniform weighting. A crawler flags 4,000 “missing meta descriptions” in red and one noindex tag on your highest-converting category page in the same shade of red. The engineer sees 4,001 problems, gets overwhelmed, and closes the tab. Missing meta descriptions cost you almost nothing — Google rewrites most of them anyway. The stray noindex is quietly deleting a page that earns real money. An audit that can’t tell those two apart is noise dressed as rigor. Everything below is built to separate the two.
The audit funnel: crawl, index, render, serve
Before any tool, hold one mental model. A page has to survive four gates in order, and a failure at gate one makes gates two through four irrelevant:
- Crawl — can a bot reach the URL and follow links to it at all?
- Index — once reached, is the page allowed and worthy to be stored in Google’s index?
- Render — when Google executes the page, does the content you care about actually appear?
- Serve — is the rendered page fast, stable, and structured enough to win the query?
The reason this ordering matters: a beautiful Core Web Vitals score on a page Google never crawls is worthless. Audit top-down. Every step that follows maps to one of these four gates, which is why learning how to conduct a technical SEO site audit in this sequence means you never waste time polishing pages that are already dead upstream.
Step 1 — Crawl like a search engine, then diff against reality
Run a full crawler (Screaming Frog, Sitebulb, or a hosted crawler) with a Googlebot user agent and JavaScript rendering enabled. The single most valuable output isn’t the crawl itself — it’s the diff between three numbers: URLs the crawler found, URLs in your XML sitemap, and URLs that get organic clicks in Search Console. When these three sets disagree, you’ve found something.
- In the crawl but not the sitemap → orphaned or faceted-nav pages diluting crawl budget.
- In the sitemap but not the crawl → internal linking gaps; nothing points to these pages.
- Getting clicks but in neither → a discovery leak worth investigating before anything else.
Watch specifically for crawl traps: faceted navigation (?color=red&size=m&sort=price) can generate tens of thousands of near-duplicate URLs from a 200-product catalog. That’s the most common way a mid-size site burns crawl budget without knowing it.
Step 2 — Separate “not indexed” from “can’t be indexed”
Open the Page Indexing report in Google Search Console and read it by reason, not by total. There’s a world of difference between two buckets. “Crawled – currently not indexed” and “Discovered – currently not indexed” are quality and crawl-budget signals — Google can index these pages but chose not to, usually because they’re thin, duplicative, or low-priority. That’s a content problem wearing a technical costume. In contrast, “Excluded by noindex,” “Blocked by robots.txt,” “Redirect error,” and “Soft 404” are hard technical blocks: pages Google physically cannot store. Fix the hard blocks first — they’re deterministic and often accidental (a noindex left over from staging is the classic). The “currently not indexed” bucket is slower and usually means the page needs to be genuinely better, not fixed with a tag.
Step 3 — Read your log files (the step most audits skip)
This is the step that separates a checklist audit from a real one. Your server access logs are the only ground truth for what Googlebot actually did — not what a tool estimates it might do. Pull 2–4 weeks of logs and answer three questions: Which URLs does Googlebot hit most (is it spending budget on your money pages or on faceted junk)? Which important pages has it not crawled in weeks (a freshness and discovery problem)? And what status codes is it receiving — a wall of 301s or 404s in the Googlebot rows means you’re wasting crawl budget on redirect chains. On a small site under a few thousand pages, crawl budget rarely bites and you can skip deep log analysis. Above that, or on any e-commerce site with faceted navigation, log files routinely reveal the single highest-impact fix in the entire audit.
Step 4 — Check what Google actually renders, not what you ship
If your site relies on JavaScript to inject content, the HTML your server sends and the HTML Google indexes can be two different documents. Use the URL Inspection tool’s “View crawled page” and “Live test” to see the rendered HTML Google holds, then compare it to your raw source. The failure you’re hunting for: primary content, internal links, or canonical tags that exist in the rendered DOM but not the initial HTML — or worse, that never render because a script errored. If your main copy only appears after a client-side fetch, treat that as a crawl-and-index risk, not a nice-to-have. A fast fix is server-side rendering or static generation for anything that has to rank.
Step 5 — Core Web Vitals with field data, per template
Only now — after you’ve confirmed pages are crawled, indexed, and rendered — does speed matter. Two rules save you from wasted effort. First, use field data (real users, from the Chrome UX Report in PageSpeed Insights or Search Console’s Core Web Vitals report), not lab data. Lab scores are a diagnostic; field data is what Google grades. Second, audit by template, not by page. Your product template, category template, and blog template each have distinct performance profiles; fixing the render-blocking script in one template silently fixes it across thousands of URLs. Target the published thresholds: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1. Miss on one template and you’ve likely got the same defect everywhere that template ships.
Step 6 — Audit for AI answer surfaces
Technical SEO now has a second audience: the crawlers behind AI Overviews, ChatGPT, and Perplexity. Three checks matter. Confirm your robots.txt isn’t accidentally blocking AI user agents you actually want to be cited by (some sites block them on purpose — decide deliberately). Confirm your key facts live in crawlable HTML, since most AI crawlers render JavaScript inconsistently or not at all. And structure content in self-contained passages — a clear question as a heading with a direct 40–60 word answer underneath — because extraction models lift passages, not whole pages. Clean structured data (FAQ, HowTo, Product, Organization) gives these systems machine-readable anchors to trust.
Step 7 — Prioritize by revenue at risk, not issue count
Here’s where the audit becomes a plan. Sort every finding into four buckets, in this order:
- Blocking — indexation or crawl failures on pages that earn or should earn traffic. Fix this week.
- High-impact pages — issues on your top 10–20 URLs by revenue or conversions, even if the issue is “minor.”
- Template-level — one fix that propagates across many URLs. High leverage, so it often outranks a bigger issue on a single page.
- Backlog — real but low-yield (the 4,000 meta descriptions). Batch it or automate it; never let it block the top three.
The organizing question for every finding is blunt: if I fix this, what changes in traffic or revenue, and how confident am I? A finding you can’t answer that for is a finding that goes to the backlog. This revenue-first triage is the difference between an audit and a to-do list.
A worked micro-example: 12,000 URLs, 3,400 that matter
Say a crawl of a home-goods store returns 12,400 URLs. The sitemap lists 3,400. Search Console shows 2,900 pages getting clicks. The naive read is “we have 9,000 pages to optimize.” The correct read: those 9,000 extra URLs are faceted-navigation combinations (?sort, ?filter) that shouldn’t be indexed at all. Log files confirm Googlebot spends 60% of its crawls on these dead-end parameter URLs. The fix isn’t 9,000 tasks — it’s one: canonical the facets to their parent category and add crawl directives for the low-value parameters. That single template-level change reclaims crawl budget for the 3,400 pages that actually sell, and you’d expect indexation of genuine pages to improve over the following weeks. Ninety findings collapsed into one decision — that is what knowing how to conduct a technical SEO site audit actually buys you.
The honest caveats nobody puts in the checklist
A few truths keep you honest. First, an audit tells you what’s broken, not what’s worth fixing — that judgment is yours, and it requires business context a crawler doesn’t have. Second, hosted crawlers cap out; a free crawl of a 500k-URL site samples, it doesn’t complete, so treat its counts as directional. Third, technical fixes rarely move rankings on their own — clean crawlability is table stakes that lets good content and links do their work, not a substitute for them. Chasing a green Lighthouse score on a site with nothing worth ranking is the most common way smart people waste a quarter. And the timeline is real: reindexing and re-evaluation after a fix routinely takes several weeks, sometimes longer on large sites, so resist declaring victory or failure in week one.
Where SEO Rocket fits the workflow
Running the diff-and-triage loop by hand across crawl exports, Search Console, and log files is where most teams stall. SEO Rocket runs a real-crawler site audit that surfaces the indexation, rendering, and Core Web Vitals issues in one place, then ties them to the pages that matter using rank tracking and competitor gap analysis — so the output is a prioritized fix list, not a raw dump. It’s the same discipline behind a playbook proven across 1,000,000+ ranking pages: audit top-down, fix what changes revenue, and re-crawl to confirm. With AI-visibility tracking alongside classic rankings, you can also see whether your fixes are earning citations in AI answers, not just blue links — at roughly $50/month with a free tier to start.
Frequently asked questions
How long should a technical SEO site audit take?
Budget half a day for a site under 500 pages and up to two days for a large or e-commerce site with faceted navigation. Most of that time is analysis and triage, not the crawl itself — the crawl runs while you work on something else. The report is fast; deciding which findings actually matter is the slow, valuable part.
How often should I run a full audit?
A full audit quarterly is a sensible cadence for most sites, with lightweight monitoring in between — watch the Search Console indexing and Core Web Vitals reports monthly, and audit immediately after any migration, redesign, or CMS change. Those events cause the most damaging technical regressions, and catching a botched migration in week one instead of month three is worth more than any scheduled audit.
Do I need paid tools to conduct a technical SEO site audit?
No, to start. Google Search Console (indexing, Core Web Vitals, URL inspection) and PageSpeed Insights are free and cover most of the diagnosis. A dedicated crawler and log-file access become worth paying for once your site is large enough that crawl budget and faceted navigation are real problems — usually a few thousand URLs and up.
Does technical SEO still matter with AI search?
More than before. AI crawlers are less tolerant of JavaScript-dependent content and messy markup than Googlebot, so crawlability and clean, passage-structured HTML directly affect whether your site gets cited in AI answers. A page an AI crawler can’t render is a page it can’t quote.
