Seo-Promt-Master: Google SEO Docs Packaged as an Agent Skill and a Live Auditor

What Seo-Promt-Master solves, and for whom

Google's SEO documentation is public, current and long. The gap this repository tries to close is not access but activation: an agent asked to "audit my SEO" has no shared checklist, so it improvises. Seo-Promt-Master ships a knowledge base under docs/ (files 01 through 17, split between page-level topics and crawling, indexing, quality, measurement, migrations and off-page authority), a five-phase workflow under prompts/, and an installer that makes both discoverable by the agent you already run. The intended reader is a developer working on a JavaScript or TypeScript site who wants the audit to happen inside the editor rather than in a separate dashboard. The README is explicit that the docs are distilled from Google Search Central and web.dev with every claim cited, which matters if you have ever had an assistant invent a canonical rule. It is not a hosted service and it has no homepage; the repository is the product.

How the skill installs itself into five different agents

The mechanism is file discovery, not a plugin API. install.sh copies the knowledge base and tools into a .seo-prompt-master/ directory inside your project and then writes the entry point each agent actually reads. Claude Code looks at .claude/skills/seo-audit/SKILL.md. OpenAI Codex CLI, Amp and Jules read AGENTS.md. Cursor reads .cursor/rules/seo-prompt-master.mdc. Gemini CLI reads GEMINI.md. GitHub Copilot reads .github/copilot-instructions.md. The README states that an existing AGENTS.md or GEMINI.md is appended to rather than replaced, and that re-running the installer is safe, which is the difference between a tool you try once and one you can put in a setup script. The workflow itself is six prompt files: 00-bootstrap detects the stack, loads docs and runs the audit tool; 01-discover-routes enumerates and classifies every route; 02-audit-page applies a nine-point check per public page; 03-prioritize-fixes produces one ordered backlog, infrastructure first; 04-apply-and-verify fixes and then typechecks, lints and builds; 05-live-signals is optional and pulls field data through MCP. There is a fallback for people who do not want an installer at all: drop the repository next to your project, or paste START.md into a chat assistant and say "begin at Phase 0".

Installing it and running a first audit

The README gives a three-step install. Clone the repository, change into your own project, and run the installer from the cloned path. The installer writes the skill files into your working directory, so run it from the project root you want audited.

git clone https://github.com/umutxyp/Seo-Promt-Master.git
cd /path/to/your-project
bash /path/to/Seo-Promt-Master/install.sh

After that, the README says you simply ask the agent to "run the SEO audit" and it finds the workflow on its own. If you would rather not go through an agent, the auditor runs standalone. It needs Node 18 or newer and has zero dependencies. The --url flag sets the target, --max caps how many pages are sampled from the sitemap, and --md writes a Markdown report.

node tools/seo-audit.mjs --url https://example.com --max 40 --md report.md

The second tool is a smoke test for deploys. It takes a space-separated list of paths in SEO_SMOKE_404_PATHS and a base URL, and it needs curl and awk. Both tools exit non-zero on failure, so either can gate a deploy or a CI job, and both work against http://localhost:3000.

SEO_SMOKE_404_PATHS="/ /blog /products" bash tools/seo-smoke.sh https://example.com

What the auditor actually checks on a live server

The design premise is stated plainly in the README: reading a repository tells you what a project intends, and only a request tells you what the server returns. So the auditor fetches pages rather than parsing source. Three findings are called out as invisible to code review. Soft 404s per template, where a route answers 200 for URLs that do not exist; in frameworks with Suspense boundaries a loading.tsx above a segment can silently turn that template's 404 into a 200 shell with no visible symptom. One-way hreflang, where a non-reciprocal set is discarded in full, so every language in the cluster loses the signal. And streamed metadata, where a framework flushes head early and emits the title later; browsers hoist it, but bots that stop reading at the closing head tag see an untitled page. The rest of the list is conventional technical SEO: robots.txt checked against RFC 9309 group semantics, blocked render-critical paths, sitemap limits and lastmod credibility, host consolidation, canonical self-reference, duplicate titles, JSON-LD validity, aggregateRating with no ratings behind it, raw-HTML content volume and image dimensions. The README claims the tool was tested against five production sites before release and found two live P1 blockers, a Disallow on a Next.js asset path and a template returning 200 for everything under it. That is the project's own account of its testing, not an independent result.

The boundary: what a fetched page cannot tell you

The README is unusually direct about the ceiling. Content quality is docs/14, off-page authority is docs/17, and real field Core Web Vitals come from CrUX rather than from fetching a page, which is docs/05. None of those are in the auditor's output, and the README says so: a high score means the technical foundation is sound, not that the site will rank. Treat that as the adoption boundary. If your pages are technically clean and still do not move, this tool will not explain why, and running it again will not either. There is a second, quieter limitation in the scoring model itself. The changelog convention is semver, and the README notes that a major version means old scores are not comparable. So a score is a snapshot tied to a version, not a metric you can chart across upgrades without re-baselining. A third constraint is scope: the auditor samples the sitemap up to --max pages, so a site whose sitemap is incomplete, stale or absent is audited on a partial picture. The README does not document what happens when no sitemap is found.

Seo-Promt-Master compared with Lighthouse and Screaming Frog

The nearest alternatives split along the same axis the README draws. Lighthouse and PageSpeed Insights measure a single URL's rendering and performance in a browser and report Core Web Vitals lab data; they do not crawl your sitemap, they do not compare hreflang sets against each other, and they say nothing about robots.txt group semantics. Screaming Frog is the closer analogue on the crawling side: it enumerates URLs, checks status codes, titles, canonicals and hreflang reciprocity, and it is the tool most technical SEOs reach for. The difference in approach is where the knowledge lives. Screaming Frog ships checks as product features behind a GUI and a licence tier; Seo-Promt-Master ships them as a single .mjs file you can read, plus a docs/ tree the agent loads as context, which is why the same repository can both run an audit and explain a rule. The trade-off runs the other way too: Screaming Frog has a graphical diff between crawls, JavaScript rendering at scale and a support contract. This project has none of those, and its auditor is a sampling pass, not a full crawl.

Licence, maintenance and the cost of upgrading

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permission grant, not legal advice; if you vendor the files into a product, read the LICENSE file in the repository rather than this paragraph. The repository is not archived, and the last push was on 2026-08-15, the same day v2.0.0 was released. The version is recorded in a VERSION file and the history in CHANGELOG.md, and the README states that a major version means old scores are not comparable. That is the real upgrade cost: after a major bump you re-run the auditor to establish a new baseline rather than comparing against the previous report. Re-running install.sh is described as safe and existing AGENTS.md or GEMINI.md files are appended to, so the mechanical upgrade is cheap. The ongoing cost is the knowledge base. Docs 09 covers 2024-2026 updates, which means the docs/ tree is maintained by hand against Google's changing guidance, and nothing in the repository automates that refresh.

A first pass on a Next.js project, and what to expect

The repository includes examples/nextjs-blog-example.md, which suggests the Next.js blog is the shape the authors had in mind. A reasonable first run is to install the skill, start your dev server, and point the auditor at localhost before you point it at production. The README confirms both tools work against http://localhost:3000. Start with a small --max so the first report is readable, fix what it flags, then widen the sample. Expect the P1 findings to be unglamorous: a blocked asset path, a route answering 200 for a URL that should 404, a canonical pointing at itself when it should point elsewhere. The auditor exits 1 on any P1, which is what makes it usable as a CI gate rather than a dashboard you check when you remember. If the first run reports nothing, that is a signal about your sitemap coverage as much as about your SEO, because the sample comes from the sitemap. The README does not describe a mode that crawls without one.

Editorial conclusion

Adopt it if you run a JavaScript or TypeScript site with a sitemap and want a repeatable technical pass wired into the coding agent you already use; install.sh is idempotent, so trying it costs one clone. Skip it if your problem is content quality, link authority or field Core Web Vitals, because the README states the tools cannot see those. Verify first that your Node runtime is 18 or newer and that your sitemap is reachable, then run tools/seo-audit.mjs with --max 40 and read the P1 findings before trusting any score.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. umutxyp/Seo-Promt-Master on GitHub