「Discovered – currently not indexed」と「Crawled – currently not indexed」は、Search Console のページのインデックス登録レポートで最もよく見かける 2 つの行であり、最も誤解されている 2 つでもあります。技術的な失敗のように見えますが、実際には Google があなたのページに対して下した優先度と品質の判断です。送信を強めても変わりません。原因を直すことで変わります。
このガイドは、Hermes Agent に丸ごと渡せる一連の流れです: URL リストの取得、各ページの検査、本当の原因のトリアージ、修正キューの承認、そしてインデックスに値するページだけを Google Indexing API 経由で送信します。終わったとき、あなたはワンタイムのボタン連打セッションではなく、繰り返し使える週次パイプラインを手にしています。
完了時点で手に入るもの
- 分類済みインベントリ: discovered のまま止まっている URL、クロール済みだが未インデックスの URL、最初から送信すべきではなかった URL
- Indexing API に送信された承認済みリストと、理由付きのスキップリスト
- 送信が本当に効果を出したかを示す検証パス
必要なもの: Hermes Agent がインストールされ動作していること(hermes chat でセッション開始。最新のインストール手順は公式ドキュメント hermes-agent.nousresearch.com/docs を参照)、Search Console プロパティのオーナー権限、そして 2 組の Google 認証情報(1 つは GSC 読み取り用、1 つは Indexing API 用)。初回セットアップは 60–90 分、以後の週次実行は約 15 分です。「完了」とは、送信した URL が数週間以内に検査 API で実際にステータスが動くこと、または動かない明確な理由の証拠があることです。
2 つのステータスを正しく読む
Google はあなたのサイトで詰まっているわけではありません。判断を下したのです。ステータスはどの判断かを教えてくれます。
ステータス | 実際の意味 | よくある原因 | いつ送信するか |
|---|---|---|---|
Discovered – currently not indexed | Google は URL の存在を知っている(サイトマップかリンク経由)が、まだクロールしていない | クロール優先度が低い、内部リンクが弱い・ない、大規模サイトのクロール予算の圧迫、新設サイト、遅い・重い JS レンダリング、サイトマップの頻繁な変更 | 優先度シグナル(主に内部リンク)を改善した後、一度だけ |
Crawled – currently not indexed | Google は URL を取得したが、インデックスに追加しないと判断した | 重複・近似重複コンテンツ、薄いコンテンツ、別 URL を指す canonical、クロール時に存在した noindex、ソフト 404、価値が低いと判断されたページ | 何かを変えた場合のみ: コンテンツ、canonical、または noindex |
Indexed | インデックスに入っている | — | 送信しない |
Excluded | クロールされ、意図的に除外された(noindex、canonical、重複選択、ブロック) | — | 送信しない。除外が意図的かを確認する |
一言で言えば: 実際に変更した URL、または再検討に値する URL だけを送信することです。Indexing API は通知チャネルであり、ランキングの上書きではありません。薄いページを 10 回送っても、同じ判断が 10 回返ってくるだけです。
なぜエージェントで実行するのか
GSC の「インデックス登録をリクエスト」ボタンには公開 API がないため、公式にスクリプトで押す方法がありません。最も近い自動化は Google Indexing API で、URL 通知を直接受け付けます。エージェントがここで力を発揮する理由は 3 つあります:
- ループが機械的で長い: インベントリ → 検査 → 分類 → 修正 → 送信 → 検証。毎週繰り返します。
- 監査証跡が必要: どの URL をいつ、なぜ送信したかを示すファイルが必要です。
- 承認ゲートが必要: Google に書き込む部分は人間がレビューすべきです。Hermes はスキル、プロジェクトフォルダ、承認ルールを備え、この分離を中心に設計されています。
始める前に必要なもの
- Hermes Agent がインストールされていること。先に進む前に
hermes chatで確認します。 - 所有する GSC プロパティ。
sc-domain:example.com形式で指定します(フル URL ではありません)。 - 読み取りアクセス: Search Console API 用の Google Cloud OAuth クライアント(クライアント ID + シークレット)。GSC スキルのスクリプトがこれを使ってサイトマップの一覧、サーチアナリティクス、URL 検査を行います。
- 書き込みアクセス: Indexing API を有効にした Google Cloud プロジェクトとサービスアカウントの JSON キー。サービスアカウントのメールアドレスを GSC → 設定 → ユーザーと権限でオーナーとして追加します。送信で 403 が返る場合、このステップが漏れています。
- Python 3 と
pip install google-auth google-api-python-client。 - プロジェクトフォルダ。例:
/hermes-seo-projectにcontext/、data/、qa/を置き、送信ステップは常に人間の承認を要すると定めたapproval-rules.mdを作成します。
ステップ 1: URL インベントリを構築する
2 つの GSC スキルを Hermes のスキルディレクトリ(~/.hermes/skills)にコピーします: 読み取りスキル(サイトマップ、サーチアナリティクス、URL 検査)とインデックススキル(送信スクリプト)。ハーネスがスキルをカタログ化していれば、skill_view で読み込むこともできます。
プロジェクトフォルダからチャットセッションで Hermes に依頼します:
sc-domain:example.com の全サイトマップを一覧し、すべての URL を lastmod 付きで取得して data/url-inventory.csv に書き出してください。取得に失敗したサイトマップにはフラグを立ててください。
Hermes はターミナルツールでサイトマップコマンドを実行し、CSV を書き出します。良い出力の目安: URL、lastmod、取得元サイトマップが重複なく入った CSV。品質チェック: 5 行をスポットチェックし、総数を GSC のサイトマップレポートと突き合わせます。リストが空か認証に失敗した場合は、GSC の認証フローをやり直してください。読み取りスクリプトには新しい OAuth トークンが必要です。
ステップ 2: 検査して分類する
次に、エージェントは URL Inspection API でインベントリをバッチ検査し、各ページの現在のカバレッジ状態を取得します。次の段階を依頼します:
data/url-inventory.csv のすべての URL を検査してください。3 つのファイルに分類してください: data/to-submit.txt(未インデックスで送信に値するもの)、data/skip.txt(URL ごとに 1 行の理由付き)、data/needs-fix.txt(未インデックスで、変更すれば解決できるもの)。
検査 API はプロパティごとにレート制限があります(現在の割り当て量は Google Cloud Console で確認してください。1 日数千リクエストですが無制限ではありません)。大規模サイトでは、このパスを lastmod が新しい URL、つまり今四半期に実際に変更した URL に絞り込みます。品質チェック: スキップリストをサンプリングします。大半は noindex、別 URL を指す canonical、重複ページであり、気になるページではないはずです。数千 URL のサイトで needs-fix が空になった場合、インベントリの段階でページを取りこぼしている可能性があります。入力を広げてください。
ステップ 3: 送信前にトリアージする
ここが省略されがちなステップです。詰まった URL を原因と修正にマッピングします。この順序で:
原因 | 修正 | 修正後に送信するか |
|---|---|---|
内部リンクが 1 本もない | 関連するインデックス済みページから文脈のあるリンクを追加 | はい |
新しいサイトまたは新しいページ | 修正不要。一度送信して 1–2 週間待つ | はい、一度だけ |
robots.txt でブロック | パスをブロック解除 | はい |
クロール済みだが重複または薄い | 書き直す、統合する、または削除 | 実際にコンテンツを変えた場合のみ |
canonical が別 URL を指している | 間違いなら canonical を修正。意図的ならこの URL の送信をやめる | 修正した場合のみ |
クロール時に noindex | noindex を外して再クロールさせる | 外した後、はい |
ソフト 404、価値のないパンくず・アーカイブ | ページを修正するか削除 | いいえ — 恒久的にスキップ |
Hermes に修正キューを表でドラフトさせます: URL、推定原因、証拠(検査結果またはコンテンツ確認)、提案アクション、リスクレベル。各行をチャットで承認します。approval-rules.md にこれを必須と定めます: エージェントは準備し、あなたは承認し、低リスクを超えるものは承認なしに送信しない。
承認ゲートがエージェントの準備作業と書き込みステップを分離する。
修正自体は通常の SEO 作業です: コンテンツの書き直し、canonical の整理、内部リンク。このパイプラインが担当するのは送信の半分です。修正の半分は Hermes シリーズの監査・リフレッシュ記事が担当します。
送信リストは「修正可能」と「インデックスに値する」の交差部分。
ステップ 4: Indexing API で送信する
キューが承認されたら、URL を data/approved-urls.txt に入れて Hermes にインデックススキルを実行させます:
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txtデフォルトの通知タイプは URL_UPDATED で、新規・変更ページに使うものです。覚えるべき数字は 3 つ: デフォルト割り当ては1 日 200 URL、1 分あたり 600 リクエスト、そして 403 はサービスアカウントがプロパティのオーナーでないことを意味します。承認リストが 200 を超える場合は日を分けて送信します。残りのバッチは Hermes にスケジュールさせられます。
すでにインデックスされているページやスキップリストは送信しないでください。無駄な通知は割り当て量とノイズを消費するだけです。
ステップ 5: 検証して待つ
送信直後の status は、Google が通知のメタデータを持っているかどうかだけを示し、ページがインデックスされたかどうかは示しません。本当の確認は数日後です。
バッチの 3–7 日後に Hermes に依頼します:
data/approved-urls.txt の URL をもう一度検査し、前回の実行と比べてステータスがどう変わったか報告してください。
健全な推移は discovered → crawled → indexed です。数週間の間にそれがどう見えるか: 未インデックスリストが縮小し、実際に行った修正(新しい内部リンク、書き直したコピー)がインデックスに現れます。GSC のデータは数日遅れること、Google は独自のスケジュールで再クロールすることを忘れないでください。本物の修正の後に 10–14 日「Crawled – currently not indexed」のままの URL は品質シグナルであり、送信の問題ではありません。コンテンツ作業にエスカレーションしてください。
ループを回し続ける
パイプラインを週次のルーチンにします: 前回以降の新規・更新 URL → 検査 → 分類 → トリアージ → 承認 → 送信 → ログ。Hermes は読み取り専用の部分(インベントリ、検査、分類)をスケジュールで無人実行し、毎週月曜にキューを提示できます。送信ステップは承認ゲートの内側に保ち、qa/indexing-log.md に継続ログを残します: 送信日、URL、通知タイプ、結果。6 か月分のログだけが、パイプラインが機能しているかを正直に測る方法です。
正直な限界
- Google は Indexing API を
JobPostingまたはBroadcastEventの構造化データを持つページ向けに文書化しています。通常ページへの利用は広く行われている SEO 手法ですが、Google はすべてのページタイプについてインデックスやサポートを保証していません。 - 「インデックス登録をリクエスト」ボタンには公開 API がありません。Indexing API は最も近い自動化であって、同じボタンではありません。
- 送信は優先度を作りません。修正し、送信し、待っても未インデックスのままのページへの次の答えは、コンテンツ品質であって、もう一度の通知ではありません。
FAQ
Indexing API は通常のページでも使えますか?どんな URL でも受け付けます。Google の公式ドキュメントは JobPosting と BroadcastEvent のページを対象としているため、通常ページへの送信はベストエフォートとして扱ってください: 役に立つ、広く行われている、しかし決して保証されません。
送信したのに「Discovered – currently not indexed」のままなのはなぜ?そのステータスは通常、失敗ではなくクロール優先度を意味します。ページへの内部リンク、robots.txt によるパスのブロック、JavaScript 主体のページかどうかを確認してください。そして待ちます。新設サイトでは発見からクロールまで 1–2 週間かかることがあります。
1 日 200 URL で足りますか?ほとんどのサイトでは足ります。実際に変更した URL だけを送信すべきだからです。それ以上が常にあるなら、ビジネス価値で優先順位を付け、Google Cloud Console で割り当て量の増加を申請します。
Indexing API でランキングが速くなりますか?いいえ。URL が変わったことを Google に通知するだけです。ランキングの判断は別物であり、通知の回数ではなく Google のシステムが下します。
Search Console の「インデックス登録をリクエスト」と何が違いますか?意図は同じ、仕組みが違います。ボタンは公開 API のない UI のみ。Indexing API はスクリプト化できるチャネルです。どちらも、ページがインデックスに属するかについての Google の判断を上書きできません。
著者: Julian Mercer、Auspia のテクニカル SEO 実務歴 14 年。クローラビリティ、インデックス、スキーマ、そして Google と AI システムの両方がサイトを正しく読めるようにする技術基盤について執筆。
