every-app/open-seo

seo-audit

Audit a website and deliver a one-page, plain-language SEO report anyone can act on, centered on a single do-this-week action.

All-time #4842 Trending #1702 Hot #701 First seen Jul 30, 2026
8-week activity · all time api

Installation

$ npx skills add every-app/open-seo --skill seo-audit

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from every-app/open-seo · top by installs.

npx skills add every-app/open-seo

Browse all from every-app/open-seo

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 17.8K
License LICENSE
Default branch main
Open issues 70
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 7,149 B
  • docs SUMMARY.md 143 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2,706 installs

Videos

Tutorials, guides, and showcases specifically about this skill.

SKILL.md

OpenSEO SEO Audit

Goal

Audit a domain and produce a one-page HTML report that anyone, including a complete SEO beginner, can read once and act on. The whole report exists to support ONE action the owner can take this week; everything else is supporting detail.

Use this when asked for an SEO audit or review of a domain, especially when the output is a shareable report for a non-expert. For expert-facing analysis of a competitor or market, use competitor-analysis or competitive-landscape instead.

Required inputs

  • Domain to audit
  • projectId (use listprojects; if no project matches the domain, create one with createproject)

Project context

The project-context tools are free and shared with the app and other agents.

  1. Call getprojectcontext first and ground the report in it — what the business does decides which findings matter and what the one thing should be.
  2. This skill needs businessoverview. If it is empty, run a minimal inline setup: infer what the business does from the site and confirm it with the user in one question, write it back with updateproject_context, then continue the audit. Never front-load the full interview; suggest seo-project-setup at the end for the rest.
  3. Before spending credits, check the research log. If the same research ran within the last 30 days, reuse that result and say so instead of re-buying it.
  4. On finish, write back what is durable — a corrected business_overview, the pages the report singles out via addKeyPages — and append a research log entry: { appendResearchLog: { summary: "Site audit: <domain>. Verdict: <conclusion>" } }.

OpenSEO MCP tools

  • whoami: confirm connection and remaining credits before spending anything. If OpenSEO is not connected, stop and ask the user to connect it.
  • listprojects / createproject: resolve the projectId.
  • runsiteaudit: start the crawl (default page budget). Leave Lighthouse off (its default) — it adds several minutes and this report doesn't need it; pass runLighthouse: true only when the user asks for performance/Core Web Vitals depth. Then check getauditstatus (the crawl takes a minute or two — wait between checks rather than polling in a loop) and read getauditissues. Use getauditpages when per-page evidence helps.
  • getbacklinksoverview: backlink and referring-domain picture; usually the deciding data for the "one thing".
  • getdomainoverview: estimated organic traffic and organic keyword count. Skip when the site is clearly dead.
  • research_keywords: keyword ideas with volume and difficulty, used to propose a starting focus area. One call with 1-3 seeds taken from what the site is actually about. Skip when the site is down.

Keep total spend modest: one audit, one backlinks overview, at most one domain overview, and at most one keyword-research call. Only the overview and keyword lookups spend credits.

Workflow

  1. whoami, then resolve the projectId.
  2. runsiteaudit for the domain (Lighthouse stays off unless the user asked for performance depth). While it crawls, fetch getbacklinksoverview.
  3. When the crawl finishes, read getauditissues (and getdomainoverview if the site is alive).
  4. If the audit comes back broken or nearly empty (certificate errors, 5xx, one page crawled): investigate before writing. Check the certificate and redirect variants yourself, and search the web for the business. A dead domain often has a live successor site, which flips the whole recommendation to "redirect the old domain".
  5. Verify every finding you plan to report against the live page HTML by fetching pages yourself. Report nothing you have not seen evidence for.
  6. Decide the one thing. Derive it from the data, never from generic advice. Common patterns:

- Clean site, no backlinks: outreach to guests, partners, or directories, with a ready-to-send message. - Dead domain, live successor site: permanent redirect via hosting support, with the exact sentence to send them. - Blocked or noindexed pages: remove the block. It must be doable this week by a non-technical person, with copy-paste-ready mechanics included.

  1. When the site is healthy, propose a starting focus area: run one research_keywords call seeded from the site's actual topic, then pick one theme and 3 to 5 specific, low-difficulty keywords the site can realistically rank for, each with the page or post to make. This is a starting direction, not a keyword strategy; point the user at the keyword-research skill for the full workflow. Skip this step entirely when the site is down — the one thing is all that matters there.
  2. Write the report using template.html in this skill directory (see Output format).
  3. Review before delivering: run an adversarial pass with a second agent or model if your environment has one, otherwise do a fresh self-review. Give the reviewer the verified facts and have it attack four things: claims beyond the facts, unglossed jargon, anything overwhelming for a beginner, and dramatic language. The reviewer may also flag true facts it was not given; check those against your evidence instead of "fixing" them.
  4. Deliver the report: if your environment can publish or preview HTML (for example as an artifact), do that; otherwise save the HTML file and tell the user to open it in their browser.

Output format

Use template.html next to this file. Fill in content; keep the CSS and structure as they are (light palette only, no dark mode).

  • Header: domain as the title, the review date on its own line under it, then a 2-3 sentence summary of the whole report (overall state; the main gap and the one thing; what the report covers).
  • Section order: verdict, the one thing, small fixes (5 to 10 max, ordered by impact), where to focus first (healthy sites only), already working, method footer.
  • Each fix row shows the exact evidence (a quoted tag or number) and concrete steps a non-technical person can follow.
  • "Where to focus first" names one topic area and 3 to 5 keywords, each with its search volume in plain words and the page or post to make. Omit the section when the site is down.

Guardrails

  • Tone: calm and plain. No exclamation points, no drama words, no em dashes, no "Not X. Y." contrasts, no filler. Severity words only where literally true (a down site is critical; a long title is not).
  • Gloss every term of art in plain English on first use: canonical, meta description, alt text, crawler, 301, structured data.
  • Skip nitpicks that do not matter for the specific site. A beginner report with twenty findings has failed.
  • Missing backlink or ranking data means "no recorded data", not a penalty; say so rather than dramatizing it.
  • Favor keywords the site can win now: specific intent, low difficulty. Do not list head terms a new site cannot rank for yet.
  • Separate what the tools reported from what you verified yourself, and note both in the method footer.