How to Run a Technical SEO Audit Your Developers Will Actually Ship

Last October a mid-market retailer in Chicago paid a London agency $9,400 for a site audit. The deliverable was a 214-row spreadsheet. Color-coded. Severity ratings on every line. It even had a tab for image alt text with 4,100 rows in it.

Six months later their engineering team had shipped exactly none of it. Not one row.

Meanwhile, their entire collections directory carried a stray noindex rule left behind by a staging deploy. That was roughly 380 money pages. Gone from Google since August. Nobody noticed because paid search was covering the gap.

Here is the part that still bothers me. The audit caught it. Row 147. Filed as "medium" priority, wedged between a note about missing alt text and a tip to compress a background image. The crawler had flagged it with a yellow dot, so it got a yellow dot in the report.

That is the state of most technical SEO audits right now. Not wrong. Just useless. The findings were real, the ranking was arbitrary, and nobody with commit access ever read past row 20. This guide is about the other way to do it.

What does a good technical SEO audit actually deliver?

A good technical SEO audit delivers a short, ranked list of things that cost you money, each with proof of the cost and a fix a developer can ship this sprint. It is not a full inventory of every flaw on your site. Ten findings your team ships beat 200 findings that rot in a shared drive. The output is a decision, not a document.

Let me set the scope, because this post is deliberately narrow.

I am not going to re-teach you canonicals or status codes here. We have deep reference posts on each of those, and I will link them where they belong in the sequence. What almost nobody writes about is the part that actually decides whether an audit works. The order. The triage. The judgment call about whether a finding matters at all.

By the end you will have four things. A first-hour sequence that surfaces revenue-killing problems before lunch. A triage matrix that sorts technical SEO audit findings by money, not by crawler color. An honest read on which tools earn their license fee. And a reporting format that gets things merged instead of ignored.

Three opinions I will defend along the way. First, most findings on a typical site are cosmetic and worth precisely nothing. Second, severity ratings from your crawler are marketing, not analysis. Third, the single most valuable question in any audit is whether Google can see and index your money pages, and most reports bury that answer on page 40.

Your main objection is probably that thoroughness protects you. If the audit misses something, you look bad. I understand it. I will show you why that instinct is exactly what makes audits worthless.

Why do most technical SEO audit reports die in a spreadsheet?

Reports die because they are written to prove effort, not to drive a decision. A 200-row export with no revenue attached forces the developer to do the prioritization work. They will not do it. They will close the tab and go back to the roadmap. The technical SEO audit that ships is the one that asks for five things.

Think about who actually reads your report.

It is a backend engineer with 30 open tickets and a product manager guarding the sprint. They do not care about SEO. They care about whether your request beats the checkout bug in priority. When you hand them 214 rows, you have handed them a research project. You have made your problem their problem.

Here is the pattern, and it repeats at agency after agency. Beautiful audits. Genuinely thorough. Almost nothing shipped. Swap the deck for a single email with three bullets and a dollar figure, and suddenly most of the list gets built. Same site, same findings, radically different outcome.

Here is the trap nobody warns you about. Thoroughness feels like professionalism, especially when a client is paying for it. A thin report feels like you underdelivered. So consultants pad. They add the alt text tab. They add 40 rows about meta description length. It looks like value, and it quietly destroys the report's ability to do its only job.

The fix is uncomfortable but simple. Cap your report. Five findings for a small site, ten for a large one. Everything else goes in an appendix nobody has to read. If a finding cannot survive that cut, it was never going to be fixed anyway.

What should you check first in a technical SEO audit?

Check whether Google can fetch, render, and index your top 20 revenue pages. Nothing else comes first. Pull your money pages from analytics, run each through the URL Inspection tool in Google Search Console, and confirm the live index status. This takes 25 minutes and catches the failures that actually cost real money.

This is the whole ballgame, and it stuns me how often it gets skipped.

Start by listing the pages that make you money. Not your most-crawled pages. Not your biggest templates. The 20 URLs tied to revenue or leads. For an ecommerce brand that is top categories and best sellers. For SaaS it is the pricing page, the top comparison pages, and your best-converting blog posts.

Then, one by one, verify four things. Does the server return a 200 for Googlebot. Is the page allowed by robots rules. Does it self-canonicalize or point somewhere sensible. Does Google report it as indexed right now.

Before any of that, confirm the site resolves cleanly. A quick DNS record lookup to confirm your domain resolves as expected takes two minutes and rules out the class of problem that makes every other test lie to you. I have watched a team spend a day debugging "indexing issues" that turned out to be a stale A record on a legacy subdomain.

For a fast overall read before you go deep, run the site through our free website SEO score checker to get a baseline health snapshot. Treat that as orientation, not as the audit. It tells you where to point the microscope.

When something fails here, stop the audit. Seriously. Do not keep collecting findings. A noindex on 380 category pages is not a row in a spreadsheet. It is a phone call.

How do you crawl a site without drowning in data?

Crawl with a purpose and a limit. Configure the crawler to answer specific questions instead of exporting everything. On sites under 100,000 URLs, crawl the whole thing but only look at four reports first. On bigger sites, crawl by section. A full unfiltered export is how audits become spreadsheets nobody ships.

The default crawl is a firehose. That is by design, because tool vendors sell completeness.

My working setup is boring. I run Screaming Frog with JavaScript rendering off for the first pass, because I want to see what the raw HTML gives Google before I complicate the picture. I connect Google Search Console and analytics to the crawl so every URL carries clicks and impressions next to its technical data. That single step changes everything. Now a broken canonical on a page with 4,000 monthly clicks looks different from the same issue on a page with zero.

Four reports open first, in this order. Indexability status. Response codes. Canonical mismatches. Crawl depth of high-value URLs.

That is it. Everything else waits.

A realistic time budget

For a 20,000-URL site, expect roughly this. Crawl configuration and API hookup, 20 minutes. Crawl runtime, 30 to 60 minutes while you do something else. First-pass analysis of those four reports, about 90 minutes. Rendering checks, 45 minutes. Report writing, two hours. Call it a solid day, not a week.

If your crawl is taking six hours and producing 400 issue types, you have not been thorough. You have been undisciplined. Crawl a representative 5,000 URLs instead and move on. The pattern will show up. Site problems are almost always template problems, and templates repeat.

How do you tell a real problem from a cosmetic one?

Ask one question of every finding. If we fix this, what changes for a user or for Googlebot. If you cannot answer in one sentence with a mechanism, it is cosmetic. Missing alt text on decorative images changes nothing. A canonical pointing at a 404 changes indexing. Same crawler, wildly different stakes.

Crawler severity ratings are the single biggest source of wasted quarters in this industry.

Understand what those ratings are. They are a static lookup table. The tool does not know your business, your traffic, or your templates. It flags a 412-character meta description as an issue because a rule says descriptions should be shorter. It has no idea that page earns 30 percent of your revenue and ranks first anyway.

Here is my honest list of findings that are almost always cosmetic on a healthy site. Meta description length. Alt text on decorative imagery. H1 count on pages that already rank. Missing Open Graph tags on internal pages. Low word count on pages that intentionally have low word count, like a shipping policy.

And here is what is almost always real. Anything blocking indexation of a page you monetize. Anything that makes primary content invisible without JavaScript. Anything that returns the wrong status code at scale. Anything that traps a crawler in infinite URL space. Anything that ruins page load for mobile users on 4G.

Title and description quality does matter for click-through rate on pages that already rank, and it is genuinely cheap to fix. If you want to check that layer properly, run the page through our meta tag analyzer to see exactly what search engines read from your head section. Just be honest about the tier it belongs in. It is a CTR lever, not a crawl fix, and it belongs in a different sprint.

How do you prioritize findings by impact and effort?

Score every finding on two axes. Revenue at risk, and engineering hours to fix. Anything with high revenue at risk goes first regardless of effort. Then take the cheap wins. Then argue about the rest. Never sort a technical SEO audit by the crawler's severity column, because that column knows nothing about your money.

This is the framework to use on every engagement. It fits on a napkin.

Tier	Test it must pass	Typical examples	When it ships
P0. Bleeding	Money pages are not indexable or not reachable right now	Stray noindex, robots block on key paths, 5xx at scale, canonical pointing off-site	Today. Escalate by phone, not by ticket
P1. Structural	A whole template or section loses visibility or wastes crawl	Broken redirect chains after a migration, primary content behind client-side rendering, infinite faceted URLs	This sprint
P2. Compounding	Fix improves performance on pages that already earn	Slow LCP on category pages, weak internal links to money pages, deep crawl paths	Next quarter, batched
P3. Hygiene	Nice to have, no mechanism tied to revenue	Alt text, meta length, orphan tag pages, minor markup validation	Appendix. Maybe never

Methodology note, because it matters. Revenue at risk is estimated from actual data, not vibes. I take the affected URLs, pull their trailing 90-day clicks and conversion value from analytics, and multiply by the share I think is genuinely at risk. If category pages worth $40,000 a quarter are deindexed, that is a P0 with a number attached. If a finding touches URLs worth nothing, it cannot be a P0 no matter what color the crawler painted it.

That dollar figure is your entire lobbying strategy with engineering. "Canonical misconfiguration" loses to a checkout bug every time. "$40,000 a quarter, one line change" wins.

Which crawl and index checks belong in the first hour?

Four checks own the first hour. Robots rules, status codes, canonical logic, and sitemap accuracy. Together these decide whether Google can find, fetch, and keep your pages. Every other technical topic is downstream of these four. Get them right and most sites stop having mysterious indexing problems.

I will keep each of these short, since we have full reference posts on all of them.

Robots and noindex. Check the live robots file and the page-level directives on your money pages. The classic disaster is a staging rule that survives a deploy. Also watch for the opposite error, where a team blocks a path in robots and expects that to remove pages from the index. It will not. Our guide to robots.txt and noindex explains exactly when each directive works and why mixing them backfires.

Status codes. Confirm that live pages return 200, dead pages return 404 or 410, and moved pages return 301. Soft 404s are the sneaky one, where a page returns 200 but shows an empty state. Google treats those as junk. The reference on HTTP status codes for SEO covers which codes preserve ranking signals.

Canonicals. Look for pages that canonicalize to a different page, to a redirect, or to a broken URL. Set the canonical link element to point at the primary URL and be consistent about protocol and trailing slash. Details live in our canonical tag guide for fixing duplicate content properly.

Sitemaps. Your sitemap should list only indexable, canonical, 200-status URLs. Nothing else. A sitemap full of redirects and noindexed pages actively degrades trust in the file. Our XML sitemap and Indexing API guide covers submission and freshness signals, and if the file itself is a mess, our XML sitemap generator builds a clean file in a couple of minutes.

How do you audit JavaScript rendering without being a rendering expert?

Compare what the raw HTML contains against what the rendered page contains. If your product copy, links, or prices only exist after JavaScript runs, you have a real risk. Crawl once with rendering off and once with it on, then diff the word counts and link counts. Large gaps on money pages are a P1 finding.

You do not need to understand hydration to run this test.

The practical method takes 20 minutes. Run your crawler in text-only mode, export word count and outlinks for your top templates. Run it again with rendering enabled. Compare. A product page showing 90 words unrendered and 1,200 words rendered is telling you something important. So is a category page with 4 links unrendered and 60 rendered.

Google does render JavaScript. That is not in dispute. The issue is that rendering is queued, it costs Google resources, and it fails in ways that are hard to see. On a small site it usually works out. On a large ecommerce catalog it is one of the more expensive risks you can carry. The full mechanics are in our JavaScript SEO guide covering rendering, indexing, and the fixes that hold up.

One honest caveat. If your rendered and raw versions match closely, close this tab and move on. Plenty of practitioners burn days here because rendering feels advanced and important. It is only important when it is broken.

When does page speed deserve a slot in the audit?

Page speed earns a slot when your real users are failing the thresholds on pages that already rank and convert. Google defines good as an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, measured at the 75th percentile of page loads. Field data decides. Lab scores do not.

Those exact thresholds come straight from Google's own guidance in the web.dev Core Web Vitals documentation, and the 75th percentile detail is the part people skip. It means your median user experience is irrelevant. Your slower quarter of visits decides the verdict.

Here is the contrarian position, and it is an unpopular one to sell. Speed is rarely the reason a page does not rank. It is often the reason a ranking page converts badly. Those are different problems with different budgets, and conflating them is how you end up asking for a six-week performance project to fix a ranking issue caused by a canonical.

So in the technical SEO audit, treat speed as a P2 unless the field data is genuinely bad on money pages. Pull real user data from the Chrome UX Report through PageSpeed Insights rather than trusting a Lighthouse score from your office fiber connection. Lighthouse is a debugging tool. CrUX is the scoreboard.

The cheap wins are usually asset weight and render blocking. Start by measuring payload, and our HTML minifier shows how much dead weight your markup carries, which is a useful data point to bring to the engineering conversation even though markup is rarely the main offender. For the deeper strategy, our Core Web Vitals guide breaks down LCP, INP, and CLS with realistic fixes.

How do you audit architecture and internal links?

Measure how many clicks it takes to reach your money pages from the homepage, and how many internal links point at them. If a page earning $10,000 a month sits five clicks deep with three internal links, that is a finding worth real money. Architecture is the highest-leverage technical work on most sites, and it is chronically ignored.

This is where I would spend my second hour on almost any site.

Sort your crawl by crawl depth, then filter to URLs with clicks. Anything valuable sitting deeper than three clicks deserves a look. Then sort by unique inlinks. Money pages with fewer inlinks than your privacy policy tell a clear story about what your navigation actually prioritizes.

A Dutch retailer we looked at had their best-margin category at depth five, reachable only through a filtered menu. We added it to the main navigation and linked it from four high-traffic guides. No other changes. Impressions on that cluster climbed steadily over the next two months and the category moved from position 14 to the top five for its main term. Total engineering time was under three hours.

Two deeper reads if this is your bottleneck. Our site architecture guide shows how to flatten crawl depth on large sites, and our internal linking strategy post covers how to push authority at pages that earn.

Watch for orphan pages too. A page in your sitemap with zero internal links is a page you have told Google to value and told your own site to ignore. Google notices the contradiction.

Is crawl budget a real problem for your site?

Almost certainly not. Google states that crawl budget optimization matters for large sites with over one million unique pages updating weekly, or medium sites with over 10,000 unique pages updating daily. Under that, the concern is mostly imaginary. Chasing crawl budget on a 900-page site is theater.

I want to be precise here, because this myth wastes enormous amounts of time.

Google's documentation on managing crawl budget for large sites, last updated in December 2025, is explicit about who this applies to. It names large sites with one million or more unique pages and content that changes moderately often, roughly weekly. It also names medium or larger sites with 10,000 or more unique pages and very rapidly changing content, meaning daily. The doc calls these rough estimates, not hard lines.

So if you run a 2,000-page B2B site and someone sells you a crawl budget project, ask for the arithmetic.

That said, crawl waste is real when your site generates infinite URLs. Filter combinations, sort parameters, session IDs, and calendar pages can manufacture millions of URLs from a small catalog. That is not a crawl budget problem in the abstract. It is a URL generation problem, and it shows up in our faceted navigation guide on stopping crawl traps before they eat your site.

If you genuinely qualify by size, the only honest way to study crawl behavior is server logs. Everything else is inference. Our log file analysis guide shows what Googlebot actually does on your site, which is often nothing like what you assume.

Which tools do you actually need for a technical SEO audit?

You need a crawler, Search Console, and field performance data. That is the core. Screaming Frog costs 199 pounds a year and crawls 500 URLs free. Search Console is free and non-negotiable. Everything beyond that is convenience, scale, or reporting polish that your client sees and your findings do not need.

Honest assessments of what each tool is actually good for, and where it lets you down.

Tool	Best at	Where it disappoints	Cost
Google Search Console	Ground truth on indexing. URL Inspection is the only tool that tells you what Google actually did	Sampled data, slow reporting lag, 1,000-row export limits in the interface	Free
Screaming Frog	Flexible crawling, API integrations, custom extraction. Still the practitioner default	Desktop memory limits on huge sites. The interface is genuinely intimidating for beginners	199 pounds per user per year. Free to 500 URLs
Sitebulb	Explaining findings. Its hints teach juniors why something matters	Slower crawls. The guidance can encourage checklist thinking	Subscription, priced per project volume
Ahrefs and Semrush Site Audit	Scheduled monitoring and client-facing dashboards	Generic severity scoring. Bundled into suites you may buy for other reasons	Included in standard suite subscriptions
Botify, OnCrawl, JetOctopus	Enterprise scale, log integration, millions of URLs	Quote-based sales cycles. Overkill below roughly 500,000 URLs	Enterprise quote
Lighthouse and PageSpeed Insights	Diagnosing why a page is slow, plus CrUX field data	Lab scores mislead. People optimize the score instead of the experience	Free

The Screaming Frog figure comes from their official SEO Spider pricing page, which lists 199 pounds per year per user, shown as 245 euros for European buyers, with a free tier capped at 500 URLs. For a solo consultant in the US or the EU, that is the best money in this industry. One found noindex pays for a decade of it.

Chrome DevTools deserves a mention too, and it is free. The network panel and the disabled-JavaScript view answer more audit questions than most paid features. If you want the wider landscape, our roundup of the best SEO tools compares the full stack honestly.

How do you handle a multi-country site?

Audit each market as if it were a separate site, then audit the connections between them. A US and EU setup adds failure modes that single-market sites never see. Wrong language versions indexed in the wrong country, duplicate content across near-identical English variants, and return tag errors that silently disable the whole cluster.

European operators feel this more than anyone.

A typical setup covers the US, the UK, Germany, France, and the Netherlands. That is five markets, four languages, two currencies in play with USD and EUR, and a whole matrix of annotations that must reciprocate correctly. When they break, they break quietly. Rankings do not collapse. They just soften in one market while the others look fine, so it takes months to notice.

My audit step is narrow. Sample five URLs per market. Confirm every annotation returns to the page it came from. Confirm the self-reference exists. Confirm the canonical points within the same language version, not across it. That last one is a classic, and it invalidates the entire cluster.

The full mechanics live in our hreflang guide for international sites that actually rank in each market. Do not attempt this from memory. Nobody remembers the return tag rules correctly, including me.

How do you write a report developers will actually ship?

Write for the engineer, not for the client. Each finding gets five lines. What is broken, which URLs, what it costs, the exact fix, and how to verify it. No severity colors. No jargon. A ticket they can drop into a sprint without translation. Then attach the dollar figure and let it argue for you.

This changed my career more than any technical skill.

Here is the format I use for every finding, written as a ticket rather than a report row. The title states the outcome, not the problem. "Restore indexing on 380 category pages" beats "Meta robots noindex present". Then a one-line business impact with a number. Then the URL list as an attachment. Then the fix in plain language, describing the change rather than pasting markup. Then a verification step, so QA knows what done looks like.

Deliver the top three verbally. Every time. A 10-minute call with the lead engineer beats a 40-page PDF, because you can answer objections in real time and you find out immediately if your fix is impossible in their stack. Half my findings get better after that call.

One more thing that seems small and is not. Send fixes in batches that match how developers work. Five tickets touching the same template ship together. Five tickets scattered across five systems ship never.

Migrations are the exception to all brevity rules. If the audit is part of a replatform, the redirect map is its own project with its own document, and our redirects and site migration guide covers the sequence that protects your traffic.

How do you prove the technical SEO audit worked?

Baseline before you change anything, then track the specific metric each fix should move. Indexation fixes move indexed page counts within days. Architecture fixes move impressions over weeks. Speed fixes move conversion rate, not rankings. Measuring everything against total organic traffic is how good work goes unrewarded.

Attach a metric to each finding before you ship it. Not after.

For a noindex fix, the metric is indexed URLs in the Page Indexing report and clicks on those specific pages. Expect movement within one to two weeks once recrawl happens. For an internal linking change, watch impressions on the target cluster over four to eight weeks. Slower, but more durable.

The reporting mistake I see constantly is claiming credit for everything. You fixed a canonical, traffic rose 12 percent, so the canonical did it. Maybe. Or a competitor got hit by an update. Or seasonality. Segment your reporting down to the affected URLs and your claims become defensible.

Track a regression too. When the Chicago retailer restored their category pages, we watched paid search spend on those same terms drop over the following six weeks. That was the real number. Organic recovery was worth roughly $6,000 a month in avoided paid clicks alone, before counting incremental revenue. That is the kind of figure that gets you invited back.

How often should you run a technical SEO audit?

Run a full technical SEO audit twice a year. Run a 15-minute health check every week. The weekly check watches indexation on money pages and nothing else. Most catastrophic technical failures announce themselves within days in the Page Indexing report, and catching one early is worth more than any quarterly deep dive.

Frequency should follow deploy velocity, not the calendar.

A site that ships code weekly needs monitoring, not audits. A brochure site that changes twice a year does not need a quarterly audit at all. Someone is selling you one anyway.

My weekly check is genuinely 15 minutes. Open the Page Indexing report and look for new exclusions. Spot check three money pages for status and canonical. Glance at the crawl stats for a server error spike. Done.

Always run a full technical SEO audit after a replatform, a CMS upgrade, a CDN change, or a navigation redesign. Those four events cause the overwhelming majority of self-inflicted technical disasters. A theme update on WordPress or a template change on Shopify can silently rewrite your canonical logic across thousands of URLs, and nobody tells the SEO.

Frequently asked questions

How long should a technical SEO audit take?

One focused day for a site under 50,000 URLs. Two to three days for a large ecommerce catalog with rendering and log analysis. If yours takes two weeks, you are documenting rather than diagnosing.

Can I do a technical SEO audit without paid tools?

Yes. Search Console, Chrome DevTools, PageSpeed Insights, and Screaming Frog's free 500-URL tier cover most small sites completely. The paid tier only becomes necessary when the site gets big.

What is the most common critical issue you find?

Accidental noindex or robots blocks from staging environments, by a wide margin. Second is broken canonical logic introduced by a plugin or theme update. Both are one-line fixes worth thousands.

Should I fix every issue the crawler reports?

No. Most reported issues are cosmetic and have no mechanism connecting them to traffic or revenue. Fix what changes indexing, rendering, or user experience on pages that earn. Ignore the rest without guilt.

Does site speed affect rankings or just conversions?

Mostly conversions. Core Web Vitals are a real but small ranking factor. Speed rarely explains why a page does not rank. It very often explains why a ranking page does not convert.

How do I audit a JavaScript-heavy site?

Crawl twice, once with rendering off and once on, then compare word counts and link counts per template. Big gaps on money pages are your finding. Matching output means move on.

Is crawl budget worth auditing on a small site?

No. Google's guidance points at sites above one million pages updating weekly, or above 10,000 pages updating daily. Below that, crawl budget work is almost always misdirected effort.

What should I check immediately after a site migration?

Redirect mapping first, then status codes, then canonical and sitemap accuracy on the new URLs. Check within 48 hours. Migration damage compounds fast and gets harder to reverse each week.

How do I convince developers to prioritize SEO fixes?

Attach money to it and cut the list. Three tickets with a revenue figure beat 200 rows with severity colors. Talk to the engineer directly instead of routing everything through a project manager.

Do audit findings differ between US and European sites?

The core checks are identical. European and UK sites carry more multi-language and multi-currency complexity, so annotation errors and duplicate English variants appear far more often in those audits.

Where to start tomorrow morning

If you take one thing from this, take the sequence.

Open analytics. List your 20 money pages. Check each one for status, robots rules, canonical target, and live index status. Give it 25 minutes. That single exercise catches more revenue damage than the other 95 percent of a typical technical SEO audit combined, and it is the part most reports bury on page 40.

Then, and only then, crawl. Then triage by dollars. Then send five tickets, not 214.

The Chicago retailer got their category pages back, incidentally. It took one developer 40 minutes to remove the staging rule, and about three weeks for Google to fully recrawl and restore the cluster. The $9,400 audit had found the problem more than six months earlier. It just never told anyone it mattered.

My prediction for the next two years is that this gap widens. As AI tools make it trivial to generate exhaustive issue lists, the scarce skill stops being detection and becomes judgment. Anyone can produce 200 findings now. Almost nobody can tell you which three to ship on Monday.

So here is my question for you. Look at your last technical SEO audit. How many of its findings actually got shipped, and did anyone ever check whether they moved a number?