IndexNow

プロトコルの仕組み

可動部は2つだけです。1つ目はキーです。ランダムな文字列を生成し、その文字列そのものを名前にしたプレーンテキストファイルとしてサイトのルートに置き、配信します。このファイルは設計上、公開されるものです。サイトの所有者にしか作れないURLでそれを公開していること自体が所有権の証明のすべてであり、だからこそIndexNowのキーは秘密ではなく、コードと一緒にコミットしても差し支えありません。2つ目は送信です。ホスト名、キー、キーファイルの場所、そして変更されたURLの一覧を載せたPOSTを送ります。

仕組みは意図的に小さく保たれています。IndexNowのドキュメントは1回のPOSTあたり10,000 URLを上限としており、大半のサイトが一度に必要とする量を超えています。新しいキーでの最初の送信は200ではなくHTTP 202が返ることがあります。エンジンが受け付ける前にキーファイルを取得して確認しているためで、それが済めば成功した送信は200を返します。拒否されるのはほぼ必ずキーファイルが原因です。存在しない、名前が変わった、あるいは送ったキーと違う内容を返している、のいずれかです。動いていた送信が失敗し始めたら、まずここを見てください。

リストに載っているエンジン

IndexNowは参加しているエンドポイントを公開しており、本稿執筆時点ではBing、Naver、Seznam.cz、Yandex、Yepです。理解しておく価値のある設計上の要点は、送信は1回で足りるということです。参加エンドポイントのどれか1つに送れば他にも共有されるため、同じ一括送信を5回繰り返しても得るものはありません。いくつかのコンテンツプラットフォームやCDNもIndexNow対応を備えており、誰も決めていないのにすでに送信しているサイトもあります。

• Googleはそのリストにいません。 IndexNowに送ってもGoogle検索には何の効果もありません。Googleは従来どおり、リンクと、すでにSearch Consoleに登録済みのサイトマップからページを見つけます。IndexNowを「Googleに早く載る方法」として売る説明は、別のプロトコルの話をしています。
• 多くの人が手間をかける理由はBingです。 英語圏では参加エンジンのなかで群を抜いて大きく、大半のサイトにとっては、このプロトコルに半日を割く価値があるかどうかを決めるのは実質この1社です。
• 地域エンジンは埋め草ではありません。 韓国、チェコ、ロシアが実際の市場なら、Naver、Seznam.cz、Yandexはそれぞれの国内検索エンジンであり、これらが含まれていること自体がこのプロトコルを動かす正当な理由になります。
• IndexNow自身の説明はAI回答を前面に出しています。 ドキュメントはこのプロトコルを、AIを用いた検索結果においてコンテンツを最新に保つ助けになるものとして説明しています。土台となるインデックスの鮮度は、そこから読み取るアシスタントより上流にあるので、これは誠実な言い方です。

200が実際に意味すること

送信が受理された、ということです。それ以上の意味はありません。IndexNowのドキュメントはこの点について珍しくはっきりしています。URLを送っても索引に入る保証はありません。クロールするかどうかは、エンジンが自らのスケジュール、クロール割り当て、品質チェックに照らして判断し続けるからです。このプロトコルが動かすのは発見の待ち行列での順番だけで、発見より後の工程は何も変わりません。

私たちはagentceres.comで、IndexNowをビルドごとではなく日次ルーチンの1ステップとして実行しています。変更のないURLを過剰に再送しないよう、プロトコル自体が求めているからです。本日の実行では公開中のサイトマップを読み、1回のPOSTで415件のURLを送信し、エンドポイントはHTTP 200を返しました。この数字が、返ってくる情報のすべてです。コールバックもURLごとのステータスもなく、クローラーがいつ実際に来たのか、そもそも来たのかを知らせるものは何もありません。確認はBing Webmaster Tools、対象エンジンについてはSearch Console、あるいは自前のサーバーログから取るしかありません。私たちの送信スクリプトは、公開しているキーファイルが無い場合や内容がスクリプト内のキーと食い違う場合、そもそも実行を拒否します。この食い違いは拒否として返りますが、見た目はただの失敗リクエストと変わらず、見落とされるからです。

• 設定する価値があるのは、有機的な再クロールを待つことが実際の遅延になるほど頻繁にページを公開・変更する場合です。ドキュメントサイト、プログラマティックに生成したページ群、在庫が変わるECカタログ、あるいは削除したページがインデックスに残り続けると具合が悪いような場合です。
• あまり効かないのは、月に数ページしか公開せず、内部リンクもしっかりしている場合です。すでにサイト全体を余裕でカバーしているクロールバジェットに、使い方の助けは要りません。
• クロールする理由の代わりには決してなりません。 薄いページを早く知らせれば、早く見てもらえるだけです。整ったcanonicalタグやllms.txtと同じレバーであり、障害物を取り除く配管であって、誰かが関心を持つ理由ではありません。