seo-geo-audit 是做什麼的？
Audit a frontend repository for classical SEO (the things Google's crawler cares about) and GEO — Generative Engine Optimization, the things LLMs care about when they read your content. Outputs a markdown report card with severities, file:line citations, and concrete fixes.
The novel value is GEO. Classical SEO scanners have existed for years. But "is your site easy for a language model to extract, cite, and reason about?" is a question only Claude can really answer — because Claude is the consumer.
Invocation
| Trigger | Behavior |
|---|---|
/audit or /seo-geo or /seo-geo-audit | Standard audit: SEO + GEO, root-level + key routes, ~30 files max |
/audit deep | Walk all routes/pages discoverable in the repo. Slower, more thorough |
/audit seo | Classical SEO only |
/audit geo | GEO only |
/audit fix | Audit, then propose concrete file edits for each high-severity finding (ask before each edit) |
/audit report.md | Write the report to a file instead of showing inline |
| Natural language: "audit this site for SEO", "is this LLM-friendly", "check my structured data" | Same |
Stop / disable
Not session-based. One-shot. Just don't invoke it.
Execution flow
- Detect framework by reading
package.json. Look fornext,astro,nuxt,svelte-kit,remix,gatsby,vite,vue, or fall back to plain HTML. The framework determines file globs and where pages live (pages/,app/,src/routes/,src/pages/,content/, etc.). - Discover content sources via
scripts/discover.sh <framework>. - Extract
<head>content and structured data viascripts/extract-head.shandscripts/find-jsonld.sh. For JSX/TSX, look for<Head>,<Helmet>,<Metadata>, or framework-specific patterns (Next.jsmetadataexports, Astro frontmatter, NuxtuseHead). - Run checks. Each check from
checks/seo.mdandchecks/geo.mdis a piece of Claude reasoning over the extracted data — not a regex. That's the point: classical scanners can tell you the meta tag exists; only Claude can tell you whether the description is good. - Score per category using
checks/scoring.md. Letter grade + numeric score per category. - Render the report from
templates/report-card.md, filling in findings with file:line citations, severities, and fix suggestions. - If
fixmode: for each high-severity finding, propose a concrete edit using the standard preview-then-apply pattern. Never apply without user confirmation.
Cross-skill awareness
If llms-txt skill is installed, recommend running it when GEO findings include "missing llms.txt". If a11y-audit skill exists, point to it at the bottom of every report ("This audit covers SEO and GEO. For accessibility, run /a11y-audit.").
Safety guardrails
- Read-only by default. Only
fixmode proposes edits, and every edit needs confirmation. - Don't fetch the live site. Audit the source repo. Live-site auditing is Lighthouse / PageSpeed territory — different tools, different concerns.
- Don't assume framework conventions. Check
package.jsonfirst. Apages/folder means different things in Next vs Nuxt vs Gatsby vs vanilla. - Never modify policy files (
robots.txt,noaimeta tags,llms.txt) without explicit user request — those are stakeholder decisions, not technical ones. - Skip generated/build artifacts. Don't audit
dist/,build/,.next/,out/,.nuxt/. Audit source. - Cap deep audits. Even in
deepmode, refuse to scan more than ~500 files without a--no-limitconfirmation.
Files in this skill
SKILL.md— this filechecks/seo.md— classical SEO checklist with severitieschecks/geo.md— GEO checklist (the novel checks)checks/scoring.md— how findings map to a 0–100 grade per categorytemplates/report-card.md— markdown template for the final reportscripts/discover.sh— find frontend source files by frameworkscripts/extract-head.sh— pull<head>content from HTML/JSX/MDXscripts/find-jsonld.sh— extract<script type="application/ld+json">blocksscripts/check-llms-txt.sh— does the repo have an llms.txt?examples/good-site-report.md— example report on a well-optimized siteexamples/bad-site-report.md— example report on a typical greenfield site