` 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.

--- name: technical-seo-audit description: >- Run a technical SEO audit of a website or page the way an experienced SEO would — diagnosing crawlability, indexation, site architecture, Core Web Vitals, structured data, and on-page fundamentals, then prioritizing fixes by impact. Use whenever the user wants an SEO audit or review, asks why a page isn't ranking or getting indexed, mentions crawl errors, Core Web Vitals, canonicals, robots.txt, sitemaps, or structured data, or asks how to improve a site's technical SEO — even if they just say "check my site's SEO". --- # 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 `` 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.