A technical SEO audit finds and ranks the crawl, indexing, performance, and structured-data issues blocking a site's visibility, then tells you which one to fix first. If you do nothing else today, run a full crawl alongside a Google Search Console check. That combination surfaces most blockers fast, whether it's a Core Web Vitals failure, a rogue robots.txt rule, or an XML sitemap full of dead URLs.

Crawl the site with a desktop crawler such as Screaming Frog or Sitebulb
Pull coverage and performance data from Search Console — the full 16 months it retains
Flag anything blocking indexing before touching page speed

That last point is the one most audits get wrong, and it is the reason this guide runs in the order it does.

Key Takeaways

A website SEO audit checklist only pays off when indexing and crawl issues get fixed before performance work begins, since Google can't rank a page it can't see.

Point	Details
Fix indexing before speed	Resolve robots.txt and noindex issues before spending time on Core Web Vitals.
Give every check a threshold	Server response under 0.5 s, HTML under 0.5 MB, URLs under 140 characters, depth within three clicks — numbers make findings comparable between quarters.
Score with ICE, not gut feel	Impact × Confidence × Ease, each on a 1–10 scale, decides the order — not the tool's default sort.
Know the actual thresholds	LCP under 2.5 s, INP under 200 ms, CLS under 0.1, measured on field data rather than a Lighthouse run.
Check what schema still earns a result	FAQ and HowTo rich results have been withdrawn. Validate what remains: Article, Product, BreadcrumbList, VideoObject.
Re-audit on a cadence	Lightweight weekly crawls, a full audit quarterly, and one within 48 hours of every major deploy.

What Does a Technical SEO Audit Actually Check?

A real audit works through several distinct categories, and skipping any one of them leaves ranking potential on the table. The CrawlRaven checklist organises this into individual checks across those categories, which is a useful mental model even if you build your own list from scratch.

Crawlability and robots rules. Robots.txt syntax, server response codes, and whether bots can reach the pages that matter.
Sitemaps and discovery. XML sitemap validity, segmentation by content type, and whether it contains only indexable 200 URLs.
Crawl budget. Where bots actually spend their requests. On any site past a few thousand URLs, parameter URLs, redirect chains and noindexed pages quietly absorb crawl that should go to pages you update. Manage it from log data or the Crawl Stats report, not from intuition.
Indexing signals. Noindex tags, canonical conflicts, and X-Robots-Tag headers that quietly remove pages from the index.
Rendering and JavaScript. Whether Google sees server-rendered content or has to execute JS to find your text. Verify with the rendered-HTML view in URL Inspection after every significant front-end deploy, not once a year.
Redirects and link health. Broken links, redirect chains, and orphan pages that exist only in the sitemap. Also check the distribution: your commercially important pages should have the most internal links pointing at them, and in most audits they do not.
Performance and Core Web Vitals. LCP, INP and CLS — see the thresholds below and our guide to Core Web Vitals and rankings.
Structured data. Types that still produce a search feature, validated against Schema.org and the Rich Results Test.
Security, mobile, and duplicate content. HTTPS with no mixed content, mobile usability, and internal duplication.

One more layer belongs on this list now: AI search readiness. That means checking whether AI crawlers can reach your content, whether critical text is delivered as HTML rather than client-side JavaScript, and whether your pages are structured so an answer engine can extract and attribute them.

Binary Pass Criteria, So Findings Aren't a Matter of Opinion

A technical SEO checklist is only useful when every item has a threshold. Most tell you to "check redirects" and leave the judgement to you. Give each check a number instead — that turns a site audit checklist into something two people can score identically, and makes quarter-on-quarter comparison mean something.

Check	Pass criterion
Server response time	under 0.5 s on average; watch 0.5–1 s; fix above 1 s
Host redirects	one www/non-www version and HTTP→HTTPS via a single 301, no chains or loops
HTML weight and compression	gzip or brotli enabled; HTML under 0.5 MB
Mixed content	zero HTTP resources on HTTPS pages
Titles and descriptions	unique across the whole site, no duplicates and no blanks; length within the SERP display limit
Headings	exactly one H1 per page; H2/H3 hierarchy with no skipped levels
URL hygiene	no dynamic parameters or session IDs on indexable URLs; under 140 characters; no more than five directory levels
Click depth	every important page reachable within three clicks of the home page
Internal anchors	the same anchor text never points to two different pages
Sitemap	only indexable, canonical 200 URLs; no URL that exists in the sitemap and nowhere else
Internal links	point directly at the destination, never through a 301
Crawlability	every exclusion from the index is a decision, not a side effect of configuration

Server response time deserves a note. It sits at the top of this table because it multiplies through everything else: a slow origin caps LCP, throttles crawl rate, and drags conversion. It is also the single check most audits skip, because crawlers report it as a number rather than as an error.

The Core Web Vitals thresholds, precisely

A website performance audit starts with three numbers, not with a Lighthouse score. Vague advice to "improve speed" is why this work stalls. The three metrics and their pass thresholds are:

Metric	Threshold	What it measures
LCP	under 2.5 s	when the largest content element finishes rendering
INP	under 200 ms	responsiveness to user input across the whole visit
CLS	under 0.1	unexpected layout shift

Two things audits routinely get wrong here. INP replaced FID in March 2024, so any checklist still listing First Input Delay is out of date. And FCP is not a Core Web Vital — it is a useful diagnostic, but it does not belong in this table. Report on field data from the Core Web Vitals report in Search Console or the CrUX dataset; Lighthouse is for debugging, not for reporting.

A note on FAQ and HowTo markup

Plenty of audit checklists still ask you to validate FAQ and HowTo schema. That instruction is obsolete and worth removing from your template.

Google withdrew HowTo rich results from desktop in September 2023. FAQ rich results were restricted to government and health sites in August 2023 and deprecated entirely on 7 May 2026 — the Search Console report and Rich Results Test support went in June 2026, and API support in August 2026. Neither type produces a search feature today.

FAQPage remains a valid Schema.org type and existing markup can stay; Google has said unused structured data causes no problems. But it is no longer something to flag as a gap in an audit. Validate what still earns a result: Article, Product with Offer, BreadcrumbList, VideoObject, Organization.

Pro Tip: Check robots.txt for accidental blocks on AI crawlers such as GPTBot, OAI-SearchBot and Claude-SearchBot. Plenty of sites block these by default and never notice. Blocking them can be a deliberate business decision — it should never be an accident of configuration.

How Does the Audit Workflow Run Step by Step?

This is how to perform a technical SEO audit end to end. The SEO audit steps below run in this order for a reason: audits should confirm that Google can reach a page before anyone optimises how fast it loads. Seoxpert's audit framework warns against the reverse order for good reason: performance work on a noindexed page produces nothing. Follow the sequence.

Crawl and sample. Run a full site crawl supported by Search Console data and server logs. Deliverable: a crawl inventory spreadsheet with every URL, its status, canonical and indexability.
Diagnose indexability. Identify noindex tags, canonical conflicts, and gaps in sitemap coverage. Every URL excluded from the index should be excluded by decision, not by accident. Deliverable: an indexability report.
Diagnose performance. Assess Core Web Vitals on real templates using field data. Deliverable: prioritised fixes with metrics and screenshots.
Score and group. Rank findings by impact, confidence and ease, then group them into developer-ready batches.
Verify and monitor. Confirm fixes in Search Console and in field data, then set up recurring crawls.

Each step produces something concrete you can hand off, which is the difference between an audit and a list of observations.

Which Tools and Scans Should You Run?

No single tool covers a full SEO technical analysis, so you combine outputs by design rather than by accident.

A desktop crawler for discovery. It should flag JS-rendering issues, since a lot of modern frameworks hide content from bots that don't execute scripts.
Search Console and Bing Webmaster Tools for indexation status and crawl errors straight from the source. Search Console retains 16 months, which is the minimum you need to compare a period against the same period last year.
Lighthouse or PageSpeed Insights for debugging, paired with the Core Web Vitals report or CrUX for the numbers you actually report.
Server log analysis to see how bots behave rather than how you assume they behave, and to catch orphan pages crawlers never visit. Quarterly is enough for most sites.
A continuous crawl tool that re-runs on a schedule, so regressions surface between quarterly audits rather than at the next one.
The Rich Results Test to validate structured data before it ships, catching errors that would otherwise sit live for months.

How Do You Prioritize What to Fix First?

Two axes are not enough. Scoring by impact and effort alone is how a single unverified crawl warning ends up at the top of a roadmap. Add a third.

Impact (1–10). Estimate it in a business metric — revenue, leads, pipeline — not in sessions. A robots.txt line blocking /blog/ scores high because it removes a whole section from the index.

Confidence (1–10). How well is the finding evidenced? A blocker confirmed in both the crawl and Search Console scores high. A warning from one tool, with nothing corroborating it, scores low. Lower confidence when you are relying on a best practice rather than on your own data.

Ease (1–10). Anything requiring a developer sprint scores lower than something you can ship yourself. A template-level Core Web Vitals rewrite is high impact and low ease; a missing alt attribute is the opposite.

Multiply the three. Sort descending, take as many items as the quarter realistically absorbs, and review the rest next quarter — anything that has not been picked up in two consecutive quarters is telling you its real score was lower than it looked.

Present each item to non-technical stakeholders with an expected outcome, a time estimate, and the risk of leaving it alone. That framing gets budget approved faster than a raw list of errors ever will.

Pro Tip: If a stakeholder asks "what happens if we don't fix this," have a one-line answer ready for every top-tier item before the meeting starts.

How Should You Report Results and Set Audit Cadence?

A report earns its keep when it reads as an SEO health assessment over time, not as a snapshot. Track indexable page counts, coverage errors, the LCP/INP/CLS distribution, crawl errors, redirect chains, and structured-data errors.

Health score chart showing overall site condition at a glance
Issue distribution by category, so stakeholders see where problems cluster
Before-and-after Core Web Vitals trends tied to specific fixes

Confirm fixes in both Search Console and field data before marking them complete — a lab test passing is not the same as real users experiencing the improvement.

On cadence, three rhythms work together: a lightweight crawl weekly, so a regression shows up as a jump in the problem count rather than as a traffic drop; a full audit quarterly, including logs; and a comparison crawl within 48 hours of any major deploy. Most SEO disasters are unintended side effects of a release, caught too late.

Cadence catches regressions. Preventing them is a separate move: put SEO into the definition of done for front-end and infrastructure changes. Four conditions, each testable before a release ships — status codes still 200 or 301 as intended, meta robots and canonical unchanged unless the change was deliberate, critical content present in the rendered DOM, Core Web Vitals within the performance budget agreed with the developers. A release that fails any of the four does not go out. That single agreement removes more audit findings than any crawl schedule.

What Are the Fastest Wins in a Technical Audit?

Some fixes take an afternoon and move the needle within days. These five are worth tackling before anything else in a website optimization review.

Revert an accidental sitewide Disallow or template-level noindex, then request re-crawling.
Fix self-referencing canonical mismatches at the template level so pages stop competing with themselves.
Collapse multi-hop redirect chains into a single direct 301, and point internal links at the final destination.
Preload the hero image, convert it to a next-gen format, and set explicit width and height to cut LCP and CLS at once.
Defer non-critical third-party scripts and move analytics off the main thread to improve INP.

None of these requires a rebuild, all five ship in a single sprint, and each has a measurable before-and-after number you can put in a report.

How AI SEO COMPANY Runs a Technical Audit

Our process runs discovery crawl, indexability triage, prioritised remediation, verification, and ongoing monitoring, in that order, for the reason outlined above: performance work on pages Google cannot see spends budget without moving anything.

Crawl inventory covering every indexable and non-indexable URL
Fix list scored by impact, confidence and ease
Developer-ready tickets with testable acceptance criteria, not vague recommendations
A verification report confirming fixes actually landed
Weekly automated crawls between audits, so regressions surface in days rather than at the next quarterly review

The biggest waste we see is teams rewriting templates for Core Web Vitals while a noindex tag or a robots.txt rule is still sitting there removing the page from the index. Discovery first. Speed matters once Google can see the page.

Audits run inside a monthly subscription alongside the rest of the SEO work; in exceptional cases we scope one as a standalone project, quoted per scope. You can see what each engagement level includes on the SEO services page, where completed projects are published as growth models with the traffic and revenue changes behind them. Results depend on your starting position and how much of the fix list actually ships — no agency can guarantee an outcome.

To start, request a scoped SEO audit. We reply to enquiries in under two hours and send an initial proposal within 24 hours.

Frequently Asked Questions

We're migrating to a new domain. When should we audit?

Twice: once on the staging environment before launch, to catch noindex tags and blocks that would otherwise ship to production, and again daily for the first four weeks after. A drop of 10–20% for two to six weeks is common and not by itself a sign of failure. No recovery after eight weeks means something is wrong with the redirect map or index coverage, and that is when you go looking rather than waiting.

How long does a site audit take?

A single-domain audit typically takes a few days to a week, depending on site size and whether log-file analysis is included. An enterprise SEO audit on a site with millions of URLs takes longer and usually needs a modular approach rather than one full crawl.

How often should I re-audit?

Lightweight crawls weekly, a full audit quarterly, and an extra comparison crawl within 48 hours of any major deploy, redesign, or migration.

What's the difference between an on page SEO checklist and a technical audit checklist?

An on page SEO checklist covers content elements — titles, headings, keyword coverage. A technical audit covers crawlability, indexing, rendering, and infrastructure, which content-level fixes cannot touch.

Do I need both an automated crawler and manual checks?

Yes. Automated scans catch volume issues like broken links and missing tags fast, but manual verification catches context-specific problems — a canonical tag that is technically valid while pointing at the wrong page, for instance.

Should I still add FAQ schema during an audit?

Not as a ranking or SERP tactic. FAQ rich results were deprecated on 7 May 2026 and HowTo in 2023. Keep briefing FAQ content — a visible block of real questions with direct answers — but stop treating the markup as a finding.

What questions should I ask before hiring a technical SEO specialist?

Ask for a sample crawl inventory, how they score and order fixes, and whether they verify results after implementation. A specialist who cannot show a fix-verification process is skipping the step that proves the audit worked.

Sources

Google documentation

Google Search Central — Core Web Vitals; INP replaced FID as a Core Web Vital in March 2024
Google Search Central — FAQPage structured data, deprecation notice dated 7 May 2026; Search Console and Rich Results Test support removed June 2026, API support August 2026
Google Search Central — HowTo structured data deprecated on desktop, September 2023
Google Search Console Help — 16-month data retention

Industry guides

Last reviewed: August 2026. Structured data guidance reflects Google documentation as of that date.

Technical SEO Audit Checklist for Digital Marketers