Technical SEO Audit: Reading the List, Not Generating It

Run your site through Semrush, Ahrefs or any free checker and you’ll get a list. 170 issues, sorted by severity, red and yellow, exportable. The number is Ahrefs’ own — its scanner advertises 170+ checks — and it’s a fair stand-in for the category. That part is solved; a dozen tools do it in a click, and most of the pages ranking for this term are those tools describing their own scanner.

This isn’t that. A technical SEO audit is the reading of that list: which of the 170 issues stops Google from crawling, rendering and indexing the pages that matter, and which are noise the crawler flagged because flagging everything is what crawlers do. A tool can tell you a page has a canonical conflict. It can’t tell you that conflict is why your best category fell out of the index eight months ago, or that the other 60 warnings above it on the list change nothing either way.

If you want the scan, close this — the tools are faster. What follows is how to read what the scan hands back, and what a technical SEO audit report should say when the reading is done.

Technical SEO audit scope: discovery, crawl, render, index, retrieval

A technical audit is one question asked six ways: can a search engine efficiently discover, crawl, render, understand, index and retrieve the URLs that matter to you? Every item a scanner flags is a symptom of a failure somewhere on that path, and the path has exactly six places it breaks:

• Undiscovered — the engine never finds the URL.
• Uncrawlable — it finds it but can’t fetch it.
• Unrenderable — it fetches the file but can’t build the page the user sees.
• Unindexable — it renders the page but doesn’t grant it a place in the index.
• Misunderstood — it indexes the page but reads it as being about the wrong thing.
• Inefficient — it does all of the above, but wastes so much effort on junk URLs that the important ones wait weeks.

Read the 170-issue list against those six states and it reorganizes itself. Most of the reds collapse into “cosmetic,” and three yellows turn out to be the reason half the site is invisible.

One scope note. This is the machine-access layer — whether the engine can reach and process your pages. Whether the pages deserve to rank once indexed is a different discipline: demand, content depth, authority, whether traffic reaches revenue, all covered in the B2B SEO audit and its ecommerce counterpart. A technically flawless site that answers nothing still doesn’t rank. This article assumes the content question is handled elsewhere and asks only: can the engine get to it.

Crawlability: robots.txt, crawl budget, crawl traps and orphan pages

Discovery is where the path starts, and it fails more silently than anything downstream, because an undiscovered page throws no error. It just isn’t there.

Crawlability is two questions the tools tend to merge. First, can Googlebot reach the URL at all — is it linked from somewhere the crawler travels, present in a sitemap, not walled off by robots.txt. Second, once reachable, is the crawler’s effort being spent on it or burned somewhere else. A site can be perfectly crawlable in the first sense and starved in the second.

The failures cluster in a few shapes. robots.txt blocking a directory someone forgot was important — a staging rule that shipped to production, a Disallow written for one path that catches three. Crawl traps: infinite URL spaces the crawler falls into and never climbs out of — a calendar that generates a “next month” link forever, a faceted navigation that multiplies filters into millions of combinations, session IDs stamped into every URL so the same page looks like a thousand. And orphan pages: URLs that exist, are indexable, are commercially real, and have not one internal link pointing at them, so the crawler has no path to discover them in the first place.

The faceted and parameter explosion is the one that does the most damage on larger sites, because it doesn’t just hide pages — it drowns the crawler in near-duplicates so the real pages wait. The index-decision side of that (which facets deserve a page, which get canonicalized away) belongs to the ecommerce SEO audit, where it’s a revenue call. Here the concern is narrower and mechanical: is the explosion eating the crawl.

I read this as a full-site crawl segmented by URL type — templates, parameters, facets, pagination — cross-read against Search Console’s Crawl stats report and the sitemap. Crawl stats splits Googlebot’s requests three ways, and each split is a tell. By purpose: a mature site whose crawl is still mostly “discovery” rather than “refresh” has a crawler that keeps finding URLs it didn’t know about, and on a site that hasn’t grown, those are traps. By response: the share of requests answered with 3xx, 404 and 5xx is crawl spent on nothing, and on a site that’s been through two migrations it runs into double digits. By Googlebot type: since the July rewrite this is where the shared budget shows, with AdsBot and the image fetcher drawing from the same pool as Googlebot Smartphone. Orphans surface where a URL sits in the sitemap or the logs but has no internal link pointing to it; traps surface as URL patterns that balloon far past the real page count. Finding where discovery breaks is the diagnosis. Rebuilding the internal-link structure or writing the robots rules is build work.

Indexability: Search Console index statuses, noindex, canonical, soft 404

A tool reports a page as crawlable and everyone assumes it’s in the index. Crawling is whether Googlebot can fetch the URL. Indexing is whether Google grants it an independent place in the results. Between the two sits every page that gets fetched, considered, and dropped — and no “can we crawl it” check reads that.

Search Console names the gap in specific statuses, and each one is a different diagnosis pointing at a different section of this article. Most reports lump them. Read apart, they tell you where the fix lives:

The mechanisms behind those rows fail differently, and the audit names each one. A noindex tag doing its job somewhere nobody meant it to — applied site-wide during a redesign and never lifted. A canonical tag pointing the wrong way, telling Google the real page is a duplicate of a weaker one, so the weaker one ranks and the real one is suppressed; Google treats the canonical as a hint, and when it overrules you the page lands in the third row above. Soft 404s: pages that return a 200 OK while showing an empty search result, a “no products found,” a placeholder. Google trusts what it sees over what the status code claims, decides the URL is worthless, and drops it.

Then the two parity failures that only show up when you compare lists. Index bloat — thousands of thin, auto-generated URLs indexed that never should have been, diluting the site’s overall quality signal. And sitemap/index mismatch — the sitemap declares 4,000 URLs, the index holds 2,500, and the 1,500-page gap is either pages Google refused or pages you never meant to submit. Either direction is a finding.

None of this is visible from what the site intends. You have to read what Google holds, and a site: search won’t give you a straight count; on a large site it can be off by an order of magnitude. The URL Inspection API is exact and capped at 2,000 requests a day per property, so on a large site the check is class by class, sampled: a bulk index check across Google and Bing, URL template by URL template, reading live index status — so the picture is “of this class of page, here’s the share that’s indexed,” set against what the site thinks it published. A class where the canonical or noindex on the page disagrees with what’s in the index is where the finding sits.

Index bloat and parity failures scale into their own kind of problem on very large sites, where the unit of analysis stops being the page and becomes the template — the enterprise SEO audit. The mechanism is the same at any size: the site’s declared index and the index Google holds have drifted.

JavaScript rendering: raw HTML vs rendered DOM

This is the layer most audits skip entirely, and it’s the one that fails hardest on modern sites, because the page a human sees and the page Googlebot receives can be two completely different documents.

When your site is built in React, Vue, Angular or any JavaScript framework, the server often ships a near-empty HTML shell — a skeleton with a <div id="root"> and a bundle of scripts. The browser runs those scripts, fetches the data, and builds the page you see. That step is hydration: the raw file is an empty frame, and the content gets poured in afterward by JavaScript running in the browser. What the user sees is the filled frame. The question is what the crawler sees.

Google renders JavaScript, but not for free and not always the way your browser does. It fetches the raw HTML first, queues the page for rendering, and comes back later to run the scripts. Google’s own figure for that queue, from Martin Splitt in 2019, was a median of about five seconds with a tail running into minutes, and it hasn’t published a newer one. In that gap, or if a script errors, or if the content depends on a click or a scroll the crawler never performs, the rendered page can come back missing the very things you need indexed. Googlebot renders with a tall viewport, so lazy-loading built on IntersectionObserver usually fires, but it doesn’t scroll and doesn’t click, so anything behind a scroll event or a “Load more” button never exists for it. A site can look perfect to every human visitor and ship Googlebot a blank.

The failures I look for: content that’s in the rendered DOM but absent from the raw HTML — present for users, invisible to a crawler that didn’t wait for the render. Internal links injected by JavaScript with no <a href> underneath, so the crawler sees no path onward and discovery dies one level deep. Metadata set by script after load — titles, canonicals, meta robots — which means the crawler may read one thing and the user another; a canonical injected by JavaScript is the one Google is most likely to ignore. Lazy-loaded content and infinite scroll with no crawlable pagination beneath them, so everything past the first screen is unreachable.

The way to catch this is to crawl the page twice — once reading raw HTML, once with rendering on — and diff the two. In Screaming Frog that’s JavaScript rendering mode with both the original and rendered HTML stored, and the JavaScript tab does the diff for you: Contains JavaScript Content, Contains JavaScript Links, Canonical Only in Rendered HTML, Noindex Only in Original HTML, Page Title Updated by JavaScript. Each filter is one of the failures above, counted per template. The same check for a single URL is Search Console’s URL Inspection: “view crawled page,” HTML tab against the screenshot — if the content grid is in the screenshot and absent from the HTML, that’s the empty frame. Content, links or metadata that appear only in the rendered version are the pages at risk: the crawler may index the empty version. Where the gap is links, the follow-up question is whether the deeper pages are reachable any other way. On paper the page returns 200 and looks healthy. The damage hides between two versions of the same URL.

URL architecture and canonicalization

A search engine wants one canonical address for each thing. Sites, left alone, generate many addresses for the same thing, and every duplicate splits the ranking signal that should have pooled on one URL.

The duplication comes from ordinary machinery, not neglect. Tracking parameters that create a new URL for every campaign. Sort and filter parameters that reorder the same list. Trailing-slash and uppercase variants the server treats as distinct. HTTP and HTTPS, www and non-www, both resolving. Session identifiers. Each of these hands Google several URLs carrying near-identical content, and Google has to guess which one you meant — and when it guesses, it sometimes keeps the parameter-stamped version and buries the clean one.

Canonicalization is the set of signals that resolve the ambiguity: canonical tags, redirects, consistent internal linking, the sitemap. The audit reads whether those signals agree with each other and with reality. The common contradiction is a canonical tag that says one thing while the internal links, the sitemap and the redirects all vote another way — so Google gets four conflicting instructions and follows none of them reliably. Duplicate content, in the technical sense, is a URL problem: the same page reachable too many ways.

Reading it means mapping the URL space from the crawl and flagging the duplication patterns — parameter variants, protocol and slash inconsistencies, canonical tags that disagree with the internal-link and redirect signals around them — and then checking Google’s verdict against yours in the Duplicate, Google chose different canonical than user report. Two URLs from the same site ranking, badly, for the same term is how it surfaces in the results.

Internal linking and crawl depth

Internal links do two jobs at once, and the audit reads both. They’re the roads the crawler travels to discover pages, and they’re votes that tell the engine which pages you consider important. A page with no internal links pointing at it is both undiscoverable and, in the engine’s eyes, unimportant — nothing on the site vouches for it.

Crawl depth is the measure that surfaces this. It’s the number of clicks from the homepage to a given page, and it’s a rough proxy for how the engine weighs the page: the deeper it sits, the less often it’s crawled and the less authority flows to it. A proxy, because Google also enters through the sitemap and through external links, so a page four clicks deep with a strong external link is not as buried as the number says. But the number is what you can measure. A product or service page eight clicks deep is being told, structurally, that it doesn’t matter — even if it’s the page that pays the bills. The failures are the predictable ones: orphan pages with zero internal links, important pages stranded deep in the tree, and dead ends where a link points to a 404 or a redirect chain and the road stops.

Orphans and crawl depth get hard at scale, where a site has millions of URLs and the question becomes structural rather than page-by-page — the enterprise version owns that ground, where the template, not the page, is the unit. The mechanism is the same regardless of size: a commercially important URL with no inbound internal links, sitting too deep for the crawler to value it.

Reading it means walking the internal-link graph from the crawl: the Crawl Depth report for the distribution per template, the filter Inlinks = 0 for orphans, and the redirect and 404 destinations for dead ends. The output is the list of important URLs that are orphaned or buried, ranked by how much they matter commercially.

HTTP status codes, redirect chains and XML sitemaps

This is the plumbing layer, and it’s where the crawl leaks through joints nobody inspects.

Status codes are the crawler’s first read on every URL, and the patterns matter more than any single code. A wall of 404s where content used to live means links and ranking history dead-ending into nothing. Redirect chains and loops: URL A redirects to B redirects to C redirects to D. Google has said since 2016 that 3xx redirects don’t lose PageRank, so the cost of a chain isn’t authority bleeding off at each hop. The cost is that Googlebot follows at most ten hops and then gives up, that every hop is a fetch spent on nothing, and that a chain built over three migrations usually has a loop or a 404 somewhere in the middle nobody has walked.

Sitemaps are the most misread signal in this layer.

So the audit of a sitemap is whether every URL in it returns 200 and deserves to be there. A sitemap where a third of the URLs are redirects, 404s or noindexed pages is working against the site — pointing the crawler at things that waste its visit. Reading it means pulling the full status-code map from the crawl, tracing every redirect to its final destination to catch chains and loops, and validating the XML sitemap URL by URL against live status, flagging any entry that isn’t a 200, indexable page.

Structured data: JSON-LD, Rich Results Test and entity consistency

Everything above gets the page discovered, fetched, rendered and indexed. This layer decides whether the engine understands it — and understanding is what separates a page that’s merely indexed from one the engine retrieves for the right query.

Structured data is markup — usually JSON-LD — that states in machine-readable terms what a page is about: this is an article, by this author, published this date; this is a product, with this price and this availability; this is an organization, and here is the entity behind it. It doesn’t change what the user sees. It removes the engine’s guesswork about what the page means, which is what makes a page eligible for rich results and, increasingly, for citation in AI answers that read structured data first.

The audit reads three things. Is the schema present on the templates where it matters, and is it valid — malformed JSON-LD is worse than none, because it signals carelessness on the exact layer meant to signal precision. Two validators, and they disagree on purpose: Google’s Rich Results Test checks only the types Google uses and tells you whether a rich result is possible; the Schema.org validator checks syntax against the whole vocabulary. Markup that passes one and fails the other is itself a finding. Does the marked-up data match the visible page, since schema that claims a price or a rating the page doesn’t show is what Google’s “spammy structured markup” manual action is for. And is the entity information consistent — does the Organization, author and product markup tell one coherent story across the site, or three contradictory ones. On most sites I open, Organization markup is either missing or present on the homepage only, and author Person markup with a sameAs to a profile doesn’t exist at all, which is the cheapest fix in the whole audit.

Two kinds of schema belong to other articles, because they stop being about machine access and start being about a specific surface. Product and offer markup that feeds shopping surfaces is the ecommerce audit’s. Localized schema and language-entity signals for multi-region sites belong to the international SEO audit. The general technical layer — valid, consistent, page-matching markup that lets the engine understand any page at all — is here.

Performance and Core Web Vitals

Speed is treated as a user-experience concern, and it is one, but for a technical audit it’s also a crawl concern, and that second reading is the one most reports miss.

Core Web Vitals are Google’s three measures of experience, each with a threshold: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1. Add time to first byte — Google’s “good” line is 800 milliseconds — and you have the vitals that matter technically. One detail that changes how you read them: the field data Google uses comes from the Chrome UX Report, which only holds numbers for URLs with enough traffic. On a long-tail template the per-URL data is empty, the report falls back to origin-level figures, and a failing template can hide behind a passing homepage.

That’s why the reading is per-template, not site-wide, and per-template means sampling — twenty URLs from each class through the CrUX API, or your own RUM. A single site-wide score is an average that hides the truth: the homepage passes, the product template fails, and the average lands in the yellow telling you nothing actionable. Every template fails differently and has to be read on its own — the listing page for layout shift, the article for paint, the interactive tool for responsiveness, and in my experience the INP failure on a commercial template is almost always the tag manager and whatever it loaded, not the page’s own code.

Then the crawl connection, which is the part specific to a technical SEO site audit. A slow server response doesn’t only frustrate users. It directly limits how many pages Googlebot fetches per visit — the crawler budgets time, not just requests, and Google’s July 2026 guidance says outright that response speed and server errors are what move the crawl limit up or down. The same rewrite added a lever most sites leave unpulled: answer a conditional request with 304 Not Modified when the page hasn’t changed, and the fetch costs almost nothing. That needs a usable Last-Modified or ETag on the template, which most CMS output doesn’t carry. On a large site this feeds straight back into the crawl-efficiency problem from the discovery section: slow responses mean the crawler reaches fewer new pages, so new content waits longer to be seen.

Log file analysis: Googlebot verification and crawl budget by URL type

Everything to this point is inference: you read the site the way a crawler would and reason about what Google probably does. Server logs replace the inference with a record. They are the one place that shows where Googlebot went — every request it made, every URL it fetched, every status it got back, in order.

That record settles questions nothing else can. Which pages Googlebot crawls often and which it hasn’t touched in months. How much of its budget goes to the URLs that matter versus facet grids, parameter junk and redirect chains. Whether it’s hitting your important templates at all, or grinding through noise while new content waits. What share of its requests got a 304 back — on most sites that number is zero, which is the crawl-efficiency finding in one line. Before any of that I verify the Googlebot hits against Google’s published ranges — the googlebot.json file under developers.google.com, or a reverse DNS to googlebot.com — because fake Googlebot traffic is common enough to distort the split. And I separate Googlebot from the AI crawlers, which are now a large share of bot traffic and behave differently: Cloudflare Radar’s June 2026 figures have Googlebot fetching about five pages per visitor it sends back, OpenAI’s crawlers around 850 and Anthropic’s several thousand. The ratios move month to month; the gap doesn’t.

Reading the logs turns “your crawl budget is probably wasted” into a measurement: a share of Googlebot’s requests over a month hit URLs you don’t want indexed, and you can name them. The method is segmenting verified Googlebot’s hits by URL type against the crawl and the sitemap, so the picture shows where the bot spends its budget versus where the important URLs sit. Almost no audit reaches this layer.

Technical SEO audit checklist: HTTPS, meta robots, hreflang, pagination, mobile parity

Everything a scanner runs is still worth running. The difference is where each check lands on the path, which decides whether a failure is a footnote or the reason a template is invisible. This is the table-stakes layer, one row per check, with the place I read it and the state it breaks:

None of these rows is an audit on its own. A site can pass all twelve and still have its best template sitting in Crawled – currently not indexed, and a site can fail three and rank, because the failures sat on pages nobody needed. The table exists so the scanner’s output can be filed by state, which is the step that turns the list into findings.

Is technical SEO still important in 2026?

Yes, but the center of gravity has moved, and an audit that checks what mattered in 2018 misses where the failures live now.

The old technical checklist — titles, meta tags, a clean robots.txt, HTTPS — is now table stakes, handled by any decent platform out of the box, and largely what the free scanners still measure. The failures that cost rankings in 2026 sit further down the path. Rendering, because so much of the web now ships as JavaScript that crawlers have to execute, and execution is where pages go blank. Crawl-efficiency, because a site now has a dozen non-human readers besides Googlebot — on June 3, 2026, Cloudflare’s CEO published Radar data showing automated requests had passed humans for the first time, 57.5% of HTML traffic to 42.5% — and most of them are far less efficient than Google about it, so a wasteful URL space costs more than it used to. And retrievability, because being indexed is no longer the finish line.

Retrievability sounds abstract until you pin down what the AI surfaces read. Google’s documentation says AI Overviews and AI Mode draw on the same index as Search, that there’s no special markup for them, and that the Google-Extended robots token controls Gemini training and grounding but has no effect on inclusion in AI Overviews. So the question of whether the engine can pull your passage into an answer reduces to three technical ones: is the page indexable, is the passage in the raw HTML rather than injected after render, and does it sit under a heading that says what it answers. That puts rendering and structured data at the center rather than the margins.

Technical SEO shifted from “is the tag present” to “can the machine reach, build, understand and retrieve this page” — which is the spine of this article, and the reason a 2018-era checklist reads as noise against a 2026 site.

Technical SEO audit report: issue, evidence, impact, fix

A flat list of 170 issues sorted by severity is a scanner’s export, not an audit, and its severity ranking is close to meaningless, because the scanner has no idea which URLs touch your business. It flags a critical warning on a page nobody reaches and a medium one on the template that carries your traffic, and hands you the dead page first.

So the deliverable inverts that, and every finding carries four things instead of one:

• Issue — what’s wrong, in one line, tied to which of the six failure states it belongs to.
• Evidence — how it’s known: the crawl diff, the log segment, the index-check mismatch. The reading itself, reproducible, rather than the tool’s flag.
• Impact — severity re-weighted by which URLs it hits. A medium issue on the money template outranks a critical one on a page that was never going to rank. This is the number the scanner can’t compute.
• Fix — the correction, and its owner: a robots rule is SEO’s, a rendering failure is engineering’s, a redirect chain belongs to whoever owns the server config. And a re-crawl date to validate the fix landed, because an unverified fix is a hope.

A technical SEO audit report that skips the owner column doesn’t get acted on — nobody knows whose job it is. One that skips the evidence column is a horoscope. The four together are what make it an engineering spec a dev team can act on Monday rather than a list somebody has to interpret first.

Three findings, each on one of the six states, each with the evidence that proves it. The other 167 go in an appendix the developers never open.

Where this goes: the free scanners will keep getting better at generating longer lists, and that will make the list worth less, because volume was never the missing thing. The scarce skill is the opposite of a scanner — knowing which failures on the path from discovery to retrieval bind, and which are the crawler flagging everything because flagging everything is all it can do. By 2028 I’d expect the rendering and log layers to stop being the advanced section of a technical SEO audit and become the part any serious one is expected to reach, and the reports still built to count issues will read like what they are: a scan, printed out, waiting for someone to read it.

If you want that read on your own site — the crawl, the render diff, the log segmentation, the index check, and a report that names the three things that matter rather than the 170 that don’t — that’s what our SEO audit is.