Technical SEO audit checklist: what should you actually check?

A technical SEO audit is not a list of 100 checks performed for the sake of producing a report. It is a structured investigation of whether search engines can discover, render, understand, index and consolidate the right versions of your important pages — and whether technical problems are getting in the way of users.

What should a technical SEO audit actually answer?

The audit should answer four practical questions: Can search engines reach the important content? Are the right URLs allowed and eligible to be indexed? Can Google understand the preferred version and relationships between pages? Are technical experience problems making the site harder to use or maintain?

Google explains Search as a process involving crawling, indexing and serving results. Following that sequence helps keep an audit focused. A page cannot rank because its title tag is excellent if Google cannot crawl it, and a beautifully structured page will not appear if it is accidentally marked noindex.

Reference: Google Search Central: How Google Search Works ↗

1. Crawlability: can bots reach the pages that matter?

Begin with robots.txt, internal links and server responses. Robots.txt can control crawling, but it is not a reliable way to keep a URL out of Google Search if other pages link to it. If a page truly should not be indexed, use the appropriate noindex mechanism where Google can crawl and see it.

Look for important pages blocked unintentionally, sections that rely on forms or scripts without crawlable links, and orphan pages that have no meaningful internal path from the site architecture. A URL may exist in a sitemap but still be poorly integrated into the website.

Crawl the site from the home page and compare the results with the XML sitemap and pages reported in Search Console. Differences often reveal forgotten redirects, orphaned content or legacy URLs.

2. Indexability: are important pages eligible for indexing?

Review robots meta directives, X-Robots-Tag headers, authentication barriers, HTTP status codes and canonical signals. Staging sites should normally be protected from indexing, but those protections must not carry onto production.

Accidental noindex is especially important during redesigns and migrations. A page can be perfectly crawlable and still be excluded because its directive says not to index it.

Distinguish between “not indexed because something is wrong” and “not indexed because Google selected another canonical or does not consider the URL worth indexing.” Search Console reasons need interpretation, not just a count to reduce to zero.

3. Canonical URLs: which version should search engines prefer?

Duplicate URLs can be created by parameters, HTTP/HTTPS variations, trailing-slash inconsistencies, category paths, staging copies and alternate versions of similar content. Google says canonicalization helps specify the preferred URL and consolidate signals for duplicates.

Check that important pages use self-referencing canonicals where appropriate, that canonical targets return 200 responses and that redirects, internal links and the XML sitemap reinforce the same destination. Avoid contradictory signals such as linking internally to one URL while declaring another as canonical.

Reference: Google Search Central: Canonicalization ↗

4. Redirects: are retired URLs going directly to the best destination?

Review permanent redirects, temporary redirects, chains, loops and redirects to irrelevant pages. When content genuinely moves, Google recommends redirects as a strong way to communicate the new location.

A clean redirect normally goes from the old URL directly to the final destination in one hop. Chains such as old page → staging-era URL → production URL add unnecessary complexity and should be cleaned up during an audit.

Do not redirect every deleted URL to the home page. Map it to the closest useful replacement when one exists. If there is no meaningful replacement, a proper 404 or 410 can be more honest than an irrelevant redirect.

Reference: Google Search Central: Redirects and Google Search ↗

5. XML sitemap: does it contain the URLs you actually want indexed?

Google describes a sitemap as a file that provides information about important pages and their relationships. A sitemap should therefore be a list of preferred URLs, not a storage area for every address the CMS can generate.

Look for redirects, noindex pages, canonicalized duplicates, staging URLs or 404s inside the sitemap. Those conflicts send mixed signals and make monitoring harder.

Reference: Google Search Central: Sitemaps Overview ↗

6. Site architecture and internal linking.

Technical SEO is not only server configuration. Internal links help search engines discover pages and help users understand how topics relate. Important service pages should not require many unnecessary clicks while low-value archives dominate navigation.

Look for orphan pages, dead ends, duplicated navigation paths and articles that should link to the relevant service or case study. Anchor text should describe the destination naturally rather than repeating exact-match keywords everywhere.

Content overlap belongs here too. If several URLs answer essentially the same question or try to win the same type of customer action, the solution may be consolidation, repositioning or redirecting — not adding more internal links to all of them.

7. Mobile-first content and responsive behaviour.

Google uses the mobile version of content for indexing and ranking under mobile-first indexing. Make sure important text, links, structured data and metadata are not missing from mobile layouts. Responsive design should not hide the substance of the desktop page.

Check navigation, accordions, tabs and dynamically loaded sections on small screens. A mobile page that technically contains content but makes it difficult to reach can still create a poor user experience.

8. Core Web Vitals and performance.

Core Web Vitals measure real-world loading performance, interactivity and visual stability. Review field data and lab diagnostics where available. The purpose is to identify experience problems and regressions, not to pursue a perfect score at the expense of useful content.

Common issues include oversized images, render-blocking assets, heavy JavaScript, third-party widgets, slow server response and layout shifts caused by images or dynamic components without reserved dimensions.

Audit high-value templates separately. A fast home page does not prove that product pages, blog articles or service pages are equally fast.

Reference: Google Search Central: Core Web Vitals ↗

9. JavaScript rendering and crawlable content.

Google processes JavaScript through crawling, rendering and indexing stages. Important links and content should be implemented in ways that search engines can discover reliably rather than depending on user-only interactions.

Check whether critical text appears in rendered HTML, whether links use real anchor elements with href attributes, and whether JavaScript errors prevent sections from loading. On highly dynamic sites, compare source HTML and rendered output.

Reference: Google Search Central: JavaScript SEO Basics ↗

10. Structured data: accurate, visible and page-appropriate.

Structured data should describe what the page really is. A service page may use appropriate service-related semantics when supported, while an editorial article should use Article or BlogPosting semantics. Do not add FAQ, Product or other markup simply because a plugin offers it.

Check for duplicate entities, invalid values, outdated URLs and schema that describes content users cannot see. Structured data is an enhancement to clear page content, not a substitute for it.

11. Status codes, 404s and soft errors.

Important pages should return the expected status. Broken internal links should not point to 404s. Retired URLs should not accidentally return 200 with a generic “not found” message. Redirect destinations should be valid and relevant.

Some 404s are normal. The goal is not to eliminate every missing URL on the internet; it is to fix broken internal links, recover valuable moved content where appropriate and avoid wasting users’ time.

12. Search Console validation.

Search Console is useful for validating what Google is seeing after the crawl. Review indexing reports, sitemap status, Core Web Vitals, manual actions, security issues and search performance. For individual high-value URLs, URL Inspection can help confirm indexing and canonical information.

Compare technical findings with performance data. A page with many impressions but weak click-through may need better snippet alignment rather than a crawl fix. A page with no impressions because it is noindexed has a different problem entirely.

13. Image discovery and performance.

Google recommends using standard HTML image elements so crawlers can discover images and using responsive image techniques with a fallback src. Image file size also affects website performance. An audit should therefore check whether meaningful images are discoverable, properly sized and supplied with accurate alt text where the image conveys information.

Do not treat alt text as a place to repeat target keywords. Describe what the image communicates in context. Decorative images can use empty alt text.

14. Prioritize fixes by business and search impact.

A technical audit becomes useful only when findings are prioritized. A simple system is to score each issue by impact, reach and effort. An accidental noindex on a primary service page has high impact and should move quickly. A minor schema warning on an unimportant archive may wait.

Group findings into blockers, high-priority improvements and housekeeping. That gives the business a roadmap instead of a spreadsheet of warnings.

What happens after the audit?

Fix the highest-impact problems, verify the changes, and then monitor Search Console and analytics over time. Some changes can be validated immediately; crawling, canonical consolidation and ranking effects may take longer.

If the business needs implementation support rather than another checklist, SEO & Search Visibility is the appropriate next step. Use this article as the reference for what should be checked and prioritized.

15. Compare technical findings with page roles.

A technically clean site can still have weak search architecture if several pages are trying to do the same job. Review high-impression URLs by topic and determine whether the page best suited to that search is the one actually receiving visibility. If an informational article is outranking the service page for a service-focused query, the solution may involve clarifying page roles, improving internal links or consolidating overlapping content rather than changing a technical tag.

This step connects crawl data with Search Console evidence. It helps prevent the audit from treating every URL as equally valuable and keeps technical cleanup aligned with the site’s business priorities.

Keep an audit change log.

Record the date, affected URLs, issue, recommended action, implementation status and verification result for high-impact fixes. That history is useful when rankings or indexation change later because the team can connect the movement with actual technical work instead of relying on memory.