Technical SEO Checklist

A technical SEO audit answers one question: can search engines find, crawl, render, and index this site without obstruction? It has nothing to do with keywords or content quality. It is infrastructure work.

In short: A technical SEO audit checks crawlability, indexation, site architecture, JavaScript rendering, speed, mobile experience, security, structured data, and AI crawler access. Most of it can be done with Google Search Console, PageSpeed Insights, Chrome DevTools, and a free crawler.

What you need before you start

Everything below can be done with free tools. You will need verified access to Google Search Console for the site; without it, roughly a third of the checks are guesswork.

Before you touch anything, create a spreadsheet with four columns: check number, finding, evidence (URL or screenshot), and severity. Fill it as you go.

Section 1: How do you check crawlability and indexation?

This is the foundation. If crawlers cannot reach pages, or Google has decided not to index them, nothing else in the audit matters.

1. Robots.txt configuration

Open yourdomain.com/robots.txt directly in a browser. Confirm it returns HTTP 200, not a 404 or 500. Read the whole file. Look for Disallow: /, which blocks the entire site, and for any rule that catches service pages, the blog, or CSS and JS files needed for rendering. Confirm a Sitemap: directive is present and points to a live sitemap URL.

Record: status code, full file contents, any Disallow rule affecting content, whether the sitemap is declared.

2. XML sitemap health

Open yourdomain.com/sitemap.xml. Confirm it is well-formed XML and returns 200. Take a sample of 15 to 20 listed URLs and check each returns 200, is the canonical version, and is not set to noindex. Confirm the sitemap excludes admin pages, cart pages, thank-you pages, and parameter URLs. Then open Search Console, go to Indexing, then Sitemaps, and compare the discovered URL count against the number of pages you believe the site has.

Record: URL count in sitemap, number of sampled URLs failing, GSC discovered count, last read date.

3. Index coverage and excluded pages

In Search Console, go to Indexing, then Pages. Note the Indexed and Not indexed totals. Open the "Why pages aren't indexed" breakdown and record the count for each reason, paying particular attention to Crawled - currently not indexed, Discovered - currently not indexed, Soft 404, Excluded by noindex tag, and duplicate reasons. Then check that your most commercially important pages appear in the indexed set.

Record: indexed count, not-indexed count, the full reason breakdown with counts, and any key page found in the not-indexed set.

4. HTTP status codes and server errors

Crawl the site with Screaming Frog. Sort the internal URL list by status code. Flag every 4xx and 5xx response that is linked from somewhere on the site or appears in the sitemap. Separately, request a URL that definitely does not exist (yourdomain.com/thispagedoesnotexist) and check the response code in the DevTools Network tab. It must return a true 404. A 404 page returning status 200 is a soft 404 and creates indexable junk.

Record: list of 4xx URLs with source pages, list of 5xx URLs, and whether the 404 page returns a real 404.

5. Redirect chains and loops

In the Screaming Frog crawl, use Reports, then Redirects, then Redirect Chains. A chain is any redirect passing through more than one hop (A to B to C). Also manually test the four host variants and any known legacy URLs. Check whether redirects intended as permanent are 301 rather than 302. Flag any URL that redirects back to itself or into a cycle.

Record: each chain with its hop count, any 302s used for permanent moves, any loops.

6. Crawl budget and index bloat

Compare the total indexed page count from check 3 against the number of pages the site genuinely needs indexed. A large gap is the signal. In Search Console, use the Pages report to list indexed URLs and scan for parameter URLs, filter URLs, tag archives, paginated duplicates, and internal search results pages. Then go to Settings, then Crawl stats, and review what Googlebot is spending requests on by file type and response code.

Record: indexed count versus intended count, categories of low-value indexed URLs with rough counts, average crawl requests per day.

7. Orphan pages

Compare two lists: every URL in the sitemap or your known page inventory, and every URL that Screaming Frog discovered by following internal links. Anything in the first list but not the second is an orphan, reachable only by direct URL or sitemap. Screaming Frog can do this directly if you connect the Search Console API before crawling.

Record: orphan URL list, flagging any that are commercially important.

Section 2: How do you check site architecture and URLs?

8. URL structure and consistency

Export the URL list from your crawl. Review a representative sample of 30 or so for lowercase-only characters, hyphens rather than underscores or spaces, absence of avoidable dynamic parameters, sensible length, and readable slugs. The thing to look for is inconsistency across page types: some URLs hyphenated and some not, some with trailing slashes and some without.

Record: the conventions in use per page type, and any mixed conventions.

9. Canonicalization and duplicate URLs

On five to ten key pages, view the source and find <link rel="canonical">. Confirm it exists, uses an absolute HTTPS URL, and points to the page itself. Then test the duplicate access paths: with and without a trailing slash, with a tracking parameter appended, and the print version if one exists. Each should either return the same canonical or redirect.

Record: per page, whether the canonical is present, self-referencing, and absolute; plus any duplicate path that resolves with 200 and no canonical.

10. Internal linking and link equity flow

In the crawl, look at the inlinks count for each page. Check that key commercial pages receive multiple internal links from relevant content, not just from the footer. Sample the anchor text used for those links and note how much of it is "click here", "read more", or the bare URL.

Record: inlink count for the top ten commercial pages, and a sample of anchor text patterns.

11. Site depth and click distance

Screaming Frog reports crawl depth as the number of clicks from the start URL. Sort by depth and look at what sits at level 4 and beyond. The target is important pages within three clicks of the homepage.

Record: depth distribution (how many URLs at each level), and any commercially important page deeper than three.

12. Pagination handling

Find a paginated series such as a blog index or category listing. Open page 2 and view the source. Check that the canonical on page 2 points to page 2, not back to page 1. Check that pagination links are real <a href> elements in the HTML rather than JavaScript-only controls. Check whether paginated pages carry noindex, and whether a "view all" page exists.

Record: canonical target per paginated page, whether pagination links are crawlable, presence of noindex.

Section 3: How do you check rendering and JavaScript?

Search engines render JavaScript, but not always immediately and not always completely. The purpose of this section is to establish what exists in the raw HTML versus what only appears after scripts run.

13. JavaScript rendering and content parity

Fetch the raw HTML for a key page. In Chrome, "View page source" gives you this, or use curl -s https://yourdomain.com/page. Then open the same page normally and inspect the rendered DOM in DevTools Elements. Compare: is the H1 in the raw HTML? The body copy? The main navigation links? The meta description and canonical? If they only appear in the rendered version, you have a dependency worth documenting. Confirm with the Rich Results Test, which shows you the rendered HTML Google actually produced.

Record: for each of H1, body content, navigation, canonical, and meta tags, whether it is present in raw HTML, rendered DOM, or both.

If you are not sure whether this affects your own site, an audit will establish it along with everything else worth checking.

14. Render-blocking resources

Run the page through PageSpeed Insights. Under Diagnostics, open "Eliminate render-blocking resources" and record the listed files with their estimated savings in milliseconds.

Record: file list, total potential saving, and the current LCP figure for context.

15. Lazy-loading of critical content

Identify the LCP element (PageSpeed names it under "Largest Contentful Paint element"). Then check the HTML for that element. If it is an image carrying loading="lazy", that is the finding. Also confirm that lazy loading is applied to below-the-fold media rather than blanket-applied to every image.

Record: the LCP element, whether it is lazy-loaded, and how lazy loading is applied across the page.

Section 4: How do you check speed and Core Web Vitals?

16. Page speed, mobile and desktop

Run the URL through PageSpeed Insights twice, once for each strategy. Record both Performance scores. Score the site against the lower figure, which is almost always mobile. Do this for at least three page types: homepage, a key service or product page, and a content page. A single homepage test is not representative.

Record: mobile and desktop Performance score per page type, plus the top three listed opportunities.

17. Core Web Vitals

From the same PageSpeed report, record LCP, INP, and CLS. Prefer the field data at the top of the report, which comes from real Chrome users, over the lab data below it. If the field data section is absent, the site has insufficient traffic for the Chrome UX Report and you are working with lab data only. Note that. Then check Search Console, Experience, Core Web Vitals for the site-wide picture across URL groups.

Thresholds: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1.

Record: the three metric values per page, whether they come from field or lab data, and the count of URLs in each GSC status band.

18. Image optimization and next-gen formats

From the PageSpeed report, record the findings under "Properly size images", "Efficiently encode images", "Serve images in next-gen formats", and "Image elements do not have explicit width and height". Then spot-check the hero image in DevTools Network: compare its transferred size and intrinsic dimensions against its rendered display size.

Record: the four diagnostic values with estimated savings, plus the hero image size comparison.

19. Caching, compression, and CDN

Open DevTools, go to Network, reload the page, and click any static asset such as a CSS or JS file. Read the response headers. Look for content-encoding: gzip or br, and a cache-control header with a meaningful max-age. You can do the same from a terminal with curl -I https://yourdomain.com/style.css. Check the asset hostnames and headers for CDN indicators such as cf-ray or x-served-by.

Record: compression method, cache-control values for static assets, and whether a CDN is in use.

20. Third-party script weight

In PageSpeed, open "Reduce the impact of third-party code" and record each third party with its transfer size and main-thread blocking time. Cross-check in DevTools Network by filtering to third-party domains. If a tag manager is installed, open its container and list the tags actually firing.

Record: third-party list with blocking time, total third-party transfer size, and any script loaded synchronously in the head.

Section 5: How do you check mobile and page experience?

21. Mobile responsiveness

Open DevTools, toggle device emulation, and set the viewport to a common mobile size such as 390 by 844. Load the homepage, a service page, a content page, and any form page. Check for horizontal scroll, content overflowing the viewport, text too small to read without zoom, and broken navigation. Test on a real device if you can; emulation misses touch and font-rendering issues.

Record: per page type, whether layout holds, plus screenshots of any breakage.

22. Viewport and tap target sizing

View the source and confirm <meta name="viewport" content="width=device-width, initial-scale=1"> is present and correct. Then, in mobile emulation, inspect the primary navigation links, buttons, and form fields. Google's guidance is a tap target of at least 48 by 48 CSS pixels with 8 pixels of spacing. DevTools shows element dimensions on hover.

Record: viewport meta content, and a list of interactive elements falling below the size or spacing threshold.

23. Intrusive interstitials

Load your key landing pages in mobile emulation with a clean session (use an incognito window so cookies do not suppress pop-ups). Note anything that appears on load or within the first few seconds and covers the main content. Distinguish a small consent banner, which is acceptable, from a full-screen overlay, which is not.

Record: which pages trigger overlays, what triggers them, timing, and how much of the viewport they cover.

Section 6: How do you check security and HTTPS?

24. HTTPS enforcement and SSL certificate

Confirm the site loads over HTTPS. Then request the HTTP version and check in DevTools Network that it redirects to HTTPS in a single hop. Click the padlock in the address bar to see certificate details: issuer, validity dates, and the domain it covers. Run the domain through SSL Labs for the configuration grade; the scan takes a couple of minutes.

Record: redirect behavior and hop count, certificate expiry date, issuer, SSL Labs grade.

25. Mixed content

Load key pages with the DevTools Console open. Mixed content warnings appear there automatically. Search the page source for http:// references in src and href attributes on images, scripts, stylesheets, and iframes.

Record: each mixed-content resource with its URL and type, separating active content (scripts, iframes) from passive (images).

26. Security headers

Run the domain through securityheaders.com, or read the response headers directly with curl -I https://yourdomain.com. Look for Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options or a frame-ancestors CSP directive, and any Content-Security-Policy.

Record: which headers are present and their values. This is a hygiene and trust check rather than a ranking factor, so log it and move on.

27. Exposed sensitive files and endpoints

Request a set of common paths and note the response codes: /.env, /.git/config, /wp-config.php.bak, /backup/, /admin/, /phpinfo.php, and the staging subdomain if you know one exists. Anything returning 200 with real content is a finding. Then search the page source of key pages for API keys or credentials; press Ctrl+F in view-source and search for key, token, secret, and api.

Record: each exposed path with its response code, and any credential found in client-side source.

Section 7: How do you check structured data and directives?

28. Structured data validity

Run the homepage and one URL of each significant page type through the Rich Results Test. Record which schema types are detected, the count of errors, and the count of warnings. Then run the same URLs through the Schema Markup Validator, which validates against schema.org rather than only Google's supported rich result types.

Record: detected types per page type, errors, warnings, and any page with no structured data at all.

29. Meta robots directives

On each key page, view the source and search for <meta name="robots". Then check the HTTP response headers for X-Robots-Tag, which is easy to miss because it never appears in the HTML. Use the Search Console URL Inspection tool on your top five commercial pages to see the indexability verdict Google itself has reached.

Record: the robots directive found per page in both locations, and the URL Inspection verdict for key pages.

30. Open Graph and social meta tags

View the source on your main page types and record whether og:title, og:description, og:image, og:url, og:type, and the Twitter Card tags are present. Confirm the og:image URL resolves and is at least 1200 by 630 pixels. The Facebook Sharing Debugger renders the preview and reports missing tags.

Record: tag presence per template, image dimensions, and any templates sharing an identical og:image.

31. Hreflang implementation

If the site is monolingual, mark this N/A and move on. Otherwise, view the source on a page that exists in multiple languages and record the <link rel="alternate" hreflang="..."> set. Check the language and region codes are valid, that each page references itself, that pairs are reciprocal, and that an x-default exists. The Merkle hreflang tester validates a URL's tags automatically.

Record: hreflang set per sampled URL, missing reciprocals, invalid codes, broken target URLs.

32. WWW, non-WWW, and protocol consistency

Request all four variants: http://domain.com, http://www.domain.com, https://domain.com, https://www.domain.com. Each should redirect in a single hop to one canonical version. Then confirm that this canonical host is the one used in canonical tags, in the sitemap, and in internal links.

Record: the final destination and hop count for each of the four variants, plus any variant resolving with 200.

33. Parameter and faceted URL handling

Identify the parameter patterns the site generates: sorting, filtering, pagination, tracking, session IDs. Search Console's Pages report will show you which of them Google has indexed. For a sample, view the source and check whether they carry a canonical to the clean URL, a noindex, or nothing at all.

Record: parameter patterns in use, how many parameter URLs are indexed, and the handling method applied to each pattern.

Section 8: How do you check AI crawler access?

34. AI crawler directives

Reopen yourdomain.com/robots.txt and search specifically for these user-agents: GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot, and Bytespider. Record whether each is allowed, blocked, or unmentioned. Then establish whether any block was a deliberate decision or an inherited default from a plugin or platform template.

Record: the directive for each user-agent, and whether the site owner intended it.

35. llms.txt and machine-readable signals

Request yourdomain.com/llms.txt and note the response. This is an emerging convention rather than a standard, so absence is not a fault; it is a data point. Separately, check whether core business information (what the company does, pricing, contact details, service descriptions) exists as plain text in the HTML, or whether it is locked inside images, PDFs, or JavaScript-rendered components.

Record: llms.txt status code, and for each of pricing, contact, and service descriptions, whether the information is plain-text accessible.

36. Entity structured data

Run the homepage through the Rich Results Test and the Schema Markup Validator. Look specifically for Organization or LocalBusiness markup and record which fields are populated: name, url, logo, description, and sameAs. The sameAs array should list the brand's profiles on LinkedIn, review platforms, and social networks.

Record: entity type used, fields present, and the full sameAs list.

FAQ

How long does a technical SEO audit take?

For a small site, the first full pass takes four to six hours if you know the tools. Most of that is waiting: crawls, SSL Labs scans, and PageSpeed runs across multiple page types. Larger sites take longer mainly because sampling has to be more careful, not because the checks change.

Do I need paid tools for a technical SEO audit?

No. Every check in this list can be completed with Search Console, PageSpeed Insights, Chrome DevTools, the free Screaming Frog tier, and a handful of free validators. Paid crawlers save time on sites above 500 URLs and give better internal link analysis, but they do not surface a category of problem that free tools miss entirely.

How often should a technical audit be repeated?

After any significant change: a redesign, a platform migration, a CMS upgrade, or a hosting move. Search Console Pages report and Core Web Vitals report are worth checking regularly, since they surface regressions without you having to look for them.

What is the difference between a technical audit and a full SEO audit?

A technical audit covers crawling, rendering, indexation, speed, and security. A full audit adds on-page content, keyword performance, backlink profile, competitor comparison, and conversion factors. Technical is the foundation layer; the rest depends on it working. Running a content audit on a site that Google cannot crawl properly wastes the effort.

Closing

The value of a technical audit is in the record, not the reading. Thirty-six measured findings, each with evidence attached, give you something to sequence and hand to a developer. Thirty-six impressions do not. If you would rather have the data collected and prioritized for you, a technical SEO audit covers all of it, and the implementation can be handled from there.