The Complete Technical SEO Audit Checklist

A technical SEO audit answers one deceptively simple question: can search engines find, crawl, render, understand, and index the pages you actually want to rank? Content quality and links matter enormously, but they only pay off when the technical foundation lets search engines reach and process your pages. A strong article sitting behind a misconfigured canonical tag, a stray noindex, or a five-hop redirect chain is, for practical purposes, invisible.

This checklist is the process we use when we audit a site from scratch. It is organized in the order problems tend to cascade: if a page cannot be crawled, nothing about its speed or schema matters yet. Work from the top down and record every finding with the affected URLs before fixing anything. The most valuable output of an audit is not a list of issues; it is a prioritized plan.

You do not need an enterprise budget. A crawler that can render JavaScript, Google Search Console, browser developer tools, and access to server logs will get you most of the way. Before you change anything, export a baseline: 16 months of Search Console performance data, indexed and not-indexed page counts, Core Web Vitals status, and a full crawl. Without it, you cannot prove what your fixes achieved.

Crawlability and robots.txt

Crawlability is the first gate. If Googlebot cannot request a URL, nothing downstream matters. Start by reading your robots.txt file line by line, as though you had never seen it before.

What to check in robots.txt

• The file lives at the root of each host (https://example.com/robots.txt) and returns a 200 status code.
• No broad Disallow rule blocks important sections, such as a leftover Disallow: / from a staging environment.
• CSS, JavaScript, and image files needed for rendering are not blocked.
• Faceted navigation, internal search results, and parameter-heavy URLs that generate near-infinite combinations are handled deliberately.
• The file references your XML sitemap with an absolute URL.
• Rules are tested against sample URLs using the robots.txt report in Search Console.

Crawl the site like a search engine

Run a full crawl starting from the homepage with your crawler set to respect robots.txt. Compare the number of URLs discovered through links with the number of URLs in your sitemap and the number Search Console reports as known. Large gaps in either direction are informative: sitemap URLs that the crawl never reached are orphan pages, and crawled URLs that are missing from the sitemap are often duplicates or parameter variants you did not intend to publish.

XML sitemaps

An XML sitemap is a hint, not a command, but a clean one helps search engines discover new and updated content faster and gives you a useful diagnostic lens in Search Console. The golden rule is simple: a sitemap should contain only canonical, indexable URLs that return a 200 status code.

• Every listed URL returns 200, is not blocked by robots.txt, is not noindexed, and is self-canonical.
• No redirected, 404, or parameter-duplicate URLs are included.
• Each file stays within the protocol limits of 50,000 URLs and 50 MB uncompressed; larger sites use a sitemap index.
• lastmod values reflect genuine content changes rather than being updated on every page load.
• Sitemaps are submitted in Search Console and referenced in robots.txt.
• Large sites split sitemaps by page type (products, categories, articles) so indexing coverage can be monitored per template.

Indexation and canonicalization

Once you know what can be crawled, the next question is what is actually indexed and whether Google has chosen the same canonical URLs you intended. This is where many of the highest-impact findings live.

Review the Page indexing report

The Page indexing report in Search Console groups non-indexed URLs by reason. Pay particular attention to these categories:

• Crawled - currently not indexed: Google fetched the page but chose not to index it, which often signals thin, duplicate, or low-value content.
• Discovered - currently not indexed: Google knows about the URL but has not crawled it yet, which can point to crawl budget pressure or weak internal linking.
• Duplicate, Google chose different canonical than user: your canonical tag is being overridden, usually because other signals contradict it.
• Excluded by 'noindex' tag: confirm every URL here is meant to be excluded.

Canonical tag checks

• Every indexable page has a self-referencing canonical tag using the absolute, preferred URL.
• Canonicals point to URLs that return 200, not to redirects, 404s, or noindexed pages.
• Protocol, host, trailing slash, and letter case are consistent between canonicals, internal links, and sitemaps.
• Only one canonical is declared per page, whether in the HTML head or the HTTP header.
• Paginated series are not all canonicalized to page one, which hides deeper items from search.
• Canonical tags in the rendered HTML match those in the raw HTML if JavaScript modifies the head.

Remember that a canonical tag is a strong hint that Google weighs alongside other signals: internal links, sitemap inclusion, redirects, and content similarity. When those signals disagree, Google may pick its own canonical. The fix is almost always to make every signal point at the same URL. Google's guide to consolidating duplicate URLs explains the hierarchy of signals in detail.

Duplicate content sources to hunt down

Common culprits include HTTP and HTTPS versions both resolving, www and non-www both resolving, trailing slash variants, tracking parameters, session IDs, sort and filter parameters, printer-friendly pages, and staging environments that were accidentally left open to crawlers. Each should either redirect to the preferred version or be canonicalized to it.

Status codes and redirect chains

Status codes tell search engines what happened when they requested a URL. Misused codes waste crawl activity and leak the value of links you have earned.

Redirect chains and loops

A redirect chain happens when URL A redirects to B, which redirects to C. Chains typically accumulate over years of migrations: HTTP to HTTPS, non-www to www, old slug to new slug. Each hop adds latency for users and an extra request for crawlers, and Googlebot will only follow a limited number of hops before giving up. Export all redirects from your crawl, collapse every chain so the first URL redirects directly to the final destination, and update internal links so they skip the redirect entirely. Loops, where URLs redirect back to one another, must be fixed immediately because the page is unreachable.

Site architecture and internal linking

Architecture determines how easily crawlers discover pages and how link equity flows through the site.

Click depth

Measure how many clicks each page sits from the homepage. Important commercial and evergreen pages should be reachable within about three clicks. Pages buried six or seven levels deep in pagination are crawled less often and receive little internal authority.

Orphan pages

Orphan pages have no internal links pointing to them. They may appear in your sitemap or receive traffic from old campaigns, but crawlers have no path to them through your navigation. Cross-reference your crawl with sitemap URLs, analytics landing pages, and Search Console pages to find them, then either link them from relevant hubs or retire them.

Internal link quality

• Navigation links are standard <a href> elements that crawlers can follow, not JavaScript click handlers.
• Anchor text is descriptive and varied rather than "click here" or "read more".
• Hub and category pages link down to their key children, and child pages link back up and sideways to related content.
• High-authority pages, such as those with strong backlinks, link to the pages you most need to rank.
• Breadcrumbs reflect the real hierarchy and are marked up with structured data.
• No internal links point to redirected, broken, or noindexed URLs.

Internal linking is also the bridge between technical SEO and content strategy. If you organize content into topic clusters, as described in our guide to content marketing with topic clusters, the linking structure becomes a deliberate map of topical relevance rather than an accident of publishing history.

JavaScript rendering

Google renders JavaScript, but rendering is an additional step with its own failure modes. Content and links that only exist after scripts run must be verified, not assumed.

Compare raw and rendered HTML

For each major template, compare the raw HTML response with the rendered DOM. The URL Inspection tool in Search Console shows the rendered HTML Google produced, along with any resources that failed to load. Check that the following are present after rendering:

• The main content, including headings and body copy.
• Internal links as crawlable <a href> elements.
• Title tags, meta descriptions, canonical tags, and robots directives.
• Structured data blocks.

Common JavaScript SEO problems

• Content loaded only after a user interaction, such as clicking a tab or scrolling, which crawlers do not perform.
• Client-side routing that serves the same empty shell with a 200 status for every URL, including ones that should 404.
• Different meta robots values in raw and rendered HTML, where the raw version says noindex. Google may not render a page it has already been told not to index.
• Critical scripts or API endpoints blocked by robots.txt.

Where possible, server-side rendering or static generation for indexable content removes most of these risks. Google's JavaScript SEO basics is the authoritative reference for how the rendering pipeline works.

Mobile-first indexing and page experience

Google predominantly uses the mobile version of a page for indexing and ranking. That means the mobile experience is not a secondary concern; for search purposes, it is the site.

Mobile parity checks

• The mobile version contains the same primary content, headings, and internal links as desktop.
• Structured data and meta tags are identical across versions.
• Images and videos use crawlable URLs and descriptive alt text on mobile.
• Tap targets are adequately sized and text is readable without zooming.
• Intrusive interstitials do not cover the main content on arrival.

Page speed and Core Web Vitals

Core Web Vitals measure loading, responsiveness, and visual stability using real-user data. Google's "good" thresholds, measured at the 75th percentile of page loads, are Largest Contentful Paint (LCP) of 2.5 seconds or less, Interaction to Next Paint (INP) of 200 milliseconds or less, and Cumulative Layout Shift (CLS) of 0.1 or less. INP replaced First Input Delay as a Core Web Vital in March 2024.

In an audit, record the Core Web Vitals report status per URL group, identify which templates fail which metric, and note the likely causes, such as unoptimized hero images, render-blocking resources, heavy third-party scripts, or ads and embeds without reserved space. Performance work is a discipline of its own; our Core Web Vitals guide walks through diagnosis and fixes metric by metric.

Structured data, hreflang, and HTTPS

These three areas are independent, but each is a common source of silent errors that only show up when you look for them deliberately.

Structured data

Structured data helps search engines understand entities on a page and can make content eligible for rich results. Audit it by template:

• Markup uses JSON-LD and the types listed in Google's structured data gallery where rich results are the goal.
• Required properties for each type are present, and values match visible on-page content.
• The Rich Results Test and the enhancement reports in Search Console show no errors.
• Organization, breadcrumb, article, product, and local business markup are consistent across the site.
• No markup describes content that users cannot see, which violates Google's guidelines.

Hreflang for international sites

If you serve content in multiple languages or regions, hreflang annotations tell Google which version to show which audience. Errors are extremely common. Check that every hreflang set is reciprocal (each page references all alternates, including itself), that language and region codes are valid ISO codes such as en-us or de-at, that referenced URLs are canonical and return 200, and that an x-default is defined where a fallback page exists. Choose one implementation method, whether HTML head, HTTP headers, or sitemaps, and apply it consistently.

HTTPS and security

• All pages load over HTTPS with a valid certificate, and HTTP URLs 301 redirect to HTTPS in a single hop.
• No mixed content: images, scripts, and stylesheets are all requested over HTTPS.
• Internal links, canonicals, and sitemaps use HTTPS URLs.
• The Security issues and Manual actions reports in Search Console are clear.
• HSTS is configured where appropriate once HTTPS is stable.

Log file analysis

Everything above tells you what crawlers could do. Server logs tell you what they actually did. For sites with more than a few thousand URLs, log analysis is often where the most surprising findings come from.

What to look for

• Crawl distribution: which sections and templates receive the most Googlebot requests. It is common to discover that a large share of crawl activity goes to parameter URLs, filters, or old redirects rather than to money pages.
• Uncrawled important pages: key URLs that Googlebot has not requested in weeks.
• Status codes served to bots: errors and redirects that crawlers hit repeatedly.
• Crawl frequency after changes: whether new or updated content gets picked up quickly.

Verify that requests claiming to be Googlebot really are, using reverse DNS lookup or Google's published IP ranges, since many scrapers spoof the user agent. Then combine log data with crawl data: pages that are in your crawl but never appear in logs, and pages that appear in logs but not in your crawl, are both worth investigating. The Crawl stats report in Search Console offers a lighter-weight view if raw logs are hard to obtain.

Prioritizing fixes: impact versus effort

A typical audit surfaces dozens or hundreds of issues. Handing a developer an unranked list of every warning a crawler produced is the fastest way to get nothing fixed. Score every finding on two axes, business impact and implementation effort, and sequence the work accordingly.

Impact depends on context. A redirect chain on a page with no traffic and no links barely matters; the same chain on your top category page matters a lot. Weight each issue by the value of the affected URLs, and write each ticket with the problem, the evidence, the affected URLs, the recommended fix, and how to verify it once shipped. Developers act on clear tickets; they stall on vague ones.

How often to run a technical SEO audit

Technical health is not a one-time project. New content, plugin updates, and redesigns can all undo previous fixes, so after each release re-crawl affected sections, use Validate fix in Search Console, and compare against your baseline. Then keep a regular rhythm:

• Full audit: at least once a year for most sites, and before and after any migration, redesign, CMS change, or domain move.
• Quarterly review: a lighter pass covering indexing trends, Core Web Vitals, new crawl errors, and structured data reports.
• Monthly monitoring: Search Console alerts, a scheduled crawl of key templates, and a check on the Page indexing report.
• Continuous: automated uptime and robots.txt change monitoring, so a staging configuration pushed to production is caught within hours, not weeks.

Next steps

A good technical SEO audit is less about finding every possible issue and more about finding the issues that stand between your best content and the people searching for it. Work through crawlability, indexation, rendering, and experience in that order, measure against a baseline, and turn findings into a prioritized roadmap your team can actually ship.

Once the foundation is solid, the rest of your SEO work compounds. For the other side of the equation, see our keyword research guide to make sure those healthy pages are targeting the right queries.

If you would rather have an experienced team run the audit and hand you a prioritized, developer-ready fix list, take a look at our technical SEO audit service or get in touch to talk through your site.