インデックス未登録の放置は危険！AIで自動チェックする仕組みの作り方
調査
「オウンドメディアにコラムを継続的に公開しているのに、いつの間にかインデックスから外れている記事があった。」
「Search Consoleで気づいたときには、すでに数週間流入を取りこぼしていた。」
そんな経験をしたSEO担当者やオウンドメディアのマーケターは多いのではないでしょうか。
インデックス未登録の放置は、せっかく作ったコンテンツの流入機会をそのまま失うことに直結します。
さらに、低品質と判断されるページがサイト内に大量に積み上がっていくと、サイト全体の評価にも悪影響を及ぼしかねません。
しかしながら、運用しているコラムが100記事を超えてくると、Search Console（サーチコンソール）のURL検査で1本ずつ手動チェックするのは現実的ではありません。
そこで本記事では、Claudeとの対話を通じて「Google Search Console API × Google Apps Script × スプレッドシート」を連携させ、コラムのインデックス状況を毎日自動チェックしてメールで通知する仕組みを構築した実例をご紹介します。
目次
そもそもインデックス未登録とは？なぜモニタリングが必要なのか
自動化の仕組みに入る前に、そもそもインデックス未登録とはどういう状態を指すのか、なぜモニタリングが必要なのかを整理しておきましょう。
インデックス未登録の主な2つのパターン
Google Search Consoleで「インデックスに登録されていません」と表示されるページには、いくつかの状態があります。代表的なのは以下の3パターンです。
- 検出 – インデックス未登録：Googleがページの存在は把握しているが、まだクロールしていない状態。ページにたどり着ける内部リンクがないなどの課題がある可能性があります。
- クロール済み – インデックス未登録：Googleがクロールはしたものの、インデックスに含めないと判断した状態。コンテンツ品質や重複、内部リンク構造に課題があるサインです。
「クロール済み – インデクス未登録」が特に注意すべき理由
この3パターンのうち、もっとも注意が必要なのが「クロール済み – インデックス未登録」です。
Googleが内容を確認したうえで「インデックスする価値がない」と判断している状態のため、技術的なクロール問題ではなく、コンテンツそのものの評価が低い可能性が高いからです。
特に「クロール済み – インデックス未登録」が大量に発生しているサイトは要注意です。記事数の多いコラムメディアやECサイトで、似た構成のページが量産されているケースなどで発生しやすい傾向があります。
1〜2本であれば軽微なシグナルですが、数十本〜数百本単位で積み上がっているなら、サイト構造やコンテンツ戦略を見直すべきタイミングです。
低品質ページの蓄積はサイト全体の評価を下げる
インデックス未登録ページの放置がやっかいなのは、その記事単体の問題にとどまらない点にあります。
Googleはサイト全体の品質を評価する仕組みを持っています。
インデックスから除外されるような低品質ページがサイト内に多く蓄積していると、ドメイン全体の評価が引き下げられ、本来であれば上位表示できていた他の記事の順位にも悪影響が出る可能性があります。
つまり、インデックス未登録ページの監視は、サイト全体の評価を健全に保つという意味合いもあるのです。
手動チェックだと限界がある
インデックス状況のチェック自体は、Search ConsoleのURL検査ツールを使えば1本ずつリアルタイムに確認できます。記事数が10本程度なら、それで十分です。
しかし、コラムが100本、200本と増えてくると、全件を手動でチェックするのは時間的に不可能になります。Search Consoleの「ページのインデックス登録」レポートも便利ですが、データの反映に数日〜1週間程度のラグがあり、リアルタイム性に欠けます。
そこで必要になるのが「全記事のインデックス状況を、毎日自動でチェックして、変化があれば通知する」仕組みです。
Claudeに相談してわかった、自動モニタリングの実現方法
自動化の方針を決めるところから、Claudeに相談しました。最初に投げたのは、こんなシンプルな質問です。
| コラムでインデックスされているかどうかのモニタリングをしたい。毎日自動でチェックをして、報告する仕組みを作りたいけど方法はある？ |
これに対してClaudeから提示されたのは、以下の4つの選択肢でした。
提示された3つの選択肢
①Google Search Console API + GAS（推奨）
Search ConsoleのURL Inspection APIで各URLのインデックス状況を取得し、Google Apps Script（GAS）のトリガーで毎日自動実行する方式です。
完全無料で、Googleの公式データを使うため信頼性も高いというのが最大の魅力です。
URL Inspection APIは1日2,000URLまで使えるため、コラム100〜500本程度のメディアであれば余裕で収まります。
②Indexing API
Googleの公式APIですが、本来は求人情報やライブ配信ページ向けに提供されているものです。
そのため、コラム記事のモニタリング用途で使うのは規約的にグレーで、推奨されません。
③有料SEOツール
AhrefsやSE Rankingなど、既に契約しているツールでインデックス状況の定点観測をする方式。
追加コストがかからない反面、Googleの公式データほどリアルタイムではない点に注意が必要です。
最終的に採用した構成
Claudeとの対話の中で、運用要件（記事数100〜500本／通知はメールでOK／実装は対話しながら一緒に進めたい）を整理した結果、「Search Console API + GAS + スプレッドシート + メール通知」の構成を採用することにしました。
全体像はこんなイメージです。
| [スプレッドシート] 監視対象URLリスト ↓[Google Apps Script] 毎日自動実行 ↓[Search Console API] 各URLのインデックス状況を取得 ↓[スプレッドシート] 結果を日付付きで記録 ↓[Gmail] 異常があればメール通知 |
Googleの公式APIを使うので精度も信頼性も高く、ランニングコストはゼロ。記事数が増えてもAPI上限内に十分収まります。
実際にClaudeと一緒に作ってみた｜セットアップの全STEP
ここからは、実際にClaudeに手順を聞きながらセットアップした流れをSTEP形式で紹介します。所要時間は初回30〜40分ほどです。
STEP1：監視対象URLをまとめたスプレッドシートを準備する
まずモニタリングのベースとなるスプレッドシートを用意します。
Claudeに「フォーマットをスプレッドシートで作成して」とお願いすると、4シート構成のテンプレートを生成してくれました。
- URLリスト：監視対象のURL・タイトル・現在のインデックス状況・最終チェック日時
- 履歴ログ：毎日のチェック結果を蓄積する記録用シート
- 設定：対象サイトのURL・通知先メールアドレスなど
- 凡例：各ステータスの意味と対応方法のリファレンス
実運用では、自社で管理している記事一覧表（Excel）をClaudeにそのまま渡しました。
すると公開済みの記事だけを自動で抽出し、URLとタイトルを正しい組み合わせでスプレッドシートに整理してくれます。
重複URLや不整合があれば指摘してくれるので、データクレンジングの工数まで一気に削減できます。
STEP2：Google Cloud ConsoleでSearch Console APIを有効化する
Search Console APIを使うには、Google Cloud Console側で準備が必要です。
- Google Cloud Consoleにアクセスし、新規プロジェクトを作成（プロジェクト名は「index-monitoring」など分かりやすい名前で）
- 「APIとサービス」→「ライブラリ」から「Google Search Console API」を検索
- 「有効にする」をクリック
ここまでで5分程度の作業です。
STEP3：OAuth同意画面を設定し、テストユーザーとスコープを登録する
個人のGmailアカウントでSearch Console APIを使う場合、OAuth同意画面の設定が必須になります。ここが今回もっともハマったポイントなので、丁寧に進めます。
- ブランディング設定：アプリ名・ユーザーサポートメール・デベロッパー連絡先を入力
- 対象設定：User Typeを「外部」に設定し、自分のGmailアドレスを「テストユーザー」に追加
- データアクセス設定：以下の5つのスコープを手動で追加
| https://www.googleapis.com/auth/webmasters.readonlyhttps://www.googleapis.com/auth/spreadsheetshttps://www.googleapis.com/auth/script.send_mailhttps://www.googleapis.com/auth/script.external_requesthttps://www.googleapis.com/auth/script.scriptapp |
STEP4：GASにコードを貼り付け、appsscript.jsonにスコープを宣言する
スプレッドシートのメニューから「拡張機能」を選び、「Apps Script」を開きます。
Apps ScriptのサービスメニューにSearch Console APIは登録されていないため、UrlFetchAppで直接APIを叩く方式でコードを書きます。
とはいえ、Claudeがこちらの要件を踏まえて完成形のコードをまるごと用意してくれるので、私たちがやるのはコピペをして保存をするだけです。
もう一つ重要なのが、appsscript.jsonへのスコープ宣言です。
Apps Scriptエディタの「プロジェクトの設定」から「appsscript.jsonマニフェストファイルをエディタで表示する」をONにし、必要なスコープを明示します。
これを忘れると、後の認証ステップで権限エラーが出てしまいます。
STEP5：GASプロジェクトをGCPプロジェクトに紐付ける
今回もっとも見落としやすく、それでいて成否を分ける最重要ステップがこれです。
Apps Scriptは通常、自動生成された別のGCPプロジェクトで動いてしまうため、STEP2で作ったプロジェクトとの紐付けを明示的に行う必要があります。
- Google Cloud Consoleの「ダッシュボード」で、プロジェクト番号（12桁の数字）をコピー
- Apps Scriptエディタの歯車アイコン（プロジェクトの設定）を開く
- 「Google Cloud Platform（GCP）プロジェクト」セクションの「プロジェクトを変更」をクリック
- コピーしたプロジェクト番号を貼り付けて「プロジェクトを設定」
これをやらないまま実行すると、後述する「アプリがブロックされる」問題が解消しません。
STEP6：テスト実行→全件チェック→週次トリガー設定
コードと認証の準備が整ったら、いよいよ実行です。
- まずは1件だけ取得するテスト関数を実行し、認証フローを通す
- ログに「判定結果：インデックス登録済み」と表示されればOK
- 全件チェック関数を実行（後述するように連続実行方式にすることで、時間制限を回避）
- 動作確認できたら、Apps Scriptのトリガー機能で「毎週月曜日 午前8時」など定期実行を設定
ここまで来れば、あとはほったらかしで毎週自動チェック＆メール通知が走ります。
ハマったポイントと、Claudeに相談しながら解決した方法
実装を進める中で、何度も詰まりました。
同じ仕組みを作りたい方は、おそらく同じ場所でつまずきます。Claudeに相談しながら一つずつ解消していった主要なハマりポイントを共有します。
ハマったポイント①Apps Scriptのサービス一覧にSearch Console APIが出てこない
Apps Scriptの「サービスを追加」ダイアログには、Drive・Gmail・Calendarなどメジャーなものは並ぶのですが、Search Console APIは含まれていません。いくら検索しても出てきません。
Claudeに相談すると、「Search Console APIはGAS公式のアドバンスドサービスに登録されていないので、UrlFetchAppで直接HTTPリクエストを叩く方式に切り替えましょう」と提案を受けて解決しました。
むしろこちらの方が動作も安定するそうです。
ハマったポイント② 個人のGmailでは「このアプリはブロックされます」が出る
テスト実行しようとすると「このアプリはブロックされます」という画面が出て先に進めない。
通常であれば「詳細」リンクから「安全ではないページに移動」で突破できるのですが、最近のGoogleの仕様変更で個人Gmailではそのリンクが表示されないケースがあります。
テストユーザーの登録、スコープの追加など、Claudeと一緒に対処策を順番に試しましたが、これだけでは突破できませんでした。
ハマったポイント③実行時間6分制限でタイムアウトする
全件チェック関数を実行すると、Apps Scriptの1回あたり最大6分という実行時間制限に引っかかってタイムアウトします。
Claudeに相談したところ、最終的にたどり着いた解は「1件処理したら、次回の実行を1分後にトリガー設定してから終了する」という連続実行方式でした。
| checkIndexStatusContinuous() を実行 ↓5分以内で可能な限り処理（10〜15件） ↓まだ残りがある？ ↓ YES次の実行を「1分後」にトリガー設定して終了 ↓（1分待機後、自動で次が実行される） ↓ 全件完了通知メール送信 |
これにより、手動で1回実行するだけで、あとは全自動で全件チェックが完了するようになりました。トリガーで週1回起動するように設定すれば、完全に手放しで運用できます。
完成した仕組みと運用イメージ
最終的にでき上がった仕組みは、こんな動きをします。
週1回、自動で全記事のインデックス状況をチェック
毎週月曜日の朝、Apps Scriptが自動起動。全記事のインデックス状況をSearch Console APIから取得し、スプレッドシートに記録します。
「インデックス登録済み」「クロール済み – インデックス未登録」「未登録」「エラー」の4種類で色分け表示されるため、視覚的に状況を把握できます。
異常があれば即座にメール通知
「クロール済み – インデックス未登録」や「未登録」の記事が見つかったら、自動でメール通知が届きます。記事ごとのステータス、URL、タイトル、そして「対応方法」のメモが本文に含まれているので、開いてすぐに行動に移せます。
逆に全件問題なければ「全X件問題なし」というOK通知が届くので、毎週の健全性チェックとしても機能します。
別サイトへの横展開も10分で完了する再現性
一度Google Cloud Console側のセットアップを終えれば、別サイトに同じ仕組みを展開するのは簡単です。
新しいスプレッドシートを用意して、対象サイトのURLと監視対象URLリストを入れ替えるだけ。同じGCPプロジェクトを使い回せるため、OAuth周りの設定はやり直し不要です。
私の場合、複数のサイトに同じ仕組みを展開しましたが、2サイト目以降は10分ほどで設置が完了しました。
まとめ
インデックス未登録、特に「クロール済み – インデックス未登録」の記事を放置することは、流入機会を失うだけでなく、サイト全体の評価を引き下げるリスクを抱え込むことを意味します。
コラム本数が増えてくるオウンドメディアにとって、この監視を自動化する価値は決して小さくありません。
Search Console API × GAS × スプレッドシートという構成は無料で実装でき、コーディング未経験でもClaudeに相談しながら進めれば組み上げられます。
実装の途中で必ずどこかで詰まりますが、状況をそのままClaudeに投げれば、原因の切り分けと解決策の提示までやってくれるため、孤独に試行錯誤する必要はありません。
「インデックス変動を早期発見できる体制」を一度作っておくと、SEO運用の安心感が大きく変わります。手動チェックに時間を取られている方は、ぜひ仕組み化に着手してみてください。
