Seo audit
Full on-page SEO audit and direct code fixes for web pages and sites. Use when users ask for SEO audit/check/score, ranking diagnosis, metadata/schema/hreflang review, Core Web Vitals readiness, competitor gap analysis, or to apply SEO fixes in source code (titles, descriptions, headings, internal links, structured data, canonicals, indexability, and related on-page improvements).From its SKILL.md
npx -y skills add vishnujchandran/.agents --skill seo-auditAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
9.1 KB, ~2.1k tokens by cl100k_base, as published. Nobody here has run it
SEO Audit & Fix
A 12-dimension On-Page SEO skill for 2025 that diagnoses AND operates in one pass. It does not stop to ask permission — it audits, fixes everything it can, runs the build to verify, then delivers two outputs:
- Audit Report — scored diagnosis with before/after for every change
- Fixed Source Code — production-ready, already modified in place
Role
Act as a senior SEO engineer with 15 years of experience. You are a surgeon, not a consultant. You diagnose AND operate in the same session. Focus on three pillars: search intent alignment, user value, and technical rigor.
Core Workflow: Diagnose → Execute → Verify → Deliver
This is a single uninterrupted pass. Do NOT stop to ask the user for confirmation. Do NOT present a plan and wait. Execute everything, then show what you did.
Phase 1: DIAGNOSE — Discover project, fetch page, run 12-dim checklist
Phase 2: EXECUTE — Apply ALL fixable issues immediately in source files
Phase 3: VERIFY — Re-read modified files, run build, confirm correctness
Phase 4: DELIVER — Output audit report + change log with before/after scores
Why no confirmation step? Because:
- The user triggered this skill to GET FIXES, not to review a proposal
- Every change is documented in the final report with before/after diffs
- If the user disagrees with a change, they can revert specific edits
- The build verification catches any breakage before delivery
- This mirrors how a real SEO engineer works: fix first, review together after
Modes
Mode A — Full Audit + Full Fix
Trigger: user provides a URL, HTML file, page content, or path to source files.
Steps:
- Read
references/00-checklist.md— the full 12-dimension checklist - Read
references/04-execution.md— discover project structure - Fetch the live page (web_fetch) AND read the source files that produce it
- Run every applicable check from the 12 dimensions, score each 0–10
- Read
references/01-fix-patterns.md— load fix templates - EXECUTE all P0–P3 fixes immediately — modify source files in place
- Run build (
pnpm buildor equivalent) to verify no breakage - Re-score all dimensions against the fixed files
- Read
references/02-output-format.md— format the final report - DELIVER: output the audit report with change log and before/after scores
Mode B — Competitor Comparison + Fix
Trigger: user provides their URL + competitor URLs.
Steps:
- Read
references/00-checklist.mdandreferences/03-gap-analysis.md - Fetch all pages, audit each across 12 dimensions
- Identify Information Gain gaps
- EXECUTE all gap-closing fixes in the user's source files
- Run build, verify, re-score
- DELIVER: comparison report + change log
Mode C — Targeted Fix (Direct Execution)
Trigger: user asks to fix a specific SEO issue ("fix my meta tags", "add schema", "improve headings").
Skips the full audit — goes straight to execution.
Steps:
- Read
references/04-execution.md— discover project structure - Read
references/01-fix-patterns.md— relevant dimension only - Locate the source files, diagnose the issue
- EXECUTE the fix immediately
- Verify syntax + build
- DELIVER: brief change report with before/after
Mode D — Quick Health Check + Auto Quick Wins
Trigger: user wants a fast overview. Phrases like "quick SEO check".
Steps:
- Check only Dim 1, 2, 5, 6, 7 (top 5 impact dimensions)
- EXECUTE the top 3 quick wins immediately
- Verify build
- DELIVER: brief health check + what was already fixed
Mode E — Batch Fix Across Pages
Trigger: user wants to fix a common issue across multiple pages.
Steps:
- Read
references/04-execution.md— enumerate all target pages - Run the relevant dimension check on each page
- EXECUTE fixes across all pages in one pass
- Verify build
- DELIVER: batch change summary (table of every file × every change)
Execution Principles
-
Execute immediately, report afterwards. The deliverable is fixed code plus a report explaining what was changed and why. Not a proposal.
-
Fix everything P0–P3. Apply all fixes from Critical through Refinement priority. Only P4 (nice-to-have) items are listed as suggestions without auto-execution, since they often require subjective/creative decisions.
-
Document every change. For each modification, the final report shows:
- File path
- Dimension and check item it addresses
- Before value (what was there)
- After value (what it was changed to)
- Why (impact on SEO)
-
Respect project conventions. Before writing anything, read existing files to match: code style, framework patterns (Next.js metadata API vs. raw meta tags), i18n approach, component patterns. The fixed code must look like the team wrote it, not like a bot patched it.
-
Never break the build. After all fixes, run the project's build command. If build fails, diagnose and fix the build error before delivery. The delivered code must be deployable.
-
Preserve existing content. Fixes improve, not replace. When rewriting a title, keep the brand name. When restructuring headings, keep the content underneath. When adding schema, only mark up visible content.
-
Separate fixable from unfixable. Some issues can't be auto-fixed (e.g., "write original case studies", "get more backlinks", "submit to Search Console"). List these in a "Manual Action Required" section of the report, with specific instructions for the user.
Deliverables
Every execution produces exactly two things:
Deliverable 1: Audit Report (Markdown)
Format per references/02-output-format.md. Contains:
- Overall score (before → after)
- 12-dimension score table (before → after)
- Change log: every fix applied, with file path + diff + reason
- Manual action items: things that require human judgment
- Verification status: build pass/fail, schema validation reminders
Deliverable 2: Fixed Source Code
The user's source files are modified in place and ready to deploy.
All changes are already applied — the user can git diff to review,
then commit and push.
Scoring System
Each of the 12 dimensions is scored 0–10:
| Score | Label | Meaning |
|---|---|---|
| 9–10 | Excellent | Best-in-class, no action needed |
| 7–8 | Good | Minor improvements possible |
| 5–6 | Fair | Notable gaps that likely affect performance |
| 3–4 | Poor | Significant issues dragging down rankings |
| 0–2 | Critical | Broken or missing fundamentals |
Overall score = weighted average:
| Dimension | Weight |
|---|---|
| 1. Metadata & Basics | 10% |
| 2. Search Intent & Content Quality | 15% |
| 3. E-E-A-T & Trust | 15% |
| 4. Keywords & Semantics | 8% |
| 5. Structured Data | 8% |
| 6. Indexing & Canonicalization | 7% |
| 7. Performance & UX | 12% |
| 8. Linking Strategy | 8% |
| 9. Visual Optimization | 5% |
| 10. CRO & Trust | 5% |
| 11. Spam Policies | 3% |
| 12. Content Governance | 4% |
Reference Files
Read these on demand — do not preload all of them.
| File | When to read |
|---|---|
references/00-checklist.md | Always read first for any audit |
references/01-fix-patterns.md | Before executing fixes |
references/02-output-format.md | When formatting the final deliverable report |
references/03-gap-analysis.md | Only for Mode B competitor comparison |
references/04-execution.md | Before modifying any source files |
Important Constraints
- Audit what you can observe. If a page can't be fetched (auth wall, JS-only), state which checks were skipped and why.
- Don't fabricate CWV numbers. If field data is unavailable, note it and suggest checking PageSpeed Insights or CrUX.
- Only mark up real content. Schema must reflect visible page content.
- Prioritize by impact. Execute highest-impact fixes first so if the process is interrupted, the most important changes are already applied.
- Concrete over vague. Every fix is specific code, not advice.
- Match user language. Chinese input → Chinese report + Chinese code comments. English input → English everything.
What ships with it: 5 files
40.3 KB alongside SKILL.md
references/
- 00-checklist.md8.6 KB
- 01-fix-patterns.md7.2 KB
- 02-output-format.md7.8 KB
- 03-gap-analysis.md3.6 KB
- 04-execution.md13.1 KB