A technical SEO audit checklist helps you find the hidden problems that stop search engines from crawling, indexing and ranking your pages, even when your content is strong. You do not need to be a developer to run one. This guide groups 25 checks into six categories, and for each check it tells you how to test it, what a pass looks like and which free tool to use. It finishes with a severity triage system so you know what to fix this week and what can wait.
Quick answer: A technical SEO audit checks whether search engines can crawl, render and index your site, and whether pages load fast and securely. Review robots.txt, XML sitemaps, status codes, redirects, indexing, canonical tags, internal links, Core Web Vitals, mobile rendering, titles, structured data and HTTPS, then fix issues in order of severity.
On this page
- Key takeaways
- What is a technical SEO audit?
- Category 1: Crawlability (checks 1–5)
- Category 2: Indexability (checks 6–10)
- Category 3: Site architecture and internal linking (checks 11–14)
- Category 4: Performance and mobile (checks 15–18)
- Category 5: On-page technical elements (checks 19–22)
- Category 6: Security and international (checks 23–25)
- How should you triage technical SEO issues by severity?
- When should you run a technical SEO audit?
- Frequently asked questions
- Next steps
Key takeaways
- Technical SEO is about access and clarity: can search engines reach your pages, understand them and choose the right version to show?
- Google Search Console is the most important free audit tool because it shows how Google actually sees your site.
- A desktop crawler finds sitewide issues such as broken links, redirect chains and duplicate titles that are hard to spot by hand.
- Not every issue matters equally. Triage by severity: anything blocking indexing of important pages comes first.
- Fix problems at the template level when possible, so one change repairs hundreds of URLs.
- Re-run the audit quarterly and after every redesign, migration or major plugin or app change.
What is a technical SEO audit?
A technical SEO audit is a structured review of the parts of a website that affect how search engines crawl, render, index and serve its pages, separate from the content and links that determine relevance and authority.
Think of it as checking the plumbing. Great content in a house with blocked pipes still does not reach anyone. The audit looks for blockages (pages search engines cannot reach), leaks (duplicate or wasted URLs), and slow flow (performance problems).
What tools do you need for a technical SEO audit?
You can complete every check in this technical SEO audit checklist with free or freemium tools:
- Google Search Console: indexing, sitemaps, Core Web Vitals, HTTPS, security issues, manual actions and the URL Inspection tool.
- A website crawler: desktop tools such as Screaming Frog SEO Spider (free for smaller crawls) or similar crawlers map every URL, status code, title and link.
- PageSpeed Insights and Lighthouse: performance and Core Web Vitals.
- Rich Results Test and the Schema Markup Validator: structured data.
- Your browser: view source, developer tools and an incognito window go a long way.
How long does a technical SEO audit take?
For a small business site with under a few hundred pages, a first pass through all 25 checks typically takes a few hours to a day, depending on familiarity with the tools. Large e-commerce or multilingual sites can take considerably longer. Treat these as rough estimates; fixing the issues usually takes longer than finding them.
Category 1: Crawlability (checks 1–5)
Crawlability is whether search engine bots can discover and access your pages. If Googlebot cannot reach a page, nothing else in this list matters for that page.
| # | Check | How to test | Pass criteria | Tool |
|---|---|---|---|---|
| 1 | robots.txt is not blocking important content | Open yoursite.com/robots.txt and review every Disallow rule; check the robots.txt report in Search Console | Only low-value areas (admin, cart, internal search) are disallowed; CSS and JavaScript needed for rendering are allowed | Browser, Search Console |
| 2 | XML sitemap is present, submitted and clean | Find the sitemap URL, submit it in Search Console, crawl the URLs it lists | Sitemap is referenced in robots.txt, submitted without errors, lists only indexable 200-status canonical URLs | Search Console, crawler |
| 3 | Important pages are linked internally with crawlable links | Crawl the site from the homepage; compare with sitemap URLs to find orphans | Every important page is reachable through standard a href links; no key page is an orphan | Crawler |
| 4 | No server errors or broken pages on important URLs | Review status codes in your crawl and the Crawl stats report | No 5xx errors; 4xx errors only on genuinely removed pages that are not linked internally | Crawler, Search Console |
| 5 | Redirects are direct, with no chains or loops | Filter redirects in your crawl; follow each to its final destination | Each redirect goes in one hop to a 200 page; HTTP and non-preferred hostnames redirect to the preferred HTTPS version | Crawler |
Notes on crawlability
A robots.txt Disallow rule stops crawling, not indexing. According to Google Search Central, a blocked URL can still appear in results if other pages link to it, just without a description. To keep a page out of the index, allow crawling and use a noindex directive instead.
For sitemaps, Google documents a limit of 50,000 URLs or 50 MB uncompressed per file; larger sites should split them and use a sitemap index. Including redirected, noindexed or error URLs sends mixed signals, so keep the sitemap a clean list of the pages you want indexed.
Category 2: Indexability (checks 6–10)
Indexability is whether pages that can be crawled are actually eligible to be stored in Google’s index, and whether the right version is chosen.
| # | Check | How to test | Pass criteria | Tool |
|---|---|---|---|---|
| 6 | Important pages are indexed | Review the Page indexing report; inspect key URLs individually | Key pages show as indexed; reasons for non-indexed URLs are understood and intentional | Search Console |
| 7 | No accidental noindex directives | Crawl for noindex in meta robots tags and X-Robots-Tag headers | noindex appears only on pages you deliberately exclude, never on key templates | Crawler |
| 8 | Canonical tags point to the right URL | Check the canonical on each template; compare user-declared and Google-selected canonical in URL Inspection | Each indexable page has a self-referencing canonical or points to the true original; Google agrees with your choice | Crawler, Search Console |
| 9 | Duplicate URL variants are consolidated | Test www vs non-www, HTTP vs HTTPS, trailing slash, uppercase and parameter versions of a URL | Every variant redirects or canonicalizes to one preferred URL | Browser, crawler |
| 10 | No soft 404s or thin placeholder pages | Look for soft 404s in the Page indexing report; crawl for pages with very little content | Removed pages return a real 404 or 410; empty category, tag and search pages are improved, noindexed or removed | Search Console, crawler |
Notes on indexability
Remember that canonical tags are hints, not commands. If Google picks a different canonical than the one you declared, look for conflicting signals: internal links pointing to the other version, sitemaps listing it, or near-identical content across URLs.
If important pages are not indexed at all, our guide to pages that are missing from Google walks through the diagnosis step by step. Parameter-heavy sites, such as online stores with filters, are especially prone to duplicate variants; our guide to faceted navigation on ecommerce sites covers how to control them.
Category 3: Site architecture and internal linking (checks 11–14)
Site architecture is how your pages are organized and connected. Good architecture helps search engines discover pages, understand which are most important and see how topics relate.
| # | Check | How to test | Pass criteria | Tool |
|---|---|---|---|---|
| 11 | Important pages are close to the homepage | Check crawl depth in your crawler | Key service, category and product pages are reachable within a few clicks of the homepage | Crawler |
| 12 | No broken internal links | Filter internal links that return 4xx or 5xx | Zero internal links to broken pages; internal links point to final URLs, not redirects | Crawler |
| 13 | URLs are readable, consistent and stable | Review URL patterns across templates | Lowercase, hyphen-separated, descriptive URLs; no session IDs; consistent structure | Crawler, browser |
| 14 | Navigation and breadcrumbs reflect the hierarchy | Review menus and breadcrumbs on key templates | Main sections appear in navigation; breadcrumbs show the path and use crawlable links | Browser |
Notes on architecture
There is no official click-depth limit, but pages buried deep in pagination or reachable only through internal search tend to be crawled less often and receive less internal link value. As a working guideline, keep revenue-driving pages within three or four clicks of the homepage.
Internal links are also how you signal topical relationships. Grouping content into topic clusters and pillar pages gives both users and crawlers a clear map of what you cover and which page is the main resource on each subject.
Category 4: Performance and mobile (checks 15–18)
Performance and mobile checks confirm that pages load quickly, respond smoothly and work fully on phones. Google now crawls sites with its smartphone crawler, completing its move to mobile-first indexing in 2024, so the mobile version of your site is the version that counts.
| # | Check | How to test | Pass criteria | Tool |
|---|---|---|---|---|
| 15 | Core Web Vitals pass on mobile and desktop | Review the Core Web Vitals report and PageSpeed Insights field data | LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less at the 75th percentile, per web.dev thresholds | Search Console, PageSpeed Insights |
| 16 | Mobile version has the same content as desktop | Compare content, headings, links and structured data on a phone and desktop | No important text, links, images or markup missing on mobile | Browser, URL Inspection |
| 17 | Key content is visible in the rendered HTML | Use URL Inspection’s live test and view the rendered HTML and screenshot | Main content, links and metadata appear in the rendered page without requiring clicks or scrolling to load | Search Console |
| 18 | Images are optimized | Check image file sizes, formats, dimensions and alt text in your crawl | Images are compressed and sized for display, use modern formats where possible, have descriptive alt text, and below-the-fold images are lazy-loaded | Crawler, Lighthouse |
Notes on performance and mobile
Google retired its standalone Mobile-Friendly Test in 2023, so use Lighthouse, Chrome DevTools device emulation and, most importantly, a real mid-range phone to check usability. For a deep dive on each performance metric with causes and fixes, see our guide on how to pass LCP, INP and CLS.
JavaScript-heavy sites need extra care. If content only appears after scripts run, confirm with URL Inspection that Google’s rendered version includes it. Server-side rendering or static generation is generally the safer choice for content you need indexed.
Category 5: On-page technical elements (checks 19–22)
On-page technical elements are the code-level signals on each page that help search engines understand and display it: titles, descriptions, headings and structured data.
| # | Check | How to test | Pass criteria | Tool |
|---|---|---|---|---|
| 19 | Every indexable page has a unique, descriptive title | Crawl for missing, duplicate or truncated titles | Each title is unique, describes the page, and puts the main topic near the front | Crawler |
| 20 | Meta descriptions are present and unique on key pages | Crawl for missing or duplicate descriptions | Key pages have unique, accurate descriptions that summarize the page and invite the click | Crawler |
| 21 | Heading structure is logical | Review H1 to H3 order on each template | One clear H1 describing the page; subheadings follow a logical order without skipping levels | Crawler, browser |
| 22 | Structured data is valid and matches visible content | Test key templates in the Rich Results Test and Schema Markup Validator | No errors on key templates; markup describes content that users can actually see | Rich Results Test |
Notes on on-page elements
Google may rewrite title links and snippets when it believes another version better matches a query, so treat titles and descriptions as your best recommendation rather than a guarantee. Duplicate titles across many pages are still a strong sign of template problems or duplicate content.
Structured data does not directly raise rankings, but it can make pages eligible for rich results and helps machines understand entities. If you are new to it, our schema markup for beginners tutorial includes copy-and-paste examples. Clear heading structure also overlaps with accessibility; our WCAG accessibility guide explains why it matters for screen reader users as well.
Category 6: Security and international (checks 23–25)
Security and international checks confirm that your site is safe to visit, free of penalties, and correctly targeted to the right languages and regions.
| # | Check | How to test | Pass criteria | Tool |
|---|---|---|---|---|
| 23 | HTTPS is enforced sitewide | Load HTTP URLs and check the HTTPS report in Search Console; look for mixed-content warnings | Every HTTP URL redirects to HTTPS; certificate is valid; no insecure resources on HTTPS pages | Browser, Search Console |
| 24 | No security issues or manual actions | Open the Security issues and Manual actions reports | Both reports show no issues | Search Console |
| 25 | Language and regional targeting is correct (if applicable) | Check hreflang annotations and lang attributes on multilingual pages | Each language version references all alternates, including itself, with valid language codes; return links are reciprocal | Crawler, browser |
Notes on security and international
Skip check 25 if your site is in one language for one market, but make sure the lang attribute on your HTML matches your content. For multilingual sites, hreflang errors are among the most common technical issues, usually because alternates do not link back to each other.
How should you triage technical SEO issues by severity?
Triage technical SEO issues by asking two questions: how many important pages does this affect, and does it stop those pages from being crawled, indexed or used? Severity then decides the order of work.
| Severity | Definition | Typical examples from this checklist | Suggested response time |
|---|---|---|---|
| Critical | Blocks crawling or indexing of important pages, or exposes users to harm | Sitewide noindex, robots.txt blocking the site, security issues, manual action, key pages returning 5xx | Immediately |
| High | Significantly reduces visibility or wastes crawling on many important pages | Wrong canonicals on key templates, redirect chains on top pages, failing Core Web Vitals on main templates, missing mobile content | Within days |
| Medium | Weakens performance or clarity but does not block indexing | Duplicate titles, broken internal links, deep click depth, structured data errors, oversized images | Within the month |
| Low | Polish and best practice with limited direct impact | Missing meta descriptions on minor pages, URL formatting inconsistencies, minor heading order issues | Backlog or next sprint |
A simple triage process
- List every failed check with the URLs or templates affected.
- Assign severity using the table above.
- Estimate effort as small, medium or large, ideally with your developer.
- Fix critical items first, regardless of effort.
- Within each remaining severity, start with high-impact, low-effort items such as fixing a template’s canonical tag.
- Validate fixes in Search Console and with a fresh crawl.
- Document what changed and when, so you can connect fixes to later changes in traffic.
Example: a hypothetical online store audit finds a staging-site noindex tag left on the product template, 40 broken internal links and missing alt text on blog images. The noindex tag is critical and gets fixed the same day; the broken links are medium priority for this month; the alt text goes into the content team’s backlog.
When should you run a technical SEO audit?
Run a technical SEO audit at least once a quarter, and always after events that can quietly break things:
- Website redesigns, platform changes or domain migrations
- Major theme, plugin or app updates
- Launching new sections, languages or product categories
- Sudden drops in organic traffic or indexed pages
- Changes to hosting, CDN or security settings
Migrations are where the most damage happens. If a relaunch is coming, follow our guide on how to redesign without losing SEO alongside this checklist.
Frequently asked questions
Can I do a technical SEO audit myself?
Yes. Most checks in this list use free tools such as Google Search Console, PageSpeed Insights and a desktop crawler, and they require careful observation rather than coding skills. You may need a developer to implement some fixes, such as server redirects, template changes or JavaScript rendering issues, but finding and prioritizing problems is very achievable.
What is the difference between crawlability and indexability?
Crawlability is whether search engine bots can reach and fetch a page. Indexability is whether a page that has been crawled is eligible to be stored in the index and shown in results. A page can be crawlable but not indexable, for example when it carries a noindex tag or canonicalizes to another URL.
How often should I run a technical SEO audit?
A full audit every quarter suits most business websites, with lighter monthly checks of Search Console reports. Always run an audit after a redesign, platform migration, major plugin or app change, or an unexplained drop in traffic, because these are the moments when technical problems usually appear without warning.
Which technical SEO issues should I fix first?
Fix anything that stops important pages from being crawled or indexed first: accidental noindex tags, robots.txt blocks, server errors, security issues and manual actions. Next, address issues affecting many key pages, such as wrong canonicals or failing Core Web Vitals. Cosmetic issues on minor pages can safely wait in a backlog.
Do I need paid SEO tools for a technical audit?
Not for most small and medium sites. Google Search Console, PageSpeed Insights, Lighthouse, the Rich Results Test and the free tier of a desktop crawler cover all 25 checks here. Paid tools become useful for very large sites, scheduled monitoring, historical comparisons and team reporting, but they do not replace Search Console data.
Will fixing technical SEO issues improve my rankings?
Fixing technical issues removes barriers, so search engines can properly crawl, index and evaluate your pages. If a problem was blocking important pages, fixing it can lead to clear gains. If the site was already technically healthy, rankings depend more on content relevance, quality and authority, which technical work supports but cannot replace.
