Rankite
ServicesResultsToolsTeamAboutBlogCareersContactFree SEO Audit
Technical

Technical SEO Audit Checklist: 62 Things to Check (2026)

Home / Blog / Technical SEO Audit Checklist: 62 Things to Check (2026)
Technical SEO audit checklist illustration showing crawling, rendering, and speed checks

A technical SEO audit checklist is a fixed list of checks that confirm search engines can crawl, render, index, and rank your site, separate from content or link quality. This checklist covers 62 checks across ten areas: crawlability, indexation, JavaScript rendering, Core Web Vitals, structured data, site architecture, XML sitemaps and robots.txt, international SEO, log files, and mobile. Work through it in order, because each layer depends on the one before it.

If you want the full-site version that also covers content and off-page authority, our SEO audit checklist walks through all six areas of a complete audit. If you would rather hand this off, our technical SEO audit service breaks down what a paid audit delivers and what it costs.

Key takeaways

  • A technical SEO audit checks only whether search engines can crawl, render, index, and rank a site, not whether the content itself is good.
  • Crawlability and indexation come first, because nothing downstream matters if Google cannot reach or store a page.
  • JavaScript rendering deserves its own check: a page can look complete in a browser and still be missing content in what Google actually indexed.
  • Core Web Vitals thresholds are specific and public: Google's own standard is an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less.
  • Log file analysis is the only source that shows exactly what Googlebot crawled, and it matters most on large or recently migrated sites.
  • Ahrefs found that 67% of hreflang implementations across 374,756 domains contain at least one error, making international SEO one of the most commonly broken checks.

What is a technical SEO audit checklist?

A technical SEO audit checklist is a structured list of checks limited to the machine-facing side of a website: whether search engines can crawl it, render its content, index it, and treat it as fast and trustworthy enough to rank. Google's own developer documentation treats crawling and indexing as prerequisites, not ranking bonuses, so every item on this list protects that foundation. It deliberately excludes content quality, keyword targeting, and backlinks, which belong to a broader SEO audit instead.

Why technical SEO needs its own checklist

A general SEO audit usually gives technical health a single section with ten or so items, which is fine for a quick health check but too shallow once a site has any real scale, a recent migration, or a JavaScript framework. This checklist exists for that gap: developers, in-house SEOs, and agencies who need to go deep on crawling, rendering, and indexing without wading through content and backlink checks that do not apply to the problem in front of them.

The 4 layers a technical SEO audit checksCrawlCan bots reach the page atallRenderCan they see the contentonce it loadsIndexDoes Google choose tostore itRankDoes it compete once it'sindexed
Source: Rankite technical SEO audit framework

How to use this checklist

Work top to bottom, because the order matches dependency, not importance. A page cannot be indexed if it cannot be crawled, and it cannot rank on speed or schema if it is not indexed in the first place. Record every failed check before fixing anything, then use the prioritization framework near the end to decide what to fix first.

Tools for a technical SEO audit

ToolWhat it tells youCost
Google Search ConsoleIndexing status, Core Web Vitals field data, crawl statsFree
Screaming Frog or SitebulbSite-wide crawl: redirects, status codes, duplicate tagsFreemium (free up to 500 URLs)
Chrome DevTools + Rich Results TestWhat actually renders, plus schema validationFree
PageSpeed Insights / CrUXLab and real-user Core Web Vitals dataFree
Screaming Frog Log File Analyzer or JetOctopusWhat Googlebot actually crawled, from raw server logsFreemium / paid
Ahrefs or Semrush Site AuditLarge-scale crawling with historical trackingSubscription

1. Crawlability

If Googlebot cannot reach a page, nothing else on this list matters, so start here every time.

  • [ ] robots.txt does not block important pages, folders, or the CSS/JS files needed to render them.
  • [ ] No orphan pages exist outside the nav, sitemap, and internal link graph.
  • [ ] Redirects resolve in a single clean 301, not chains or loops (see our guide to what a 301 redirect is).
  • [ ] Crawl budget is not wasted on faceted navigation, session IDs, or near-duplicate parameter URLs.
  • [ ] No broken internal links or 404s point at important pages.
  • [ ] Important URLs return a clean 200, not stray 4xx or 5xx errors.
  • [ ] Priority pages sit within roughly three clicks of the homepage.

Google's own documentation frames crawl budget as capacity plus demand: how many connections your server can handle, and how much Google wants to crawl based on a page's popularity and how often it changes. That framing matters most on large sites, which is why crawl budget checks belong on every enterprise technical audit even when they can be skipped on a 50-page brochure site.

2. Indexation

Indexation checks decide which of your crawlable pages are actually eligible to show up in search results at all.

  • [ ] A site:yourdomain.com search shows your key pages are indexed.
  • [ ] No important template carries an accidental noindex tag.
  • [ ] Canonical tags point to the single preferred version of each page, including self-referencing canonicals.
  • [ ] The XML sitemap only lists canonical, indexable, 200-status URLs.
  • [ ] No index bloat from thin or duplicate parameter pages (our guide on what index bloat is and how to fix it covers the cleanup).
  • [ ] Search Console's Page indexing report shows no unexplained "not indexed" reasons; if you see "Crawled - currently not indexed," see how to fix crawled, currently not indexed.
  • [ ] Pagination and faceted URLs are canonicalized or noindexed consistently, not left to chance.

3. Can Google actually render your JavaScript?

Google typically indexes a page in two passes: it reads the raw HTML first, then queues a second render pass once resources are available to execute the JavaScript, according to Google's own Search Central documentation on how rendering works. A page can look complete in a browser and still be missing content, links, or schema in what Google actually indexed, which is why rendering gets its own section instead of hiding inside "technical health."

  • [ ] Search Console's URL Inspection tool shows the same content in the rendered HTML that a browser shows.
  • [ ] Critical content and internal links exist in the server-rendered HTML, not injected client-side only.
  • [ ] No important content sits behind a click, hover, or other interaction Googlebot will not trigger.
  • [ ] JavaScript execution does not delay revealing primary content long enough to hurt Core Web Vitals.
  • [ ] Cookie or consent banners do not hide page content from Googlebot's render pass.
  • [ ] Internal links are real <a href> tags Google can follow, not JavaScript-only onclick handlers.

4. Core Web Vitals and page speed

Google, through its web.dev developer resource, defines a "good" page as one where Largest Contentful Paint happens in 2.5 seconds or less, Interaction to Next Paint is 200 milliseconds or less, and Cumulative Layout Shift stays at 0.1 or less, all measured at the 75th percentile of real visits.

  • [ ] LCP is 2.5 seconds or less at the 75th percentile in the Search Console field data.
  • [ ] INP is 200 milliseconds or less.
  • [ ] CLS stays at 0.1 or less.
  • [ ] Time to first byte stays under roughly 800 milliseconds, web.dev's own "good" threshold for server response time.
  • [ ] Images are compressed and served in a next-gen format, with below-the-fold images lazy-loaded.
  • [ ] Render-blocking CSS and JS are trimmed, deferred, or inlined where it matters.
  • [ ] Mobile field data is checked separately from desktop, since the two often score differently.
  • [ ] Hosting and server capacity hold response times steady under real traffic, not just in a quiet test.

5. Structured data

Schema does not write your rankings for you, but it is one of the highest-leverage technical fixes because it is fast to ship and immediately testable.

  • [ ] The right schema types are implemented for each page (Article, Product, FAQPage, HowTo, LocalBusiness, and so on).
  • [ ] Every schema block validates with zero errors in Google's Rich Results Test.
  • [ ] No schema describes content that is not actually visible on the page.
  • [ ] FAQPage or HowTo markup mirrors the on-page questions and steps exactly, item for item.
  • [ ] Organization and sitelinks searchbox markup is present on the homepage where relevant.
  • [ ] Schema updates automatically when the underlying page content changes, so it never goes stale.

6. Site architecture and internal linking

  • [ ] The site follows a logical, mostly flat hierarchy rather than deep, winding paths.
  • [ ] Internal links use descriptive anchor text, not "click here" or bare URLs.
  • [ ] No orphan pages exist outside the main navigation and internal link graph.
  • [ ] URLs are short, readable, and describe the page without unnecessary parameters.
  • [ ] Internal links route authority toward priority pages instead of diluting it across low-value ones.
  • [ ] Breadcrumbs are implemented in the UI and marked up with BreadcrumbList schema.

7. XML sitemaps and robots.txt

  • [ ] The sitemap lists only canonical, indexable, 200-status URLs, nothing redirected, blocked, or noindexed.
  • [ ] Large sites split sitemaps into files under 50,000 URLs and 50MB, linked from a sitemap index.
  • [ ] The sitemap is submitted in Search Console and referenced at the top of robots.txt.
  • [ ] robots.txt does not block CSS or JS files that Google needs to render the page.
  • [ ] Every disallow rule has been tested against real URL patterns, not written from memory.
  • [ ] Sitemaps regenerate automatically on large or frequently updated sites, instead of relying on a manual export.

8. Why do most hreflang setups have errors?

Ahrefs analyzed hreflang tags across 374,756 domains and found that 67% of them contain at least one error, most often a missing x-default tag or a missing reciprocal (return) link between language pairs. Hreflang fails quietly: Google simply ignores the broken signal and falls back to its own judgment about which version to show, so a site can carry the tags for years without anyone noticing they never worked.

67%of hreflang implementationscontain at least one errorAhrefs analyzed 374,756 domains using hreflang and found errors on 67% of them.
Source: Ahrefs (study of 374,756 domains)
  • [ ] Every localized page includes hreflang tags for every language and region variant, including itself.
  • [ ] Reciprocal tags exist on both sides of each pair; a page pointing to another must be pointed back to.
  • [ ] An x-default tag is set for the fallback version shown to unmatched locales.
  • [ ] hreflang values use correct ISO language and region codes, not made-up or reversed combinations.
  • [ ] hreflang tags point to indexable canonical URLs, never to a redirect or a 404.

9. What is log file analysis and do you actually need it?

Log file analysis reads your server's raw request logs to see exactly what Googlebot crawled, when, how often, and what response code it received, which is ground truth that Search Console's sampled reports do not fully show. It earns its place mainly on large sites, thousands of URLs or more, where crawl budget is a real constraint; a small brochure site rarely needs it.

Search Console vs. log filesSearch Console showsCrawl stats summary by response codeTotal indexed page countCore Web Vitals field scoresSitemap submission statusLog files revealEvery single Googlebot hit, by exact URLReal response codes and load time per hitWhich pages get crawled and how oftenCSS, JS, and image requests Search Console hides
Source: Rankite technical SEO audit framework
  • [ ] Confirm Googlebot is actually crawling priority pages, not just theoretically able to reach them.
  • [ ] Check that crawl frequency roughly matches how important or how often each page type changes.
  • [ ] Spot crawl waste on parameter URLs, duplicate pages, or dead paths eating server resources.
  • [ ] Verify the response codes Googlebot receives match what a real browser sees.
  • [ ] Separate Googlebot Smartphone crawl volume from Googlebot Desktop, since mobile-first indexing makes the mobile crawler the one that counts.
  • [ ] Confirm paths disallowed in robots.txt have actually stopped being requested.

10. Mobile technical SEO

  • [ ] The mobile version carries the same content, internal links, and structured data as desktop, since Google indexes mobile-first.
  • [ ] Tap targets and font sizes are usable on a real phone, not just a resized browser window.
  • [ ] No intrusive interstitial blocks content immediately after a mobile visitor arrives.
  • [ ] Mobile Core Web Vitals are checked on their own, since mobile devices and networks are typically slower and less consistent than desktop.
  • [ ] The viewport meta tag is configured correctly, with no unwanted horizontal scroll or forced zoom.

How often should you run a technical SEO audit?

A full pass once or twice a year is enough for most sites, paired with a lighter monthly glance at Search Console's crawl stats and Core Web Vitals reports. Run an unscheduled audit immediately after any migration, replatform, or major redesign, since those events are the single most common cause of new crawl blocks, broken redirects, and lost indexation.

How to prioritize technical SEO audit findings

A raw list of 62 checks is only useful once it is sorted by what actually blocks rankings versus what merely helps at the margins.

PriorityWhat it coversExamples
P0: fix immediatelyAnything blocking crawling or indexing outrightStray noindex tags, robots.txt blocking key paths, broken canonical chains
P1: fix this quarterRendering, speed, and schema issues that cap competitivenessFailing Core Web Vitals, JS-only content, invalid or missing schema
P2: plan and monitorSlower, compounding structural workHreflang cleanup, site architecture, crawl budget on large sites

Clear the P0 column before touching anything else, since fixing schema or Core Web Vitals on a page Google cannot index wastes the effort. Once the P0 list is empty, P1 items usually deliver the fastest visible movement, while P2 work compounds over months rather than weeks.

A real example of technical fixes compounding

Clean technical fundamentals are also what let AI answer engines cite a page with confidence, since a crawlable, well-structured page is easier for both Google and language models to verify. We saw this directly with LiveHelpNow, where technical and content work together added roughly 3,000 organic visits a month and got the site cited in AI Overviews, a result that depends on Google being able to crawl, render, and understand the page cleanly in the first place. You can read the full breakdown in our case studies.

Frequently asked questions

What is a technical SEO audit checklist? It is a fixed, ordered list of checks limited to the parts of a website that decide whether search engines can crawl, render, index, and rank it: crawlability, indexation, JavaScript rendering, Core Web Vitals, structured data, site architecture, sitemaps, robots.txt, international SEO, and log files. It leaves out content quality, keyword research, and backlinks, which belong to a full SEO audit instead.

What is the difference between a technical SEO audit checklist and a full SEO audit checklist? A technical checklist only covers the machine-facing layer: crawling, rendering, indexing, speed, and structured data. A full SEO audit adds content quality, on-page optimization, keyword intent, and backlinks on top of that. Our broader SEO audit checklist walks through both layers if you need the complete picture.

How many checks should a technical SEO audit include? This checklist runs 62 checks across ten areas, which is enough depth for most small and mid-sized sites. Enterprise sites with millions of URLs often expand it further, especially around log file analysis and international SEO, where a single missed hreflang pair can affect thousands of pages at once.

Do I need to check log files for a technical SEO audit? Small sites usually do not need it, since Search Console's crawl stats are close enough to reality. Sites with thousands of URLs, a history of crawl budget problems, or a recent migration benefit most, because log files are the only source that shows exactly what Googlebot requested and when, rather than a sampled summary.

How do I know if Google can render my JavaScript? Run the page through Search Console's URL Inspection tool, then compare the rendered HTML it shows against your raw server response. If key content, links, or schema only appear in the rendered version, they still count, but if they are missing from both, Googlebot never saw them at all.

What is the most common technical SEO mistake? A stray noindex tag or an overly broad robots.txt disallow rule left over from a staging environment or migration, which can silently deindex an entire section of a site. It rarely announces itself, which is exactly why crawling and indexing come first on every audit checklist.

How often should you run a technical SEO audit? Once or twice a year covers most sites, with a lighter monthly check of Search Console for new crawl errors or indexing drops. Run an extra pass immediately after any migration, redesign, or CMS change, since those are the moments most likely to introduce crawl blocks or broken redirects.

Can I run a technical SEO audit without paid tools? Yes, for small sites. Google Search Console, Chrome DevTools, the Rich Results Test, and PageSpeed Insights are free and cover most of this checklist. Paid crawlers like Screaming Frog, free up to 500 URLs, or Ahrefs become worth it once a site grows past a few hundred pages or needs ongoing tracking.

What is crawl budget and does it matter for small sites? Crawl budget is the combination of how much Google's servers are willing to fetch from your site, its crawl capacity, and how much Google wants to, based on popularity and how often content changes. Google's own documentation notes that crawl budget is mainly a concern for sites with millions of URLs, so a small site with a few hundred pages rarely needs to worry about it.

Does structured data affect rankings? Google states that structured data does not directly move rankings on its own, but it does make pages eligible for rich results like star ratings, FAQ snippets, and how-to steps, which can lift click-through rate. It also helps Google and AI systems understand what a page is about, which supports rankings indirectly.

Your next step

Work through all ten sections, sort your findings into the P0, P1, and P2 buckets above, and clear the P0 column first. If your site is complex enough that this checklist raises more questions than it answers, our technical SEO company page explains what ongoing technical support looks like, or you can book a free technical SEO audit call and we will walk through your crawl, index, and speed issues together.

Related articles

Let's grow

Ready to own page one?

Get a free, no-obligation SEO audit and a 30-minute strategy session. We'll show you exactly where the growth is hiding.

Book your free audit Explore services
Get in touch

Tell us about your project

Fill out the form and we'll get back to you within one business day. Prefer email? Write to us directly at contact@rankite.com.

Or copy our email and write to us directly: contact@rankite.com