Technical SEO Audit Checklist: 30 Things to Check

A technical SEO audit should tell you whether search engines can reliably reach, understand, and index the pages that matter. It should also show you where the site's own structure is making that harder than it needs to be.

This checklist gives you 30 checks to work through. For each one, record the affected URLs, what you observed, and whether the problem is isolated or repeated across a template. That makes the audit easier to hand off later.

Keep the checklist and the prioritization work separate. This page is about what to inspect. If you're comparing a paid audit, see Technical SEO Audit Service: What Should Be Included? for what the deliverable should contain. Once you have the findings, use How to Prioritize SEO Problems After an Audit to decide what should go first.

Technical SEO audit checklist: crawl and discovery

1. Confirm the site is reachable

Open the homepage and a few representative pages deeper in the site. Important public pages should load without login walls, persistent server errors, or accidental staging restrictions.

2. Review robots.txt

Open /robots.txt and inspect the rules that apply to major crawlers. Look for broad Disallow rules that accidentally cover products, services, locations, articles, or other pages you expect search engines to crawl.

Robots.txt controls crawling. It is not a reliable substitute for removing a page from search results, so treat a suspicious rule as something to investigate rather than something to delete automatically.

3. Verify sitemap availability

Find the XML sitemap or sitemap index and make sure it loads successfully. A sitemap should help search engines discover the URLs you want crawled, not act as a warehouse for every URL the CMS has ever produced.

4. Check sitemap quality

Review whether sitemap URLs are current, canonical, indexable, and successful. Flag redirects, errors, obsolete URLs, and URLs that intentionally point their canonical elsewhere.

5. Compare discovered URLs with important pages

A crawler can discover thousands of URLs and still miss the pages that matter commercially. Compare crawl discovery with your navigation, sitemap, key landing pages, products, services, locations, and conversion journeys.

6. Find orphan or weakly linked pages

Important pages should not depend solely on a sitemap or an external link for discovery. Identify valuable pages with no meaningful internal links, as well as pages buried so deeply that users and crawlers rarely reach them.

Check indexability and canonical signals

7. Find accidental noindex directives

Inspect important pages for noindex directives in meta robots tags or HTTP headers. Staging rules, plugin settings, and old campaign configurations can survive long after launch.

8. Separate crawl blocks from index controls

Do not treat robots.txt and noindex as interchangeable. If a crawler cannot access a page, it may not be able to see page-level indexing directives. Record which mechanism is creating the restriction.

9. Inspect canonical tags

Check that important indexable pages point to the intended canonical URL. Look for canonicals pointing to unrelated pages, old hosts, HTTP versions, staging domains, or the wrong member of a duplicate set.

10. Look for conflicting canonical signals

A canonical tag is only one signal. Internal links, redirects, sitemap inclusion, URL variants, and page content can tell a different story. Flag cases where the site says one URL is canonical while consistently promoting another.

11. Identify duplicate URL variants

Check whether the same content is available through unnecessary parameter, case, protocol, hostname, trailing-slash, tracking, or alternate-path variants. Not every duplicate needs a fix, but uncontrolled variants can create confusing signals and waste crawl attention.

12. Review pagination and faceted navigation

Ecommerce, directories, listings, and large catalogs can generate huge URL spaces through filters and sorting. Work out which combinations provide distinct search value and which mostly reproduce the same result set.

Audit status codes and redirects

13. Find broken internal links

Crawl internal links for 4xx and 5xx destinations. Pay particular attention to navigation, templates, high-traffic pages, and important conversion paths before obscure historical references.

14. Review permanent redirects

Old URLs that have clear replacements should usually lead directly to the most relevant current destination. Sending every retired URL to the homepage may produce a successful response while still losing the original intent.

15. Find redirect chains

Look for paths such as old URL → intermediate URL → newer URL → final page. Update internal links to point directly to the final destination and simplify redirect rules where it is safe to do so.

16. Detect redirect loops

A loop makes the destination unusable. Fix these quickly when they affect navigation, canonical URLs, migrated sections, or frequently linked pages.

17. Investigate soft-404 behavior

A page can return 200 OK while effectively saying "not found," showing empty content, or sending users to an irrelevant destination. Check removed products, locations, listings, and dynamically generated pages carefully.

Audit internal linking and site structure

18. Check navigation paths to priority pages

Your most important pages should have sensible paths from the site's main architecture. If a high-value service or location is buried behind several low-value archive pages, the problem is structural, not simply a missing-link count.

19. Review internal anchor text

Anchor text should help users understand the destination. Replace vague or misleading anchors when a clearer description would improve navigation and context, but do not force exact-match keywords into every link.

20. Find excessive repeated links

Templates can create hundreds of repeated links that add little navigational value. Inspect sitewide blocks, tag clouds, giant footers, and automatically generated cross-links that crowd out more useful relationships.

21. Check breadcrumbs and hierarchy

Breadcrumbs should reflect a useful hierarchy and lead to real, relevant parent pages. They are especially useful on ecommerce, publishing, directory, and multi-location sites.

Review page-level technical signals

22. Audit title elements

Find missing, duplicated, generic, or obviously malformed titles. Then check whether the problem comes from one page or a shared template. A template fix can solve an entire class of issues at once.

23. Review meta descriptions

Missing descriptions are not automatically emergencies. Focus on important pages with duplicated, irrelevant, template-broken, or clearly unhelpful descriptions where a better summary could improve how the page is presented to searchers.

24. Check heading structure

Make sure the main visible heading accurately describes the page and that the remaining headings support a readable hierarchy. Do not spend time chasing a mechanically perfect heading sequence when the page is already clear and well structured.

25. Inspect images and alternative text

Check broken images, oversized assets, missing dimensions, and meaningful images that lack useful alternative text. Decorative images do not need keyword-heavy descriptions.

26. Review structured data

Validate structured data on page types where it genuinely applies. Fix invalid properties and mismatches between markup and visible content. More schema is not automatically better schema.

Check site quality at scale

27. Identify thin or empty templates

Look for pages that technically exist but provide almost no useful content: empty category pages, placeholder locations, generated tag pages, thin search results, or unfinished profiles. Decide whether they should be improved, consolidated, excluded from indexing, or removed.

28. Group repeated issues by root cause

If 300 pages have the same broken title pattern, you probably do not have 300 separate tasks. You may have one template repair with 300 affected pages. Group findings only when the evidence supports a shared cause; similar symptoms can still come from different problems.

29. Mark findings for prioritization

At this stage, do not let the checklist turn into its own scoring system. Note which pages matter, how broad the issue is, how confident you are in the evidence, and whether the repair carries meaningful risk. Then move those findings into a separate priority queue.

The detailed framework is in How to Prioritize SEO Problems After an Audit.

30. Rescan after changes

A fix is not finished because someone changed a setting. Recheck the affected URLs after deployment. Confirm the original evidence is gone, the intended pages still work, and the repair did not create a new redirect, canonical, indexability, or template problem.

Keep the evidence with each finding

By the end of a crawl, even a small team can be looking at more findings than it can reasonably work through. The notes you keep during the audit are what make those findings usable later.

For each meaningful issue, record four things:

1. What is wrong? State the observable problem.
2. Where is it happening? Capture representative and affected URLs.
3. Why does it matter? Connect the issue to crawling, indexing, consolidation, navigation, or user experience.
4. What should happen next? Describe the smallest safe repair and how you will verify it.

Keep confirmed defects separate from recommendations that need judgment. A broken link or redirect loop is direct evidence. A suggestion to expand a page, rewrite a title, or consolidate content may still be useful, but it needs more context before someone changes the site.

After the checklist

Once you have worked through the 30 checks, resist the urge to sort everything by warning count. Use the separate SEO prioritization framework to turn the findings into a realistic order of work based on impact, scope, confidence, and effort.

Where FixList fits

FixList uses the same basic approach. Standard 150 is read-only and checks up to 150 pages, then organizes the evidence into a prioritized, plain-English FixList. The point is to keep the affected pages and the reason for the recommendation attached to the repair.

If an audit ends with "2,000 issues" and no order of work, it is not finished. The useful output is a short list of repairs backed by evidence, with a clear way to verify each one after the change.

FixList checks up to 150 pages and turns what it finds into a prioritized, plain-English list of what to fix first.