The Technical SEO Audit Checklist

Setting up the audit correctly

Before running a single check, confirm access to the four data sources every credible audit needs: Google Search Console, a crawler (Screaming Frog or an equivalent), server log files covering at least thirty days, and either GA4 or an equivalent analytics platform. Missing any one of these forces guesswork in place of evidence.

Segment the site by template before crawling, not just by URL depth — a large site's problems are almost always concentrated in specific templates (a faceted product listing, a legacy blog template, a staging subdomain accidentally left crawlable) rather than spread evenly, and template-level segmentation finds the pattern faster than a flat URL list does.

Establish the audit's scope and cadence up front — a full audit quarterly, with a lighter monthly health check covering just crawl stats, Core Web Vitals, and indexation counts, catches regressions early rather than letting them compound for a full year between full audits.

Crawlability

Check robots.txt for accidental disallow rules — the single most damaging technical SEO bug we still see in the wild is a staging-environment robots.txt rule left in place after a production deploy, silently deindexing an entire site over a period of weeks.

Verify sitemap coverage matches what should actually be indexed — a sitemap listing URLs that 404, redirect, or carry a noindex tag wastes crawl budget and signals poor site hygiene; a sitemap missing URLs that should be indexed means new or updated content may take significantly longer to be discovered.

Audit JavaScript-rendered content specifically — confirm that content requiring client-side rendering is actually visible in Google's rendered HTML (via the URL Inspection tool), not just present in the source after a build step that a search engine's renderer may not fully replicate.

Find orphan pages — pages with no internal links pointing to them, discoverable only via the sitemap or external links. These consistently underperform equivalent pages that have real internal-linking equity, and finding them is only possible by cross-referencing the crawl against the sitemap and internal-link graph.

Trace internal redirect chains and fix them at the source — every redirect hop dilutes link equity and adds latency, and chains of three or more hops are a common byproduct of years of incremental URL changes without a cleanup pass.

Indexation

Reconcile Search Console's indexed-page count against the actual sitemap count and a site: search sample — meaningful discrepancies in either direction indicate either an indexation problem or a sitemap-hygiene problem, and the audit needs to identify which.

Hunt for soft 404s at scale, particularly on faceted navigation, expired product pages, and thin paginated archives — these are pages that return a 200 status but contain no meaningful content, and search engines increasingly detect and effectively deindex them even without an explicit signal telling them to.

Audit parameterised URL bloat from filters, sorting, and tracking parameters — left unmanaged, these can multiply a site's crawlable surface area by an order of magnitude with almost no unique content to show for it, directly wasting crawl budget that should go to genuinely valuable pages.

Check for noindex misuse — both accidental noindex tags left on pages that should rank, and the absence of noindex on pages that genuinely shouldn't be in the index (internal search results, thank-you pages, duplicate print versions).

Rendering

Compare server-rendered HTML against client-rendered final output for every major template — any content, links, or metadata that only appear after client-side JavaScript execution carry meaningfully more indexation risk than content present in the initial server response, even with a capable renderer on the search engine's side.

Measure hydration cost specifically for frameworks that hydrate client-side — a page that appears fully rendered but isn't yet interactive has a hidden INP problem that field data will eventually surface, and it's cheaper to catch in an audit than in a subsequent Core Web Vitals regression investigation.

Quantify third-party tag impact on INP directly — disable each third-party script one at a time in a controlled test and measure the delta, rather than guessing which of a dozen tags is the culprit. This single exercise routinely finds the highest-leverage performance fix in an audit.

Performance

Pull field Core Web Vitals from CrUX for the site's actual URLs, segmented by device type — mobile and desktop performance profiles frequently diverge enough that a single blended score hides a serious mobile-specific problem.

Layer in RUM data from the site's own analytics or a dedicated RUM tool for a more granular, real-time view than CrUX's rolling 28-day aggregate provides, particularly useful for measuring the immediate impact of a specific fix rather than waiting a month for CrUX to reflect it.

Inspect the actual LCP element on priority templates — confirm it's the content the business wants prioritised (a hero image, a headline) rather than an unintended element like a cookie-consent banner or an ad slot that happens to render largest first.

Autopsy INP handlers on the templates with the worst scores — profile the JavaScript execution during a real interaction (button click, menu open) to find the specific long task causing the delay, rather than applying generic performance advice that may not address the actual bottleneck.

Structured data

Run every template through the Rich Results Test and a general schema.org validator — these catch syntax errors and missing required properties, but not semantic mismatches, so treat a clean validator pass as necessary, not sufficient.

Manually spot-check a sample of pages for semantic accuracy — a Product schema stating an item is in stock when it isn't, or a Review schema with an inflated aggregate rating, is syntactically valid and a real trust and policy risk simultaneously.

Confirm coverage of every feature-earning schema type genuinely applicable to the site — FAQPage, HowTo, Article, LocalBusiness, Product, BreadcrumbList — rather than deploying only the one type the original build happened to include.

Set up ongoing monitoring for schema errors via Search Console's Enhancements reports, checked at minimum monthly, since a template change elsewhere in the codebase can silently break structured data on a whole page type without anyone noticing until organic performance drops.

Log-file analysis

Pull at least thirty days of raw server logs and filter to verified search-engine bot traffic — this is the only data source that shows exactly what a crawler actually requested and how it was treated, as opposed to every other tool's inference from crawl simulation or reported indexation.

Identify which templates and URL patterns consume the largest share of crawl budget, and cross-reference against which of those actually drive organic traffic or conversions — a disproportionate share of crawl activity on low-value parameterised URLs at the expense of priority content is one of the clearest, most actionable findings a log analysis can produce.

Check crawl frequency on recently updated priority pages specifically — if a page updated last week hasn't been recrawled, that's a direct, measurable signal of an indexation or crawl-budget problem worth escalating above most other findings.

Compare bot response-code distribution against the site's overall response-code distribution — a bot disproportionately hitting 404s, 500s, or redirects relative to real users suggests the crawler is being routed toward broken or legacy paths that ordinary navigation avoids.

International and migration considerations

Verify hreflang correctness bidirectionally — every hreflang annotation needs a matching return annotation on the target page, and the single most common hreflang bug is a one-directional relationship that search engines simply ignore.

Audit redirect maps from any recent migration for completeness and accuracy, checking a statistically meaningful sample against both the old URL structure and current analytics data for the highest-traffic legacy pages specifically, not just a spot-check of the map file.

Confirm the canonical strategy across locales doesn't accidentally canonicalise distinct-language or distinct-region content to a single version, which silently removes an entire locale from consideration in its target market's search results.

Security and infrastructure checks

Confirm HTTPS is enforced sitewide with no mixed-content warnings and no lingering HTTP versions still crawlable or indexed from a past migration. Check that the canonical protocol and www/non-www preference are configured consistently at the server level, not just in the meta tags, since a server-level mismatch overrides page-level signals.

Review CDN and caching configuration for any rules inadvertently serving stale or incorrect content to search-engine bots specifically — a caching rule that serves an old version of a page to a bot user-agent while serving current content to browsers is a subtle but real source of ranking and indexation problems.

Prioritising the backlog

Score every finding on two axes — estimated impact and estimated effort — and prioritise high-impact, low-effort fixes first regardless of how technically interesting a larger finding might be. This is where most audits lose credibility: a hundred-item list with no prioritisation is a research document, not an actionable plan.

Group related findings into single work items where they share a root cause — a dozen individual soft-404 examples are one fix (a rule change for the underlying template condition), not twelve separate tickets, and presenting them as one item both clarifies the effort estimate and speeds implementation.

Assign an owner and a target week to every item in the final backlog before delivery, not just a priority label — a backlog without accountability attached tends to stall regardless of how well it was prioritised.

The executive summary

One page, no exceptions. State the business impact in plain terms before any technical detail — what's being lost or left on the table because of the top issues found, expressed in traffic, conversion, or revenue terms wherever the data supports it.

List the top five risks and the top five opportunities as two short, ranked lists — not the full findings list restated at a higher level. The executive summary's job is to be read in ninety seconds by someone who will never read the full audit, and to give them enough to authorise the work.

Close with the ordered backlog, owner, and target week for the highest-priority items — the reader should be able to answer 'what happens next and when' from the summary alone, without needing to open the appendix.

The first 30/60/90 days after an audit

Days 1–30: fix every high-impact, low-effort item identified — these are almost always crawlability and indexation bugs (robots.txt errors, sitemap mismatches, obvious redirect chains) that require developer time measured in hours, not weeks, and typically produce the fastest visible improvement in Search Console.

Days 31–60: execute the performance workstream — third-party tag audit and remediation, LCP element fixes, INP handler optimisation — since these require more coordinated developer effort and QA than the day-1-30 fixes but compound significantly once shipped.

Days 61–90: complete structured-data deployment and validation across all templates, finish any migration or hreflang cleanup, and establish the ongoing monthly health-check cadence so the next full audit finds a maintained baseline rather than a full year of undetected drift.

Questions we get about this guide

How often should a full technical SEO audit be run?

Quarterly for most active sites, with a lighter monthly health check on crawl stats, indexation counts, and Core Web Vitals in between.

Is a Lighthouse score of 100 sufficient proof of good performance?

No. Lighthouse is lab data from a single simulated condition. Field data from CrUX and RUM, reflecting real users on real networks and devices, is what search systems and actual visitors experience.