IndexNowにGoogleは参加していない──418URL送ってもGoogleには渡らない仕組みと、鍵が無効なときに返る403 UserForbiddedToAccessSite

IndexNowでURLを送っても、Googleの検索結果は動かない。IndexNowの参加検索エンジンにGoogleが入っていないからである。2026年8月14日に公式サイトを取得して確認したところ、トップページが挙げているのは Microsoft Bing・Naver・Seznam.cz・Yandex・Yep で、FAQのエンドポイント一覧に載っているのもこの5社＋Amazon＋共通エンドポイントの計7本だった。Googleへの経路はサイトマップとURL検査ツール（と、求人・ライブ配信ページ限定のIndexing API）のままである。あわせて実測で2つの罠を踏んだ。①共通エンドポイントに素のGETを投げるとHTTP 400が返り、Bingは解説ページの200、Yandexは302を返すので、素のGETは疎通確認に使えない。②鍵ファイルを置いていない偽の鍵に、共通エンドポイントが一度だけHTTP 202を返した——公式ドキュメントが202を「IndexNow key validation pending（鍵の検証は保留中）」と定義している通りで、202は「鍵が通った」証拠にならない。同じ鍵を32分後に投げ直すと403に変わった。

• IndexNow公式トップの原文は「has support from Microsoft Bing, Naver, Seznam.cz, Yandex, Yep.」。Googleの記載は無い。FAQのエンドポイント一覧（global／Amazon／Bing／Naver／Seznam.cz／Yandex／Yep の7本）にも無く、Bing公式の解説ページ www.bing.com/indexnow（22,592バイト）には "Google" という文字列が1度も出てこない（大文字小文字を無視したgrepで0件）【2026-08-14 16:06〜16:08 JSTに自分で取得して確認】
• 鍵ファイルを置いていない64桁の偽の鍵で同じ記事URLを送ると、api.indexnow.org/indexnow も www.bing.com/indexnow も HTTP 403・160バイト（UserForbiddedToAccessSite）を返した。同じURLを本物の鍵で投げ直すと、どちらも HTTP 200・0バイトだった【2026-08-14 16:41:55／16:41:57／16:42:00／16:42:57 JSTの実測・各1回】
• ただし、その偽の鍵をはじめて共通エンドポイントへ投げた16:09:23だけは HTTP 202・0バイトが返っていた。32分後の再測では同じ鍵・同じURLで403に変わっている。202は鍵の有効性を保証しない【当サイトの記録・各1回。切り替わりの条件は切り分けていない】
• パラメータ無しの GET https://api.indexnow.org/indexnow は HTTP 400・136バイトで、本文は {"errorCode":"InvalidRequestParameters","message":"Invalid request","details":[{"target":"url","message":"The url field is required."}]}。url だけ付けて key を落とすとHTTP 400・94バイトで The key field is required. に変わる【2026-08-14 16:06:37／16:08:42 JSTの実測】

症状1：エンドポイントにブラウザやcurlで素アクセスすると400が返る

「まずエンドポイントが生きているか確かめよう」と思ってパラメータ無しで叩くと、こうなる。macOS 15.1.1（Darwin 24.1.0）・curl 8.7.1・2026年8月14日16時06分37秒（日本時間）の実行結果である。

$ curl -s -o /dev/null -w "HTTP %{http_code} size=%{size_download}\n" https://api.indexnow.org/indexnow
HTTP 400 size=136

本文はJSONで、そのまま貼れば検索できる。

{"errorCode":"InvalidRequestParameters","message":"Invalid request","details":[{"target":"url","message":"The url field is required."}]}

url パラメータだけ付けて key を落とすと、同じ400でも本文が変わる（16時08分42秒の実測・94バイト）。

{"errorCode":"InvalidRequestParameters","message":"The key field is required.","details":null}

パスの大文字小文字は、少なくともこの素のGETについては結果が変わらなかった。https://api.indexnow.org/indexnow（公式ドキュメント表記）と https://api.indexnow.org/IndexNow（当サイトのスクリプトが使っている表記）の両方に同じ秒で投げて、どちらもHTTP 400・136バイト・同一本文だった。POSTでも同じかは試していない。

他社エンドポイントは、素のGETに対してもっと紛らわしい返し方をする。

Bingのエンドポイントは、素で開くと HTTP 200 で解説ページのHTMLを返す。ステータスコードだけを見て「疎通OK」と判定するスクリプトを書くと、ここで通ってしまう。Yandexは解説ページへの302である。どのエンドポイントも「素のGETの200/302」は送信成功を意味しない。

症状2：鍵ファイルの無い偽の鍵に202が返り、32分後には403に変わった

これが一番厄介だった。当サイトの実在する記事URL1本に対して、鍵ファイルをどこにも置いていない64桁ゼロの偽の鍵を付けて共通エンドポイントへ送ると、1回目はこうなった。

$ curl -s -o /dev/null -w "HTTP %{http_code} size=%{size_download}\n" \
  "https://api.indexnow.org/indexnow?url=https%3A%2F%2Fwww.ai-jitan-hub.com%2Fnews%2Fai-glossary&key=0000000000000000000000000000000000000000000000000000000000000000"
HTTP 202 size=0

2026年8月14日16時09分23秒（日本時間）。HTTP 202、本文0バイト。 この応答だけを見ても、鍵が存在しないことは分からない。

19秒後の16時09分42秒に、まったく同じURL・まったく同じ偽の鍵をBingのエンドポイントへ投げると、今度は落ちた。

$ curl -s -o /tmp/r.txt -w "HTTP %{http_code} size=%{size_download}\n" \
  "https://www.bing.com/indexnow?url=https%3A%2F%2Fwww.ai-jitan-hub.com%2Fnews%2Fai-glossary&key=0000000000000000000000000000000000000000000000000000000000000000"
HTTP 403 size=160

{"errorCode":"UserForbiddedToAccessSite","message":"User is unauthorized to access the site. Please verify the site using the key and try again","details":null}

UserForbiddedToAccessSite は、綴りも含めてこの通りに返ってくる（Forbidden ではなく Forbidded）。日本語で検索しても情報が出てこないので、この文字列をそのまま貼って探す人のために原文を置いておく。

32分後に測り直したら、共通エンドポイントも403に変わっていた

公開前に数字を測り直したときに、上の理解が引っくり返った。同じURL・同じ偽の鍵を同日16時41分55秒に共通エンドポイントへ投げると、202ではなく403が返った。 本文はBingが返したものと同じ160バイトの UserForbiddedToAccessSite だった。

本物の鍵を使った3本は、鍵を画面やシェル履歴に残さないため、curlではなくPythonの urllib からファイル経由で鍵を読んで実行している。

つまり、「共通エンドポイントは偽の鍵でも202を返す」という一般則は、当サイトの実測では成り立たなかった。共通エンドポイントも、鍵が無効なら403、有効なら200を返す。202が返ったのは、その鍵ではじめて送信した1回だけである。16時41分55秒の403と16時42分57秒の200は62秒差で、違いは鍵だけである。

これは公式ドキュメントの定義とそのまま重なる。202は URL received. IndexNow key validation pending.、つまりまだ鍵を見ていないという意味であって、鍵が通った合図ではない。FAQも「最初のリクエストでは202が返ることがある」と書いている。実務上の含意は3つになる。

• 202を「送信成功」として扱わない。 初回の202だけを見て「鍵OK」と判定するスクリプトを書くと、鍵ファイルを置き忘れていても通ってしまう
• 鍵の生死は403と200で判定する。 共通エンドポイントでもBingでも、検証が済んだ後は無効な鍵に403、有効な鍵に200が返った
• 202から403へ切り替わる条件は特定できていない。 時間の経過なのか、検証処理の完了なのか、同じ鍵をBingへ投げたことが引き金なのかを、当サイトは切り分けていない。観測は各1回である

原因1：参加リストにGoogleが無い

IndexNow公式トップページ（2026年8月14日16時06分に取得・HTTP 200・15,393バイト）の原文はこうである。

IndexNow is offered under the terms of the Attribution-ShareAlike Creative Commons License and has support from Microsoft Bing, Naver, Seznam.cz, Yandex, Yep.

（IndexNowは Attribution-ShareAlike クリエイティブ・コモンズ・ライセンスの条件で提供され、Microsoft Bing、Naver、Seznam.cz、Yandex、Yep のサポートを受けている）

同じ日に取得したFAQページ（HTTP 200・55,943バイト）の「How Do I Submit a URL Using IndexNow?」の節には、投げ先の一覧が並んでいる。

You may submit your request to only one of the following participating endpoints. Each endpoint sends your submission directly to its respective search engine, and your submission will be shared across all IndexNow-enabled search engines:

（以下の参加エンドポイントのうち1つにだけリクエストを送ればよい。各エンドポイントは送信をそれぞれの検索エンジンへ直接届け、あなたの送信はIndexNow対応の全検索エンジンで共有される）

一覧に載っているのは次の7本で、Googleは無い。

トップページの列挙（5社）とFAQのエンドポイント一覧（Amazonを含む6社＋共通1本）は一致していない。Amazonはトップページの「support from」の文には出てこないが、FAQのエンドポイント一覧には載っている。 どちらにもGoogleは無い、というのが両ページを突き合わせて言えることである。

Bing側の解説ページ https://www.bing.com/indexnow（同日16時07分に取得・HTTP 200・22,592バイト・タイトル「Why IndexNow | Bing Webmaster Tools」）を全文grepしたところ、"Google" という文字列の出現回数は 0回だった。

Google側の公式手段は、いま何があるか

Google Search Centralの「Ask Google to recrawl your URLs」（最終更新2025年12月10日UTC・2026年8月14日16時07分に取得）が挙げている方法は2つだけである。

Use the URL Inspection tool (just a few URLs)

Submit a sitemap (many URLs at once)

（URL検査ツールを使う〈URLが数本のとき〉／サイトマップを送信する〈大量のURLを一度に〉）

同ページは冒頭で「Crawling can take anywhere from a few days to a few weeks.（クロールには数日から数週間かかることがある）」「Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all.（クロールをリクエストしても、検索結果への掲載が即座に起きる保証も、そもそも起きる保証もない）」とも書いている。

Googleにも直接pingするAPIはあるが、用途が限定されている。Indexing API Quickstart（最終更新2026年7月16日UTC・同日16時07分に取得）はこう定義する。

The Indexing API allows site owners to directly notify Google when their job posting or livestreaming video pages are added or removed. (中略) The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.

（Indexing APIは、求人ページやライブ配信動画ページが追加・削除されたときにサイト所有者がGoogleへ直接通知できるようにするものである。〈中略〉Indexing APIは JobPosting または VideoObject に埋め込まれた BroadcastEvent を持つページのクロールにしか使えない）

つまりニュース記事や解説記事をGoogleへ直接pingする手段は、2026年8月14日時点の公式ドキュメント上には無い。当サイトのような記事サイトにとって、Google側の経路はサイトマップ＋内部リンク＋URL検査ツールのままである。

原因2：202は「受け取った」以上のことを言っていない

IndexNow公式ドキュメント（同日16時06分に取得・HTTP 200・28,555バイト）のレスポンス表は次のようになっている。

202の説明は「URL received. IndexNow key validation pending.（URLを受け取った。IndexNowの鍵の検証は保留中）」である。鍵の検証はまだ済んでいない、と明記されている。FAQ側も同じことを別の言い方で書く。

Note: For your first request, you may receive an HTTP 202 response. This means the URL was received, and the search engine will verify your key before indexing the content. Once verification is complete, subsequent successful submissions will typically return HTTP 200.

（注：最初のリクエストではHTTP 202が返ることがある。これはURLが受け取られ、検索エンジンがコンテンツをインデックスする前にあなたの鍵を検証する、という意味である。検証が完了すると、その後の成功した送信は通常HTTP 200を返す）

ドキュメントは200についても、期待を下げる書き方をしている。

A successful request will return an HTTP 200 response code; if you receive a different response, verify that you don’t submit too often, that the key and URL are valid and resubmit the request. The HTTP 200 response code only indicates that the search engine has received your URL.

（成功したリクエストはHTTP 200を返す。異なる応答が返った場合は、送信頻度が高すぎないか、鍵とURLが有効かを確認して再送すること。HTTP 200というレスポンスコードは、検索エンジンがあなたのURLを受け取ったことを示すだけである）

この表と当サイトの実測は、食い違ってはいない。 鍵が無効なときの403は、共通エンドポイントでもBingでも再現した。一方で、同じ偽の鍵をはじめて共通エンドポイントへ投げたときだけ202が返ったのも、表が202を「validation pending」と定義している通りである。食い違うのは、202を見て「送信が通った」と読んでしまう側の期待のほうである。ただし、いつ202から403へ切り替わるのかは公式に書かれておらず、当サイトも切り分けていない。

原因3：鍵ファイルが本番で引けないと、全URLが弾かれる

IndexNowの所有権確認は、鍵と同じ名前のテキストファイルをホスト上に置くことで行う。ドキュメントの原文はこうである。

To submit URLs, you must "prove" ownership of the host for which URLs are being submitted by hosting at least one text file within the host. Once you submit your URLs to search engines, search engines will crawl the key file to verify ownership and use the key until you change the key. Only you and the search engines should know the key and your file key location.

（URLを送信するには、送信対象ホスト内に少なくとも1つのテキストファイルを置くことで、そのホストの所有権を「証明」しなければならない。URLを検索エンジンへ送信すると、検索エンジンは鍵ファイルをクロールして所有権を検証し、鍵を変更するまでその鍵を使い続ける。鍵と鍵ファイルの場所は、あなたと検索エンジンだけが知っているべきである）

最後の一文が効いている。鍵ファイルは公開ホスト上に置くものだが、公式は「あなたと検索エンジンだけが知っているべき」と書いている。 そのため本記事では当サイトの鍵を伏せ字で書く。

当サイトの鍵ファイルは https://www.ai-jitan-hub.com/5eb8cf03…0411bc.txt（64文字の16進＋.txt）にあり、2026年8月14日16時07分に取得したところ HTTP 200・65バイト・text/plain; charset=utf-8 で、中身は鍵と完全一致していた（64文字＋改行1バイトで65バイト）。

鍵ファイルが引けないと何が起きるかは、ドキュメントの表とFAQが両方書いている。ドキュメントの403は「key not found, file found but key not in the file（鍵が見つからない、またはファイルはあるが中に鍵が入っていない）」、FAQの422の節は「The IndexNow key file is missing or inaccessible.（IndexNowの鍵ファイルが無い、またはアクセスできない）」を原因に挙げる。送信するURLの本数とは無関係に、鍵で落ちれば全部落ちる。

当サイトの送信スクリプト（scripts/indexnow_submit.py）は、この事故を避けるために送信前に本番の鍵ファイルを取りに行き、中身が鍵と一致しなければそこで止める設計にしてある。

# 鍵ファイルが本番で引けるかを先に確認する。引けないと全件弾かれる
try:
    with urllib.request.urlopen(f"{BASE}/{key}.txt", timeout=20) as r:
        if r.read().decode().strip() != key:
            sys.exit("鍵ファイルの中身が鍵と一致しない")
    print(f"鍵ファイル確認OK: {BASE}/{key[:8]}….txt")
except Exception as e:
    sys.exit(f"鍵ファイルが本番で引けない（デプロイ済みか確認）: {e}")

ここで注意点が1つある。このスクリプトの鍵バリデーションは re.fullmatch(r"[a-f0-9]{8,128}", key)、つまり小文字16進のみを通す実装になっている。これは仕様より狭い。 公式ドキュメントは「Your-key should have a minimum of 8 and a maximum of 128 hexadecimal characters. The key can contain only the following characters: lowercase characters (a-z), uppercase characters (A-Z), numbers (0-9), and dashes (-).（鍵は最小8文字・最大128文字の16進文字であるべきである。鍵には次の文字だけを含められる：小文字〈a-z〉、大文字〈A-Z〉、数字〈0-9〉、ハイフン〈-〉）」と書いており、「hexadecimal」と言いながら16進に無い文字を許可している。FAQ側は同じ内容から「hexadecimal」を落として「Your key must be 8 to 128 characters long. Allowed characters: lowercase (a to z), uppercase (A to Z), numbers (0 to 9), and hyphens (-).」と書いている。公式ドキュメント内で表現が揃っていないので、I-love-IndexNow-3000 のようなハイフン入りの鍵を使う場合、上記の正規表現では弾かれる。

対処

1. Googleへの期待をIndexNowから外す。 参加リストにGoogleが無い以上、IndexNowの送信本数を増やしてもGoogle側の露出には効かない。Google向けはサイトマップ・内部リンク・URL検査ツールが公式の手段である
2. 疎通確認に素のGETを使わない。 共通エンドポイントは400、Bingは解説ページの200、Yandexは解説ページへの302を返す。どれも「送信が通る」ことの証拠にならない
3. 202を「成功」として扱わない。 202の公式の定義は「鍵の検証は保留中」で、当サイトでは鍵ファイルの無い偽の鍵に202が返った。鍵の生死は403（UserForbiddedToAccessSite）と200で判定する。共通エンドポイントもBingも、検証が済んだ後はこの2つで返し分けた
4. 送信の前に、本番の鍵ファイルをHTTPで取りに行く。 200が返り、中身が鍵と完全一致することを確認してから送る。ここで落ちれば全URLが弾かれる
5. 鍵の文字種を仕様に合わせる。 16進だけを通すバリデーションを書くと、仕様上有効なハイフン入りの鍵で自分のスクリプトが止まる
6. 全URLの一括送信は、原則やらない。 FAQは「It is not designed for submitting every URL on your site at once.（サイトの全URLを一度に送るための設計ではない）」「Should I submit URLs that changed before I started using IndexNow? / No.（IndexNowを導入する前に変更したURLを送るべきか？ 送るべきでない）」と明記している。ただし「If your entire site has been recently updated, such as after a migration or redesign, it is acceptable to submit all URLs using IndexNow.（サイト移転やリニューアルの直後など、サイト全体が最近更新された場合は全URL送信も許容される）」という例外も併記されている

観測条件（2026年8月14日・当サイト1件）

当サイトはNext.js＋Vercelで運用している記事サイトで、2026年8月14日16時07分（日本時間）に本番のサイトマップを取得すると <loc> は 424件（うち /news/ 配下は357件）だった。実測はすべて同日16時06分〜16時43分（日本時間）、macOS 15.1.1（Darwin 24.1.0）、curl 8.7.1およびPython 3の urllib、日本国内の一般回線からの実行である。16時41分以降の4本は、公開前に数字を測り直したときのものである。

偽の鍵による送信は、共通エンドポイントとBingへ各2回ずつ、同一URL（当サイトの公開済み記事1本）に対してのみ行った。鍵ファイルを置いていない鍵なので、検証時に破棄される想定である。なお400系の3本（パラメータ無し・大文字小文字違い・key無し）と、上に挙げた各ページの取得（indexnow.org の3ページ、www.bing.com/indexnow、Google Search Centralの3ページ、当サイトのサイトマップと鍵ファイル）は、公開前に測り直しても同じコード・同じバイト数・同じ本文だった。

正直な但し書き

「418URL」は当サイトの記録から引いた数字で、送信レスポンスのログは残っていない。 リポジトリ内の scripts/bing_coverage.py の冒頭に、2026年8月14日付で「IndexNow で418URLを送っているが、Bing側に入った形跡が無い」と書き残してある。ただしIndexNow送信そのものの応答をファイルに保存する実装になっておらず、data/bing/ に残っているのはBing Webmaster APIでの一括送信記録（submitted-2026-08-14.json・100URL・HTTP 200）だけである。418という数字の裏付けは当サイトの記録のみで、本記事の執筆時に再現・再測はしていない。 同日16時07分にサイトマップを取り直すと424件だったので、送信時点と現在で母数も動いている。

「Bing側に入った形跡が無い」「タイトル完全一致で10本中0本」も、同じ記録に依拠している。 これは検索結果を目視・スクレイピングで確認したときのメモであり、生ログは残っていない。Bing Webmaster APIによる全数確認（scripts/bing_coverage.py）は2026年8月14日時点でまだ実行できておらず、data/bing/coverage-*.json は存在しない。したがって本記事は「IndexNowで送ったのにBingに入らない」ことを立証していない。 立証できているのは、参加リストにGoogleが無いことと、上の表に並べた実測だけである。

「IndexNowで送ってもGoogleには渡らない」は、公開された参加リストとプロトコルの記述から導いた推論である。 IndexNowの仕様は「your submission will be shared across all IndexNow-enabled search engines（あなたの送信はIndexNow対応の全検索エンジンで共有される）」と書いており、その「対応検索エンジン」にGoogleが載っていない。Googleの内部で何が起きているかを当サイトが観測したわけではない。Googleが将来参加する可能性、あるいは非公表で受け取っている可能性を否定する材料は持っていない。

偽の鍵で202が返ったのは共通エンドポイントに対する1回だけの観測で、32分後の再測では再現しなかった（403）。 同じ鍵を1度目と2度目に投げた結果が違う、という2点の記録があるだけで、何が切り替えたのかは切り分けていない。鍵の値・URL・時間帯を変えた追試もしていないので、本記事は「初回は必ず202が返る」ことを立証していない。立証できているのは、鍵が無効なら403・有効なら200が返ることを共通エンドポイントとBingの両方で確認した、という一点である（無効と有効を2秒差・62秒差で取得している）。

日本語版の公式ページとは突き合わせていない。 indexnow.org には日本語表示があるが、本記事の引用はすべて英語版（既定表示）の原文で、訳は当サイトで付けた。訳の責任は当サイトにある。

Amazonが「参加検索エンジン」に当たるかは判断していない。 FAQのエンドポイント一覧には indexnow.amazonbot.amazon が載っているが、トップページの「has support from」の列挙には含まれていない。当サイトはこの差の理由を確認できていないので、両方の記述をそのまま並べるにとどめる。

出典

• IndexNow - Home（2026年8月14日16:06 JST取得・HTTP 200・15,393バイト）: https://www.indexnow.org/
• IndexNow - FAQ（2026年8月14日16:06 JST取得・HTTP 200・55,943バイト）: https://www.indexnow.org/faq
• IndexNow - Documentation（2026年8月14日16:06 JST取得・HTTP 200・28,555バイト）: https://www.indexnow.org/documentation
• Why IndexNow | Bing Webmaster Tools（2026年8月14日16:07 JST取得・HTTP 200・22,592バイト）: https://www.bing.com/indexnow
• Ask Google to Recrawl Your Website | Google Search Central（最終更新2025年12月10日UTC・2026年8月14日16:07 JST取得）: https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl
• Indexing API Quickstart | Google Search Central（最終更新2026年7月16日UTC・2026年8月14日16:07 JST取得）: https://developers.google.com/search/apis/indexing-api/v3/quickstart
• Build and Submit a Sitemap | Google Search Central（最終更新2026年7月8日UTC・2026年8月14日16:08 JST取得。全文grepで "indexnow" の出現は0回）: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
• AI時短ラボ 実測ログ: scripts/indexnow_submit.py／scripts/bing_coverage.py／data/bing/submitted-2026-08-14.json（いずれも2026年8月14日時点のリポジトリ内ファイル）