What a Technical SEO Audit Covers

What the word technical is doing in that phrase

A technical audit answers four questions about your site and deliberately declines to answer a fifth. Can a search engine reach your pages? When it does, does it see what a visitor sees? Does it store the right ones and leave out the rest? And do those pages load and respond well enough to meet a published set of thresholds? The fifth question — is the content any good, does it deserve to rank, is anyone linking to it — is a different audit with different methods, and mixing the two produces a document that is vague about both.

This matters commercially because “SEO audit” is sold as one thing and delivered as several. If the report you receive spends thirty pages on keyword opportunities and four on indexation, you did not buy a technical audit. If it spends thirty pages on crawler warnings sorted by severity color, you bought a tool export.

Everything below is scope. Not all of it applies to every site, and a good audit says which sections do not apply to yours and why — that sentence is worth more than the sections that do.

Can it be reached: crawl

The first question is whether search engines are requesting your pages at all, and what they get when they do.

• robots.txt — what is disallowed, whether anything important is caught by a pattern nobody has read since a redesign, and whether the file itself returns cleanly.
• Status codes actually served, which is not always what the CMS reports. The inventory that matters: 200, 301 and 302, 304, 404 and 410, 429, and any 5xx. Google treats 404 and 410 as a strong signal not to crawl a URL again, and treats persistent 5xx and 429 responses as instructions to slow down — which means server errors actively suppress crawling rather than merely inconveniencing visitors.
• Redirects. Googlebot follows up to ten hops, but Google's own migration guidance is to redirect straight to the final destination. Chains are found by crawling, and the ones that hurt are usually the ones introduced accidentally by a rule that ran after another rule.
• XML sitemaps — whether they exist, whether they list canonical URLs only, and whether <lastmod> is accurate rather than set to the date of the last database refresh.
• Server response time and caching. Google states the causal link directly: faster loading and rendering means it may be able to read more of your content. Supporting 304 Not Modified lets it reuse a cached copy.

Does it see what a visitor sees: render

Google's pipeline has three stages — crawl, then render, then index — and a page only enters the render queue after being crawled successfully. Google is explicit that a page can sit in that queue for a few seconds or considerably longer, and publishes no upper bound.

The audit work here is a comparison. Fetch the raw HTML the server sends, then look at the rendered DOM, and diff them. On a site where content, internal links or canonical tags are injected by JavaScript after load, the two can differ enormously, and every conclusion drawn from a source-HTML crawl is then wrong. Google's own diagnostic for this is the URL Inspection tool, which shows the rendered HTML and lets you confirm the content is present after rendering.

One under-known detail belongs in every audit of a JavaScript-heavy site: Google's Web Rendering Service may ignore caching headers, which can leave it executing outdated JavaScript or CSS. Google's stated mitigation is content fingerprinting in asset filenames. And Google's own argument for server-side rendering is worth repeating to a development team that thinks this is only about Googlebot — not all bots can run JavaScript, which in 2026 covers a growing population of crawlers that are not Google's.

Is the right set stored: index

Indexation problems split into two kinds, and they need opposite remedies. Pages that should be in the index and are not, and pages that are in the index and should not be.

For the first: what does Search Console give as the reason, and is it credible? “Discovered — currently not indexed” at scale is a specific and diagnosable signal rather than a mystery. Check for accidental noindex on a template, canonical tags pointing somewhere unintended, pages orphaned from internal linking, and soft 404s where a page returns 200 while telling the visitor nothing was found.

For the second: the audit inventories every mechanism generating URLs. Parameters, filters, sort orders, session identifiers, pagination, print views, internal search results. Faceted navigation is the usual culprit, and Google describes the mechanism plainly — crawlers cannot tell whether a novel filtered URL is useful without crawling it, so they will typically request a very large number of them before concluding they are not. Where facet URLs should not be indexed, Google's preferred controls are a robots.txt disallow or URL fragments, which it does not crawl. Notably, Google states that rel="nofollow" and rel=canonical are generally less effective in the long term for this purpose — which contradicts a lot of received practice and is worth checking against whatever your site currently does.

One more correction that saves money: noindex is the wrong tool for controlling crawl volume. Google still requests the page and then discards it, so the crawl cost is paid anyway.

Does it perform: the three numbers and their thresholds

Page experience is measured by three metrics, all at stable status, all assessed at the 75th percentile of real page loads and segmented by mobile and desktop. Lab scores from a testing tool are diagnostic; the field distribution is what counts.

• Largest Contentful Paint — good at 2.5 seconds or under.
• Interaction to Next Paint — good at 200 milliseconds or under; over 500 milliseconds is poor.
• Cumulative Layout Shift — good at 0.1 or under; over 0.25 is poor.

Two specifics that change how the numbers are read. INP replaced First Input Delay as a stable Core Web Vital in 2024, so any audit still reporting FID is out of date. INP measures only three interaction types — mouse clicks, touchscreen taps, and key presses — and explicitly excludes scrolling, hovering and zooming; it captures the whole span from interaction start to the next frame being fully presented, not just the input delay. CLS is not the sum of every shift on the page: shifts are grouped into bursts when the gap between them is under one second, with a maximum window of five seconds, and the reported figure is the largest such burst. The thresholds and lifecycle status are published in full.

The sections that only apply to some sites

An audit that runs every check on every site is padding. These are conditional, and the condition should be stated.

• Crawl budget. Google names the thresholds where this becomes a real constraint: sites with a million or more unique pages whose content changes roughly weekly, sites with ten thousand or more pages changing daily, or any site with a large proportion of URLs sitting at “Discovered — currently not indexed”. Below those thresholds it is usually not your problem, and a crawl-budget project sold to a two-thousand-page site is a project sold against a non-problem.
• Faceted navigation. Applies to catalogs and listing sites, not to brochure sites.
• International annotations. If you serve more than one language or country, every hreflang pair is checked for return links, valid codes, and agreement with the canonical tags — the most common failure produces no error message anywhere.
• Structured data. Validity, and whether the markup matches what is visible on the page. Worth stating clearly: there is no special structured data required for AI features, whatever is being sold on that basis.
• Log file analysis. Valuable on large sites and impossible on some hosted platforms. It shows what Search Console's crawl report cannot, including full user-agent strings, which is how you separate Googlebot from the AI crawlers now in the mix.

Where the evidence comes from, and what each source cannot see

A finding is only as good as the instrument behind it, and every instrument here is partial.

A crawler sees what it is configured to request from one location at one moment, and will happily report a thousand instances of a problem that lives in one template. Search Console's Crawl Stats report gives request counts, response codes, file types, crawl purpose and Googlebot type, plus host status across robots.txt fetch, DNS and connectivity — but Google documents that some requests might not be counted, only your own domain is included, and the example URLs shown are samples rather than complete lists. It also cannot show a request that never reached your server. The Performance report caps at 1,000 rows in the interface and retains 16 months, which on a large site means it cannot describe the site at all without the API or a bulk export. Field performance data comes from real visits and needs enough traffic per template to be meaningful.

Server logs are the only complete record of what was actually requested and what was actually served, which is why they are worth the extraction effort on large sites and why a platform that cannot expose them sets a hard ceiling on the audit.

What separates an audit from a crawler export

Both documents contain a list of problems. Only one of them is usable.

The difference is that an audit answers three additional questions for every finding. What is this costing? — expressed as the pages and traffic affected, not as a severity color. What does fixing it involve? — which template, which system, which team, and roughly how much of their time. How will anyone know it worked? — the specific measurement, taken before and after, with a stated waiting period.

That last one is what makes an audit checkable, and it is the item most often missing. “Fix duplicate title tags” cannot be verified. “The category template produces 340 duplicate titles; change the template so the title includes the active filter; re-crawl to confirm zero exact duplicates; watch impressions on those 1,100 URLs against today's baseline” can be closed or not closed by anyone.

The other tell is ordering. Findings sorted by tool severity are sorted by the tool's opinion; findings sorted by traffic at risk against engineering effort are sorted by yours. Prioritization is the hard part and the part a crawler cannot do, which is why a document that skipped it is not finished.

Frequently Asked Questions

Published 2026-08-11