Stats
Actions
Tags
From seo-codebase-auditor
Use when the user wants a codebase-only SEO audit of a website or web app repository. Audits technical SEO, metadata, schema, sitemap, robots.txt, canonicals, internal links, images, accessibility basics, performance setup, framework-specific SEO (Next.js, Shopify, WordPress, Astro, Nuxt, Remix, Gatsby, Vite/React, static HTML), content structure, and AI visibility readiness — using ONLY evidence found inside the repository. Generates reports/codebase-seo-audit.md, reports/codebase-seo-action-plan.md, and reports/codebase-seo-evidence.json. Never invents traffic, rankings, backlinks, domain authority, GA4, or Search Console data.
How this skill is triggered — by the user, by Claude, or both
Slash command
/seo-codebase-auditor:auditThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Audit a website or web-app repository for SEO using **only evidence that exists inside the codebase**. Produce an honest, reproducible report that a developer can act on immediately.
Audit a website or web-app repository for SEO using only evidence that exists inside the codebase. Produce an honest, reproducible report that a developer can act on immediately.
This skill audits code, not a live website. You have no access to analytics, crawlers, or search engines.
NEVER invent, estimate, or imply any of the following:
When any of these would normally appear, write exactly:
Not available from codebase
Every claim in the report MUST be traceable to a file path (and, where useful, a line number or code snippet). If you cannot point to a file as evidence, you cannot make the claim. When a check is partially verifiable, lower the Confidence rating rather than guessing.
A score of N/A ("Not enough codebase evidence") is an acceptable and honest result. Do not pad scores to look complete.
Use Glob and Grep to discover files, and Read to inspect them. Prefer reading real files over assuming conventions. Never fabricate file contents — if a file is absent, record it as absent.
Inspect these signals (in order) and classify the project. A repo may match more than one; pick the dominant framework and note the others.
| Project type | Primary signals |
|---|---|
| Next.js | next in package.json deps; next.config.{js,mjs,ts}; app/ or pages/ directory |
| Nuxt | nuxt in deps; nuxt.config.{js,ts} |
| Remix | @remix-run/* in deps; remix.config.js; app/routes/ |
| Astro | astro in deps; astro.config.{mjs,ts}; src/pages/*.astro |
| Gatsby | gatsby in deps; gatsby-config.js |
| Vite/React (SPA) | vite + react in deps; vite.config.*; index.html with a root mount node |
| Shopify (Liquid theme) | layout/theme.liquid; templates/, sections/, snippets/; config/settings_schema.json |
| Shopify (Hydrogen) | @shopify/hydrogen in deps |
| WordPress | style.css theme header; functions.php, header.php, footer.php, single.php, page.php; or wp-content/ |
| Static HTML | Raw *.html files, no JS framework manifest |
| Unknown | None of the above match confidently |
Read package.json first when present. If there is no package.json, look for Liquid, PHP, or raw HTML signatures. Record the evidence (which file proved the type) in the evidence JSON.
Discover and record which of the following exist. Only inspect files that are actually present. Do not assume a file exists because the framework usually has one — its absence is itself evidence.
Universal / config
package.json, tsconfig.json, .env* (note presence of hardcoded URLs, never print secrets)public/robots.txt, public/sitemap.xml, public/llms.txt, public/.well-known/public/manifest.json, public/site.webmanifestNext.js / React
next.config.{js,mjs,ts}, next-sitemap.config.jsapp/layout.{tsx,jsx,js}, app/**/page.{tsx,jsx,js}, app/**/layout.*app/sitemap.{ts,js}, app/robots.{ts,js}, app/manifest.{ts,js}app/**/not-found.{tsx,jsx,js}, app/**/opengraph-image.*, app/**/icon.*pages/**/*.{tsx,jsx,js}, pages/_app.*, pages/_document.*, pages/api/**components/**, src/**, lib/**, utils/**Shopify (Liquid)
layout/theme.liquid, templates/**, sections/**, snippets/**config/settings_schema.json, assets/**WordPress
functions.php, header.php, footer.php, single.php, page.php, index.php, archive.phptheme.json, style.css, inc/**, template-parts/**Content
content/**, posts/**, blog/**, articles/**, data/**, _posts/**, src/content/***.md, *.mdxUse Glob patterns and cap large enumerations (e.g. sample representative files when there are hundreds of pages). Note the sample size in the report so the audit is honest about coverage.
For each category, collect evidence, then describe What is working, Issues found, and Recommendations. Tie every issue to an evidence file.
'use client' at route roots, SPA-only index.html, missing SSR.noindex usage (<meta name="robots">, robots in metadata, X-Robots-Tag).<title>, Next metadata.title / generateMetadata, Liquid {{ page_title }}, WP wp_title/add_theme_support('title-tag')).og:title, og:description, og:image, og:url, og:type).twitter:card, twitter:title, twitter:image).<script type="application/ld+json"> usage.Organization, WebSite, Article, BlogPosting, Product, BreadcrumbList, FAQPage.Article/BlogPosting, store without Product).@type mismatches.sitemap.xml, app/sitemap.ts, next-sitemap, plugin-generated, or none.Sitemap: line).Disallow: / in production, blocking CSS/JS, blocking key paths).noindex left on, staging guards leaking to prod).<link rel="canonical">, Next metadata.alternates.canonical, Liquid {{ canonical_url }}, WP rel_canonical).localhost, 127.0.0.1, :3000, staging/preview domains hardcoded as base URL.href="", href="#", or href="javascript:void(0)".target="_blank" without rel="noopener"/rel="noreferrer".next/image (or framework image component) vs raw <img>.alt, and empty-alt misuse on meaningful images.priority/preload on hero images).next.config images.remotePatterns/domains).width/height attributes (CLS prevention).loading="lazy") and whether it's wrongly applied to LCP images.<h1> per page.divs; links with discernible text.<main>, <nav>, <header>, <footer>, <article>).revalidate, export const revalidate), or fully dynamic (dynamic = 'force-dynamic', cookies()/headers() forcing SSR).next/font, font-display, preconnect to font hosts).next/script strategy, async/defer, render-blocking scripts).package.json).Person/author schema.Organization and Article schema.llms.txt presence and AI crawler rules in robots (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, etc.).Run the section matching the detected project type. If multiple apply, run each relevant block.
metadata export and generateMetadata coverage.app/sitemap.ts, app/robots.ts, app/manifest.ts.revalidate usage / rendering mode per route; unintended force-dynamic.next/image and next/font adoption.not-found.tsx presence.opengraph-image.*, metadata.openGraph.images).theme.liquid: <head> completeness, {{ content_for_header }}, meta tags.{{ canonical_url }} usage.alt handling ({{ image.alt }}), responsive images, lazy loading.wp_head() present in header.php; wp_footer() in footer.php.add_theme_support('title-tag') vs hardcoded <title>).single.php, page.php, archive.php, template parts).wp_enqueue_script / wp_enqueue_style vs hardcoded tags.add_image_size, the_post_thumbnail sizes).Apply the universal checks (metadata, schema, sitemap, robots, canonicals, images, links) using that framework's idioms (Nuxt useHead/useSeoMeta, Astro <head> + integrations, Remix meta export, Gatsby gatsby-plugin-sitemap/react-helmet). For SPAs (Vite/React) with no SSR, flag client-only rendering as a crawlability risk and note whether prerendering is configured.
Score each category 0–100 using the weighted sub-criteria below, then map to a grade. Use N/A when there is not enough codebase evidence to score honestly (do not guess a number).
Grade scale
| Score | Grade |
|---|---|
| 90–100 | A |
| 80–89 | B |
| 70–79 | C |
| 60–69 | D |
| 0–59 | F |
| N/A | Not enough codebase evidence |
Confidence (report per category): High (directly verified in files), Medium (inferred from partial evidence), Low (weak/ambiguous evidence). Never report High confidence for something you did not read.
Weights — each category's score is the weighted sum of its sub-criteria (each sub-criterion rated 0–100, then weighted).
Technical SEO
Image SEO
Accessibility basics
Performance setup
Content structure
AI visibility readiness
The summary "Audit results" table also reports Metadata, Schema, Sitemap, Robots.txt, Canonicals, and Framework SEO implementation as their own rows. Derive each from the relevant evidence (you may reuse the Technical SEO sub-criteria for the shared rows). Keep scoring consistent between the per-row scores and the detailed sections.
Create the reports/ directory inside the audited project and write three files. Use the report template at templates/codebase-seo-audit-report.md (in this plugin) as the structure for the main report.
Column guides are required. The template places a short "How to read this table" block above every table that explains each column and how each number (Score, Grade, Priority) is calculated. Reproduce these guides above the matching table in the generated report — they are part of the deliverable, not template scaffolding, so never strip them. If you add an Issues found table in a section that doesn't have one in the template, copy the Issues-table column guide above it too.
reports/codebase-seo-audit.mdFull report with these sections, in order:
Audit scope — project name, project type, audit source (Codebase only), date, what was audited, what was not audited. Include this exact warning verbatim:
This audit is based only on codebase evidence. It does not include live traffic, keyword rankings, backlinks, real SERP performance, GA4, or Google Search Console data.
Executive summary — overall codebase SEO health, top strengths, top risks, top 5 fixes.
Audit results — the results table, preceded by its column guide:
How to read this table — one row per SEO category. Score is 0–100, the weighted sum of the category's sub-criteria (each sub-criterion 0–100 × its weight; weights total 100 per category). Grade maps from Score (A 90–100, B 80–89, C 70–79, D 60–69, F 0–59). Status = Pass / Warn / Fail / N/A. Confidence = High / Medium / Low (how directly it was verified). Evidence = the file path(s) the score traces to.
| Category | Score | Grade | Status | Confidence | Evidence |
|---|---|---|---|---|---|
| Technical SEO | |||||
| Metadata | |||||
| Schema | |||||
| Sitemap | |||||
| Robots.txt | |||||
| Canonicals | |||||
| Internal links | |||||
| Image optimization | |||||
| Accessibility basics | |||||
| Performance setup | |||||
| Framework SEO implementation | |||||
| Content structure | |||||
| AI visibility readiness |
Technical SEO — What is working / Issues found / Recommendations + issues table. Precede the table with its column guide (reuse it above every issues table in the report):
How to read this table — one row per issue; these are judgments from code evidence, not scores. Issue = the problem found. Severity = Critical / High / Medium / Low. Status = Pass / Warn / Fail / N/A. Evidence file = the file (and line) that proves it. Why it matters = the SEO consequence. Recommendation = the concrete fix.
| Issue | Severity | Status | Evidence file | Why it matters | Recommendation |
|---|
Metadata audit
Schema audit
Sitemap and robots audit
Canonical audit
Internal linking audit
Image optimization audit
Accessibility basics audit
Performance setup audit
Framework-specific SEO audit (Next.js / Shopify / WordPress / other)
Content structure audit
AI visibility readiness
Action plan — High / Medium / Low priority with the table below.
Evidence summary — Verified from codebase / Not available from codebase / Files reviewed / Assumptions.
Final checklist — practical developer checklist.
Use the issues table everywhere issues are listed. Severity ∈ {Critical, High, Medium, Low}. Status ∈ {Pass, Warn, Fail, N/A}.
reports/codebase-seo-action-plan.mdA focused, prioritized plan. Begin the tables with the column guide below, then group tasks into High priority, Medium priority, Low priority using this table:
How to read this table — one row per task, sorted by descending Priority. Priority is calculated as
Impact + Confidence − Effort(range −4 to 9); higher = do sooner. Task = the action. Impact = 1–5 SEO upside (added). Effort = 1–5 work required (subtracted, so more effort lowers priority). Confidence = 1–5 certainty the fix is needed/correct (added). Files to update = the file(s) to change. Bucketing: ≥ 6 → High, 3–5 → Medium, < 3 → Low (Critical-severity fixes always go in High).
| Priority | Task | Impact | Effort | Confidence | Files to update |
|---|
Rate Impact, Effort, Confidence each 1–5. Compute a priority score:
Priority score = Impact + Confidence - Effort
Sort within each group by descending priority score. Put each task in the High/Medium/Low bucket based on its score (e.g. ≥6 High, 3–5 Medium, <3 Low) — but always keep Critical-severity fixes in High regardless of score.
reports/codebase-seo-evidence.jsonMachine-readable evidence so the audit is reproducible. Suggested shape:
{
"auditSource": "codebase-only",
"generatedAt": "<ISO-8601 date>",
"project": {
"name": "<from package.json/theme/dir>",
"type": "<detected type>",
"typeEvidence": "<file that proved it>"
},
"filesReviewed": ["<relative paths actually read>"],
"filesMissing": ["<expected-but-absent files>"],
"categories": {
"technicalSeo": { "score": 0, "grade": "F", "confidence": "High", "status": "Warn", "evidence": [{ "file": "", "note": "" }] }
},
"actionPlan": [
{ "id": "T1", "bucket": "High", "priority": 8, "task": "", "category": "Technical SEO", "impact": 5, "effort": 2, "confidence": 5, "files": [""], "severity": "Critical" }
],
"notAvailableFromCodebase": [
"Organic traffic", "Keyword rankings", "Backlinks", "Domain authority",
"AI citation counts", "Google Search Console data", "GA4 data", "Real SERP performance"
],
"assumptions": []
}
Populate filesReviewed with paths you actually read, filesMissing with expected files that were absent, and one entry per category under categories. Always include the notAvailableFromCodebase array as an honesty guard.
The actionPlan array is the machine-readable mirror of the action plan tables — one object per task, with the same bucket (High/Medium/Low), priority (= impact + confidence − effort), task, category, impact, effort, confidence, files, and severity values you put in the markdown. Keep it in sync with reports/codebase-seo-action-plan.md. The sheet skill in this plugin reads this array to build a Google Sheet tracker, so emitting it lets users export the plan with assignees and status without re-parsing markdown.
After writing the files, give a short summary in chat:
sheet skill.Keep the chat summary concise; the detail lives in the report files.
N/A used where evidence was insufficient — no padded scores.reports/ in the audited project.npx claudepluginhub zeshanamindev-hub/seo-codebase-auditor --plugin seo-codebase-auditorSearches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Implements vector databases with Pinecone, Weaviate, Qdrant, Milvus, pgvector for semantic search, RAG, recommendations, and similarity systems. Optimizes embeddings, indexing, and hybrid search.