The Technical SEO Audit Checklist That Actually Finds Problems

Start with crawlability, not content

There is a strict order to how search works, and auditing out of order wastes weeks. A page must be crawled before it can be indexed, indexed before it can rank, and rendered before Google can judge what is on it. A brilliant page that is blocked in robots.txt ranks for nothing, and no amount of keyword work changes that. So the audit starts at the bottom of the stack.

Open your robots.txt first. The single most damaging mistake we find is a Disallow on /css/, /js/ or /assets/. Those directives look tidy and they are quietly catastrophic: Google renders pages like a browser, so blocking your stylesheets means it sees an unstyled skeleton and judges the layout, mobile-friendliness and content placement of that skeleton. If you take one thing from this article, it is that render-critical assets must be crawlable.

Then check that the rules do what you think. robots.txt matching is prefix-based with * wildcards and $ anchors, longest matching rule wins, and the most specific user-agent group wins outright — meaning a Googlebot block completely replaces the * block rather than adding to it. That last rule surprises people. Test real URLs rather than reading the file and assuming.

You can check any site with our Robots.txt Validator, which tests specific URLs against the rules instead of just checking syntax.

Confirm what is actually indexed

Crawlable is not the same as indexed. The fastest read on indexing health is the Pages report in Google Search Console, which splits your URLs into indexed and not indexed with a reason for each. Do not skip the reasons — they are diagnostic.

Crawled – currently not indexed usually means Google fetched the page and judged it not worth keeping: thin content, near-duplicates, or a page that adds nothing over what is already indexed. Discovered – currently not indexed usually means a crawl-budget or quality-signal problem: Google knows the URL exists but has not prioritised fetching it. Duplicate, Google chose a different canonical means your canonical tag was treated as a hint and overruled, which is a content-similarity problem rather than a markup one.

Then check the directives themselves. Every indexable page needs a self-referencing canonical pointing at the exact final URL, including the trailing slash and protocol your server actually serves. A canonical that points at a URL which then redirects is a wasted signal. And confirm no page carries a stray noindex — a single templating mistake can deindex a whole section, and it is silent.

Rendering is where most audits stop too early

Google renders JavaScript, but rendering is queued and resource-limited, so anything critical that only appears after JavaScript runs is at risk. The test is simple: fetch a page with JavaScript disabled, or use the URL Inspection tool in Search Console and read the rendered HTML. If your main content, internal links or canonical tag are missing from that output, they may as well not exist.

Internal links deserve particular attention here. Links injected by JavaScript, built from onclick handlers, or rendered only after user interaction are frequently not followed. If your primary navigation is JavaScript-dependent, your crawl graph may be far shallower than your sitemap suggests.

Core Web Vitals: measure the right numbers

Core Web Vitals are a confirmed ranking signal, but they are a tie-breaker rather than a primary factor — they will not rescue weak content, and they will separate you from an equally good competitor. The three metrics are Largest Contentful Paint, which measures loading, Interaction to Next Paint, which replaced First Input Delay in March 2024 and measures responsiveness, and Cumulative Layout Shift, which measures visual stability.

The distinction that matters most is lab versus field data. Lighthouse gives you lab data from one simulated load on your machine, which is useful for debugging and is not what Google ranks on. Google uses field data from the Chrome User Experience Report, aggregated from real visitors over 28 days at the 75th percentile. Chasing a perfect Lighthouse score while your field data stays poor is a common and expensive mistake.

For LCP specifically, the usual culprit is render-blocking CSS. Every stylesheet in the <head> blocks the first paint, so a page loading a dozen separate stylesheets cannot paint until the last one arrives. Bundling them into one request routinely removes a full second on a slow connection. For CLS, the fix is almost always setting explicit width and height on images so the browser reserves the space before the file loads.

Structured data that earns something

Structured data does not directly improve rankings. It makes you eligible for rich results, which change how your listing looks and therefore your click-through rate. That distinction matters because it tells you which types are worth the effort.

Worth implementing: Organization and WebSite on the homepage, BreadcrumbList on every page since Google displays breadcrumbs in place of the URL, Product with price and availability for e-commerce, Article for editorial content, and LocalBusiness with real address and hours if you have a physical location.

Worth knowing before you invest: FAQPage rich results were restricted in August 2023 to authoritative government and health sites. The markup is still valid and still helps machines understand your page, but for a commercial site it will not produce the expanded listing it once did. Anyone selling you an FAQ schema rollout on the promise of rich results is working from outdated information.

Whatever you implement, validate it. Invalid JSON-LD is silently discarded, so a single missing brace can disable schema across a whole template. Our Schema Markup Generator produces valid markup, and the JSON Validator will catch a syntax error before Google does.

Internal linking is the most underrated fix

Internal links do three jobs at once: they let crawlers discover pages, they distribute authority between pages, and their anchor text tells search engines what the destination is about. Most sites underuse them badly.

Two problems come up repeatedly. Orphan pages exist in your sitemap but have no internal links pointing at them, so they receive no authority and are crawled rarely. Excessive crawl depth means important pages sit four or five clicks from the homepage, which search engines read as a signal of low importance. Anything commercially important should be within three clicks.

One nuance worth understanding: navigation links carry less weight than contextual links inside body content. A site-wide footer linking to every service is fine for discovery but does little for relevance, because the same links appear on every page. A paragraph in a relevant article that links to a service page with descriptive anchor text is worth considerably more.

Audit your headings while you are in there. Every page should have exactly one <h1> and heading levels should not skip. A surprisingly common cause is a navigation menu that uses real heading tags for its category labels, which injects headings above the page title on every single page. Our Heading Structure Analyzer will find it.

The order to fix things in

An audit that lists 200 issues without prioritising them is a way of avoiding decisions. Work in this order, because each level is a prerequisite for the next:

1. Blocking issues — anything preventing crawling or indexing of pages you want ranked. Wrong robots.txt rules, stray noindex, broken canonicals.
2. Rendering issues — content or links that only exist after JavaScript.
3. Duplication — multiple URLs serving the same content, missing canonicals, parameter variants.
4. Core Web Vitals — starting with render-blocking resources and unsized images.
5. Internal linking — orphans, depth, anchor text.
6. Structured data — validity first, then coverage.

Re-audit after each level rather than at the end. Fixing a robots.txt rule can change what is indexed within days, which changes what the rest of the audit should focus on.