SEO Skill：给 agent 用的本地 SEO 审计 CLI 和 MCP
做 SEO 排查时，程序员最不喜欢的部分往往不是改 title、canonical 或 sitemap，而是证据分散。站点 crawl 是一套数据，Search Console 是一套数据，GA4 是另一套数据，关键词和竞争对手研究又来自别的工具。最后给 agent 的上下文常常变成几张截图、几段手抄指标和一句“帮我看看哪里有问题”。这类输入很容易让 agent 写出看似合理、但很难复核的建议。
今天推荐的 iannuttall/seo 试图把这个流程往本地和可验证的方向拉。它提供一个 seo 命令，用本地 crawl、Google Search Console、Google Analytics 以及可选研究 provider 的数据生成结构化报告；同时把同一套能力暴露给 CLI、JSON 输出、MCP server 和 packaged SEO skill。换句话说，它不是又一个 SEO dashboard，而是给人类和 agent 共用的本地审计层。
按 GitHub repository API、repository page、README、Releases 页面、tags API、LICENSE、package.json、npm registry 和公开 git history 在 2026-07-22 能核验的信息，iannuttall/seo 当前有 32 stars、0 forks。GitHub 显示主要语言为 TypeScript，许可证是 Apache-2.0。GitHub repository API 的创建时间是 2026-07-10 10:12:32 UTC，latest pushed 时间是 2026-07-22 09:26:44 UTC。公开 git history 的首个提交是 9dc810f，提交时间 2026-06-01 17:34:05 UTC，提交信息为 feat(core): add seo cli foundation；当前默认分支提交是 446d803，提交时间 2026-07-22 09:26:42 UTC，提交信息为 Merge pull request #15 from iannuttall/fix/workers-header-limit。GitHub Releases 页面显示目前 没有正式 release；GitHub tags API 显示最新 tag 是 v0.2.21，npm 上 seo 的 latest 也是 0.2.21。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | iannuttall/seo |
| 定位 | 本地 SEO 审计 CLI、agent evidence layer、MCP 工具 |
| Stars | 32 |
| Forks | 0 |
| 主要语言 | TypeScript |
| 许可证 | Apache-2.0 |
| GitHub 创建时间 | 2026-07-10 10:12:32 UTC |
| 首个公开提交 | 9dc810f，2026-06-01 17:34:05 UTC |
| 当前 main 提交 | 446d803，2026-07-22 09:26:42 UTC |
| latest pushed | 2026-07-22 09:26:44 UTC |
| GitHub release | 暂无正式 release |
| 最新 tag / npm | v0.2.21 / seo 0.2.21 |
| 关键词 | SEO、crawl、Search Console、GA4、MCP、CLI、JSON reports |
先把 SEO 证据变成机器可读材料
seo 的 README 把重点放在“evidence-backed reports”。这对 agent workflow 很关键。SEO 建议很容易变成泛泛而谈：改 meta description、补 internal links、提高速度、写更多内容。真正有价值的是把建议和可复核证据绑在一起，比如哪些 URL 受影响、哪条规则触发、Search Console 里有哪些 query 或 page 接近突破、crawl 结果里哪些 canonical 或 indexability 信号有问题。
这个项目的设计方向是先收集证据，再生成报告。你可以从 seo report --url https://example.com 这种纯本地技术检查开始；有 Search Console property 后，再通过 seo start 保存项目配置，用 seo report、seo quick-wins、seo second-page、seo technical-watch 等命令做更贴近业务数据的检查。对 agent 来说，JSON 输出和稳定 report catalog 比 dashboard 截图有用得多，因为它可以在同一结构里看到 evidence、finding、status、limitation 和 verification step。
README 里还有一个我很喜欢的约束：缺失或部分数据不能被当成零。比如一个 provider 返回 capped、sampled 或 unavailable，报告应该明确标出，而不是把缺口渲染成“没有问题”。这类规则听起来像细节，但正是 agent 做 SEO 时容易出错的地方。模型倾向于补全故事；工具层如果不把证据边界说清楚，最后的建议就会过度自信。
CLI、JSON、MCP 是同一套表面
这个仓库不是只给人类跑命令。package.json 暴露了 seo binary，README 也列出 seo report --json、seo mcp install、seo skill list、seo reports list 等入口。也就是说，同一套审计能力可以在终端里看，也可以给脚本消费，还可以挂到 MCP client 或 agent skill 里。
这和传统 SEO 工具有明显差异。传统 dashboard 很适合浏览，但 agent 想要的是结构化上下文和明确边界。比如你可以先让 CI 或本地脚本跑 seo crawl，保存 crawl report；再让 agent 读取 JSON，挑出高影响问题，生成 patch 或 issue；最后用同一个命令验证修复。这里的重点不是让 agent “懂 SEO”，而是给它一个可以检查、引用和复跑的工作台。
它也适合个人站点和小团队。README 里的 quick start 是 npm i -g seo、seo start、seo report，要求 Node 22 或更新版本。Google 相关能力通过本机登录和本地项目 profile 连接；DataForSEO、Bing Webmaster、IndexNow、server log analysis 等能力则作为可选 provider 或子命令存在。对只想先排查站点技术问题的人，可以不连接 Google，直接从 URL crawl 开始。
小工具值得关注的原因
iannuttall/seo 现在还很小，star 和 fork 都不高，但方向很明确：把 SEO 从“看仪表盘、复制结论”变成“本地生成可审计证据”。这和 Gumi 平时关注的 developer workflow 很贴。SEO 本来常被看作营销工具，但大量实际问题都落在工程侧：redirect、robots、canonical、structured data、performance、i18n hreflang、internal links、content templates、release regression。
如果你维护的是文档站、SaaS marketing site、开源项目官网或程序员博客，这类工具有两个好处。第一，它能把日常排查压成可复跑命令，而不是等流量掉了再登录三个 SaaS。第二，它能让 agent 参与具体修复，而不是只写建议清单。Agent 可以看 JSON、看 affected URL、看 verification step，然后改代码或模板。
另一个有趣点是它把“AI search evidence”也纳入文档目录。README 里有相关 docs 入口，说明项目不只看传统搜索排名，也在考虑 agent 和 AI search 需要怎样的证据表面。这个方向还早，但对内容站和产品文档来说值得观察。
需要注意的地方
第一，项目非常年轻。GitHub 创建时间是 2026-07-10，公开 git history 虽然从 2026-06-01 开始，但仓库本身刚公开不久。现在没有正式 GitHub Release，只有 tags 和 npm 发布。自动化依赖它之前，要把版本固定好，并确认命令输出 schema 的稳定性。
第二，它要求 Node >=22.19.0。这对新机器不是大问题，但很多 CI runner、旧服务器或系统 Node 仍停在 20 或更早。把它纳入现有 pipeline 前，最好先用单独 job 验证安装和浏览器/crawl 依赖。
第三，Google Search Console、GA4、Bing Webmaster 和第三方研究 provider 都涉及凭据。项目强调本地配置和 keychain/fallback 文件，但团队使用时仍要明确哪些机器能跑、哪些 agent 能读、哪些报告能上传或发给外部服务。
第四，SEO 工具很容易被误用成“自动生成增长结论”。seo 的 README 反复强调 evidence、partial data、heuristics 和 verification，这很好；使用者也应该保持同样纪律。报告能告诉你某个检查发现了什么，不等于它能保证排名、流量或业务结果。
总结
iannuttall/seo 值得写，是因为它把 SEO 审计变成了程序员熟悉的形态：本地命令、结构化输出、可复跑报告、MCP 和明确的证据边界。它不是要替代所有 SEO 平台，而是给“我想让 agent 基于真实 crawl 和搜索数据做事”这个场景补一块基础设施。
如果你有一个需要长期维护的站点，又已经在用 Codex、Claude Code、Cursor 或其他 agent，seo 是一个可以试的小工具。先用它跑本地 crawl 和 JSON report，看看证据是否足够清楚；再决定要不要接 Search Console、GA4、MCP 和 CI。对小项目来说，这种从本地证据开始的节奏，比一开始就依赖大型 dashboard 更容易落地。