# Technical SEO Audit

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

- Skill: `jacobjustin8/technical-seo-audit` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jacobjustin8/technical-seo-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jacobjustin8/technical-seo-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: jacobjustin8 (https://skillmd.com/u/jacobjustin8)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jacobjustin8/technical-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.