Technical SEO Audit Checklist: 47 Items to Fix Crawlability, Indexing, Core Web Vitals, and Site Health

What Is a Technical SEO Audit?

A technical SEO audit is a systematic review of a website’s infrastructure to identify issues that prevent search engines from crawling, rendering, indexing, or understanding its pages. Unlike content audits, which evaluate what a page says, technical audits evaluate whether Google can access and process the page at all.

You can publish strong content and earn quality backlinks and still underperform if technical barriers block Google from reaching that content. A technical audit removes those barriers.

Crawlability — Items 1–10

Crawl issues block Google before it ever sees your content. Work through these ten items before checking anything else. Fix this before touching speed.

1. robots.txt is accessible and correctly configured

Fetch yourdomain.com/robots.txt directly in a browser. Verify it loads with a 200 status and does not accidentally disallow important pages or directories. Blocking /wp-admin/ is correct. Blocking / is a site-wide crawl block. Test the file using Google’s robots.txt testing tools or Search Console inspection where available. (Google: robots.txt documentation)

2. XML sitemap is present, submitted, and clean

Your sitemap should list only canonical, indexable URLs. Remove noindexed pages, redirect targets, and 404 URLs from the sitemap. Submit in Google Search Console under Sitemaps. A sitemap with outdated or invalid URLs can waste crawl attention and make technical monitoring harder. Do not rely on the sitemap alone — internal links are what Googlebot primarily follows during a crawl. (Google: Sitemaps documentation)

3. No important pages return non-200 status codes

Crawl your site with Screaming Frog (free up to 500 URLs). Sort by HTTP status code. Every important page should return 200. Soft 404s — pages that display “not found” content but return a 200 status — appear under Coverage in Search Console and need separate attention.

4. Internal links do not point to redirect chains

Internal links should point directly to the final destination URL. Unnecessary redirect hops slow users, waste crawl resources, and weaken signal consistency. Update internal links to point to the final URL. Screaming Frog’s “Redirect Chains” report shows every multi-hop redirect on your site.

5. No crawl traps exist

Infinite pagination, endless faceted navigation, and calendar archives trap crawlers in loops. Common sources: WooCommerce filter URLs, WordPress date archives, session ID parameters appended to every URL. Manage these using canonical tags, noindex where appropriate, internal-link controls, and robots.txt where crawling must be limited. Review crawl patterns in Search Console’s crawl stats report and your server logs.

6. Important pages are easy to reach

Use Screaming Frog’s Crawl Depth visualization. Deep pages are harder for users and crawlers to reach, especially if they are not linked from important hubs or contextual sections. Every commercial or high-value page should be easy to reach from navigation, hub pages, or relevant contextual internal links. The 3-click guideline is a practical benchmark, not a Google rule — but it serves as a useful sanity check. Flat architecture and strong internal linking solve most crawl depth problems.

7. No blocked resources preventing rendering

If Googlebot cannot load your CSS and JavaScript files, it sees a broken version of your page — which affects how it indexes and ranks the content. Go to Search Console, use URL Inspection on key pages, and click “Test Live URL” to see what Googlebot actually renders. Compare it to what a browser shows.

8. Pagination is handled correctly

Google dropped support for rel="next" and rel="prev" in 2019. For paginated content, avoid automatically canonicalizing every page to page 1 unless the content is truly duplicate or low-value. Important paginated archives, product category pages, and content series may need to remain crawlable with self-referencing canonicals — not pointed at page 1. (Google: Duplicate URL consolidation)

9. Faceted navigation is handled on a case-by-case basis

Ecommerce and directory sites generate thousands of near-duplicate URLs from filter combinations (color + size + price). Handle faceted URLs case by case. Some filtered pages should be indexed if they match search demand and provide unique value. Others should be canonicalized, noindexed, internally de-emphasized, or blocked from crawling depending on crawl risk and business value. There is no single rule that applies to all sites.

10. Crawl budget is not wasted on low-value URLs

Session IDs in URLs, tracking parameters without canonicalization, and print-version pages consume crawl budget without producing indexable value. For large sites, check the crawl stats report in Search Console to see which URL types Google is spending the most time on. (Google: Managing crawl budget for large sites)

Indexation — Items 11–18

11. All important pages are indexed

In Search Console, go to Indexing and review the “Indexed” count. Cross-reference it against your known page count. A significant gap usually means indexation issues — noindex tags, canonical misconfigurations, or low-quality pages Google has chosen not to index.

12. No important pages are accidentally noindexed

Screaming Frog can crawl your site and flag pages with noindex meta tags or X-Robots-Tag headers. Review the full list. CMS migrations, theme changes, and plugin updates have all been responsible for accidentally noindexing entire sites.

13. Canonical tags are implemented correctly

Most important indexable pages should have a clear canonical signal, often self-referencing when the page is the preferred version. Near-duplicate URLs should canonical to the preferred version. A canonical tag pointing to the wrong page can cause Google to choose a different preferred URL than the one you intended. Consistent internal links, sitemap URLs, redirects, and content signals help Google understand which version you prefer. (Google: Canonical URL documentation)

14. Hreflang is correctly implemented for multilingual sites

Each language version should hreflang to every other language version, including a self-referencing hreflang tag. Mismatches — where page A points to page B but B does not point back to A — are a common failure mode. Validate with Screaming Frog’s hreflang report. (Google: Internationalization documentation)

15. All domain variants redirect to one canonical version

Test all four versions: http://domain.com, https://domain.com, http://www.domain.com, https://www.domain.com. All four should 301-redirect to the same preferred version. Multiple live versions create duplicate content and split signals.

16. Thin content pages are reviewed and addressed

Pages with little unique value — auto-generated pages, near-duplicates, or posts with no meaningful content differentiation — should be reviewed for improvement, consolidation, or noindexing. Word count alone is not the deciding factor. Usefulness, uniqueness, and search intent match matter more than hitting a minimum word count. Use Screaming Frog filtered by low word count to surface candidates for review.

17. Search Console shows no manual actions

Check Search Console under Security and Manual Actions. A manual action means a human Google reviewer has penalized your site for a specific policy violation. Manual actions require you to fix the underlying issue and submit a reconsideration request.

18. Staging or dev environments are not being indexed

Staging subdomains indexed by Google create duplicate content at scale. Password-protect staging environments or use a blanket Disallow: / in the staging robots.txt. Check with a site:staging.yourdomain.com search.

Core Web Vitals and Page Speed — Items 19–26

Core Web Vitals became part of Google’s page experience signals in 2021. They are not the primary ranking driver — content and authority remain more important — but they can tip results when competing pages are otherwise similar. (Google web.dev: Core Web Vitals)

19. LCP under 2.5 seconds

Largest Contentful Paint measures how long the largest visible element takes to load. Test with PageSpeed Insights and validate against real-user field data in Search Console’s Core Web Vitals report. The most common cause of slow LCP is an unoptimized hero image or render-blocking resources above the fold.

20. INP under 200ms

Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. It measures responsiveness to user interactions — clicks, taps, keyboard input. Heavy JavaScript execution is the main cause of poor INP. Audit with Chrome DevTools Performance panel.

21. CLS under 0.1

Cumulative Layout Shift measures visual stability. Pages that shift as they load frustrate users. Common causes: images without explicit width and height attributes, late-loading web fonts, and third-party ad units that expand after initial render. Set explicit dimensions on all images.

22. Total page weight is reasonable for key landing pages

Open Chrome DevTools, go to the Network tab, and hard-reload the page. Oversized images are the most common culprit. Compress images before upload and serve them via a CDN. A 10MB landing page is usually excessive and should be reviewed, even if server response is fast.

23. Images use modern formats

Serve images in WebP or AVIF format. Both offer 25–50% smaller file sizes than JPEG at equivalent quality. Use srcset and sizes attributes to serve appropriately sized images to different screen widths. Apply loading="lazy" to all images below the fold. (Google: Image SEO best practices)

24. JavaScript is not render-blocking

Defer or async-load non-critical JavaScript. Scripts loaded with <script src="..."> in the <head> block HTML parsing until they download and execute. Identify render-blocking scripts using Chrome DevTools Performance panel or PageSpeed Insights Opportunities section.

25. Critical CSS is inlined or preloaded

External CSS files block rendering until they are downloaded. Inline the CSS required to render above-the-fold content, or use <link rel="preload"> for critical stylesheets. Non-critical CSS can load asynchronously.

26. TTFB is measured and within reasonable range

Time to First Byte measures how long the server takes to start responding. Slow TTFB indicates server performance problems, lack of caching, or heavy server-side processing. Use 800ms as a practical diagnostic benchmark — but the best target depends on page type, server setup, geography, and user expectations. Improve TTFB with a faster hosting tier, a CDN, full-page caching (LiteSpeed, Varnish, Redis), and database optimization.

Mobile Usability — Items 27–33

Google has used mobile-first indexing as its default since 2019. The mobile version of your site is what Google primarily crawls and indexes, regardless of what proportion of your traffic is mobile.

27. Site works correctly on mobile devices

Check mobile usability using PageSpeed Insights, Chrome DevTools device emulation at common mobile widths (375px, 390px, 430px), and real-device testing. Search Console’s indexing and page experience reports may surface mobile issues at scale where available. A page that looks broken on mobile affects both user experience and how Googlebot renders the mobile-first version.

28. No intrusive interstitials on mobile

Full-screen popups that appear within the first few seconds of page load on mobile are a negative signal. Cookie consent banners and legally required age-gate overlays are exempt. Marketing email capture popups that cover the main content are not. (Google: Intrusive interstitial policy)

29. Tap targets are large enough and properly spaced

Google recommends tap targets of at least 48×48 CSS pixels with at least 8px spacing between adjacent targets. Buttons, links, and form elements that are too small or too close together create usability friction that affects user experience and engagement. Test with Chrome DevTools device emulation at 375px width.

30. No horizontal scrolling on mobile

Test at 375px viewport width in Chrome DevTools. Common causes: fixed-width elements, wide images without max-width: 100%, oversized tables, and pre-formatted code blocks. Any element wider than the viewport forces horizontal scroll.

31. Base font size is at least 16px

Text smaller than 16px on mobile is difficult to read without zooming — which signals poor user experience. A 16px base is the practical minimum for readable body text on mobile. Verify in Chrome DevTools computed styles for your body or main content element.

32. HTTPS is site-wide with no mixed content

Every resource loaded by an HTTPS page — images, scripts, stylesheets, iframes — must also be served over HTTPS. Mixed content (HTTP resources on HTTPS pages) triggers browser security warnings and is a trust signal issue. Check with Chrome DevTools Security panel.

33. 404 page is custom and useful

A useful 404 page includes a search bar, links to popular sections, and a clear explanation that the page was not found. A blank white page or unbranded error message erodes user trust and increases bounce rate from accidental 404s.

Structured Data — Items 34–40

Structured data gives Google machine-readable context about your content and can make eligible pages qualify for rich results such as breadcrumbs, product details, or article enhancements. It does not guarantee rich results or AI citations. Structured data also strengthens entity understanding, which matters for AI Overviews, Google AI Mode, and Generative Engine Optimization. It does not directly boost organic rankings. (Google: Structured data overview)

34. Organization schema on homepage

Include: name, URL, logo (as ImageObject), contactPoint, and sameAs (links to social profiles and third-party directories). Organization schema helps clarify brand identity and official profiles — it can support entity understanding, but it does not guarantee a Knowledge Panel. (Google: Organization schema documentation)

35. WebSite schema for site identity

WebSite schema defines your site’s name, URL, and search-related metadata at the entity level. Google removed the visible Sitelinks Search Box feature from search results in November 2024, so do not implement WebSite schema with SearchAction expecting a search box to appear in your SERP listing. Use it for structured site identity rather than as a search-feature tactic.

36. Article schema on all blog posts and guides

Include key properties such as headline, datePublished, dateModified, author (using Person schema with name and URL), image (using ImageObject), and publisher (using Organization schema) where appropriate. Accurate dateModified dates help Google understand content freshness. Pair this with a named author bio page linked from the byline — schema and on-page E-E-A-T signals work together. (Google: Article schema documentation)

37. BreadcrumbList schema on all pages

BreadcrumbList schema can help Google understand page hierarchy and may make breadcrumb paths eligible to appear in search results. Match schema breadcrumbs to the visual breadcrumbs visible on the page. (Google: Breadcrumb schema documentation)

38. FAQPage schema on eligible pages

FAQPage schema can help clarify visible FAQ content for eligible pages, but Google has significantly limited FAQ rich-result visibility in recent years. Use FAQ schema only when the content is visible, useful, and compliant with Google’s structured data guidelines — not for keyword-stuffed fake FAQs. Validate in Google’s Rich Results Test before deploying. (Google: FAQPage schema documentation)

39. LocalBusiness schema on local landing pages

Useful for local SEO when the page represents a real business location. Include: name, address (using PostalAddress), telephone, openingHours, geo (latitude and longitude), and URL. Add it to every location page — not just the homepage — if you have multiple locations. (Google: LocalBusiness schema documentation)

40. All structured data validates without errors

Use Google’s Rich Results Test for individual URLs and Schema.org Validator for JSON-LD syntax. Structured data with critical errors may prevent eligibility for rich results. Warnings should be reviewed, but not every warning blocks eligibility.

On-Page Signals — Items 41–47

41. Every page has a unique, optimized title tag under 60 characters

Title tags are one of the most important on-page relevance signals and strongly influence how search results are presented. Keep them under 60 characters to avoid truncation in search results. Lead with the primary keyword. Avoid duplication — Screaming Frog, Ahrefs Site Audit, or Semrush Site Audit can identify missing, duplicate, and over-length title tags at scale.

42. Every page has a unique meta description under 155 characters

Meta descriptions are not a ranking factor but they influence click-through rate. Write them as ad copy — what does the user get by clicking? Screaming Frog’s “Meta Description” tab shows missing, duplicate, and over-length descriptions across the entire site.

43. One H1 per page, containing the primary keyword

Multiple H1s are not automatically a penalty, but one clear primary H1 usually creates cleaner page structure for users and search engines. One H1 per page matching or closely related to the title tag is standard practice. Heading structure as a whole — H1 → H2 → H3 — helps both users and Google understand content hierarchy.

44. Descriptive alt text on all meaningful images

Alt text serves two purposes: accessibility for screen reader users, and image indexing signals for Google Images. Describe what the image shows. Decorative images (spacers, dividers) use empty alt attributes (alt=""). Never keyword-stuff alt text. (Google: Image SEO best practices)

45. Internal links use descriptive, keyword-relevant anchor text

Anchor text tells Google what the linked page is about. “Click here” and “read more” provide little topical context compared with descriptive anchor text. A page with no internal links pointing to it is a weak signal — build contextual links from related pages. Use anchor text that describes the destination page’s topic. For a full treatment of internal link strategy, see the Internal Linking for SEO guide.

46. No broken internal or external links

Broken links create dead ends for users and can waste crawl attention, especially on larger websites. Screaming Frog identifies all broken links in a crawl. Prioritize fixing broken internal links first — external broken links matter less unless they link to authoritative sources cited in your content.

47. URLs are clean, keyword-relevant, and stable

Short, readable URLs are easier for users to understand and share, but avoid changing established URLs unless there is a clear reason. Use hyphens, not underscores. Keep URLs lowercase. Remove unnecessary parameters, dates, and stop words. The redirect cost and authority disruption from URL changes typically outweigh any benefit from a cleaner URL on an established page.

Frequently Asked Questions

How often should I run a technical SEO audit?

For most active websites, a full technical audit once every six months is a reasonable baseline. Run an additional audit after any major site change — platform migration, redesign, hosting change, or CMS update. Monitor Google Search Console continuously for new crawl errors and indexation drops between full audits.

What tools do I need for a technical SEO audit?

The core toolkit: Google Search Console (free, essential), Screaming Frog SEO Spider (free up to 500 URLs, £259/year for unlimited), and PageSpeed Insights (free). For large sites, add Google’s CrUX dashboard for real-user Core Web Vitals data. You do not need expensive paid platforms to run a thorough audit.

Which items should I fix first?

Crawlability (items 1–10) and indexation (items 11–18) take priority. A site that Google cannot crawl or cannot index cannot rank regardless of content quality. Fix blocking issues first. Once Google can access and index all important pages, move to Core Web Vitals and structured data.

Do I need to fix all 47 items?

Not necessarily. Not every item applies to every site. A single-page brochure site has no pagination issues. A blog with no local presence does not need LocalBusiness schema. Work through each category, identify which items apply to your specific site, and prioritize by impact. Items that affect crawling and indexing have the highest average impact across site types.

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

A technical audit checks whether Google can access and understand your site. A content audit checks whether the content on your site serves user intent well enough to rank. Both are distinct processes. Technical issues block Google at the infrastructure level. Content issues affect whether indexed pages are competitive for their target queries. Fix technical issues first, then audit content.

Sources and References

• Google Search Central: robots.txt documentation
• Google Search Central: Sitemaps overview
• Google Search Central: Canonical URL documentation
• Google Search Central: Managing crawl budget
• Google web.dev: Core Web Vitals
• Google Search Central: Structured data overview
• Google Rich Results Test
• Google Search Central: Mobile-first indexing