Technical SEO Audit: The Complete 2026 Checklist
A technical SEO audit answers one question: is there anything about how this website is built that stops search engines finding, understanding or trusting its pages?
It is not a content review and it is not a keyword exercise. It is the structural survey you do before investing in either, because content published on a site with indexing problems is content nobody will ever read.
The problem with most audits is that they produce a 60-page document listing 300 issues in no particular order, which is overwhelming enough that nothing gets fixed. A useful audit is short, ordered by impact, and written so the person implementing it knows exactly what to change.
This is the checklist we actually work through, in the order we work through it: crawling and indexing first, because nothing else matters if pages are not being seen; then duplication, architecture, performance, rendering, structured data and internationalisation. At the end there is a framework for deciding what to fix first, which is the part most checklists leave out.
What a technical audit is, and what it is not
A technical audit examines the infrastructure of a site: how it is crawled, how it renders, how URLs resolve, how quickly it loads and how clearly it describes itself to machines.
It does not tell you whether your content is good, whether you are targeting the right keywords, or whether your backlink profile is strong. Those are separate reviews. Conflating them is why audits balloon into unusable documents.
The value of doing it first is sequencing. If a section of your site is accidentally blocked, or half your pages are canonicalised to the homepage, then every hour spent on content is wasted until that is fixed. Technical work rarely produces dramatic ranking gains on its own — its job is to remove the ceiling that stops everything else working.
One caveat worth stating plainly: a technically flawless site with nothing worth reading will not rank. Technical SEO is necessary, not sufficient.
Before you start: three sources of truth
Every finding should come from real data about your site rather than a generic best-practice list.
Google Search Console is the most important, because it tells you what Google actually did rather than what a third-party tool predicts. The Page Indexing report, in particular, is where most serious problems surface first.
A crawler — Screaming Frog, Sitebulb or similar — which walks your site the way a bot would and exposes response codes, redirect chains, duplicate titles, orphan pages and depth problems at scale.
Field performance data, meaning how real users experience your site rather than a synthetic lab test on a fast connection. Lab scores are useful for diagnosis; field data is what actually counts.
Cross-referencing all three is what separates a real audit from a tool export. A crawler might report a page as fine while Search Console shows it excluded from the index — and that contradiction is usually where the interesting problem lives.
Crawling and indexing
This is the foundation. Work through it before anything else, because every issue here invalidates work done further down the list.
Can search engines reach your pages?
Start with robots.txt. A single misplaced disallow can remove an entire section from search, and it happens more often than you would expect — usually when a staging rule survives a launch. Check that nothing important is blocked, and that you are not blocking CSS or JavaScript files that the page needs in order to render properly. Google’s robots.txt documentation covers the syntax precisely, and the syntax is unforgiving.
Then check for accidental noindex tags. These hide in theme settings, SEO plugin defaults and page templates. A noindex on a template can silently remove hundreds of pages at once, and because the pages still load normally for humans, nobody notices until traffic drops.
Finally look at crawl depth. Pages more than three or four clicks from the homepage get crawled less often and tend to rank worse. If your most valuable pages are buried, that is an architecture problem worth fixing.
Is the right set of pages indexed?
Two failure modes, and they pull in opposite directions.
Pages missing from the index that should be there. Search Console will usually tell you why — discovered but not crawled, crawled but not indexed, blocked, or excluded by a canonical. “Crawled, currently not indexed” is the most common and most frustrating: it generally means the page was assessed as not worth including, which is a quality signal rather than a technical fault.
Pages in the index that should not be. Tag and author archives, paginated duplicates, internal search result pages, thin category pages, filtered ecommerce URLs producing near-infinite combinations, and leftover staging URLs. Index bloat dilutes the crawl attention available for pages that matter and drags down overall quality signals.
The fix depends on intent. Use noindex for pages that must exist for users but do not belong in search. Use canonical tags where several URLs are genuine variants of one page. Block in robots.txt only where you want to prevent crawling entirely — and remember a blocked page cannot be seen to have a noindex tag, which is a classic way to get stuck.
XML sitemaps
Your sitemap should list exactly the URLs you want indexed, and nothing else. Common problems: sitemaps containing redirected or 404 URLs, containing noindexed pages, missing recently published content, or not being referenced in robots.txt.
Check the submitted-versus-indexed counts in Search Console. A large gap is a signal worth investigating, not a number to accept.
Duplication and canonicalisation
Duplicate content is rarely plagiarism. It is almost always the same page reachable at several URLs.
The usual culprits: HTTP and HTTPS both resolving, www and non-www both resolving, trailing-slash and non-trailing-slash variants, URLs with tracking or session parameters, uppercase and lowercase paths, and paginated series where every page canonicalises to page one.
Every version should resolve to one canonical URL through a 301 redirect, with a self-referencing canonical tag on the destination. Google’s guidance on consolidating duplicate URLs explains the precedence rules, which matter when signals conflict.
Watch for canonical tags that point somewhere unexpected. A template error canonicalising every page to the homepage will remove an entire site from search results while every page still loads perfectly for visitors. It is one of the most damaging and least visible faults there is.
Also check for genuine content overlap, where two separate pages target the same query and compete with each other. Usually the right answer is to merge them into one stronger page and redirect the weaker URL.
Site architecture and internal linking
Architecture determines how authority moves around your site and how easily anything gets found. It is the most under-audited area on this list.
Look for orphan pages — URLs with no internal links pointing at them. They are usually in the sitemap and invisible everywhere else, and search engines treat them as unimportant because your own site does.
Check click depth for your commercially important pages. If a key service page takes five clicks to reach, it is being told it does not matter.
Review anchor text. Internal links reading “click here” or “read more” pass no context. Descriptive anchors help both users and search engines understand the destination.
Look at topical grouping. Related pages should link to each other so a reader arriving on one can find the rest. Blogs that publish consistently without internal linking slowly become a pile of disconnected posts, each fending for itself.
This is ongoing work rather than a one-time fix, which is why it forms part of our monthly WordPress SEO plan rather than sitting only in the initial audit.
Core Web Vitals and performance
Three metrics matter, and they measure different kinds of frustration.
Largest Contentful Paint (LCP) — how long until the main content appears. Usually held back by oversized images, slow server response, or render-blocking resources.
Interaction to Next Paint (INP) — how quickly the page responds when someone interacts with it. Almost always a JavaScript problem: too much of it, executing on the main thread at the wrong moment.
Cumulative Layout Shift (CLS) — how much the page jumps while loading. Caused by images without dimensions, ads and embeds injected above existing content, and web fonts swapping late.
Use field data from real users as the source of truth and lab tools for diagnosis. A perfect lab score means little if real visitors on mid-range phones are having a poor experience — and mid-range phones on ordinary connections are the realistic case for most audiences. The Core Web Vitals documentation defines the current thresholds.
Be realistic about what is fixable. Image compression, removing unused plugins and scripts, and reserving space for dynamic elements are usually where the meaningful gains are. Beyond that you are into theme and hosting decisions, and it is worth being honest with yourself about whether a redesign is really on the table.
Mobile
Google indexes the mobile version of your site. If your mobile pages contain less content, fewer internal links or different structured data than desktop, the reduced version is the one being assessed.
Check that content is not hidden or removed on mobile, that tap targets are large enough and not crowded, that text is readable without zooming, and that nothing overflows horizontally. Test on a real device rather than only a browser emulator — emulators miss touch behaviour, font rendering and the effect of a slower processor.
Intrusive interstitials deserve a specific mention. A cookie banner or newsletter popup that covers the content on a small screen is both a ranking risk and a conversion problem.
JavaScript rendering
If your site relies on JavaScript to build its content, this section matters enormously. If it is a mostly static site, you can move through it quickly.
The question is whether important content and links exist in the initial HTML or only appear after JavaScript executes. Rendering does happen, but it is deferred and not guaranteed for every page on every crawl. Content that depends on it is at a disadvantage.
Compare the raw HTML source against the rendered DOM. If your main content, headings, canonical tags or internal links are absent from the source, consider server-side rendering or static generation for those elements.
Pay particular attention to links built as JavaScript click handlers rather than real anchor tags with href attributes. Those are frequently not followed at all, which quietly removes whole sections from discovery.
Structured data
Structured data does not directly improve rankings, but it makes pages eligible for richer result types and helps machines — increasingly including AI systems — interpret what a page is about.
Check that the schema types you use are appropriate for each page, that required properties are present, that the markup validates, and that it describes what is genuinely on the page. Marking up reviews you do not display, or FAQs that do not appear to users, is a policy violation rather than a clever tactic.
Watch for conflicting or duplicated markup, which is common when a theme and an SEO plugin both output schema for the same page. Two competing definitions of the same entity is worse than one.
Our free schema generator produces valid JSON-LD for the common types, and the FAQ schema generator handles question markup specifically.
International and multi-language setup
Only relevant if you serve multiple languages or regions, but when it applies it is a frequent source of expensive errors.
Hreflang annotations must be reciprocal — if page A points to page B as its alternate, B must point back to A. They must use valid language and region codes, include a self-referencing tag, and ideally specify an x-default for unmatched visitors. A single missing return tag can invalidate the whole cluster.
Check also that each language version is genuinely distinct rather than machine-translated boilerplate, and that regional variants are not competing against each other for the same audience. Our hreflang generator builds correct annotation sets and flags the reciprocity requirement, which is the rule broken most often.
HTTPS, redirects and broken links
Confirm HTTPS is enforced site-wide with a valid certificate and no mixed-content warnings from assets still loading over HTTP.
Audit your redirects. Chains where one URL redirects to another and then another waste crawl budget and lose a little signal at each hop — point the first URL at the final destination instead. Watch for redirect loops, and for soft 404s where a missing page returns a 200 status with a “not found” message, which prevents search engines from ever removing it.
Fix broken internal links, which are entirely within your control and signal neglect. Broken outbound links matter less but still degrade the experience.
Finally, check how your titles and descriptions actually render in results — truncation is measured in pixels rather than characters, so character counts mislead. Our SERP snippet preview shows the real cut-off point, and the meta tag generator builds the head block.
How to prioritise what you find
This is the step that determines whether an audit is useful. A list of 200 issues is not a plan.
Score each finding on two axes: impact — how much traffic or revenue is affected — and effort — how hard it is to implement. Then work in this order:
- High impact, low effort. Do these immediately. A stray noindex, a wrong canonical, a blocked directory. These are often single-line fixes that recover significant visibility.
- High impact, high effort. Plan these properly with whoever owns the site. Architecture changes, migrations, rendering strategy.
- Low impact, low effort. Batch them and clear them when convenient.
- Low impact, high effort. Write them down and consciously decline to do them. Perfect technical scores are not the goal.
Weight by the pages affected, too. A problem on one blog post from 2019 is not equivalent to the same problem on a template used by every product page.
Each item should say what is wrong, which URLs are affected, why it matters, and what specifically to change. “Improve site speed” is not actionable. “Compress the 14 hero images listed here, all currently over 1MB” is.
How often should you audit?
A full audit once or twice a year is enough for most sites. What matters more is continuous monitoring in between, because technical problems are usually introduced by changes rather than appearing spontaneously.
Run a focused check after any site redesign, platform migration, URL structure change, major plugin or theme update, or significant template change. Those are the moments things break.
Between audits, watch the Page Indexing report monthly and set an alert for sudden changes in indexed page counts. A drop of a few hundred pages overnight is a fault, and catching it in a week rather than a quarter is the difference between an inconvenience and a serious problem.
If you would rather not own this yourself, technical monitoring and fixes are part of our ongoing SEO services, and every plan starts with the audit above. You can also run a quick content-side check with our content citability score or browse the rest of the free SEO tools. If you want a second opinion on what an audit turned up, send it over.
If you are pricing up this work rather than doing it yourself, our guide to SEO pricing packages explains what an audit should cost. Software companies with a longer buying cycle should also read our guide to B2B SaaS SEO.
Frequently Asked Questions
What is a technical SEO audit?
It is a structured review of how a website is built, covering whether search engines can crawl it, index the right pages, understand its structure, and load it quickly enough for real users. It deliberately excludes content quality and backlink analysis, which are separate reviews.
How long does a technical SEO audit take?
A small site of a few dozen pages can be audited properly in a day or two. A large ecommerce site or a multi-language site takes one to two weeks. Crawling is quick; the time goes into interpreting contradictions between what the crawler, Search Console and field data each report.
What is the most common technical SEO problem?
Indexing issues, by a wide margin — pages excluded by a stray noindex, a misconfigured canonical, or a robots.txt rule that survived a launch. They are common because the pages still load normally for humans, so nothing looks broken until traffic falls.
Can I do a technical SEO audit myself?
Yes, for a smaller site. Search Console plus a crawler will surface most of the important issues, and this checklist covers the order to work through them. The harder parts are interpreting conflicting signals and deciding what is genuinely worth fixing rather than fixing everything.
How much does a technical SEO audit cost?
Standalone audits typically range from a few hundred dollars for a small site to several thousand for a complex one. The question that matters more than the price is whether implementation is included — an audit that produces only a document leaves the expensive work with you.
Will fixing technical SEO improve my rankings?
It removes obstacles rather than creating growth on its own. If pages were blocked, duplicated or unreachable, fixing that can produce a clear improvement. If the site was already technically sound, the gain will be small and progress will depend on content and authority instead.
How often should a technical audit be repeated?
A full audit once or twice a year, plus a focused check after any redesign, migration, URL change or major template update. Continuous monitoring of the Page Indexing report matters more than audit frequency, since most problems are introduced by changes.
Do Core Web Vitals really affect rankings?
They are a genuine but modest signal, and they matter most as a tiebreaker between pages of similar relevance. Their larger effect is on user behaviour — slow, unstable pages lose visitors before search rankings become the issue.
Ready to grow your rankings?
Get a free consultation and a tailored growth plan for your business.
Get free consultationContinue reading
Related articles
B2B SaaS SEO: How to Build a Pipeline-Driven Strategy
How B2B SaaS SEO actually works: bottom-funnel pages that close deals, mapping keywords to the buying committee, programmatic pages, links, and measuring pipeline.
SEO Pricing in 2026: What SEO Packages Actually Cost
Real SEO pricing for 2026: the four pricing models, what packages cost at every budget level, what drives the price, warning signs, and how to compare quotes.
Schema Markup Generator: The Complete Guide to Structured Data
Schema markup helps search engines and AI understand your pages. Learn every major schema type, JSON-LD syntax, how to validate it, and how to generate it free.