先に要点
SEO まわりで IndexNow って入れた方がいいの？ と聞かれることがあります。
名前だけ見ると大げさですが、やっていることはかなりシンプルです。
ページを公開した、更新した、削除した、リダイレクトした。
そのタイミングで検索エンジンへ この URL が変わったよ と通知する仕組みです。
この記事では、2026年4月16日時点で IndexNow.org の公式ドキュメント、FAQ、Bing Webmaster Tools の案内を確認したうえで、IndexNow の意味、何がうれしいのか、XML サイトマップとの違い、どこまで期待してよいのかを整理します。
IndexNowとは何か
IndexNow は、検索エンジンに対して URL の追加・更新・削除を早めに知らせるためのプロトコルです。
公式ドキュメントでは、URL を GET または POST で送信でき、受け取った検索エンジンはその URL を他の参加検索エンジンとも共有すると説明されています。
かなりざっくり言うと、クローラーが気づくのを待つ のではなく、こっちから変更を知らせる 仕組みです。
特に、更新頻度が高いサイトや、公開直後に検索エンジンへ変更を伝えたいサイトと相性がよいです。
何がうれしいのか
IndexNow のうれしさは、検索エンジンに 変更が起きたページ を絞って伝えやすいことです。
これによって、全部のページを毎回見に来てもらうより、更新対象にクロールが寄りやすくなります。
主なメリットはこのあたりです。
| うれしい点 | 実務で効く場面 |
|---|---|
| 更新 URL をすぐ通知できる | 記事公開、商品追加、削除、リダイレクト変更 |
| 不要な待ち時間を減らしやすい | ニュース、在庫変動、更新頻度が高いページ |
| 変更対象に絞って送れる | 全ページ再クロールより効率がよい |
| 参加検索エンジンへ共有される | 複数の検索エンジンへ個別送信しなくてよい |
特に、新着記事を出したらすぐ検索エンジンへ知らせたい、削除した URL を早めに整理したい という運用では意味があります。
毎回クローラーが自然に来るのを待つより、少なくとも 変わった ことは明示できます。
ただし、送れば必ずインデックスされるわけではない
ここはかなり大事です。
Bing の公式案内でも、IndexNow を使うことは 検索エンジンが変更を認識しやすくなる ためのものであって、クロールやインデックスを保証するものではないと明記されています。
つまり、IndexNow でできるのは主に 通知 です。
その後に実際にどう評価されるかは、ページの品質、重複、クロール状況、サイト全体の構造など別の要素に左右されます。
このため、次のような誤解は避けた方が安全です。
- IndexNow を入れれば上位表示しやすくなる
- 送信したら即インデックスされる
- XML サイトマップが不要になる
- 質の低いページでも早く拾ってもらえる
IndexNow は SEO の魔法 ではなく、検索エンジンへの更新通知を整理する仕組み と見た方が実態に近いです。
XMLサイトマップとの違い
ここが一番混ざりやすいです。
IndexNow と XML サイトマップは、似ているようで役割が違います。
| 項目 | IndexNow | XMLサイトマップ |
|---|---|---|
| 役割 | 変更が起きた URL を通知する | サイト全体の URL 一覧を渡す |
| 向いている用途 | 追加・更新・削除の即時連携 | 継続的な URL 発見と棚卸し |
| 通知のタイミング | 変更時に送る | 定期的に参照される |
| 全件送信 | 通常運用では非推奨 | そもそも全体一覧を渡す前提 |
| 置き換え可否 | サイトマップの代わりにはならない | IndexNow の代わりにもならない |
FAQ でも、IndexNow は最近追加・更新・削除した URL の通知向けで、長期的な URL 発見には XML サイトマップを使うよう案内されています。
つまり、実務では どちらか一方 ではなく、役割分担して両方使う のが自然です。
実務での使い分け
- XML サイトマップ: サイト全体の URL 構造を検索エンジンに伝える
- IndexNow: 変更が起きた URL をその都度伝える
この組み合わせにしておくと、全体像も更新差分も両方渡しやすくなります。
どうやって送るのか
IndexNow の公式ドキュメントでは、1 URL なら GET、複数 URL なら POST JSON で送れます。
また、所有確認のためにキーを使い、そのキーを含んだ UTF-8 のテキストファイルをサイト上に置く方法が推奨されています。
ざっくりした流れはこうです。
- キーを作る
{key}.txtをサイトのルートに置く- URL が公開・更新・削除されたタイミングで
/indexnowへ送る - 200 や 202 の応答を確認する
公式では、複数 URL をまとめて送るときは 1 リクエストあたり最大 10,000 URL まで対応できると案内されています。
また、200 は受信成功、202 はキー確認待ち、403 はキー不正、429 は送信過多の可能性という扱いです。
アプリや CMS 側で記事公開や商品更新の処理があるなら、その保存完了後に IndexNow を呼ぶ形が一番きれいです。逆に、全 URL を毎日まとめて送る運用は IndexNow の良さを消しやすいので、差分だけ送る方が向いています。
どんなサイトで使う価値があるか
IndexNow は、すべてのサイトで最優先というわけではありません。
ただ、次のようなサイトでは相性がよいです。
- 新着記事を継続的に出すメディア
- 商品追加や在庫切れが多い EC サイト
- URL の削除やリダイレクトが発生しやすいサイト
- CMS や独自システムで公開フローを制御できるサイト
一方で、ほとんど更新がない小規模サイトでは、まず XML サイトマップ、内部リンク、クロールしやすい構造の方が先に効くこともあります。
IndexNow はその上で 更新通知を整える 施策として考えるとバランスがよいです。
実務で気をつけたいポイント
1. 全 URL を何度も投げない
FAQ でも、通常は 最近追加・更新・削除した URL を送るためのものとされています。
サイト全件を毎回送るのは、通知の意味が薄くなります。
大規模移行や全面リニューアルのように、サイト全体が変わったときは全件送信もありえます。
ただし、日常運用では差分送信が基本です。
2. キーの配置を雑にしない
キー確認ファイルは、検索エンジンが所有確認に使います。
公式ではルート配置が強く推奨されており、別の場所に置く方法もありますが、パス設計を誤ると確認に失敗しやすいです。
3. 通知だけで満足しない
IndexNow を入れても、ページが薄い、重複している、内部リンクが弱い、canonical が崩れている、という問題は別で残ります。
通知の仕組みと、コンテンツ品質やサイト構造は分けて考える必要があります。
このサイトのような記事運用だとどう考えるか
コード管理で記事を追加してデプロイするタイプのサイトなら、IndexNow はかなり相性がよいです。
記事公開や更新のタイミングが明確なので、公開後にその URL だけ送る という流れを組み込みやすいからです。
たとえばこのサイトのように、
- 記事追加時に URL が確定する
- 用語ページ追加時に URL が確定する
- デプロイ後に公開確認を行う
という流れなら、最後に差分 URL を IndexNow へ送るのは自然です。
逆に、静的に近いけれど更新は定期的にある、というサイトほど恩恵を感じやすいです。
まとめ
IndexNow は、検索エンジンに対して URL の変更を早めに知らせる仕組みです。
追加・更新・削除の通知には向いていますが、インデックス保証や順位改善そのものを担うものではありません。
実務での整理としては、
- IndexNow: 変更通知
- XML サイトマップ: URL 一覧の土台
と分けて考えるのが分かりやすいです。
更新が多いサイトや、公開タイミングを明確に制御できるサイトでは入れる価値があります。
ただし、まずはコンテンツ品質、内部リンク、クロールしやすい構造が前提で、その上に載せる仕組みだと考えておくのが安全です。
参考リンク
- IndexNow.org: Documentation
- IndexNow.org: FAQ
- Bing Webmaster Tools: How to add IndexNow to your website