Technical SEO Audit Guide — 10-Step Site Health Checklist

Most technical SEO problems are invisible until they become urgent. A page that Google quietly stopped crawling three months ago. A redirect chain that's been leaking PageRank on your most important category page. A structured data error that's been blocking rich results since the last deploy. None of these show up as obvious user-facing bugs — they only appear when you go looking for them.

This checklist covers the 10 areas where technical SEO issues are most commonly found, in the order they should be investigated. Each step builds on the last: there is no point optimising page speed for a page that is noindexed, and no point fixing structured data on a page that Googlebot cannot reach.

Step 1 — Crawlability Check

Before any other checks, verify Googlebot can reach your site at all.

robots.txt review. Fetch https://yourdomain.com/robots.txt directly. Scan for Disallow: / (blocks the entire site) and for rules that accidentally block CSS or JS directories — Googlebot cannot render pages without those resources, which leads to thin-content classifications. A Robots.txt Tester parses the full rule set and lets you test specific paths against each user-agent without manual interpretation.

GSC URL Inspection. Pick three to five important pages and run them through Google Search Console → URL Inspection. Look at whether Googlebot can crawl and render each one. The rendered HTML screenshot reveals whether dynamic content is loading — a blank or partial render indicates JavaScript execution problems that robots.txt won't show.

Check for accidental blocks after deployments. Staging environments routinely include Disallow: / to keep themselves out of search results. Deploying the staging robots.txt to production is among the most common — and most damaging — technical SEO accidents. The drop in indexed pages typically appears in GSC two to four weeks after the event, long after the cause has been forgotten.

Step 2 — Indexability Audit

Crawlability and indexability are not the same thing. A page can be crawlable but intentionally or accidentally excluded from the index.

GSC Coverage report. Review all four tabs: Indexed, Excluded, Error, and Warning. The Excluded tab is particularly important — it shows pages Google has decided not to index, grouped by reason. Common reasons that need investigation: "Crawled — currently not indexed" (Google visited the page but chose not to index it, often thin content), "Alternate page with proper canonical tag" (working correctly or canonicalising to the wrong URL), and "Submitted URL marked noindex" (a noindex tag on a page you submitted in your sitemap — a contradiction).

Noindex audit. Crawl your site with a tool that reports the <meta name="robots"> tag and X-Robots-Tag response header on every page. Flag every noindexed URL and confirm each one is intentionally excluded. Login pages, thank-you pages, and admin paths should be noindexed. Your blog index, product pages, and category pages should not.

Sitemap cross-check. Your XML sitemap should contain only pages you want indexed. A noindexed URL appearing in your sitemap sends contradictory signals to Google. Submit the sitemap through a Sitemap Validator to detect any noindexed or broken URLs listed alongside your healthy pages.

Step 3 — Site Speed and Core Web Vitals

Core Web Vitals are Google's user experience metrics. Pages that pass all three are eligible for a minor ranking boost; more importantly, poor scores correlate with higher bounce rates independent of any ranking effect.

TTFB (Time to First Byte) is the single metric that underlies LCP more than any other. If your server takes more than 800 ms to send the first byte, passing LCP becomes extremely difficult regardless of frontend optimisation. TTFB above 800 ms indicates slow hosting, absence of caching, or heavy server-side computation on each request. A Page Speed Inspector measures DNS, TCP, TLS, TTFB, and download timing independently so you can pinpoint exactly where the time is being spent.

Render-blocking resources. CSS and JavaScript in the <head> that must download and execute before the browser can render anything. Defer non-critical JS with the defer attribute. Inline critical CSS for above-the-fold content. Use <link rel="preload"> for fonts and hero images that are needed immediately.

Image optimisation. Missing width and height attributes cause CLS because the browser doesn't know how much space to reserve before the image loads. Missing loading="lazy" on below-fold images wastes bandwidth and delays more critical resources. Modern formats (WebP, AVIF) deliver significantly smaller file sizes than JPEG or PNG for equivalent visual quality.

Step 4 — Mobile Usability

Google indexes and ranks based on the mobile version of your pages. Any usability issue that affects mobile users also affects your rankings.

GSC → Mobile Usability flags three categories of problems: text too small to read (font size below ~12px on mobile), clickable elements too close together (tap targets under 48px), and viewport not configured (missing or incorrect <meta name="viewport"> tag).

All three are fixable with responsive CSS and rarely require JavaScript changes. For pages not yet flagged in GSC — particularly new pages or recently redesigned sections — run a manual check at common mobile breakpoints (375px, 390px, 430px) to catch issues before Google finds them.

Step 5 — Internal Link Audit

Internal links do three things: they distribute PageRank, they tell search engines which pages are important, and they help crawlers discover content. Problems with internal links are often the highest-leverage fixes in a technical audit because they compound across the entire site.

Broken internal links. A 404 inside your own site is a crawl budget waste and a user experience failure. Run a crawl of your site with a Link Checker to surface all internal links returning 4xx or 5xx status codes. Each broken link should either be updated to the correct destination or removed.

Redirect chains in internal links. If page A links to page B, which redirects to page C, you are losing a small amount of PageRank at each hop. At scale — hundreds of internal links hitting redirect chains — this adds up. The fix is to update internal links to point directly to the final destination URL. This is more impactful than it sounds because site migrations often leave thousands of internal links pointing to old URLs that now redirect.

Orphan pages. Pages with zero internal links pointing to them are invisible to crawlers unless they appear in your sitemap. They also receive no PageRank from the rest of your site. Export your full page list, then cross-reference with your internal link data to find any URLs that nothing links to. Add contextual internal links from relevant pages.

Anchor text distribution. Over-optimised exact-match anchor text on internal links can attract algorithmic scrutiny. Natural anchor text variation — brand name, URL, descriptive phrases, generic "read more" — is the standard pattern.

Step 6 — Duplicate Content and Canonicalisation

Duplicate content does not result in a penalty, but it does cause crawl budget waste and ranking dilution when Google has to choose between near-identical versions of the same page.

URL variants. A single page can be accessible as HTTP, HTTPS, with www, without www, with a trailing slash, and without. That is eight potential variants of the same URL. Pick one canonical form, 301-redirect all others to it, and add a <link rel="canonical"> self-referencing tag. Verify the redirect chain is a single hop — HTTP non-www → HTTPS www should be one redirect, not two.

Parameter-based duplicates. Sorting, filtering, session, and pagination parameters frequently create hundreds of near-identical URL variants. ?sort=price and ?sort=date on the same category page show the same products in a different order — the same content under two URLs. Solutions: canonical tags pointing to the parameter-free URL, or noindex on parameter variants if they have no standalone search value.

Pagination. /category/page/2/, /category/page/3/, etc. should either be indexable (if each page has distinct content and keyword value) or canonicalised to the first page. Blocking paginated URLs in robots.txt prevents crawlers from discovering content only accessible through pagination — a common but counterproductive mistake.

Step 7 — Site Structure and URL Audit

Crawl depth. Every important page should be reachable in three clicks or fewer from the homepage. Pages buried at depth 4 or 5 receive fewer crawls and less PageRank. Flat site structures consistently outperform deeply nested ones for SEO, especially for large sites with thousands of pages.

URL cleanliness. Canonical URLs should be: lowercase, hyphen-separated, free of special characters, free of session parameters, and consistent with or without a trailing slash across the entire site. Inconsistent capitalisation and trailing slash treatment are both common sources of unintentional duplicate content.

Redirect chain audit. Use a Redirect Tracer to follow the full chain for any URL that returns a 3xx. A chain of three or more hops (A → B → C → D) should be flattened to a single hop (A → D). Chains add latency and reduce PageRank transfer at each hop.

Step 8 — Structured Data Validation

Correctly implemented structured data is one of the highest-ROI technical SEO tasks. Rich results — star ratings, FAQ dropdowns, recipe cards, breadcrumbs in search snippets — increase click-through rate without requiring any change to organic ranking position.

Extract and validate JSON-LD. Use a Schema Markup Tester to fetch key pages, extract all JSON-LD, Microdata, and RDFa blocks, and validate them against schema.org required properties. Common failures: missing datePublished on Article schemas, missing image on Product schemas, incomplete BreadcrumbList item URLs.

GSC Enhancements tab. Google Search Console shows structured data errors it has detected during its own crawls. These are the errors that directly affect rich result eligibility. Errors (not warnings) must be fixed to recover rich results; warnings are typically recommended but not required properties.

Priority schema types to validate:

• Article / BlogPosting — requires datePublished, author (with name), and image
• BreadcrumbList — requires item with a valid URL on every ListItem
• FAQPage — requires at least one Question with both name and acceptedAnswer
• Product — requires name; offers with price and priceCurrency for price-based rich results
• LocalBusiness — requires name, address, and telephone for map pack eligibility

Step 9 — Sitemap Health

Your XML sitemap is a direct signal to search engines about which pages exist and should be indexed. An unhealthy sitemap — with broken URLs, noindexed pages, or invalid XML — actively misleads crawlers.

Run a sitemap validation. Fetch your sitemap and check every listed URL for HTTP status, noindex tags, and canonical mismatches. A 404 in your sitemap tells Google a page exists that doesn't. A noindexed page in your sitemap contradicts itself. A canonical pointing elsewhere in your sitemap means you're asking Google to crawl a page whose own canonical tag points away from it.

XML validity. Malformed XML (unclosed tags, unescaped ampersands in URLs, special characters) can cause the entire sitemap to fail silently. Google will stop processing the file at the first parse error without reporting which URLs it missed.

Last-modified dates. The <lastmod> tag in sitemaps should reflect the actual date of last meaningful content change. Updating all <lastmod> values on every deploy regardless of whether the page changed is a common CMS behaviour that trains Google to ignore the signal entirely.

Submit to both Google and Bing. Google Search Console and Bing Webmaster Tools both accept sitemap submissions. Bing's IndexNow protocol can deliver even faster indexation signals for updated content — worth adding if you publish time-sensitive content.

Step 10 — HTTPS and Security Headers

HTTPS has been a confirmed Google ranking signal since 2014. In practice the ranking boost is minimal for most sites, but the absence of HTTPS creates user-facing security warnings that increase bounce rate — which does affect rankings indirectly.

Full HTTPS coverage. Every page, every asset (images, scripts, stylesheets, fonts) must load over HTTPS. A single HTTP asset on an HTTPS page triggers a mixed content warning in browsers. Check the browser console on key pages for mixed content errors, and verify your CDN or asset host is serving over HTTPS.

HTTP to HTTPS redirect. http://yourdomain.com should 301-redirect to https://yourdomain.com. Verify this is a single hop, not a chain. Include both www and non-www variants in your redirect testing.

HSTS header. The Strict-Transport-Security header instructs browsers to always use HTTPS for your domain, even if a user types http://. Set it to at least one year (max-age=31536000) on production. This eliminates the window during which a man-in-the-middle attack could intercept the initial HTTP request before the redirect fires.

SSL certificate validity. An expired or misconfigured certificate (e.g. not covering the www subdomain) will return a browser security error to all users — the most visible technical failure a site can have. Set up expiry monitoring so you receive an alert at least 30 days before any certificate expires.

Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.