Seo-Promt-Master ships two zero-dependency tools and calls the rest documentation

The repository name drops a letter the project never does

The repository is `Seo-Promt-Master`, with the p missing from prompt, and every reference to it on the page spells the word correctly: the heading reads SEO Prompt Master, the install target is `.seo-prompt-master/`, and the cursor rule file is `seo-prompt-master.mdc`. So the name you type into a clone URL is not the name the project uses for itself, which is worth knowing before you grep for it.

The release history is one entry. v2.0.0, titled as a skill that runs, was published on 2026-08-15 at 06:25 UTC, and the last push to the branch is 2026-08-15 at 09:06 UTC, a couple of hours later the same day. The repository is not archived.

Version discipline is still written into the tree: a `VERSION` file and a `CHANGELOG.md` at the root, described as semver where a major bump means old scores are no longer comparable. That is a promise about score comparability rather than about API stability, and with a single 2.0.0 release there is no earlier score to compare against yet.

Alongside the skill files sit `checklists/`, `prompts/`, `templates/`, `verticals/`, `tools/`, `docs/` and an `examples/` folder holding a single Next.js blog walkthrough.

The installer writes five different entry points into your project

Installing is a clone plus a shell script pointed at your own project:

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

What it does is copy the knowledge base and the tools into `.seo-prompt-master/` inside your repository and then write the one file each agent actually reads. Claude Code reads `.claude/skills/seo-audit/SKILL.md`, the OpenAI Codex CLI, Amp and Jules read `AGENTS.md`, Cursor reads `.cursor/rules/seo-prompt-master.mdc`, Gemini CLI reads `GEMINI.md`, and GitHub Copilot reads `.github/copilot-instructions.md`. After that, asking for an SEO audit finds the workflow.

Two safety properties are stated for the write. An existing `AGENTS.md` or `GEMINI.md` is appended to and never replaced, and re-running the installer is safe. What the page does not claim is any check on what is already in those files, so an append can still merge into a document you have carefully written.

There are three ways to avoid the installer at all: drop the repository next to your project and let most agents discover `AGENTS.md` on their own, paste `START.md` into any chat assistant and start at Phase 0, or ignore the automation and read `docs/README.md` as a cited reference.

Two dependency-free tools, both usable as a deploy gate

The two scripts are the part that makes requests instead of reading files:

# The thorough pass — sample the sitemap, audit each page, score it
node tools/seo-audit.mjs --url https://example.com --max 40 --md report.md

# The ten-second deploy tripwire
SEO_SMOKE_404_PATHS="/ /blog /products" bash tools/seo-smoke.sh https://example.com

Neither pulls a package. The auditor needs Node 18 or newer, the smoke test needs `curl` and `awk`, and both exit non-zero on failure, which is the property that matters: either can sit in a deploy pipeline or a CI job and stop a bad release. Both also accept a local address, so `http://localhost:3000` is a valid target and the check can run before anything is public. One cosmetic change was made when transcribing the snippet: the em dash in the first comment was replaced with a hyphen, and no command above it was altered.

The stated reason for shipping them at all is the distinction the page draws between what a repository tells you and what a server returns. `seo-audit.mjs` samples the sitemap up to a page cap and writes a markdown report; `seo-smoke.sh` checks a short list of paths for 404 behaviour in about ten seconds. One is an audit you run deliberately, the other is a tripwire you run on every deploy.

The soft 404 that a loading file turns into a 200 shell

The auditor's headline case is a route answering 200 for URLs that do not exist. The interesting part is why it goes unnoticed: in frameworks with Suspense boundaries the symptom is invisible, because a `loading.tsx` above one segment silently turns that whole template's 404 into a 200 shell. Nothing looks broken, the page renders, and the crawler is told the address is fine.

The other two named finds have the same shape of blindness. One-way hreflang is a set that is not reciprocal, and such a set is discarded in full, so every language in the cluster loses the signal at once; it is only visible by comparing pages against each other rather than looking at one. Streamed metadata covers frameworks that flush `<head>` early and emit `<title>` later, where browsers hoist the late title but a bot that stops reading at `</head>` sees an untitled page.

Behind those three, the checklist reads like a list of things a code reviewer cannot see: robots.txt measured against RFC 9309 group semantics, render-critical paths that are blocked, sitemap limits and the credibility of `lastmod`, host consolidation, canonical self-reference and duplicate titles, JSON-LD validity, an `aggregateRating` with no ratings behind it, raw-HTML content volume and image dimensions.

A P1 blocker caps the score whatever else the page gets right

The output is two numbers, an SEO Score and a GEO Score, each out of 100 with a per-category breakdown, and the rubric is a document in the knowledge base rather than a hidden formula. One rule dominates: a P1 crawl or index blocker caps a page's score no matter what else it gets right, on the reasoning that a page which cannot be indexed does not benefit from polish.

Coverage is gated too. No score is reported as final without full coverage plus a self-recheck of a random sample, which means a partial crawl produces a partial result rather than a confident number.

The scope is stated each time the score appears, and the boundary is where this stops being an SEO tool. Content quality, off-page authority and real field performance data are declared out of scope, with the last one explained properly: field data comes from CrUX rather than from fetching a page, so no amount of requesting the site produces it. A high score is described as the technical foundation being sound, not as the site ranking. Backlinks, content quality and competition are named as out of scope.

Freshness is argued with dates, and the workflow resumes from files

The currency argument is a list of specifics rather than a claim of being up to date: INP replaced FID in March 2024, FAQ rich results were removed in May 2026, `rel=next/prev` has been unused since 2019, Google does not support IndexNow, and `llms.txt` is not required. Each one is a way a stale checklist can be caught out.

The knowledge base is numbered `docs/01` through `docs/17`, with 01 to 11 covering the page itself and 12 to 17 covering crawling and crawl budget, indexing and canonicals, content quality and the spam policies, measurement, migrations, and off-page authority. Every claim in it is cited back to Google Search Central or web.dev, and the three subjects the tools cannot measure are pinned to specific documents, content quality to `docs/14`, off-page authority to `docs/17` and Core Web Vitals to `docs/05`.

The workflow is six phases: bootstrap detects framework, i18n and rendering and runs the auditor for a baseline; discovery writes every route to `ROUTES-INVENTORY.md` classified as public-index, public-noindex or private; audit writes a nine-point check per page to `SEO-AUDIT-PROGRESS.md`; prioritisation builds one backlog infra-first from P1 to P3; fixing runs change, then typecheck, lint and build, then a re-fetch before ticking the box; the last phase, on live signals, is named in the page and its description stops mid-word after `opti`. Progress living in files rather than in the conversation is what lets a long run survive a context reset and resume.

Five production sites, two blockers the source review missed

The evidence offered for the tools is a specific claim: they were tested against five production sites before release, and `seo-audit.mjs` found two live P1 blockers that reading the source had not surfaced. One was a `Disallow: /_next/` directive breaking rendering. The other was a template returning 200 for every URL beneath it, which is the soft 404 case again, this time as a production incident rather than a thought experiment.

That is the argument the repository is making about itself, and it is worth weighing as such. Five sites is a small sample, chosen by the author, and the two findings are stated without naming the sites or showing the reports. What the claim does establish is a mechanism: a robots directive and a template default are both invisible in a code review and both fatal to indexing, and both are trivially detectable with a request.

So the tools earn their place on the narrow question of what the server actually returns, and the knowledge base earns its place on the narrow question of what the current rules are. Neither covers whether the content is good or whether anyone links to it, and the page says so directly.

Editorial conclusion

Use it as a technical-readiness pass for a site you control, and read the scores as what they are: out of 100 for technical foundations, with a P1 blocker capping a page regardless of everything else it gets right. Two things to check before trusting it on a real site. The auditor cannot see content quality, off-page authority or field Core Web Vitals, so a high score says nothing about ranking. And there is exactly one release, v2.0.0, published the same day as the last push, so pin that commit and expect the knowledge base to be the part that goes stale.

Frequently asked questions

Official sources

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