SEO の調査で programmer が面倒に感じるのは、title、canonical、sitemap を直すことそのものより、証拠が散らばることだ。site crawl は一つの dataset、Search Console は別 dataset、GA4 はさらに別、keyword や competitor research はまた別の tool にある。最後に agent へ渡す context は、数枚の screenshot、手で写した数字、そして「どこが悪いか見て」という一文になりがちだ。この入力では、もっともらしいが検証しにくい提案が出やすい。

今日紹介する iannuttall/seo は、この流れを local で検証可能な形に寄せる project だ。seo command は local crawl、Google Search Console、Google Analytics、optional research provider の data から structured reports を作る。同じ能力は CLI、JSON output、MCP server、packaged SEO skill としても使える。つまり、もう一つの SEO dashboard というより、人間と agent が共有できる local audit layer に近い。

2026-07-22 時点で GitHub repository API、repository page、README、Releases page、tags API、LICENSE、package.json、npm registry、public git history から確認できる情報では、iannuttall/seo は 32 stars、0 forks。GitHub の primary language は TypeScript、license は Apache-2.0。GitHub repository API の created time は 2026-07-10 10:12:32 UTC、latest pushed time は 2026-07-22 09:26:44 UTC。public git history の最初の commit は 9dc810f、commit time は 2026-06-01 17:34:05 UTC、message は feat(core): add seo cli foundation。現在の default branch commit は 446d803、commit time は 2026-07-22 09:26:42 UTC、message は Merge pull request #15 from iannuttall/fix/workers-header-limit。GitHub Releases page には現在 formal release はない。GitHub tags API で確認できる latest tag は v0.2.21、npm の seo latest も 0.2.21。

プロジェクト概要

項目内容
リポジトリiannuttall/seo
位置づけlocal SEO audit CLI、agent evidence layer、MCP tool
Stars32
Forks0
主言語TypeScript
ライセンスApache-2.0
GitHub 作成時刻2026-07-10 10:12:32 UTC
最初の public commit9dc810f、2026-06-01 17:34:05 UTC
current main commit446d803、2026-07-22 09:26:42 UTC
latest pushed2026-07-22 09:26:44 UTC
GitHub releaseformal release なし
latest tag / npmv0.2.21 / seo 0.2.21
キーワードSEO、crawl、Search Console、GA4、MCP、CLI、JSON reports

SEO の証拠を machine-readable にする

seo の README が重視しているのは “evidence-backed reports” だ。これは agent workflow ではかなり重要になる。SEO の提案は簡単に一般論へ流れる。meta description を直す、internal links を増やす、speed を改善する、content を増やす、といった話だ。本当に役に立つのは、提案が検証可能な証拠と結びついていることだ。どの URL が影響を受けているのか、どの rule が triggered なのか、Search Console でどの query/page が伸びかけているのか、crawl result でどの canonical や indexability signal が問題なのか。

この project の方向は、先に evidence を集めて、それから report を作ることにある。seo report --url https://example.com のような local technical check から始められる。Search Console property があるなら、seo start で project profile を保存し、seo report、seo quick-wins、seo second-page、seo technical-watch などで business data に近い確認ができる。Agent にとっては、dashboard screenshot より JSON output と stable report catalog のほうが扱いやすい。同じ structure の中で evidence、finding、status、limitation、verification step を読めるからだ。

README にある制約の中で特に良いのは、missing data や partial data を zero として扱わない点だ。Provider response が capped、sampled、unavailable なら、report はそれを明示すべきで、「問題なし」と表示してはいけない。このような detail は地味だが、agent に SEO を任せるときに失敗しやすい場所でもある。Model は story を補完しがちなので、tool layer が evidence boundary をはっきり示さないと、提案は過剰に自信を持つ。

CLI、JSON、MCP が同じ surface になる

この repository は人間が command を打つためだけのものではない。package.json は seo binary を公開しており、README には seo report --json、seo mcp install、seo skill list、seo reports list などの入口が並んでいる。同じ audit capability を terminal で読み、script で消費し、MCP client や agent skill に接続できる。

ここが traditional SEO tool と違うところだ。Dashboard は browse には向いているが、agent が必要とするのは structured context と明確な boundary だ。たとえば CI や local script で seo crawl を実行して crawl report を保存する。その後、agent が JSON を読み、高 impact issue を選び、patch や issue を作る。最後に同じ command で修正を検証する。この流れの中心は agent に「SEO を理解させる」ことではなく、agent が inspect、cite、rerun できる workbench を渡すことだ。

個人 site や small team にも合っている。README の quick start は npm i -g seo、seo start、seo report で、Node 22 以上が必要。Google 関連の能力は local sign-in と local project profile を通じて接続する。DataForSEO、Bing Webmaster、IndexNow、server log analysis などは optional provider や subcommand として存在する。まず technical issue だけを見たいなら、Google を接続せず URL crawl から始められる。

小さい tool として面白い理由

iannuttall/seo はまだ小さく、star も fork も多くない。ただし方向ははっきりしている。SEO を「dashboard を見て conclusion をコピーする作業」から、「local で audit 可能な evidence を生成する作業」に寄せている。これは Gumi が普段追っている developer workflow と相性がよい。SEO は marketing tool と見られがちだが、実際の問題の多くは engineering 側にある。redirect、robots、canonical、structured data、performance、i18n hreflang、internal links、content templates、release regression などだ。

Document site、SaaS marketing site、open-source project website、programmer blog を維持しているなら、この種の tool には二つの利点がある。一つ目は、日常調査を rerunnable command にできること。Traffic が落ちてから複数の SaaS にログインするより、普段から report を作れるほうがよい。二つ目は、agent を具体的な修正に参加させられること。Agent は JSON、affected URL、verification step を見て、code や template を直せる。

もう一つ興味深い点は、documentation に “AI search evidence” も含まれていることだ。README には関連 docs への入口があり、project が traditional search ranking だけでなく、agent や AI search にどんな evidence surface が必要かも考えていることがわかる。この領域はまだ早いが、content site や product docs にとっては追う価値がある。

注意したいところ

第一に、project はかなり若い。GitHub created time は 2026-07-10 で、public git history は 2026-06-01 からあるものの、repository 自体は公開されてから長くない。現時点では formal GitHub Release がなく、tags と npm publish がある。Automation に組み込む前に version を固定し、command output schema の安定性を確認したい。

第二に、Node >=22.19.0 が必要だ。新しい machine なら問題になりにくいが、多くの CI runner、old server、system Node は 20 以前に残っていることがある。既存 pipeline に入れる前に、separate job で install と browser/crawl dependencies を確認したほうがよい。

第三に、Google Search Console、GA4、Bing Webmaster、third-party research provider は credentials を扱う。Project は local config、keychain、fallback file を説明しているが、team で使うなら、どの machine が実行できるのか、どの agent が読めるのか、どの report を upload してよいのかを先に決める必要がある。

第四に、SEO tool は「growth conclusion generator」として誤用されやすい。seo の README は evidence、partial data、heuristics、verification を繰り返し強調している。使う側も同じ discipline を持つべきだ。Report はある check が何を見つけたかを示すものであり、ranking、traffic、business outcome を保証するものではない。

まとめ

iannuttall/seo を記録する価値は、SEO audit を programmer に馴染みのある形へ落としているところにある。Local command、structured output、rerunnable reports、MCP、そして evidence boundary。すべての SEO platform を置き換えるものではなく、「agent に real crawl と search data をもとに作業させたい」という場面の基盤部品だ。

長期的に維持する site があり、すでに Codex、Claude Code、Cursor などの agent を使っているなら、seo は試す価値がある。まず local crawl と JSON report を走らせ、evidence が十分 clear かを見る。その後で Search Console、GA4、MCP、CI へ広げるかを決めればよい。Small project では、この local evidence から始める順序のほうが、大きな dashboard に最初から寄せるより導入しやすい。