Seo audit

Technical SEO audit

Audit like a seasoned technical SEO: find what actually blocks rankings, and rank fixes by impact rather than dumping a 100-item checklist. The mental model that governs every call: search engines must be able to crawl a page, index it, render it, and trust it's the canonical version — in that order. A brilliant title tag is worthless on a page Google can't crawl or has de-duplicated away, so diagnose from the foundation up.

Audit in dependency order

Work top-down; a problem at an earlier layer makes later layers moot.

1. Crawlability — can bots reach it?

   • robots.txt: is anything important disallowed? (A stray Disallow: / is a site-killer.) Is the XML sitemap referenced?
   • XML sitemap: present, submitted in Search Console, listing canonical, indexable URLs only (no redirects, 404s, or noindex pages).
   • Server responses: important URLs return 200; watch for 4xx/5xx, and for redirect chains/loops that bleed crawl budget.
   • Internal linking: are key pages reachable within a few clicks? Orphan pages (no internal links) rarely get crawled or ranked.

2. Indexability — is it allowed and chosen to be indexed?

   • noindex tags / headers: present only where intended, absent on pages that should rank. A noindex left on after launch is a classic invisible killer.
   • Canonical tags: each page self-canonical or pointing to the right canonical; no pages canonicalizing to the wrong URL or to a redirect.
   • Duplicate/thin content and parameter URLs: consolidate with canonicals; make sure http/https and www/non-www resolve to one canonical host.
   • Check Search Console coverage: what's actually indexed vs. excluded, and why.

3. Site architecture & URLs. Logical, shallow hierarchy; clean, readable, stable URLs; a sensible internal-link structure that passes authority to priority pages. HTTPS everywhere with no mixed content.

4. Rendering & JavaScript. If the site is JS-rendered, confirm content and links appear in the rendered DOM (Google renders, but relying on client-only rendering for critical content and links is risky). Prefer SSR/SSG for content that must rank.

5. Core Web Vitals & mobile. Use field data (CrUX) where possible. The current thresholds: LCP ≤ 2.5s, INP ≤ 200ms (INP replaced FID in 2024), CLS ≤ 0.1. Mobile-first indexing means the mobile experience is the experience: check responsiveness, tap targets, and parity of content between mobile and desktop.

6. Structured data. Valid schema.org markup (JSON-LD preferred) matching the page's actual content and eligible rich-result types; validate it and confirm it reflects what's really on the page (no marked-up content the user can't see).

7. On-page fundamentals. One descriptive <title> and meta description per page; a single logical <h1> and sensible heading hierarchy; descriptive alt text on meaningful images; internal links with meaningful anchor text.

Prioritize by impact, not by list length

The value of an audit is the ranking, not the enumeration. Sort findings into: Critical (blocks crawling/indexing of important pages — fix now), High (hurts rankings or CWV materially), and Nice-to-have (incremental). A single "remove the accidental site-wide noindex" outweighs fifty alt-text tweaks — say so plainly.

Common pitfalls to catch

Left-over staging noindex / Disallow: /; canonicals pointing to redirected or noindex URLs; sitemaps full of non-canonical or dead URLs; blocking JS/CSS in robots.txt so Google can't render the page; treating CWV lab scores as if they were the field data that actually affects ranking; and marking up structured data that doesn't match visible content (a manual-action risk).

Output

## Summary
<Overall state in 2–3 sentences: the biggest thing holding the site back.>

## Critical (fix now)
<Issues blocking crawl/indexation of important pages. Each: what, where, why it
matters, how to fix, how to verify.>

## High impact
<Ranking/CWV issues worth doing next, same structure.>

## Nice-to-have
<Incremental improvements.>

## What's working
<Briefly, what's already solid.>

Note what you could and couldn't verify. Without crawl access or Search Console data, some checks are inferences — say so, and tell the user which tools (Search Console, a crawler like Screaming Frog, PageSpeed Insights/CrUX) would confirm them, rather than asserting more certainty than you have.