Technical SEO Audit Checklist: 40 Checks, in the Order We Run Them

A technical SEO audit checks whether Google can crawl, render and index your pages, and whether anything in the setup holds them back. This checklist has 40 checks in the order we run them: first access (can Google get in?), then indexing, then everything that affects how pages are understood and shown.

The order matters. There is no point tuning structured data on pages that robots.txt blocks. Where it helps, each check has a real example from our own site: the WordPress version we audited in October 2026, and the static site that replaced it.

What is a technical SEO audit?

It’s a review of the parts of a website that users rarely see but search engines depend on: server responses, robots rules, redirects, canonical tags, sitemaps, internal links, page speed, mobile rendering and markup. Content and links are separate audits. A technical audit makes sure good content can actually be found and indexed.

What you need:

• Google Search Console for the site (ideally a Domain property plus a URL-prefix property).
• A crawler such as Screaming Frog or Sitebulb.
• PageSpeed Insights for Core Web Vitals.
• curl (or any header checker) to see what the server really returns.

Crawlability: can Google get in?

1. Check robots.txt. Open /robots.txt and read every rule. Google’s robots.txt introduction explains that it controls crawling, not indexing. Our WordPress site had duplicated Disallow lines and blocked /wp-content/ and /wp-includes/, which is where WordPress keeps the CSS, JavaScript and images Google needs to render pages. The new site’s file is three lines:

User-agent: *
Allow: /

Sitemap: https://digitalusmedia.com/sitemap.xml

2. Check that important resources aren’t blocked. CSS, JavaScript and images must be crawlable, or Google renders a broken page. The URL Inspection tool in Search Console shows blocked resources.

3. Check server status codes. Crawl the site and list everything that isn’t 200 or a deliberate 301/404. Look for 5xx errors and soft 404s (pages that say “not found” but return 200).

4. Check server response time. Slow responses limit how much Google crawls. Our WordPress /technical-seo/ page took about 1.5 seconds to first byte. On the static site, the home page answers in about 0.09 seconds and /services/technical-seo/ in about 0.16 seconds (measured with curl, 26 October 2026):

curl -s -o /dev/null -w "TTFB %{time_starttransfer}s, %{size_download} bytes\n" https://example.com/

5. Check for crawl traps. Calendars, faceted filters, session IDs and endless parameter combinations can create millions of URLs. A crawler that never finishes is usually a sign of one.

Indexing: is what you want in Google actually in Google?

6. Read the Page indexing report. Search Console’s Page indexing report lists every reason pages aren’t indexed. Look at the reasons, not just the total.

7. Compare indexed pages with the pages you want indexed. Your sitemap is the list you want; the report is what Google has. Big gaps in either direction need an explanation.

8. Check robots meta tags and X-Robots-Tag headers. Look for noindex on pages that should rank, and the opposite: thin or private pages left indexable. Remember that a noindex header on a sitemap file is fine. Our old Rank Math sitemap carried x-robots-tag: noindex, which keeps the XML file itself out of search results and doesn’t affect the URLs in it.

9. Inspect your key pages one by one. Run URL Inspection on the home page and your top service and product pages. Check “Page is indexed”, the Google-selected canonical and the rendered HTML.

10. Check that staging or preview sites are not indexable. Search for your staging domain in Google. Preview builds should be noindex or behind a password.

Redirects

11. Check the www and HTTP versions. Every variant (http://, http://www., https://www.) should reach the canonical version in one hop. On our WordPress site, http://www took two (to https://www, then to https://). Check with:

curl -sI http://www.example.com/ | grep -iE "^HTTP|^location"

12. Look for redirect chains and loops. A crawler report of redirect chains shows them. Point every redirect straight at the final URL. Google’s redirects documentation explains how it treats each type.

13. Check that moved URLs return a real 301 or 308. After a migration, test old URLs at the server. Google recommends server-side redirects; a page that answers 200 with a meta refresh or a JavaScript redirect is a fallback, not the real thing. This is the first check we’d run after any migration, ours included.

14. Fix internal links that point to redirects. Internal links should go straight to the final URL, not through a 301.

15. Check that deleted pages return 404 or 410. Not a blanket redirect to the home page, which Google may treat as a soft 404.

Canonicals and duplicates

16. Every indexable page has a self-referencing canonical. Our home page, for example:

<link rel="canonical" href="https://digitalusmedia.com/">

17. Canonicals point to indexable 200 pages. Not to redirects, 404s, noindex pages or another domain by mistake. See Google’s guide to specifying a canonical URL.

18. Check Google’s choice of canonical. In URL Inspection, compare the “user-declared” and “Google-selected” canonical.

19. Find duplicate content. Trailing slash vs no slash, uppercase vs lowercase, parameters, printer versions and HTTP/HTTPS copies. Pick one version and redirect or canonicalize the rest.

20. Check pagination and parameters. Paginated pages should be crawlable and canonical to themselves, not all to page 1.

XML sitemaps

21. The sitemap exists and is submitted. It should be listed in robots.txt and submitted in Search Console. Google’s sitemaps overview covers the format.

22. The sitemap lists only canonical, indexable 200 URLs. No redirects, no noindex pages, no 404s. Run the sitemap through your crawler to check.

23. lastmod dates are real. Only change them when the content changes.

24. Every important page is in the sitemap, and the sitemap matches what you actually publish.

Site structure and internal links

25. Find orphan pages. Pages that no other page links to are hard for Google to discover. On our WordPress site, 5 of the 6 blog posts linked to no other page on the site, and two service pages had no internal links in their content at all.

26. Check click depth. Important pages should be reachable within three clicks from the home page.

27. Check anchor text. Internal links should describe the target page (“technical SEO audit”), not “click here”. Google’s link best practices also require real <a href> links that Google can follow.

28. Check the URL structure. Short, readable, lowercase URLs that follow the site’s sections.

29. Check breadcrumbs and navigation. They should be plain HTML links, consistent across the site.

Page speed and Core Web Vitals

30. Check Core Web Vitals in Search Console. The report uses real-user data. Google’s Core Web Vitals page explains LCP, INP and CLS and their thresholds.

31. Test key templates in PageSpeed Insights. Test one page per template (home, service, article), not every URL.

32. Check page weight. Our WordPress pages carried about 225 to 260 KB of HTML each, mostly page-builder markup, before any images or scripts. The static home page is about 46 KB of HTML. In our view, heavy HTML is one of the most overlooked speed problems on page-builder sites.

33. Check images. Modern formats (WebP or AVIF), width and height attributes to prevent layout shift, and lazy loading below the fold.

Mobile and rendering

34. Check the mobile version has the same content. Google uses mobile-first indexing, so content missing on mobile is effectively missing.

35. Check JavaScript rendering. Compare the raw HTML with the rendered HTML in URL Inspection. If titles, text or links only appear after JavaScript runs, read Google’s JavaScript SEO basics and consider server-side rendering.

Titles, meta descriptions and structured data

36. Check titles. Every page needs a unique, descriptive <title>. Our WordPress home page had no SEO title set, so the title tag fell back to a template that repeated the site name and ran to about 115 characters. Google’s title link guidelines explain what it uses instead when a title is unhelpful. Our free title tag length checker shows whether a title is likely to be cut off.

37. Check meta descriptions. Unique and specific to the page. Google may rewrite them, but a good one is used more often. See Google’s guidance on snippets, and preview yours with the meta description checker.

38. Validate structured data. Run key templates through the Rich Results Test and fix errors. Mark up only what’s visible on the page. Google’s introduction to structured data covers the formats.

International, security and monitoring

39. Check hreflang (multilingual sites only). Every language version should list all versions including itself, with return links, and match the canonicals. Google’s localized versions guide has the rules. Errors here are common: in Ahrefs’ 2023 study, 67% of domains using hreflang had at least one issue. Our hreflang tag generator builds the tags and catches invalid codes.

40. Check HTTPS and monitoring. Valid certificate, no mixed content, HSTS where possible, and the Security Issues report in Search Console empty. Then set up monitoring: Search Console email alerts, an uptime check, and a monthly look at the Page indexing report.

How to prioritize what you find

Not every finding matters equally. Our rule of thumb for ordering fixes:

1. Anything that blocks crawling or indexing of important pages (robots.txt, noindex, 5xx errors, wrong canonicals).
2. Anything that wastes signals (redirect chains, redirects to the wrong page, internal links through redirects, duplicates).
3. Anything that affects how pages are shown (titles, snippets, structured data).
4. Performance, unless it’s extreme, in which case it moves up.

Write each finding with the URL, what you saw, why it matters and the fix. A list of 300 “issues” from a crawler with no priority is a report nobody acts on.

After the audit

Technical fixes remove obstacles; they don’t create demand. Once the site can be crawled and indexed cleanly, the next questions are about the pages themselves: which ones deserve to exist, which should be merged and which should go.

If you’d rather have someone run this checklist on your site and turn it into a prioritized fix list, that’s what our technical SEO service does.