SEO Skill: a local CLI and MCP server that turns crawl and Search Console data into ranked fixes
The only SEO skill your agent needs. 70+ SEO audit tools through a local CLI and MCP server, using your own crawl, Search Console, and GA4 data.
At a glance
- What is it?
- iannuttall/seo packages 70+ SEO audit tools behind one `seo` command and an MCP surface for agents. It keeps first-party data local and separates observed evidence from derived findings, but the Google and research-provider paths add setup weight that a plain crawler does not have.
- Who is it for?
- Adopt SEO Skill if you want crawl, Search Console and analytics evidence in one local command that both you and an agent can call, and you are willing to run Node 22 or newer and complete the Google OAuth setup. Do not adopt it if you need a hosted dashboard, a scheduled crawler you do not maintain, or if you cannot grant Search Console access to a desktop OAuth client.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap SEO Skill is aimed at: audits that end in a screenshot
Most SEO tooling produces a dashboard, and a dashboard is a poor input for an agent. An agent asked to fix metadata, canonical tags or indexability either gets a rendered page it has to interpret, or a report it cannot cite back to a specific row. SEO Skill takes the opposite position. The README describes it as turning crawl, Search Console, connected traffic analytics and optional research-provider data into "work you can inspect and ship", and it exposes that work as deterministic JSON, Markdown and stable rule IDs.
The stated audience is three groups. People running their own sites who want a ranked list of fixes without learning a heavy dashboard. AI agents that need crawl, Search Console, analytics, keyword, result, domain, competitor and link evidence through MCP rather than screenshots. And developers who want the same report engine inside a script, a CI job or a TypeScript app. Those are different buyers with different tolerances for setup, and the README addresses all three with one installation path, which is worth noting because the agent use case is the one the naming leans on hardest.
How the report engine is structured: evidence, findings, actions
The design rule that matters most is stated plainly in the README: observed evidence stays separate from derived findings and recommended actions, and the crawl row or provider row behind a claim is always visible. That is a data-model decision, not a marketing line. It means a finding cannot exist without a source row attached, which is what makes the JSON output usable by an agent that has to justify a change.
Two more rules reinforce it. Partial data is never reported as a zero, so a capped, filtered or sampled source is labeled as such and cannot support a definitive all-clear. Heuristics are labeled as heuristics, meaning a convention or threshold is not presented as a search-engine rule. The README also says each recommendation ships with a way to check whether the fix worked, rather than a promise about rankings or traffic.
On the tooling side, the README lists audit coverage across metadata, links, indexability, canonicals, structured data, performance, security, mobile, international SEO and social previews. Ranking of that work uses affected URLs, rule severity, search visibility and analytics value, so a warning on a high-traffic template outranks the same warning on a dead page. Crawl reports can be saved and compared without re-crawling, and SEO changes can be measured with matched before and after Search Console windows.
Installing and running it: the commands the README gives
The requirement is Node 22 or newer. The quick start is three lines:
npm i -g seo seo start seo report
The README states that setup walks through Google sign-in, Search Console property selection, an optional traffic analytics connection, and a local project profile. Public releases can include a shared Google app; if that app is unavailable in your build, the setup guides you through adding your own desktop OAuth client. That conditional is the single most important thing to check before planning a rollout, because it decides whether setup is a sign-in or an OAuth client registration.
There is a no-sign-in path. `seo report --url` crawls the site and returns findings and an action list without connecting Google at all. Reports can also run against a property directly with `seo report --site sc-domain:example.com`, or without a saved profile.
The command list in the README is the real map of the tool. `seo start` connects first-party data and saves a profile. `seo projects list`, `seo projects add` and `seo sites` manage profiles and Search Console properties. `seo doctor` checks local auth and config. Acting on a report means `seo refresh-priorities`, `seo quick-wins` (ranking 4 to 10, low CTR), `seo second-page` (URLs averaging positions 10 to 20) and `seo technical-watch`. For agents and scripts there is `seo report --json`, `seo export diagnose` for CSV, `seo mcp install` to install the tools into MCP clients, `seo skill list`, and `seo reports list`. `seo help all` prints the longer command list.
Where the data comes from, and what stays on the machine
Three evidence sources feed the main report: your own crawl, Search Console, and connected traffic analytics. DataForSEO, Semrush and Ahrefs are optional research providers built into the main package, and the README is explicit that you should connect one "only when external result, keyword, domain, competitor, or link evidence would change the decision." That is a reasonable default, and it also means the tool is useful without paying for a third-party API.
The repository carries a `local-first` topic and links a privacy page, and the architecture described is consistent with that: a global CLI on the machine, a local project profile, a local MCP server, and saved crawl reports and keyword sets stored locally. The README does not enumerate which fields leave the machine when Google or a research provider is connected, so treat that as something to verify yourself rather than assume. The privacy page is the place the project points to for the answer.
The MCP surface is described as compact and local. `seo mcp install` registers the tools with MCP clients on the machine, which is what lets an agent call the same report engine the CLI uses instead of scraping a page.
The limits: OAuth, Node 22, and reports that cannot give an all-clear
The first real constraint is the Google path. If the shared Google app is not in your build, you register your own desktop OAuth client. That is a manual step with an external dependency, and it is the kind of thing that stalls a rollout inside an organisation where nobody owns the Google Cloud project. The no-sign-in crawl avoids it, but you lose Search Console and analytics evidence, which is where the ranking and quick-win logic gets its inputs.
The second constraint is Node 22 or newer. That is a hard floor, not a suggestion, and it rules out older CI images and long-lived build containers until they are updated.
The third is a design consequence rather than a bug. Because partial data is never reported as a zero, a capped or sampled source cannot support a definitive all-clear. You get an honest report and you also get a report that will not tell you the site is fine when the crawl was truncated. Teams used to a green checkmark will read that as ambiguity.
Finally, the README lists no releases in the supplied material, and the repository has no retrieved release notes, so there is no version history here to judge upgrade cadence against. The last push date is recent, which tells you the branch is active, not that any particular command is stable across versions.
Alternatives: Screaming Frog, Lighthouse CI and hosted crawlers
The closest comparison is a desktop crawler such as Screaming Frog. It crawls deeply and exports to CSV, and it does not ask you to authenticate anything to run a technical pass. The difference in approach is where the judgement lives. Screaming Frog hands you rows and you decide what matters. SEO Skill ships a ranking layer that weighs affected URLs, rule severity, search visibility and analytics value, and it folds Search Console and GA4 into the same output. If you already have a spreadsheet workflow built on Screaming Frog exports, SEO Skill replaces the ranking step, not the crawl.
Lighthouse CI sits at the other end. It runs in a pipeline and asserts on performance budgets for a single URL at a time. SEO Skill's `seo technical-watch` and `seo report --json` are the comparable CI-shaped commands, but the report is site-level and evidence-linked rather than a per-page score. If your need is a performance gate on every pull request, Lighthouse CI is the narrower and better fit.
Hosted crawlers with scheduled audits are the third option. They remove the Node 22 requirement and the OAuth client question entirely, at the cost of sending your Search Console and analytics data to a third party and losing the local MCP surface. SEO Skill's position is the inverse: you own the runtime and the data, and you own the setup.
Licence, maintenance and what to verify before adopting
The project is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. It also carries the usual obligations around preserving notices and stating changes. That is a summary of the identifier, not legal advice; read the LICENSE file and the SECURITY.md the README links before shipping it inside a product.
Maintenance cost is mostly environmental rather than code-level. You are responsible for Node 22 or newer on every machine and CI runner that calls `seo`, for the Google OAuth client if the shared app is unavailable in your build, and for any research-provider API keys you connect. The README's own guidance to connect a provider only when external evidence would change a decision is also the cheapest maintenance position: fewer credentials, fewer things to rotate.
Because no release notes were retrieved, verify behaviour against your own site rather than against a changelog. Run `seo doctor` first to confirm local auth and config, then `seo report --url` for a no-sign-in technical pass, and only then decide whether the Google and analytics connections earn their setup cost. The `seo help all` output is the fastest way to see whether the commands you need exist in the version you installed.
Editorial conclusion
Adopt SEO Skill if you want crawl, Search Console and analytics evidence in one local command that both you and an agent can call, and you are willing to run Node 22 or newer and complete the Google OAuth setup. Do not adopt it if you need a hosted dashboard, a scheduled crawler you do not maintain, or if you cannot grant Search Console access to a desktop OAuth client. Before committing, run `seo doctor` to confirm local auth and config, then `seo report --url https://your-site` to see what the no-sign-in technical report actually returns for your markup.
Community notes