IndexNow が 403 UserForbiddedToAccessSite になる原因と直し方｜キーファイルは正しいのに拒否されるとき

（更新: 2026年7月21日 ） SEO IndexNow Bing ドメイン移行 Cloudflare 2026
結論

キーファイルが公開できていても、Bing が host + key を拒否登録していると 403 UserForbiddedToAccessSite が続く。見直すのはファイルではなく キーそのもの。新キーにローテしてデプロイし、検証完了後に sitemap 全件を送り直す。

この記事で扱う症状

ビルド後に IndexNow へ sitemap を POST すると、次のようなレスポンスになるケースです。

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

一方で、キーファイル自体は問題なく見えます。

curl -sI "https://example.com/<your-key>.txt"
# HTTP/1.1 200 OK
# Content-Type: text/plain; charset=utf-8

curl -s "https://example.com/<your-key>.txt"
# <your-key> と完全一致（余分な改行や BOM がないこと）

公式ドキュメントの 403 説明は「キーが見つからない / ファイル内のキーが一致しない」が中心です。今回の UserForbiddedToAccessSite は それとは別レイヤー（Bing 側のサイト所有権バインディング）と考えた方が早いです。

まず切り分ける（5分）

キーファイルを何度も眺め直す前に、次の対比だけ取ります。

POST する key api.indexnow.org の典型結果
ファイルと一致する正しいキー 403 UserForbiddedToAccessSite → 拒否キャッシュの疑い大
わざと違うキー（keyLocation は正しいファイル） 202 Accepted → ファイルは読める。問題は『このキー』側

正しいキーだけが 403 で、違うキーが 202 になるなら、ファイル破損でも Bot Fight 単体でもなく、そのキーがホストに対して拒否されている可能性が高いです。

当サイト（kawagame.com）でも、ドメイン移行後にこのパターンを実測しました。キー本文は 32 bytes で完全一致、Bingbot UA でも 200、Cloudflare Bot Fight Mode をオフにしても同じ 403、という状態でした。

Cloudflare Crawler Hints が動いていても安心できない

Bing Webmaster Tools の IndexNow Insights で「Cloudflare 経由の提出がある」ことがあります。ただし中身が次のようなアセットばかり、ということもあります。

  • robots.txt
  • fonts/*.woff2
  • icons/*.webp

これはエッジの更新検知による CDN 提携経路で、リポジトリに置いた IndexNow キーとは別物です。「Insights に数字がある＝自前の npm run indexnow も通る」ではありません。

HTML やツールページをビルドのたびにまとめて通知したいなら、自前キー API（または同等のバッチ送信）が必要です。

なぜ拒否されるのか（実務上の見立て）

Bing 側の内部ログは見えませんが、次の流れと整合します。

  1. 新ドメイン公開直後などに、キー検証クロールが走る
  2. その時点で検証が失敗／拒否扱いになる（Bot 対策、未整備なホスト、検証方法の不整合などが候補）
  3. Bing が host + key を UserForbiddedToAccessSite として覚える
  4. 以降、キーファイルを直しても同じキーでは通らない

Microsoft Q&A でも、キーファイルが公開できているのに同エラーになり、Bing Webmaster の検証方法をやり直して直った報告があります。ポイントは「キー文字列が正しいか」より サイトとキーの紐付けが Bing に通っているかです。

直し方（本筋）

キーローテ手順

1

新しいキーを発行する（8〜128 文字、英数字とハイフン）

2

サイトルートに {key}.txt を置き、本文はキーのみ（BOM・余分な改行なし）

3

本番へデプロイし、https://your-domain/{key}.txt が 200 で一致することを確認

4

少数 URL で POST する。SiteVerificationNotCompleted なら検証完了まで待つ

5

sitemap 全 URL を再送信し、200 または 202 を確認する

ローテ直後に出る別エラー

{
  "errorCode": "SiteVerificationNotCompleted",
  "message": "Site Verification is not completed. Please wait..."
}

これは拒否固定ではありません。新キーの所有権確認中です。数分待ってから全件送信すれば通ることが多いです。スクリプト側でポーリングするのが安全です。

やってはいけないこと

  • 重要 URL だけ送るように変えて終わりにする（原因を残したまま利点を捨てる）
  • 拒否されたキーを変えずにリトライし続ける
  • 「キーファイルの中身は合っている」だけで調査終了する
  • Cloudflare Insights の件数だけで自前送信の成功を断定する

ドメイン移行時のチェックリスト

pages.dev から独自ドメインへ移した直後は、特に壊れやすいです。

  1. canonical / sitemap / robots のホストが新ドメインになっている
  2. 旧ホスト → 新ホストの 301 がパス保持で動いている
  3. Google Search Console のアドレス変更とは別に、Bing / IndexNow のキー検証も見る
  4. npm run indexnow（または同等）が 200/202 になるまで移行完了にしない
  5. キー変更は Git に含めてデプロイする（直アップロードだけだと次の CI で消える）

Bing Webmaster のサイト検証は、可能なら XML や meta も用意しておくと安心です。Google Search Console からのインポートだけに依存すると、IndexNow のバインディングが不完全になる報告があります。

まとめ

症状意味打ち手
キー 404 / 中身不一致普通の設定ミスファイルを直す
正しいキーだけ UserForbiddedToAccessSiteBing がキーを拒否キーローテ
SiteVerificationNotCompleted検証中待つ / ポーリング
CF Insights だけ動く別経路自前送信は別問題として直す

IndexNow は「キーを置けば終わり」ではなく、検索エンジン側の所有権バインディングが通って初めて全件通知が効く仕組みです。403 のエラーコードを見て、ファイル修正ループに入らないことが最短です。

関連