Technical SEO Audit Checklist 2026

A technical SEO audit checklist is not a list of every warning a crawler can produce. It is a way to find the technical problems that stop search engines discovering, rendering, indexing, ranking, and users using your most valuable pages.

The current page already ranked for audit checklist queries, but it was missing several checks that now separate a basic crawl from a serious technical SEO review: JavaScript rendering, log file analysis, Google Search Console workflow, faceted navigation, accessibility, and a usable template structure.

This technical SEO checklist is written for 2026 search conditions. It covers the checks I run when auditing a site, how to interpret the findings, and how to prioritise fixes so the audit becomes a plan rather than a spreadsheet of unresolved problems.

Table of contents

• Start with what a technical SEO audit checks
• Use the checklist without creating noise
• Set up free tools and paid tools before the audit
• Run the Google Search Console audit workflow
• Check crawlability, crawl budget and URL controls
• Check indexing, canonicalisation and duplicate content
• Audit JavaScript rendering and crawlability
• Review site architecture, internal links and on-page technical checks
• Review structured data, E-E-A-T and accessibility
• Fix status codes, broken links and server errors
• Audit page speed, Core Web Vitals, mobile SEO and HTTPS
• Validate international SEO and hreflang
• Use log file analysis and server-level checks
• Prioritise findings and decide audit frequency
• Use the free technical SEO audit template and FAQs

What is a technical SEO audit?

A technical SEO audit checks whether search engines can discover, crawl, render, index, understand, and trust the pages that matter to the business.

Technical SEO sits underneath content and authority. If Google cannot access a page, understand the rendered HTML, select the correct canonical URL, or trust the site architecture, better copy and more links will only go so far.

Google explains how Google Search works as a process of discovering URLs, crawling them, indexing the content, and serving results when the page is relevant. A technical audit follows the same chain and asks where the chain is weak.

A useful audit does not treat every issue as equal. A duplicate title on a low-value tag page is not the same as a commercial page blocked by robots.txt. The output should tell a developer, marketer, or founder what to fix first and why it matters commercially.

What should a technical SEO audit include?

A proper audit should include crawlability, indexation, site architecture, internal links, canonical tags, status codes, XML sitemaps, robots.txt, JavaScript rendering, page speed, Core Web Vitals, structured data, mobile-first checks, security, hreflang where relevant, and server log analysis for larger sites.

That sounds like a lot because it is. The point is not to produce a longer report than everyone else. The point is to check every technical layer that can stop organic search performance from compounding.

How should you use this technical SEO checklist?

Use this checklist by auditing templates and page groups first, then validating individual URLs where the risk is highest.

Most sites do not have 500 separate technical problems. They have 10 to 20 recurring problems multiplied across templates. Category pages share one canonical rule. Blog posts share one heading structure. Product pages share one JavaScript rendering issue. Service pages share one slow hero image pattern.

Start with the pages that earn or should earn money: service pages, category pages, product pages, lead-generation pages, comparison pages, and high-intent guides. Then move into lower-value cleanup once the core search surfaces are stable.

Separate findings from recommendations

A finding says what is wrong. A recommendation says what to do about it. Keep them separate so the audit does not become a dump of crawler exports.

• Finding: 312 internal links point to redirected URLs.
• Impact: Link equity and crawl efficiency are diluted across a common template.
• Recommendation: Update the source links to point directly at the final canonical URLs.
• Priority: Fix on the shared navigation and footer before cleaning low-traffic legacy articles.

This is the same difference between a structural survey and a repair plan. One identifies the crack. The other tells you whether the wall needs urgent work, monitoring, or no action at all.

What tools do you need before starting a technical SEO audit?

You can complete a useful technical SEO audit with free tools, but larger sites usually need a crawler, log access, and developer-level debugging tools.

The most important free tool is Google Search Console because it shows how Google sees the site. A crawler then shows how the site behaves when you request URLs at scale. Performance tools, schema validators, and log files add the evidence needed for deeper decisions.

Set the crawl before trusting the crawl

Crawler settings matter. Crawl the canonical domain, use the correct protocol, obey or deliberately ignore robots.txt depending on the test, enable JavaScript rendering when the site needs it, and connect Search Console data if the tool supports it.

Run at least one normal crawl and one diagnostic crawl. The normal crawl should behave like a compliant search crawler. The diagnostic crawl can test blocked areas, rendered HTML, redirects, duplicate URLs, and parameter paths more aggressively.

Keep the audit evidence in one map

Use one audit map to connect each issue to its URL pattern, source tool, impact, owner, and next action. The map is more useful than five separate exports because technical SEO problems usually cross tool boundaries.

For example, a URL may appear as duplicate in a crawler, excluded in the Page indexing report, missing from the XML sitemap, and absent from internal links. Seeing those signals together changes the recommendation.

Google Search Console audit workflow

Google Search Console should drive the audit workflow because it shows which technical issues Google has already detected on the live property.

Crawler data is useful, but it is still your simulation of the site. Search Console shows Google data: indexed pages, excluded pages, URL Inspection details, sitemap processing, Core Web Vitals groups, search queries, and manual action warnings.

Use Google Search Console at the start of the audit, not after the crawler has produced a long issue list. It keeps the audit anchored to search performance rather than tool preference.

Page indexing report checks

The Page indexing report shows the indexing status of URLs Google knows about. Group the report by reason and template. A single excluded URL may not matter. Hundreds of excluded URLs from a money template probably do.

Pay attention to "Crawled, currently not indexed", "Discovered, currently not indexed", "Duplicate without user-selected canonical", "Alternate page with proper canonical tag", "Blocked by robots.txt", "Excluded by noindex", and soft 404 patterns.

URL Inspection checks

The URL Inspection tool is for representative examples, not every URL on the site. Test one URL from each important template, then test the highest-value pages individually.

Check the user-declared canonical, Google-selected canonical, crawl status, last crawl date, indexing state, rendered HTML, page resources, and structured data. If Google-selected canonical differs from your declared canonical, treat that as a signal that the page cluster is unclear.

Performance and query checks

Search Console performance data helps you connect technical fixes to search demand. A page with impressions but no clicks needs a different recommendation from a page with no impressions because it is not indexed.

For this page, the update brief showed 621 impressions in 28 days and 0 clicks, with terms such as "technical seo audit checklist", "technical seo checklist", and "technical seo audit template". That is more than a technical issue. It is a depth, date signal, and SERP offer issue.

Crawlability, crawl budget and URL controls

Crawlability checks whether search engines can reach the URLs that matter, while crawl budget checks whether crawl activity is being wasted on low-value URL patterns.

On small B2B sites, crawl budget is rarely the main problem. On ecommerce, directory, marketplace, publisher, and faceted sites, wasted crawl activity can become a real technical constraint.

Start by checking the URLs search engines are allowed to access, then compare that with the URLs you want indexed. The mismatch between those two lists is where many technical SEO issues begin.

Robots.txt audit

Google’s robots.txt guide is clear that robots.txt controls crawler access. It is not a reliable way to keep a page out of Google’s index. If a blocked URL has external links, Google may still know about it without being able to read the page.

• Check that robots.txt does not block CSS, JavaScript, images, or page resources needed for rendering.
• Check that staging, admin, search, filter, and internal URLs are handled deliberately.
• Check that blocked URLs are not included in XML sitemaps.
• Check that pages needing removal use noindex or proper access control rather than robots.txt alone.

XML sitemap audit

An XML sitemap should include canonical, indexable, live URLs that you want search engines to find. It should not be a dumping ground for every URL your CMS can output.

Compare sitemap URLs against crawl data and Search Console. Remove 3xx, 4xx, 5xx, noindex, blocked, duplicate, and parameter URLs. Then check whether important pages are missing from the sitemap and from internal links.

Faceted navigation and URL parameters

Faceted navigation creates filtered URL combinations for size, colour, price, location, availability, category, sort order, and other attributes. On ecommerce and listing sites, this can create thousands of crawlable URLs that do not deserve indexation.

Audit whether filtered URLs are useful landing pages, duplicate variants, or crawl traps. Then choose the right control: canonical tags, noindex, internal link changes, robots.txt for crawl waste, parameter handling in the platform, or building selected filter pages as real landing pages.

Redirect chains and loops

Redirect chains slow crawlers and users. Redirect loops can block access entirely. Export all 3xx URLs from the crawl and reduce chains so internal links point directly at the final destination.

Migration redirects need extra care. A product, service, or category URL should redirect to the closest equivalent page, not to the homepage. Poor redirect mapping throws away relevance.

Indexing, canonicalisation and duplicate content

Indexing checks whether Google stores the right URLs, while canonicalisation checks whether duplicate or similar URLs consolidate signals into the preferred version.

A page can be crawlable but not indexed. A page can be indexed but not the version you intended. A page can declare one canonical URL while Google selects another. Each state needs a different fix.

Indexed pages audit

Search for indexed pages using Search Console and sampled Google searches. The goal is not to count every URL perfectly. The goal is to identify whether valuable pages are missing and whether low-value pages are taking up space.

Look for indexed internal search results, tag pages, parameter URLs, thin archives, duplicate location pages, outdated campaign pages, and PDFs that should be supporting HTML pages rather than competing with them.

Canonical tag checks

Canonical tags should point to clean, indexable URLs that return 200 status codes and match the preferred page version. Canonicals to redirects, noindex pages, blocked URLs, or unrelated pages create conflicting signals.

Use the crawler to find canonical errors, then use URL Inspection to see whether Google agrees. If Google is choosing a different canonical, the problem may involve duplicate content, weak internal links, inconsistent sitemaps, or contradictory signals across templates.

Duplicate content checks

Duplicate content is not only copied text. It can come from print URLs, tracking parameters, HTTP and HTTPS variants, trailing slash variations, uppercase URLs, session IDs, product variants, pagination, and location pages with near-identical copy.

Do not fix every duplicate by canonicalising it away. Some duplicates need redirects. Some need noindex. Some need consolidation. Some need unique content because they target different search intent.

JavaScript rendering and crawlability

JavaScript rendering checks whether search engines can see the content, links, metadata, canonicals, and structured data that users see after the page has rendered.

This is a high-priority gap in many older technical SEO checklists. Modern sites often use React, Next.js, Nuxt, Vue, Shopify apps, headless CMS setups, and client-side components. The HTML source and the rendered DOM can be very different.

Google’s JavaScript SEO basics documentation explains the process around crawling, rendering, and indexing JavaScript content. The audit question is simple: what can Google see before and after rendering, and does that match what the page needs to rank?

Rendered HTML checks

Compare raw HTML, rendered HTML, and the live browser view. Important content, internal links, title tags, meta descriptions, canonicals, robots directives, and schema should appear reliably in the rendered HTML.

If a page depends on JavaScript to inject the main content, test whether Google can render it. A page that looks fine to a user in Chrome can still fail if scripts are blocked, delayed, errored, or too slow for a crawler to process consistently.

Framework and hydration checks

For JavaScript frameworks, check server-side rendering, static generation, hydration errors, lazy-loaded content, route handling, and whether internal links use real crawlable anchors. Client-side routing can hide URLs if it is implemented poorly.

Hydration cost can affect both rendering and Core Web Vitals. A page may deliver initial HTML, then lock the main thread while the framework attaches behaviour. That can damage INP and make the page feel broken on mobile.

JavaScript error and resource checks

Use browser console logs, DevTools, crawler rendering reports, and URL Inspection screenshots to find rendering failures. Blocked scripts, failed API calls, CSP errors, missing resources, and third-party script failures can change what Google sees.

The fix may be technical rather than editorial: server-render critical content, expose links in HTML, reduce script weight, defer non-essential scripts, and make sure key metadata is not created only after slow client-side execution.

Site architecture, internal links and on-page technical checks

Site architecture and internal links tell search engines which pages matter, how topics relate, and how authority should move through the site.

A clean architecture makes the site easier to crawl and easier to understand. A weak architecture leaves important pages buried, orphaned, duplicated, or competing against pages with the wrong intent.

If you need the broader non-technical process, the companion guide on how to do an SEO audit covers content, intent, authority, and measurement alongside the technical checks.

Click depth and crawl paths

Check how many clicks important pages sit from the homepage and from key hub pages. High-value pages buried five or six clicks deep usually need better hub, navigation, breadcrumb, or contextual links.

Click depth is not a ranking factor in isolation. It is a useful proxy for internal importance. If a business-critical page is hard for users to find, it is usually weakly signalled to crawlers as well.

Orphan pages and internal link gaps

Orphan pages have no internal links pointing to them. They may still appear in sitemaps, analytics, backlinks, or Search Console, but the site architecture is not supporting them.

Fix orphan pages by linking from relevant hubs, service pages, category pages, articles, and navigation elements. Do not link every page from everywhere. Link where the relationship helps a user move to the next useful page.

Title tags, headings and image optimisation

On-page technical checks still matter. Audit title duplication, missing titles, overlong titles, missing meta descriptions, one-H1 structure, heading order, image dimensions, alt text where useful, lazy loading, and file weight.

These are not glamorous checks, but they remove friction. A clean title tag helps the SERP result. A clear H1 confirms the page topic. Optimised images support performance. A sensible heading structure helps both readers and machines parse the page.

Structured data, E-E-A-T and accessibility

Structured data, E-E-A-T signals and accessibility checks help search engines and users understand whether the page is trustworthy, eligible for richer presentation, and usable.

Structured data does not replace good content. It labels entities and relationships that should already be visible on the page. If schema says something the page does not support, the markup is a liability.

E-E-A-T is not a single technical tag. It is a set of trust signals across authorship, evidence, citations, company information, reviews, case studies, policies, and accuracy. Technical SEO can help expose those signals in a form search engines and users can verify.

Structured data and schema checks

Check schema type, required properties, duplicate markup, invalid values, nested entities, and whether structured data matches the visible content. Blog posts, FAQs, products, breadcrumbs, local businesses, events, and reviews each have different requirements.

Use validation tools, then compare against Search Console enhancement reports where available. Warnings are not always urgent. Errors that block eligibility or misrepresent the page need fixing.

E-E-A-T and AI-era visibility checks

Search is becoming more answer-led through AI Overviews and other generated results. Technical SEO still starts with crawlability and indexation, but the page also needs clear authorship, evidence, entity consistency, and useful passages that can be cited or summarised.

For this site, E-E-A-T matters because a reader is judging whether an independent SEO consultant has the technical depth to find issues an agency might miss. The page should show process, judgement, and evidence rather than vague claims.

Accessibility and technical SEO checks

Accessibility is not a direct substitute for SEO, but the overlap is real. Semantic HTML, sensible headings, labelled controls, readable text, keyboard access, predictable layouts, and descriptive media all support cleaner pages.

Audit missing labels, empty links, inaccessible menus, poor colour contrast, focus traps, modal behaviour, image alternatives, and forms that cannot be completed on mobile. These issues affect users before they affect reports.

Status codes, broken links and server errors

Status code checks show whether URLs return the response search engines and users expect: live pages return 200, removed pages return 410 or 404, redirects are clean, and server errors are rare.

Status code issues are usually easy to find and easy to underestimate. A handful of broken internal links may be minor. A template linking to thousands of redirected or missing URLs is a structural issue.

Broken internal links

Find every internal link that returns 404, 410, 5xx, or an unnecessary redirect. Fix links at source rather than relying on redirects forever.

Prioritise links from navigation, footer, breadcrumbs, hub pages, high-traffic content, and commercial pages. A broken link buried in a 2019 news article is less urgent than a broken link in a primary service page CTA.

Server error patterns

A server error seen once during a crawl may be a temporary blip. Repeated 5xx errors on important templates need investigation. Compare crawler data, logs, uptime monitoring, and Search Console reports before deciding impact.

Server errors can come from hosting limits, database strain, plugin conflicts, CDN misconfiguration, timeout rules, firewall blocks, or application bugs. The audit should identify the affected pattern, not merely record the status code.

Page speed, Core Web Vitals, mobile SEO and HTTPS

Performance, mobile usability and HTTPS checks confirm that users and Googlebot Smartphone can access the secure mobile version of the page without avoidable friction.

Page speed is not a single score. It is a set of user experience constraints: loading speed, responsiveness, visual stability, server response, resource delivery, JavaScript cost, image weight, and mobile rendering.

Use the Core Web Vitals report in Search Console to identify poor URL groups, then use PageSpeed Insights and DevTools to diagnose example URLs. My Core Web Vitals guide goes deeper into the LCP, INP, and CLS fixes.

Core Web Vitals checks

• Check LCP on mobile and identify the element causing the delay.
• Check INP and look for long JavaScript tasks, third-party scripts, and hydration work.
• Check CLS and reserve space for images, embeds, adverts, cookie banners, and dynamic modules.
• Compare URL-level and origin-level field data where available.
• Test the templates that drive leads or revenue before low-value archive pages.

Do not chase a perfect Lighthouse score before fixing indexation, internal links, and search intent. Do fix performance issues when they affect valuable templates and real users.

Mobile-first and HTTPS checks

Google uses mobile-first indexing, so the mobile version of the page must contain the primary content, links, metadata, schema, canonicals, and functionality needed for search.

Check responsive layouts, tap targets, mobile navigation, hidden content, intrusive overlays, viewport configuration, font sizes, and whether mobile HTML differs from desktop HTML in a way that weakens search visibility.

HTTPS should be universal. Check redirects from HTTP to HTTPS, mixed content, expired certificates, canonical tags, sitemap URLs, hreflang references, internal links, and external scripts. Security problems are trust problems as well as technical problems.

International SEO and hreflang

International SEO checks confirm that language and regional page variants use the right canonical and hreflang signals without contradicting each other.

Hreflang is only relevant when a site has translated or region-specific alternatives. If the site serves one language to one market, do not add hreflang for the sake of it.

Google’s hreflang documentation explains that hreflang helps Google understand localised versions of the same content. It does not detect language by itself, and it does not replace canonical tags.

Hreflang checks

• Check every hreflang URL returns a 200 status code and is indexable.
• Check each language or regional variant references itself.
• Check return tags exist between equivalent pages.
• Check x-default is used where a selector or global fallback page exists.
• Check hreflang and canonical tags do not send conflicting signals.

International sitemap checks

For larger international sites, hreflang in XML sitemaps can be easier to manage than page-level tags. The same quality rules apply: only canonical, indexable, live URLs belong there.

International errors are often spreadsheet errors. One incorrect URL pattern can create hundreds of broken language references, so validate at scale rather than checking only the homepage.

Log file analysis and server-level checks

Log file analysis shows what search engine bots request from the server, how often they visit, and what response they receive.

This is where a technical SEO audit becomes more than a crawl. A crawler shows what it found by following links. Server logs show what Googlebot and other bots requested, including URLs that are no longer linked internally or do not appear in your sitemap.

Log file analysis is most useful for large sites, ecommerce sites, migrations, news or content-heavy sites, and sites with parameter or faceted navigation problems.

What to look for in server logs

• Googlebot requests to important templates, low-value templates, old URLs, and parameter paths.
• High volumes of 3xx, 4xx, or 5xx responses seen by search crawlers.
• Important pages that receive little or no bot activity.
• Crawl spikes after deployments, migrations, or sitemap changes.
• Wasted activity on filtered URLs, internal search pages, tracking parameters, or legacy paths.

Combining logs with crawl and Search Console data

Logs become valuable when combined with crawl data and Search Console. If Googlebot is spending time on blocked parameter URLs while important category pages are discovered but not indexed, you have a stronger case for URL controls and internal link changes.

For sites without log access, you can still audit many technical issues. You lose the clearest view of bot behaviour, which means crawl budget recommendations should be more cautious.

How do you prioritise technical SEO findings?

Prioritise technical SEO findings by indexation impact, affected page value, template scale, implementation effort, and the confidence that the fix will improve organic performance.

A technical SEO checklist can produce hundreds of findings. That does not mean the site needs hundreds of actions. The senior part of the work is deciding what matters, what can wait, and what should be ignored.

Turn the audit into a delivery queue

Each recommendation should have an owner, evidence, affected URL pattern, expected impact, implementation note, and validation method. Without those details, the audit becomes a document people agree with and never use.

For example, "fix redirects" is weak. "Update 214 internal links in the blog template from redirected HTTP URLs to final HTTPS canonical URLs, then rerun the crawl and confirm zero internal 3xx links from that template" is usable.

Measure the impact of fixes

Technical fixes should be measured after deployment. Track indexation, crawl patterns, affected keyword rankings, impressions, clicks, Core Web Vitals groups, and conversions where the affected pages have commercial value.

For commercial work, connect technical fixes to measuring SEO ROI. Not every fix produces a neat ranking jump, but the work should still reduce risk, improve access, or support pages that can generate leads and revenue.

How often should you run a technical SEO audit?

Most sites should run a light technical SEO audit monthly or quarterly, then run a deeper audit before and after major site changes.

Audit frequency depends on site complexity. A ten-page brochure site does not need the same rhythm as a 50,000-URL ecommerce site with faceted navigation, product churn, and frequent deployments.

The best audit schedule is boring. Regular checks catch regressions before they become traffic drops. The worst schedule is waiting until rankings fall, then asking a crawler to explain a problem that started months earlier.

Free technical SEO audit template and FAQs

A downloadable template is useful when it forces prioritisation, ownership, and evidence. It is not useful when it becomes a longer version of the crawler export.

Search demand around this topic includes "technical seo audit template", "free technical seo audit checklist", "technical seo audit checklist Excel", and similar queries. The template offer matters because people do not only want to read the checklist. They want a working structure.

A good free template should include columns for URL, template, issue type, evidence, tool source, severity, business impact, recommendation, owner, implementation notes, validation method, and status. That turns the technical SEO checklist into a delivery tracker.

What is a technical SEO checklist?

A technical SEO checklist is a structured list of checks used to find problems with crawlability, indexing, rendering, site architecture, internal links, page speed, schema, mobile usability, security, and server behaviour. The useful version adds priority and fix guidance, not issue names alone.

What should I look for in a technical SEO audit?

Look for anything that stops search engines discovering, rendering, indexing, understanding, ranking, or users using important pages. Start with blocked URLs, noindex errors, bad canonicals, broken internal links, JavaScript rendering gaps, server errors, duplicate content, and poor mobile performance.

What robots.txt issues should I fix in a technical SEO audit?

Fix robots.txt rules that block important pages, CSS, JavaScript, images, or rendered resources. Remove blocked URLs from XML sitemaps. Do not use robots.txt as a noindex substitute, because blocked pages can still appear in Google without useful content.

What should I include in a technical SEO audit checklist for long-tail targeting?

For long-tail targeting, include checks for crawlable internal links, clean indexation, unique titles, clear H1s, useful headings, schema, canonical signals, content depth, template speed, and internal links from related pages. Long-tail pages often fail because they are thin, orphaned, duplicated, or buried.

What does an SEO audit include?

An SEO audit usually includes technical SEO, content quality, search intent, internal links, backlinks, E-E-A-T signals, analytics, and conversion performance. A technical SEO audit is one part of that broader process, focused on access, indexation, rendering, performance, and technical trust.

How long does a technical SEO audit take?

A small site can be audited in a few hours. A complex ecommerce, marketplace, international, or JavaScript-heavy site may take several days, especially if log files, templates, staging checks, and developer recommendations are included.

Can I do a technical SEO audit myself?

Yes, if the site is small and the issues are straightforward. Use Search Console, a crawler, PageSpeed Insights, and this checklist. Bring in technical SEO help when findings involve rendering, migrations, faceted navigation, log files, server behaviour, or developer implementation.

A technical SEO audit should end with clearer decisions. If you want an independent SEO consultant to audit the site, translate the findings into developer-ready actions, and connect the fixes back to organic growth, work with me.