IndexNowは、ページの追加・更新・削除を参加検索エンジンへ知らせる仕組みです。送信成功は、クロール、インデックス登録、検索順位、AI回答への引用を保証するものではありません。更新を通知する工程と、変更が取り込まれたことを確認する工程を分けて運用します。
この記事では、企業サイトの担当者が実装者へ渡せる導入条件、最小の送信例、エラー確認表、変更通知の記録方法をまとめます。公開サーバーへの導入作業を行う場合は、CMSやCDNの既存機能を先に調べ、通知経路を重複させないことが重要です。
IndexNow、XMLサイトマップ、登録確認は役割が違う
| 仕組み | 担当すること | 代わりにできないこと |
|---|---|---|
| IndexNow | 追加・更新・削除されたURLを参加エンジンへ通知する | 登録やAI引用を強制すること |
| XMLサイトマップ | 公開する正規URLと適切な更新情報を案内する | ページ本文や応答の誤りを修正すること |
| URL検査・サーバーログ | 受信、取得、登録などの状態を工程別に確認する | 通知しただけのURLを登録済みと扱うこと |
IndexNowは参加する検索エンジン向けのプロトコルです。特定サービスへの対応を確認せず、「送ればGoogleもすべて更新される」「すべての生成AIへ伝わる」と説明しないでください。Google側のサイトマップやURL検査は別の確認経路として残します。
BingはAI Performanceの公式発表で、情報の鮮度を保つ手段としてIndexNowを案内しています。これはAI検索で引用されることの保証ではなく、更新発見を助ける仕組みと捉えるのが適切です。
導入前に確認する4項目
- 既存機能。CMS、プラグイン、CDN、サーバー側の実装がすでに通知していないかを調べます。管理画面に機能がある場合は、稼働状況とログを確認してから追加実装を判断します。
- 対象ホスト。本番のドメイン、サブドメイン、HTTPS、wwwの有無を決めます。別の会社サイトやステージングを同じ一覧に混ぜません。
- 公開状態。公開予定の本文が実際に取得できるか、意図しないnoindex、ログイン制限、転送ループがないかを確認します。
- 変更の判定。公開・実質更新・削除のどのイベントで通知するかを決めます。自動保存や閲覧のたびに送信する実装は避けます。
例えば料金表の更新は本文や条件の変更後に通知します。管理画面で保存ボタンを押しただけ、アクセス数が増えただけ、取得できる内容が変わっていない場合は、通知の必要性を区別します。具体的な対応製品はBingの導入案内で確認できます。
キー配置から最小送信までの手順
1．所有を確認するキーを用意する
自社で生成したキーを、指定のテキストファイルとして対象ホストへ配置します。ルート配置は分かりやすい構成です。UTF-8のファイルにキーを記載し、ファイル名・本文・送信値の一致と、認証なしで取得できることを確認します。既存のWordPressファイルやサーバー設定を上書きしないでください。詳細な配置条件はIndexNow仕様に従います。
このキーはIndexNowの所有確認用であり、FTPやCMSの管理パスワードではありません。記事やサポート依頼へ実運用のキーをむやみに貼り付けず、担当者が変更できる場所で管理します。キーを変えた場合は、配置ファイルと送信元の設定をそろえて点検します。
2．最初は少数の変更URLで送信する
次は形式を示す架空ドメインの例です。サイト所有者が管理する実際の値へ置き換える必要があり、このまま実行するための設定ではありません。送信先は採用する検索エンジンの公式エンドポイントを確認します。
POST https://api.indexnow.org/indexnow
Content-Type: application/json; charset=utf-8
{
"host": "www.example.com",
"key": "REPLACE-WITH-YOUR-OWN-KEY",
"keyLocation": "https://www.example.com/REPLACE-WITH-YOUR-OWN-KEY.txt",
"urlList": [
"https://www.example.com/service/"
]
}送信するURLは、確認したホストに属する変更URLへ限定します。通知の応答だけで作業を終えず、次の表のように受付段階と掲載段階を別々に記録します。リクエスト形式の根拠は公式仕様の複数URL送信です。
応答コードで次の作業を決める
| 応答 | 意味・確認箇所 | 担当者の次の作業 |
|---|---|---|
| 200 | URL送信を受け付けた | 受付記録を残し、取得・登録は別途確認する |
| 202 | URLを受け取ったが、キー確認が保留 | ファイルの配置と取得状態を確認する |
| 400 | リクエスト形式の不備 | JSON、必須値、URL形式を点検する |
| 403 | キーが有効と確認できない | ファイル名・本文・アクセス制限を確認する |
| 422 | ホストやキーとの対応などに不整合 | 通知URLと対象ホスト・キーの適用範囲を照合する |
| 429 | 送信過多などによる制限 | 送信を抑え、応答と再試行条件を確認する |
コードの定義は公式仕様のResponse format、再試行や確認の考え方は公式FAQを参照してください。キーや形式が間違っているのに同じデータを連打するより、原因を修正して再試行する設計が必要です。
追加・更新・削除の通知を設計する
| 変更 | 通知する対象 | 同時に点検すること |
|---|---|---|
| 新規公開 | 新しく公開した正規URL | 本文が取得できること、内部リンク、サイトマップ |
| 実質更新 | 内容が変わった既存URL | 古い条件の残存、更新履歴、表示キャッシュ |
| 削除 | 削除した旧URL | 意図した404・410などの状態と内部リンク整理 |
| URL移行 | 変更のあった旧URLと新URLを管理する | 旧新の転送先、canonical、サイトマップ、内部リンク |
削除を知らせるために、削除済みURLを200へ戻す必要はありません。移行先のないページをすべてトップへ転送するのではなく、内容に対応する移行先の有無で処理を判断します。下書きや会員限定情報を、変更通知に載せるために一般公開することも避けます。
自動化する場合のログ項目
運用上の記録例として、変更日時、公開環境、対象ホスト、URL、変更の種類、送信日時、応答コード、再試行回数、次の確認担当を残します。実装者向けログと社外向けレポートを分け、キーの値や認証情報をレポートへそのまま含めないようにします。
通知キューは、同じURLの短時間の連続保存をまとめるなど、重複を抑える構成にします。通知処理が失敗しても記事本文の公開を巻き戻すのか、公開は維持して後で通知を再試行するのかを、業務要件に応じて決めます。通知成功と記事公開成功を別ステータスにすると、障害時に確認しやすくなります。
導入完了は「送信できた」だけで判定しない
- 通知元と対象ホストを確認し、別サイトや下書きを含めていない。
- キーのファイル名、本文、送信値が一致し、正しく取得できる。
- 変更URLの送信と応答を記録できる。
- 形式不備やキー不一致のとき、原因と再試行を追跡できる。
- 実質変更のないURLを繰り返し送信していない。
- XMLサイトマップ、canonical、内部リンクと公開状態に矛盾がない。
- 検索エンジン側のURL検査やログで、取得・登録を別途確認する手順がある。
- AI回答の引用や検索順位を、通知の受付結果から推測していない。
通知後も登録されない場合は、コンテンツの重複、取得制限、noindex、公開状態などを切り分けます。公式FAQも、送信が登録を保証しないことと、エンジンごとに判断が異なることを説明しています。
よくある質問
IndexNowを使えばXMLサイトマップは不要ですか？
役割が違うため、通知の導入だけを理由に削除しません。公開する正規URLを案内するサイトマップと、変更があったURLの通知を整合させます。
200が返ったのに検索結果へ出ません。失敗ですか？
200は受付の確認で、登録完了を意味しません。まず対象URLの取得状態と検索エンジン側の確認情報を調べ、送信失敗と登録の判断を分けます。
毎日すべてのURLを送れば有利ですか？
変更のないURLを繰り返し送る運用は避けます。公開・更新・削除の発生に合わせて通知し、送信過多と確認しにくいログの増加を防ぎます。
関連記事と相談窓口
株式会社AOでは、Webサイト運用・改善とSEO・AIO支援を行っています。CMSの現状、対象ドメイン、更新頻度、確認できているエラーを整理したうえでご相談ください。
編集：株式会社AO。公式情報確認日：2026年11月4日。コードと表は導入設計の例であり、株式会社AOのサイトへこの設定を導入済みであることを示すものではありません。
コメント