SEO監査をAIエージェントに任せる｜37項目チェックリスト

SEO監査をAIエージェントに任せる｜37項目チェックリスト

なぜエージェントに監査させるのか

SEOの改善提案は、世の中に無数にあります。困るのは提案が無いことではなく、自分のサイトでどれが未対応なのかを判定する作業です。

「パンくずリストを追加」と言われても、実際に何ページに入っていて何ページに入っていないのかは、全ファイルを開かないと分かりません。「正規URLタグを追加」も同じです。37項目を人力で棚卸しすると、それだけで丸一日消えます。

ここはAIエージェントが得意な領域です。コードベース全体を機械的に走査して「済／未」を判定するのは、まさに退屈で正確さが要る仕事だからです。

この記事では、実際に自社サイト（AI Agent Camp）で37項目の監査をエージェントに任せた記録を、プロンプトつきで公開します。何が出てきたか、どこで判断を誤りかけたかも含めて書きます。

37項目のSEOチェックリスト

まずは監査の対象にしたチェックリストです。カテゴリ別に整理しています。

技術SEO（クロール・インデックス）

構造化データ・マークアップ

メタ情報

コンテンツ

キーワード・分析

外部施策

そのままエージェントに渡せるチェックリスト

下のブロックをコピーして、後述の「棚卸しプロンプト」と一緒に貼り付けてください。

# SEO 37項目チェックリスト
## 技術SEO
1. インデックス問題を修正する
2. robots.txt と noindex でブロックされたページを確認する
3. 正規URL（canonical）タグを追加する
4. サイトマップを Search Console と Bing に送信する
5. 壊れたリンクと404エラーを修正する
6. 孤立ページ（内部リンクが無いページ）を修正する
7. JavaScriptで描画されるコンテンツがクロール可能か確認する
8. コアウェブバイタルを改善する
9. サイトをモバイルフレンドリーにする
10. クリーンで説明的なURLを使う
## 構造化データ
11. スキーママークアップを追加する
12. パンくずリストを追加する
13. リッチリザルトテストでスキーマを検証する
14. 見出し構造（h1の重複など）を修正する
## メタ情報
15. タイトルを適正な長さにする
16. ユニークなメタディスクリプションを書く
17. 画像を最適化し、代替テキストを追加する
18. コンテンツを更新したら dateModified を更新する
## コンテンツ
19. オリジナルコンテンツを書く
20. 重複コンテンツを避ける
21. 薄いページ・重複するページを統合する
22. すべてのページを検索意図に合わせる
23. キーワードカニバリゼーションを修正する
24. カテゴリ内で最高のリスト記事を書く
25. 比較・代替ページを公開する
26. 機能・ユースケース専用のページを作る
27. ピラーページを中心にトピッククラスターを作る
28. 著者バイオ / E-E-A-Tシグナルを追加する
## キーワード・分析
29. 高検索量・低難易度のキーワードを見つける
30. 重要なページへの内部リンクを追加する
31. 高インプレッション・低CTRのページのタイトルとメタを改善する
32. 2ページ目にとどまる古いページを見つけて更新する
33. トラフィックと順位を失っているページを監視する
34. site: 検索で切り詰められたタイトルを確認して書き直す
35. 「他の人はこちらも質問」を展開してFAQページを作る
## 外部施策
36. 高品質な被リンクを獲得する
37. ローカルSEOのため Google ビジネスプロフィールを整える

実際にやってみた：出てきたレポート

エージェントに「このチェックリストでできていないことを洗い出して」と投げた結果です。判定はこう分かれました。

面白いのは、基盤は成熟していたのに「配線の抜け」が致命傷になっていたことです。canonical も hreflang も構造化データもサイトマップも揃っていて、記事も170本以上ありました。それでも次の4つが起きていました。

発見1: robots.txt が実質何もブロックしていなかった

Disallow: /login
Disallow: /settings

一見まともです。しかしこのサイトは多言語対応で、実際のURLは /ja/login /ja/settings。ロケール接頭辞が付くため、上の記述は1つもマッチしていませんでした。

さらに調べると、認証ゲートの定義（middleware側）と robots.txt 側でパスの一覧が食い違っていました。2箇所で別々に管理された結果、片方だけ更新されて壊れていたわけです。

発見2: 商用ページ20本が孤立していた

比較記事10本・研修記事10本という、購買直前の検索意図を狙う最重要コンテンツがありました。

サイト全体を href で走査した結果、それらのハブページへの内部リンクが1本もありませんでした。書いたまま導線が繋がっておらず、事実上死蔵している状態です。

発見3: 35ページで h1 が2つあった

記事テンプレートがヒーロー部分に <h1> を出し、さらに Markdown 本文の先頭が # タイトル で始まっていたため、両方が h1 として描画されていました。

発見4（これが最大）: 全ページがCDNに乗っていなかった

チェックリストの「コアウェブバイタル」を調べる過程で見つかった、一番影響の大きい問題です。

cache-control: private, no-cache, no-store, max-age=0
x-vercel-cache: MISS        ← 毎回オリジンへ
TTFB: 0.36〜0.45秒

静的なはずのブログ記事まで動的レンダリングに落ちており、CDNキャッシュに一切乗っていませんでした。原因は共通レイアウトが cookies() と headers() を呼んでいたことと、i18nライブラリの静的レンダリング設定が未適用だったことの合わせ技です。

そしてこれが、Search Console の数字と一致しました。

「Discovered - currently not indexed」は、URLは発見したがクロールすらしていない状態です。遅くてキャッシュできないサイトでGoogleがクロールを見送るときの典型的な症状で、上の計測結果と症状が完全に一致していました。

修正後の実測

そのまま使えるプロンプト

実際に使った流れを4段階に分けます。一度に全部やらせないのがコツです。

以下のコードブロックは右上の「コピー」ボタンでそのままコピーできます。<ここに〜を貼る> の部分だけ自分の環境に合わせて差し替えてください。

Step 1: 棚卸しさせる

以下のSEOチェックリストについて、このリポジトリを実際に走査して
「対応済み / 未対応 / 外部データが必要 / スコープ外」を判定してください。

条件:
- 推測で判定しない。必ず該当ファイルを開いて根拠を示す
- 判定の根拠はファイルパスと行番号で示す
- 「たぶん対応済み」は未対応として扱う
- 結果は docs/reports/ にMarkdownで保存する

<ここにチェックリストを貼る>

ポイントは根拠をファイルパスと行番号で出させることです。これが無いと、それらしい判定表が返ってきて検証できません。

Step 2: 実測させる

コードを読むだけでは分からない項目があります。ここは実際にリクエストを飛ばさせます。

本番サイトに対して次を実測し、結果を表にしてください。推測は禁止です。

1. 主要5URLの cache-control と x-vercel-cache ヘッダ、TTFB
2. トップページの初期HTMLに <h1> が含まれるか（curlの生HTMLで確認）
3. robots.txt の Disallow が実際のURL形式とマッチしているか
4. sitemap.xml のURL数と、実在するページ数の差分
5. Lighthouse を3回実行し、中央値で報告（1回の値は使わない）

「Lighthouseは3回実行して中央値」は必ず入れてください。 後述しますが、1回計測は完全に信用できません。

Step 3: 是正させる

Step1で「未対応」と判定した項目のうち、コードで直せるものを実装してください。

規律:
- feature ブランチを切って作業する。main に直接コミットしない
- 1つの変更ごとに、なぜそれが問題なのかをコメントで残す
- 既存の挙動を変える箇所は、変える理由と影響範囲を明示する
- 実装後に type-check / lint / build / E2E をすべて実行し、結果を報告する

Step 4: 検証させる（ここを省かない）

変更後、次を検証してください。自己申告ではなく実際のコマンド出力で示すこと。

1. ビルドして生成物を確認（robots.txt / sitemap.xml の中身を実際に読む）
2. サーバーを起動し、主要URLの実HTMLで h1 数・canonical・構造化データを検証
3. E2E を全件実行
4. 修正前後で数値がどう変わったかを表にする

Search Console / GA4 と連携する

チェックリストの約3分の1（インデックス状況・CTR・順位・被リンク）は、コードを読むだけでは判定できません。外部データが要ります。連携方法を確実な順に3つ挙げます。

方法1: CSVエクスポートを読ませる（一番確実）

最初はこれで十分です。 Search Console の画面からエクスポートして、そのファイルをエージェントに渡すだけです。

Search Console からエクスポートしたCSV（またはスプレッドシート）を読んで、
次を分析してください。

1. 未インデックスの理由別の内訳と、それぞれが示す原因の仮説
2. インプレッションが多いのにCTRが低いページの上位20件
3. 平均掲載順位が11〜20位（2ページ目）のページ
4. 直近30日で順位を落としているページ

各項目について「なぜそうなっているか」の仮説と、確認方法をセットで書いてください。

実際、この記事のもとになった監査でも、決定的だった「Discovered - not indexed 125件」という内訳はスプレッドシートを渡して読ませただけで判明しました。API連携より先に、まずこれを試すのが早いです。

Google Drive 連携が使える環境なら、スプレッドシートのURLをそのまま渡せます。

方法2: GA4は公式MCPサーバーがある

Google Analytics は Google の公式リポジトリでMCPサーバーが公開されています（2026年7月時点で experimental 扱い）。

• googleanalytics/google-analytics-mcp

experimental なので仕様変更の可能性がありますが、GA4のレポートを自然言語で引けるようになります。セットアップにはGoogle Cloudのサービスアカウントと、GA4プロパティへの閲覧権限が必要です。

方法3: Search Consoleはコミュニティ製MCPかAPI直叩き

Search Console には Google 公式のMCPサーバーがありません（2026年7月時点）。選択肢は次のとおりです。

コミュニティ製MCPは複数存在します（AminForou/mcp-gsc、metehan777/google-search-console-mcp など）。公式ではないので、認証情報を渡す前にコードを確認してください。

方法3を選ぶ場合のプロンプト例です。

Search Console API をサービスアカウントで叩くスクリプトを作ってください。

要件:
- 認証情報は .env から読む。コードにハードコードしない
- 取得するのは: 直近90日のクエリ別インプレッション・クリック・CTR・平均掲載順位
- 出力は data/ 配下にCSVで保存する（/tmp は使わない）
- レート制限に当たったらリトライする

どこまで自動化すべきか

正直なところ、最初からAPI連携を組むのは費用対効果が悪いです。監査は月に1回程度しかやりません。CSVを手でエクスポートして渡す方が、セットアップの手間を考えると速いことが多いです。

自動化が効いてくるのは「毎週順位を監視して、落ちたページを通知する」のような定期実行に移す段階からです。

エージェントに任せて危なかったこと

ここが一番役に立つ部分かもしれません。実際に踏んだ落とし穴です。

1回のLighthouseを信じてはいけない

同じURL・同じ環境で3回測った結果です。

Performance:  54  /  85  /  97

同一条件でこれだけ振れます。 最初に1回だけ測って「改善した」と判断しかけましたが、測り直したら誤差の範囲でした。逆に「悪化した」と誤判定する危険もあります。

必ず3回以上measって中央値を使ってください。そして確定的な判断は、Search Console の実ユーザーデータ（Core Web Vitals）で数週間後に行うのが正しいです。

壊れた環境で測ってしまう

ローカルで「LCPが2.9秒→1.3秒に改善！」という結果が出て、危うくそのまま報告するところでした。

調べると、ハイドレーション直後にアプリがクラッシュしていて、そもそもページが描画されていませんでした。「軽くなった」のではなく「何も表示されていなかった」だけです。

計測する前に、そのページが本当に正常に描画されているかを確認してください。DOMに期待する要素があるか、コンソールエラーが出ていないかです。

エージェントの自己申告を信用しない

実装を委任した際、「完了しました」という報告とともに上がってきた成果物に、次の問題が残っていました。

• 内部メモとして書いた TODO（要確認） が、読者に見える形で本文に出力される状態だった
• 料金表のMarkdownの列数が崩れており、本番でレイアウトが壊れる状態だった

どちらも「テストは通る」し「ビルドも成功する」ので、自動チェックでは捕まりません。実際に描画されたHTMLを目視・機械検証する工程を必ず入れてください。

「記事を増やす」がカニバリを自作しかねない

キーワードの穴を埋めるために新規記事を作る、という作業をしていたときのことです。

「Claude Code インストール」というキーワードに記事が無い、という分析結果が出ました。しかし既存のセットアップ記事が既にそのキーワードをターゲットしていたため、新規に作れば自分で自己競合を作り出すところでした。

チェックリストの「キーワードカニバリゼーションを修正する」を潰しながら、別の手で新しいカニバリを作る。エージェントは指示に忠実なので、こういう矛盾を自分では止めません。新規ページを作る前に、既存ページのターゲットキーワードと突き合わせる手順を必ず入れてください。

事実の捏造を防ぐ

技術記事を書かせると、それらしいコマンドやオプション名を創作することがあります。有効だったのは次の指示です。

- コマンド・設定・料金は、公式ドキュメントで裏取りしてから書く
- 裏取りできなかった箇所は、それらしく書かずに TODO として明示する
- 出典URLを本文に入れる

「分からないときは分からないと書け」と明示的に許可すると、素直にTODOを残します。逆に言えば、これを言わないと埋めてしまいます。

よくあるつまずき

FAQ

Q. プログラミングの知識がなくても監査できますか。 チェックリストを渡して判定させるところまでは、知識がなくても実行できます。ただし「この指摘は本当か」を検証する場面が必ず来るので、出力を鵜呑みにしない姿勢は必要です。是正の実装まで任せる場合は、変更内容をレビューできる人が必要になります。

Q. どのくらい時間がかかりますか。 37項目の棚卸しと実測だけなら数十分です。ただし今回のように「robots.txtが実質機能していない」といった構造的な問題が見つかると、その原因調査と是正で相応の時間がかかります。むしろ問題が見つかるほど時間がかかるのが普通です。

Q. Search Console のデータは必須ですか。 必須ではありませんが、無いと約3分の1の項目が判定できません。特に「インデックスされているか」「どのページがCTRが低いか」はコードからは絶対に分かりません。CSVエクスポートだけでも渡す価値があります。

Q. 自動で修正まで任せて大丈夫ですか。 技術SEO（canonical、robots.txt、構造化データ）は比較的安全です。一方でキャッシュ制御や認証まわりに触れる変更は影響範囲が広いため、必ずE2Eを含む検証を通してください。今回も、認証ゲート配下のページに設定を追加した結果、別ページのクライアント遷移が壊れる事象が発生しました（E2Eで検出できました）。

Q. コンテンツの執筆まで任せられますか。 下書きまでは任せられますが、事実確認は人間が持つべきです。料金やコマンドは平気で創作されます。出典URLを本文に入れさせ、それを1つずつ確認する運用にしてください。

Q. 効果はいつ出ますか。 技術的な修正（キャッシュ・クロール効率）は数週間でSearch Consoleのインデックス状況に現れ始めます。順位への反映はさらに先です。デプロイ直後に順位を見ても何も分かりません。

関連記事

• Claude Code × DataForSEO で SEO 計測を自動化してみた
• Claude Code セットアップ完全ガイド
• Claude Codeで5分、最初の業務自動化を体験する
• MCPサーバーとは？AIエージェントに"道具"を持たせる仕組み

最終確認日: 2026-07-24