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. 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. The list is the easy part. The hard part is reading it: which of those 170 issues actually 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 quietly fell out of the index eight months ago, or that the other 60 warnings above it on the list change nothing either way.

So if you want the scan, close this — the tools are faster. What follows is how to read what the scan hands back.

What a technical audit actually asks

I won’t define “technical SEO audit.” The ranking pages have that ground covered, and if you’re here you know the shape of it. The delta worth stating is the question underneath.

A technical audit isn’t a checklist of things to verify. It’s 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. That reordering is the audit.

One boundary before the checks. This is the machine-access layer — whether the engine can reach and process your pages. It is not the whole SEO audit. 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 audit and its e-commerce 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 — can Google discover the pages that matter

Discovery is where the path starts, and it fails more quietly 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 e-commerce audit, where it’s a revenue call. Here the concern is narrower and mechanical: is the explosion eating the crawl.

The way I read this is a full-site crawl segmented by URL type — templates, parameters, facets, pagination — cross-read against Search Console’s crawl stats and the sitemap. Orphans surface where a URL sits in the sitemap or the logs but has no internal link pointing to it; crawl 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, and it lives in the rebuild.

Indexability — crawled isn’t indexed

Here’s the gap the word “audit” most often hides. 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 quietly dropped — and no “can we crawl it” check reads that.

The mechanisms that keep a crawled page out of the index are worth naming one at a time, because they fail differently. 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. Soft 404s: pages that return a “200 OK, everything’s fine” status while showing an empty or error-like page, which Google eventually reads as thin and demotes.

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 actually holds, and a site: search won’t give you a straight count. So the check is a real one, class by class: a bulk index check across Google and Bing, URL template by URL template, reading live index status rather than a site: estimate — so the picture is “of this class of page, here’s the share that’s genuinely indexed,” set against what the site thinks it published. The tell is a class where the canonical or noindex on the page disagrees with what’s actually in the index.

The single most common trap I flag here is a self-inflicted one: a URL blocked in robots.txt and carrying a noindex tag. Because the block stops the crawler from fetching the page, it never reads the noindex — so a page already in the index stays there, uncrawlable and unremovable by the tag meant to remove it. One signal per URL. Block it or noindex it, chosen by whether you’re saving crawl budget or clearing something already indexed. Never both.

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 version of this audit. Here the mechanism is the same at any size: the site’s declared index and its real index have drifted, and the drift is the finding.

Rendering — what the crawler receives vs what the user sees

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.

The mechanic is worth walking through, because it’s where the trouble hides. 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 building step is called hydration.

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 — and 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. A site can look perfect to every human visitor and ship Googlebot a blank.

The failures I look for are specific. 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 real <a href> underneath, so the crawler sees no path onward and discovery quietly 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. 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. Content, links or metadata that appear in the rendered version but not the raw one 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. This is a diagnosis a status-code checklist can’t produce, because on paper the page returns 200 and looks healthy. The damage hides between two versions of the same URL, and you only see it by rendering both.

If you’ve read this far and recognize your own site in it, this is the point where an actual crawl of your URLs says more than any article can. The rest of the sections are the rest of the path.

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, parameter handling. 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 almost never a writing problem. It’s 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. The self-competing pairs are the tell: two URLs ranking, badly, for the same term.

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 product or service page buried 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 genuinely 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. Here the mechanism is the same regardless of size: the page that should rank, with nothing on the site voting for it, sitting too deep for the crawler to value.

Reading it means walking the internal-link graph from the crawl — click depth from the homepage per URL, pages with no inbound internal links, and links that dead-end in a 404 or a redirect. The output is the list of important URLs that are orphaned or buried, ranked by how much they matter commercially.

HTTP status, redirects and sitemaps

This is the plumbing layer, and it’s where equity 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. 302 temporary redirects left in place for years where a 301 permanent belongs, so the equity never fully passes to the destination. And the worst offender, redirect chains and loops: URL A redirects to B redirects to C redirects to D, and at each hop a little authority bleeds off while the crawler, which gives up after a few hops, may never reach the end at all.

Sitemaps are the most misread signal in this layer, so it’s worth being exact about what they are.

That’s the real audit of a sitemap: not “does it exist” but “does every URL in it return 200 and deserve to be there.” A sitemap where a third of the URLs are redirects, 404s or noindexed pages is actively 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 — helping the engine understand

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. Does the marked-up data match the visible page, since schema that claims a price or a rating the page doesn’t show is a manipulation signal Google penalizes. And is the entity information consistent — does the organization, author and product markup tell one coherent story across the site, or three contradictory ones.

Two kinds of schema belong to other articles, not this one, because they stop being about machine access and start being about a specific surface. Product and offer markup that feeds shopping surfaces is the e-commerce audit’s. Localized schema and language-entity signals for multi-region sites belong to the international 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 specific measures of experience: Largest Contentful Paint (how fast the main content appears), Interaction to Next Paint (how fast the page responds when you act on it), and Cumulative Layout Shift (how much the page jumps around as it loads). Add TTFB — time to first byte, how long the server takes to start responding — and you have the vitals that matter technically.

The reading that changes the diagnosis is per-template, not site-wide. 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.

Then the crawl connection, which is the part specific to a technical 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, so a slow site gets fewer of its pages crawled per session. On a large site that feeds straight back into the crawl-efficiency problem from the discovery section: slow responses mean the crawler reaches fewer new pages, so genuinely new content waits longer to be seen. Speed and crawl budget are the same problem read from two ends. The usual culprits are third-party scripts, tag managers and unoptimized server response, and reading it per template locates which of the three is costing the most and where — a slow template shows up both as an experience failure and as a crawl-budget drain.

Log file analysis — the evidence layer

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 actually 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. The pattern in almost every large-site log is the same one the crawl only hinted at: the bot spending its day in the low-value tail while the pages you care about get visited rarely.

Reading the logs is what turns “your crawl budget is probably wasted” into something exact: a specific share of Googlebot’s requests over a month hit URLs you don’t want indexed, and you can name them. A guess becomes a measurement — segmenting verified Googlebot’s hits by URL type against the crawl and the sitemap, so the picture shows where the bot actually spends its budget versus where the important URLs sit. Almost no audit reaches this layer, which is exactly why it’s worth reaching.

Is technical SEO still important in 2026?

Short answer: 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 actually 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 silently go blank. Crawl-efficiency, because AI crawlers now make up a real share of bot traffic and are far less efficient than Googlebot, so a wasteful URL space costs more than it used to. And retrievability, because being indexed is no longer the finish line. The question now is whether the engine can pull your specific passage into an AI answer, which puts rendering and structured data at the center rather than the margins.

So technical SEO didn’t shrink. It shifted from “is the tag present” to “can the machine actually reach, build, understand and retrieve this page” — which is the whole spine of this article, and the reason a 2018-era checklist reads as noise against a 2026 site.

Issue → Evidence → Impact → Fix — what the deliverable actually says

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. Not “the tool says so” — the actual reading, reproducible.
• 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 crucially 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 to validate the fix landed, because an unverified fix is a hope.

An audit that skips the owner column doesn’t get acted on — nobody knows whose job it is, so it becomes a document. An audit 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.

The issue count was never what mattered. Which three failures, fixed first, let the engine reach and index the pages that matter — that’s what a technical audit is for, and it’s a different deliverable from the one the scanner prints.

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

My read on where this goes: the free scanners will keep getting better at generating longer lists, and that will make the list worth less, not more, 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 actually bind, and which are the crawler flagging everything because flagging everything is all it can do. Within a couple of years the rendering and log layers stop being the advanced section of an audit and become the part any serious one is expected to reach. The reports still built to count issues will read like what they are: a scan, printed out, waiting for someone to actually read it.