IndexNowで変更ページを通知する方法。送信成功とインデックス登録を区別する

IndexNowは、URLが変わったことを参加検索エンジンへ知らせる仕組みです。新しい記事、修正した商品ページ、ページの削除に利用できます。クロール、インデックス登録、順位改善、アクセス増加を保証するものではありません。通知の成功が答えるのは、送信がサービスへ届いたかという、より限定的な問いです。

この区別から始めると、設定の良し悪しを判断しやすくなります。公開システムは意味のある変更を確実に送り、応答を記録し、失敗を見えるようにするべきです。変えていないページを繰り返し送っても、検索に出ない理由の調査にはなりません。

すでに通知されているか確認する

Bingの導入ガイドは、追加、変更、削除したURLがすでに送信されているか、Bing Webmaster Toolsで確認するよう勧めています。CMS、ホスティング、プラグインに連携があるかもしれません。二つ目の送信元を追加する前に、実際の動作を確認してください。

誰が連携を管理し、どのイベントで動き、どこで結果を確認できるかを聞きます。プラグインをインストールしたことと、最新の公開ページが送られた証拠は別です。最近の実際の変更を一つ選び、公開から送信記録まで追跡してください。

サービスを比較するときは対象範囲を区別します。ClickSyrupのGoogle Indexing APIの対象条件は、独自の制限を持つ別の仕組みを扱っています。どちらもURLを扱うからといって、対象条件、上限、保証を一方から他方へ持ち込まないでください。

サービスが読めるキーを配置する

手動で実装する場合はIndexNowキーを生成し、送信するURLと同じホスト上のUTF-8テキストファイルに値を入れます。最も単純なのは、キーをファイル名にし、拡張子を.txtとしてルートに置く方法です。ホスト内の別の場所に置くなら、keyLocationで完全なアドレスを指定します。サブディレクトリのキーが対象とするのはその配下のURLなので、サイト全体を扱うならルートのキーが単純です。

管理画面にログインしていない状態でファイルを確認してください。返されるべきなのはプレーンテキストのキーであり、ログイン画面やサイトの装飾付きエラーページではありません。ファイルのアドレス、内容、リクエストのキーを一致させます。ホストの不一致やファイルへのアクセス不能は、見た目が正しいリクエストでも検証エラーにつながります。

www.example.org向けの仮の実装では、まず公開ページを実際に配信するホストを決めます。wwwありとなしの両方がある場合、一方のキーファイルと他方の送信URLを不用意に混ぜないようにします。今後の移行で気付かず壊さないよう、その判断を連携設定に記録してください。

変更したURLを送り、応答を残す

単一URLの文書化された方法は、検索エンジンの/indexnowエンドポイントに対するGETリクエストです。urlとkeyを使い、配置したキーファイルを指定する場合はkeyLocationも加えます。パラメーターの値を正しくURLエンコードしてください。送信URL内のクエリ文字列を適切に処理しないと、通知リクエスト自体のパラメーターと誤認されることがあります。

まとめて送る場合はhttps://api.indexnow.org/indexnowへPOSTでJSONを送ります。フィールドはhost、key、keyLocation、urlListです。リストは対象のホストに限定してください。実装の詳細はIndexNowのプロトコル文書で確認し、概念的な例をそのまま本番用コードと見なさないようにします。

送ったURL、きっかけとなった変更、送信時刻、応答コードを保存します。これは運用上の提案です。公開の失敗と通知の失敗を分ける追跡記録になります。デプロイ全体を再現しなくても、何が起きたかを把握できるログにしてください。

エラーを次の確認への手掛かりとして読む

• 200はURL送信の成功です。インデックス登録の確認ではありません。
• 400はリクエスト形式の問題を示します。構造とエンコードを確認します。
• 403はキーの問題で、ファイルが見つからない場合や内容と値が違う場合を含みます。
• 422はURLがホストに属していない、またはキーがプロトコルの形式を満たしていない可能性を示します。
• 429はリクエスト過多やスパムの可能性を示します。不要な送信を減らし、返された再試行の指示に従います。

Bing Webmaster Toolsで受信を確認します。その後、クロールとインデックス登録を別々に調べてください。受信されているのに検索に出ない場合、何度も送り直す前にアクセス可能性、インデックス指示、内容、内部からの発見経路を見ます。通知によってアクセス不能なページが読めるようになるわけではありません。

IndexNowのFAQは、正確なレート制限は公開されず、参加検索エンジンによって異なると説明しています。共通の日次上限を作ったり、Bingの別の手動送信ツールの上限を流用したりしないでください。文書にリクエスト単位のサイズ制限があっても、それは一日の送信枠ではありません。

意味のある公開変更に通知を連動させる

導入後に実際に追加、更新、削除したURLを送ります。変更のない過去ページを大量に積み上げて送ることは避けます。Bingはクロールがクロール枠を消費すると説明し、FAQも意味のある変更なしの再送を勧めていません。サイト全体を繰り返し送るタイマーではなく、実際の公開イベントに連動させてください。

削除では古いURLを通知し、サイト自体も削除を適切に伝えていることを確認します。更新では、新しい内容が公開済みであることを確認してから通知します。これにより、クローラーが到着したときに見る内容と通知を一致させられます。

通常の発見経路も維持します。クロール可能な記事アーカイブは最新通知以外の内容を発見する助けになり、URL削除の計画は削除の通知と、ページを隠すことやアクセス管理を区別します。IndexNowはこうした作業と併用するものです。正確で適時な通知と失敗の見えやすさで評価し、インデックス登録の判断は検索エンジンに委ねます。