Hakaru Lab | 公開: 2026-09-25 | 検証記事

IndexNowを0円で実装し、初回にURL9件を送ってHTTP 202を受けた——「受理された」と「索引された」の間にあるもの

対象読者:自分のサイトの新規公開・更新を検索エンジンにできるだけ早く伝えたい個人サイト運営者・小規模ブログ運営者、および「送った」と「検索結果に出た」の違いを整理したい方。

3行要点
・当ラボは、サイトの更新URLを検索エンジンへ通知するIndexNow(インデックスナウ)という無料の仕組みを、鍵ファイル1つと小さなスクリプトで実装し、2026年9月6日にURL9件を送信してHTTPステータスコード(サーバーの応答を表す3桁の数字)202を受け取りました。
・自分のサイトの更新をできるだけ早く検索エンジンに伝えたい個人サイト運営者が、有料ツールなしで何ができ、何が確認できないままかを見極める材料になります。
・IndexNowはGoogleを含まない一部の検索エンジン向けの仕組みで、送信が受理されたことと実際に索引されたことは別です(索引状況の確認経路と直近の送信状況は④・③で説明します)。
検証の前提
・検証日:2026-09-13(実装・初回送信の記録照合)
・状態の再確認:2026-09-17(公開直前)
・利害関係:本記事に広告リンクはありません

目次

① IndexNowとは何か——更新URLを検索エンジンへ知らせる無料の通信手順

IndexNow(インデックスナウ。「いま索引して」という意味の名称)は、サイトの新規公開・更新があったURLを検索エンジンへ知らせるための共通の通信手順(プロトコル。複数のコンピュータが情報をやり取りするための取り決め)です。公式サイトによれば、この手順はMicrosoft Bing・Naver・Seznam.cz・Yandex・Yep(いずれも検索エンジン)の支援を受けて公開されており、Bingのウェブマスター向けブログには2021年10月付けでこの手順を紹介する記事があります(出典は末尾)。仕組みは単純で、サイト側が用意した「鍵ファイル」(後述)の存在によって自分のサイトであることを示したうえで、更新のあったURLの一覧を1回のリクエストで送信するだけです。

ここで押さえておきたいのは、この一覧にGoogleは含まれていないという点です。当ラボが確認できた範囲(参照日2026-09-13)では、Google自身がIndexNowへの対応を公式に表明した記録は見つかっていません。対応表明が確認できない以上、IndexNowの送信によってGoogle経由の流入や検索結果への反映が早まることは期待できません(この点についてGoogle側の一次情報は当ラボでは確認できていません)。Google向けにサイトの更新を伝える手段は、従来どおりsitemap.xml(サイト内のURL一覧を機械が読める形式で示すファイル)の送信や、検索エンジン側が自発的にサイトを再訪問(クロール)するのを待つ方法が中心です。

当ラボがIndexNowを選んだ理由は、追加費用がかからず鍵ファイル1つで完結すること、既存のsitemap.xml生成の出力をそのまま流用できたことです。なお「0円」が指すのはIndexNowの利用と当ラボの自作スクリプトの範囲であり、サイトの配信基盤やドメインの取得・維持にかかる費用は別です。Google向けは対象外のため、別途sitemap.xmlの整備で対応しています。

```mermaid
flowchart LR
A["サイトを更新・新規公開"] --> B["sitemap.xmlを再生成"]
B --> C{"通知先は?"}
C -->|"Bing/Yandex等"| D["IndexNowで更新URLを送信<br/>→202なら受理・鍵検証は保留"]
C -->|"Google"| E["sitemap.xmlを公開<br/>+通常のクロールを待つ<br/>(Search Consoleへの送信は未実施)"]
D --> F["受理されただけ<br/>索引されたかは別途確認が要る"]
```

模式図:更新の通知先は検索エンジンによって分かれる。IndexNowで202が返っても、索引されたかどうかは別の確認が必要(索引可否を確認する経路は当ラボでは未整備のため図に含めていない)。

② 当ラボの実装——鍵ファイル1つ・スクリプト1つ・同日二重送信を防ぐ設計

当ラボはIndexNowを、追加の有料サービスを使わず、標準ライブラリのみで書かれた1本のスクリプト(バージョン表記v0.1・2026-09-06時点。以後変更されうる)で実装しています。仕組みは次の3点です。

鍵ファイル。 IndexNowでは、サイトが用意した鍵ファイルの存在によって自分がそのサイトの管理者であることを示します。公式ドキュメントによれば、鍵は8〜128文字の16進文字列(16進数。0から9とa-fの16種類の文字だけで数値を表す記法)であればよく、設置場所もサイト直下に限らず、鍵の所在を示すURLを指定する項目(keyLocation)を添えれば任意の場所に置けます。当ラボの実装では、このうち32文字の16進文字列をサイト直下に置く方式を選んでおり、この鍵は秘密の情報ではなく仕様上公開が前提のものです(実際の値は伏せます)。ファイルが無ければ起動時に自動生成し、公開用ディレクトリに書き出す設計にしています。

送信対象の決め方。 送信するURLの一覧は、sitemap.xml生成スクリプトが書き出したsitemap.xmlファイルを、その時点の内容のまま読み取ります(生成は別実行で、送信スクリプトとは連動していません)。生成スクリプト自体は、あらかじめ決めた対象(固定ページ数種・記事ページ・英語版ページ)のうち実在するファイルだけを毎回洗い直して組み立てます。更新日時は、記事ページなら本文中の公開日・更新日(更新日優先)を読み取れなければsitemapに載せません。固定ページ(トップ・about・privacyなど)は既存sitemapの値を引き継ぎ、無ければ当日日付を使います。計測用リダイレクトURLは対象外です。IndexNow側は既定で直近7日以内に更新日が入ったURLだけを送信対象にします。

同日二重送信を防ぐ歯止め・既定は未送信(dry-run)。 このスクリプトは、明示的なオプション(`--go`)を付けない限り実際には何も送信せず、送信予定のURL一覧を記録するだけの動作(dry-run。実際の処理を行わず結果だけを事前確認する実行方式)になっています。さらに、送信が受理(応答コード200または202)されていれば、同じ日の再実行では再送信しません。送信が失敗した場合はこの記録が更新されないため、同日中でも再実行すれば再送信されます。これは同じ更新を同日に重ねて送って検索エンジン側から負荷とみなされることを避けるための上限です。ただしこの歯止めには裏があり、当日すでに送信したあとに新しいURLを公開しても、次にスクリプトを実行するまで送信されません。この裏がどう表れたかは③で扱います。

③ 初回送信の実測——URL9件を送りHTTP 202を受け取った、その後の取りこぼし

当ラボの実行記録によると、2026年9月6日2時46分(実行機のローカル時刻。ログはタイムゾーン情報を持たない形式で記録されており、運用上は日本標準時(JST。Japan Standard Timeの略で、協定世界時UTCより9時間進んでいる日本国内の標準時刻)を想定していますが、ログ自体にその裏づけはありません)に、このスクリプトを`--go`付きで実行し、URL9件を送信しました。内訳はトップページ・方法論ページ・about・privacyの固定ページ4件、日本語版記事3本(30days-50man・opera-cli-tokens・systemeio-free-plan)、英語版トップページ、英語版記事1本(30days-50man)です。応答はHTTPステータスコード202で、公式ドキュメントによればこれは「URLを受け取った。鍵の検証は保留中」であることを示すコードであり、送信の受理と鍵の検証完了は別の段階です。

この約22分前(同日2時24分)、同じスクリプトを`--go`なしで実行した記録では送信予定のURLは8件でした。この差は英語版トップページ1件で、当ラボが導入時に残した作業記録(2026年9月6日付)によれば、この直前に英語版の入口ページが新設され、sitemap.xmlが9件へ再生成されています。sitemap生成スクリプトは固定ページの更新日時を「既存sitemap.xmlの値、無ければ当日日付」として扱う仕様のため、新設された英語版トップページが当日日付で直近7日フィルタを通過し、送信対象に加わったとみられます。ただし、再生成の正確な時刻はログに残っておらず、その一点は未確認です。

また、鍵ファイルは2時24分の生成時点で「配信(deploy。作成したファイルを公開先のサーバーへ反映させる操作)後に有効・deployが要る」と記録されており、その22分後に送信しています。この間に配信(deploy)を行った記録はなく、直前の公開記録は鍵生成より前の2時13分です。202は鍵の検証が保留中であることを示すコードのため、送信時点で鍵が公開先に存在していなければ、後続の鍵検証は通らない可能性があります。当ラボはこの間の到達確認(鍵URLへの1回のアクセス)を行っておらず、これも未確認です。

この記録が示すのは、IndexNowの共通受付口(api.indexnow.org)がリクエストを受け付けた、という事実だけです。202は、送ったURLが実際に検索結果に反映される、あるいは優先的にクロールされることを保証するものではありません。さらに、この初回送信より後、同日中に新しい記事3本(日本語1本・英語版2本)が公開されていますが、公開記録と検証日(2026-09-13)時点のsitemap.xml(12件)を照合すると、これらは初回送信のURL一覧(9件)に含まれておらず、その時点で一度もIndexNowへ送信されていませんでした。②の「同日1回」の歯止めと定期実行の不在が重なった結果、送信対象URLの一部(検証日時点で12件中3件)が、公開から1週間以上未送信のまま残っていたことになります。

この未送信の3件は、その後解消しています。当ラボの実行記録によると、検証日と同じ2026年9月13日12時08分(前記と同様、実行機のローカル時刻)にIndexNow送信スクリプトを`--go --all`(送信済み記録の有無にかかわらず全件を送る指定)付きで実行し、この3件を含む公開済みURL計12件をまとめて再送信して、応答はHTTPステータスコード200を受け取っています(当ラボのIndexNow送信ログに「SENT urls=12 http=200」として残る記録が根拠。200が鍵の検証まで通ったことを意味するかは、当ラボでは確認していません)。また、これ以後は公開処理そのものに「公開の直後にIndexNowへ送信する」工程を追加しており、今後は個別の取りこぼしが起きにくい設計に変わっています。ただし、この工程が実際に想定どおり動くかどうかの継続確認は、本記事の検証範囲外です。

④ 「送った」と「索引された」は別——未計測を未索引と混同しない

IndexNowを導入したあとに起きがちな誤解は、「送信が受理された(202が返ってきた)」ことと「検索エンジンがそのページを実際に索引した(検索結果に出せる状態にした)」ことを同じ意味に扱ってしまうことです。この2つは別の事実であり、202という応答は前者しか示しません。

索引されたかどうかを確認する代表的な手段は、各検索エンジンが提供する専用の管理画面に自分のサイトを登録し、索引済みのURL数や表示回数を見ることです。Google向けにはGoogle Search Console(グーグル・サーチコンソール。Googleが無料で提供する、自分のサイトが検索結果にどう表示されているかを確認できる管理画面)があります。当ラボが導入時に残した作業記録(2026年9月6日付)によれば、この時点でSearch Console側の所有権確認タグが検出されておらず、その後に登録した記録もありません。本記事の公開直前(2026年9月17日)にサイトの配信ファイルを機械検査した限りでも所有権確認タグは見つからず、未登録とみられる状態が続いています(Search Consoleの管理画面そのものは開いておらず、管理画面での確認は未実施です)。IndexNowの送信先であるBing向けにはBing Webmaster Tools(ビング・ウェブマスターツール。Microsoftが無料で提供する同種の管理画面)がありますが、こちらは登録の有無を示す記録が当ラボの手元になく、2026年9月17日時点でも未確認のままです。初回送信(2026-09-06)から本記事の公開直前確認(2026-09-17)まで約11日が過ぎていますが、送信した9件(2026-09-13の再送分を含めれば12件)が実際に索引されたかを確認する手段を、当ラボはまだ十分に持てていません。

ここで重要なのは、「確認する手段がない」ことと「索引されていない」ことは別だという点です。当ラボはこの状態を「未索引」ではなく「未計測」と呼んでいます。索引されている可能性もされていない可能性もあり、どちらかを示す記録が手元に無い状態です。この書き分けを怠ると、後日たまたま検索結果でページが見つからなかった場合に「IndexNowが効かなかった」と誤って結論づけてしまう恐れがあります。

同様に、「Bing等のクローラ(自動巡回プログラム)が実際にサイトを再訪問したか」も、当ラボはアクセスログのUser-Agent(アクセス元のソフトが名乗る識別情報)とIPアドレス(インターネット上の機器を識別する番号で、どこからアクセスしたかを示す)を突き合わせて判定する仕組みをまだ整えていません。当ラボが施策の予定と結果を管理している一覧は、送信後にBingのクローラ到達を確認できる目安として72時間を置いていますが、これは見込みであり実測ではなく、確認は今後の課題です。

⑤ 送っていても効果を確認できない状態を避ける——導入前の6項目

IndexNowの導入を検討している方向けに、当ラボの実装から作ったチェックリストです。

当ラボ自身、4番目・5番目の項目に当てはまらない実例があります。直前2日間(2026年9月4日・5日)の公開記録では記事の一つ(systemeio-free-plan)の到達確認がHTTPステータス403(アクセス拒否)で失敗していましたが、翌9月6日のdry-run・本送信ではこのURLをそのまま送信対象に含めていました。ファイルが存在することと、公開先で実際に読めることは別であるという反例です。

一つでも当てはまらない項目があれば、送信はしていても効果を確認できないまま運用してしまう可能性があります。

結論

採用(当ラボの決定): 当ラボは、鍵ファイル1つと1本のスクリプトによるIndexNow送信を2026年9月6日に初回実施し、9件のURLを送信してHTTP 202(受理・鍵検証は保留)を確認しています。既定では何も送信しない設計(dry-run)にし、明示的な指定があるとき、かつ同日は受理済みなら二重に送らない設計を採用しています。初回送信より後に公開した3件のURLは、同日1回の歯止めと定期実行の不在が重なった結果、検証日(2026-09-13)時点まで一度も送信できないまま残っていましたが、同日中(2026-09-13 12時08分)にこの3件を含む計12件を`--go --all`で再送信し、HTTP 200を確認しています。あわせて、公開処理に「公開の直後にIndexNowへ送信する」工程を追加し(2026-09-13時点)、以後は個別の取りこぼしが起きにくい設計に変えています。

推奨(読者への助言): 更新の通知を早めたい方には、まず自分が重視する検索エンジンがIndexNowの対応一覧に含まれているかを確認することを勧めます。Googleへの効果を期待する場合は、IndexNowではなくsitemap.xmlの整備を優先してください(Google側の対応表明は当ラボでは確認できていません)。送信が受理されたことをもって「索引された」と早合点せず、各検索エンジンの管理画面を合わせて登録し、送信と索引を別々に記録する運用を勧めます。同日1回の歯止めを入れる場合は、送信後に新しく公開したURLを取りこぼさない仕組み(定期実行や差分検知、または公開処理自体への組み込み)も併設することを勧めます。基準日は検証日(2026年9月13日)、状態の再確認は2026年9月17日時点です。

管理情報

方法・未確認事項・訂正履歴・出典

方法: 本記事は、当ラボが運用するIndexNow送信スクリプトとsitemap.xml生成スクリプトのソースコード、実際の実行ログ(送信日時・送信件数・応答コード)、およびサイトの公開記録(公開日時・到達確認結果)にもとづく検証です。応答コードは当ラボの実行記録に記載された値をそのまま用いています。IndexNowの仕様(鍵の長さ・202の意味・対応検索エンジン一覧)については、IndexNow公式サイトの記載を参照日時点で確認しています。本記事の数値の多くは当ラボが自ら運用する内部の実行ログ・記録にもとづいており、読者が直接開いて確認できるのはIndexNow公式サイト・公式ドキュメント・各検索エンジンの公式ヘルプなど、出典欄でリンクを添えた部分に限られます。

未確認事項:

訂正履歴:

出典:


このラボについて

当ラボの調査・執筆・検証は複数のAIによる分業で行っています。本記事は当ラボ自身が導入した更新通知の仕組みを、実際の実行記録にもとづいて説明したものです。方針の決定と最終確認は運営側の人間が担っています。