A technical SEO audit is a structured evaluation of whether search engines can crawl, render, index, and trust a website's infrastructure. Automated tools like Semrush Site Audit and Ahrefs Site Audit flag symptoms: broken links, slow Core Web Vitals, missing tags. An engineering review traces each symptom to its cause in the build step, the render path, or the crawl trap.
Only 48% of mobile sites pass all three Core Web Vitals (Web Almanac 2024). A scan can tell every one of the failing 52% that they failed. The reason behind each failure is a diagnosis, and a scan does not produce one.
This post draws the line the rest of the SERP avoids: where the automated scan and the printable checklist stop, and where reading the rendered DOM, the response headers, and the server log begins. It walks three failure classes with code, then the crawl-render-index workflow, crawl-budget math, and what the market charges.
The core idea: a tool finds the broken link. An engineering review finds why the build emits it and fixes the template so it stops emitting it.
A technical SEO audit is a structured evaluation of whether search engines can crawl, render, index, and trust a website's infrastructure. Run the keyword through Google and the whole results page splits two ways: tool landing pages that promise a scan in seconds, and 6,500-word process guides that teach a numbered checklist. Both are useful. Neither draws the line this page is about - where the scan stops and the diagnosis starts.
What Is a Technical SEO Audit?
The word "audit" makes most people picture a tool's red-yellow-green report. A technical SEO audit is the structured evaluation behind that report: it confirms search engines can crawl, render, index, and trust a site's infrastructure. The standard scope is fixed across every provider - crawlability and indexability, site architecture and internal linking, rendering, Core Web Vitals, duplicate content and canonicals, HTTP status codes, HTTPS, and structured data for classic rich results. Every provider covers that scope. What separates them is the output.
The same audit produces two different artifacts depending on who runs it. A tool produces a prioritized list of symptoms. An engineering review produces a causal map from each symptom to the code, config, or template that emits it. Take Core Web Vitals: only 48% of mobile sites pass all three (Web Almanac 2024, drawing on Chrome User Experience Report field data). A scan can tell every site in the failing 52% that it failed. Whether the cause is an unoptimized hero image, a layout-shifting ad slot, or a long task blocking Interaction to Next Paint is a diagnosis the scan cannot make.
A technical SEO audit differs from a broader SEO audit by layer. The broader review adds on-page content, keyword targeting, and off-page signals. The technical version is the crawl-render-index foundation everything else sits on. It is the diagnostic event inside Technical SEO Engineering, the discipline that owns the infrastructure as an in-house practice. "Technical SEO audit" is the industry term for the scan; an engineering-grade version of it is what Haide runs as an opportunity review.
Tool Scan vs Engineering Review: Where the Checklist Stops
A tool scan covers breadth well. Ahrefs Site Audit checks 170+ technical and on-page issues; Semrush flags 40+ (vendor-stated counts, via the live SERP). That coverage is real and worth running. Tracing each symptom to its cause and shipping the source-level fix is a different job, and three failure classes show why.
This comparison is a method comparison, the spine of the section:
| Criterion | Automated Tool Scan | Engineering Review |
|---|---|---|
| What it produces | A prioritized list of symptoms | A causal map from each symptom to the code that emits it |
| Crawlability | Reports blocked URLs and broken links | Reads robots.txt, X-Robots-Tag, and meta-robots together to find the conflict, plus the log to see what Googlebot fetched |
| Rendering | Audits the rendered page | Compares view-source against the rendered DOM to catch content that only exists after JavaScript |
| Crawl budget | Reports pages found | Diagnoses whether Googlebot spends budget on revenue pages or filter permutations |
| Core Web Vitals | Flags failing LCP, INP, CLS scores | Identifies the specific cause and the build-level fix |
| Output you act on | A dashboard of red flags | A build spec the client owns, with no lock-in |
The silent de-index. A tool reports a page as "not indexed". The cause is usually a directive conflict, and the tool sees only the outcome. Consider a page where the HTML looks indexable but the response carries a header:
HTTP/1.1 200 OK
X-Robots-Tag: noindex
The same outcome appears when a shared template leaves a <meta name="robots" content="noindex"> in the <head>, or a Disallow: in robots.txt blocks the very URL whose canonical points to it. Reading the response headers and the template together is what removes the directive at the source. This is indexability work, the eligibility question robots directives, canonicals, and status codes decide together.
The render gap. A tool that audits the rendered page can pass a product page where the price, description, and structured data only exist after client-side JavaScript runs. Googlebot indexes in two waves: it indexes the raw HTML first, then queues the page for rendering. Anything outside the initial HTML waits on that queue. Consider a product page where view-source shows an empty shell:
<div id="product"><!-- price and copy injected after hydration --></div>
The median delay between crawl and render was about 5 seconds (Martin Splitt, Google, Chrome Dev Summit 2019, via Onely), but the long tail matters more: 5-50% of JavaScript-heavy pages stayed unindexed two weeks after they were added (Onely). The fix is server-side rendering or static generation of the critical content, a build change the checklist has no line for. This is the heart of JavaScript rendering: the gap between "the tool says it is fine" and "Google has not rendered the real content yet".
The crawl trap. Faceted navigation that combines color, size, and price filters generates thousands of crawlable URLs:
/collections/boots?color=red&size=l&sort=price
/collections/boots?color=red&size=m&sort=price
A crawler dutifully reports these as "pages found" while Googlebot burns its budget on permutations and never reaches the new collection pages. The fix is a robots.txt disallow pattern, rel="canonical" discipline, or parameter handling - a configuration decision the tool can flag the symptom of but cannot make. This is where crawl efficiency and Core Web Vitals scores stop being checklist items and become engineering ones.
How a Technical SEO Audit Actually Runs (Crawl, Render, Index)
The standard guide presents a flat numbered checklist, one through twelve. The engineered version organizes the same work around the three things search engines actually do, because that is where causes hide. The breadth checks (hreflang, duplicate content, HTTPS, structured data) belong in the scan. The crawl-render-index spine is what diagnoses.
Crawl
Can search engines reach the URLs? A full crawl from the Screaming Frog or Sitebulb category maps the site, then gets cross-referenced with the server log file to see what Googlebot actually fetched, against what the crawler merely simulated. Add robots.txt and XML sitemap validation in Google Search Console. The log file is the step the checklists skip, and it is the only source of truth for Googlebot behavior. Reading it is log file analysis, and it is also where site architecture problems surface as crawl-depth and orphan-page patterns.
Render
Does the content survive rendering? Compare view-source against the rendered DOM in Chrome DevTools or the URL Inspection tool's rendered HTML, specifically for content that appears only after JavaScript. This is where the render gap from the previous section gets caught before it costs an indexed page.
Index
Is the page eligible and actually indexed? The Index Coverage report in Search Console names the states that matter: "Discovered - currently not indexed", "Crawled - currently not indexed", and "Excluded by noindex". Add canonical consistency and status-code hygiene - single-hop 301s that avoid redirect chains, and no soft 404s. For the full breadth checklist, the Technical SEO Engineering pillar carries it; this spoke stays on the spine.
Crawl Budget: The Check Most Audits Skip (and Who Actually Needs It)
Crawl budget is the set of URLs Google can and wants to crawl on a site, set by crawl capacity (how hard Googlebot can hit the server) and crawl demand (how much Google wants the content). Most templates list it as a critical issue for everyone, which is noise.
Google scopes it precisely. Crawl budget is a concern for large sites with 1M+ pages where content changes weekly, medium-to-large sites with 10K+ pages changing daily, or sites carrying a large share of "Discovered - currently not indexed" URLs in Search Console (Google Search Central documentation). For a 200-page brochure site, crawl budget is a non-issue, and flagging it manufactures a problem that does not exist. For a large eCommerce catalog with faceted navigation, it is the difference between Googlebot reaching the new products and spending the budget on filter permutations.
That scoping is the evidence discipline the work demands. A finding is critical only when you can name the consequence - here, Googlebot reaching the pages that earn revenue, or not. No tool page scopes crawl budget this honestly, because a scan reports "all pages crawled" and says nothing about whether the budget went to the pages that matter.
A scan reports that all pages were crawled. It says nothing about whether Googlebot spent its budget on the pages that earn the revenue.
What a Technical SEO Audit Costs - and What You Pay For
A technical SEO audit ranges roughly from $500 to $15,000 by site size and depth (NAV43, 2025; HatchTechs). Automated tool reports sit effectively free-to-$99 at the low end, and enterprise or migration-grade reviews run higher. The range is wide because the deliverable behind it varies more than the number does.
The price difference between tiers is almost never the tools. Every serious provider runs the same crawl plus Search Console plus PageSpeed stack. The difference is the depth of diagnosis, and whether you walk away with a list of symptoms or a causal fix path. That reframes the buyer's question from "how much" to "what is in the deliverable". Haide runs its version as an opportunity review, the Growth Engine Diagnostic, that outputs a build spec the client owns and can implement, with no lock-in.
The decision tree for a buyer comes down to fit:
A free tool scan or a checklist is genuinely enough for a small site, an obvious broken-link or missing-tag fix, or a periodic health check. An engineering review earns its cost when the symptoms do not explain the lost traffic, or a migration, a JavaScript framework, or a large faceted catalog is involved. AI answer engines read the rendered HTML on your page, so the same crawl-render-index foundation that wins classic search also decides whether your content is available to be quoted. Structured data still earns classic rich results; it is not a shortcut to AI citations.
How to Apply This
Run the scan first. Ahrefs, Semrush, Search Console, and PageSpeed Insights give you breadth cheaply, and the breadth is worth having. Fix the obvious symptoms a tool surfaces well - broken links, missing tags, redirect chains. That clears the noise so the real signal stands out.
When the symptoms do not explain the lost traffic, change the question. Pull the server log and see what Googlebot fetched. Compare view-source against the rendered DOM on the pages that matter. Scope crawl budget to whether your site is actually large enough to have a problem. Each of those reads a cause the scan cannot reach, and each points at a fix that lives in the build itself.
The full breadth checklist and the surrounding mechanics live on the Technical SEO Engineering pillar. The build itself is where the Organic Growth Systems service turns the causal map into shipped fixes the business owns.
FAQ
Frequently asked questions
What is a technical SEO audit?
A technical SEO audit is a structured evaluation of whether search engines can crawl, render, index, and trust a website's infrastructure. It covers crawlability, indexability, architecture, rendering, Core Web Vitals, structured data, and HTTPS. The output depends on who runs it. A tool returns a list of symptoms. An engineering review goes one step further and maps each symptom back to the code, config, or template that emits it.
How much does a technical SEO audit cost?
A technical SEO audit ranges roughly from $500 to $15,000 depending on site size and depth, with free-to-$99 automated tool reports at the low end (NAV43, 2025). The price driver is the depth of diagnosis. Every serious provider uses the same crawl plus Search Console plus PageSpeed stack, so the tools are constant and you are paying for whether you get a symptom list or a causal fix path.
What tools do you use for a technical SEO audit?
Breadth comes from crawlers like Screaming Frog and Sitebulb, plus Google Search Console and PageSpeed Insights. Ahrefs Site Audit checks 170+ issues and Semrush flags 40+, which is genuine coverage. Cause comes from two sources those tools under-weight: the server log file, which shows what Googlebot actually fetched, and the rendered DOM compared against view-source.
How is a technical SEO audit different from an SEO audit?
A technical SEO audit evaluates the crawl, render, and index infrastructure: robots directives, status codes, rendering, Core Web Vitals, site architecture. A broader SEO audit adds on-page content, keyword targeting, and off-page signals like backlinks. Technical SEO is the foundation layer the rest of the review sits on top of.
Can I do a technical SEO audit myself for free?
Yes, for breadth. Free tiers of Ahrefs and Semrush, plus Google Search Console and PageSpeed Insights, cover crawlability, indexability, and Core Web Vitals scoring. DIY usually stops at three places: comparing the rendered DOM against raw HTML to catch the render gap, reading the server log to see Googlebot behavior, and doing the crawl-budget math on a large catalog.
