ページが発見され、再クロールされる仕組み
ここには3つの異なる質問があり、それぞれに異なる答えがあります。クローラーがページを見つける方法、ページが変更されたことをどれだけ早く認識するか、そして結果について何を確認できるかです。このページでは、実際のタイマーを使って3つすべてに答えます。
クローラーはそもそもどのようにページを見つけるのか#
どちらも自動的に行われる、2つのプルベースの経路があります。
- サイトマップ。 各オーナーには、インデックスされたリポジトリのすべてのページと、実際に翻訳されたロケールごとに1つのエントリを一覧にした
sitemap.xmlが1つずつ提供されます。これはサイト自身のホストから配信され、再構築される頻度は最大でも1時間に1回です。 robots.txtが指定します。 Docsbookがホストするすべてのホストでは、robots.txtが提供され、そこにそのホストに対応するサイトマップを指すSitemap:行が記載されています。apexには複数のサイトマップが含まれます。apex自身のもの、各プロダクトドキュメントサイトのもの、そしてSEOが有効になっている各公開ショーケースサイトのものです。これらのサイトにはapexからしか到達できないため、そうしなければクローラーをそれらのサイトへ誘導するものがないからです。
それだけでなく、サイドバーはすべてのページで実際のHTMLリンクとしてレンダリングされるため、どのページをクロールしても、コンテンツのマップも同時にクロールされます。
変更はどのくらいの速さで検索エンジンに届くのか?#
プッシュ。 変更が Docsbook を通じて公開されると、つまりエディター、エージェント、MCP ツール、ワークスペース設定の変更などの場合、Docsbook はそのサイトの独自キャッシュを直ちに無効化します。また、docsbook.io apex 上でホスティングされているサイトについては、サイトのルートとサイトマップを指定した IndexNow 通知も送信します。この呼び出しはファイア・アンド・フォーゲット方式です。変更されたページではなく 2 つの URL を指定します(この時点でわかっているのは「このサイトが変更された」ということだけで、サイトマップによって参加している検索エンジンが具体的な変更内容を確認できます)。公開処理をブロックしたり失敗させたりすることはなく、IndexNow の障害はユーザーに表示されず、ログに記録されます。
プル。 それ以外の場合は、クローラーが戻ってきてサイトマップを再読み込みするまで待機します。
そして、正直なところ: Docsbook には GitHub webhook がありません。 Docsbook を経由せずにリポジトリへ直接プッシュされたコミットは、無効化も IndexNow プッシュも発生させません。タイマーによって取得されます。
| タイマー | 間隔 | 更新対象 |
|---|---|---|
| リポジトリのファイルツリー | 30 分 | 存在するページ |
| デフォルトブランチとコミット日時 | 1 時間 | lastmod、dateModified |
| 匿名ページ HTML のキャッシュ | 24 時間 | クローラーに提供される内容 |
sitemap.xml と robots.txt |
1 時間 | クロール可能なインデックス |
| セマンティックインデックスの巡回 | 1 時間ごと、バッチ処理 | サイト内検索と AI 検索(Google は対象外) |
つまり、Docsbook で編集されたページは、次のクローラーが数秒以内に訪れる頃には最新の状態になっています。一方、GitHub に直接プッシュされたページは、最長 24 時間キャッシュから提供される可能性があります。この 24 時間という間隔は意図的なトレードオフです。すべてのページを 1 時間ごとに再レンダリングするボットのクロールが、ホスティング料金の中で単独最大の項目となっていました。また、ドキュメントページは書き込まれるよりもはるかに頻繁に読まれます。
ページの名前を変更するとどうなりますか?#
Docsbookを通じて行われた移動では、移動と同じコミット内で、旧ページパス → 新ページパスが
.docsbook/redirects.json ファイルに書き込まれ、古いURLはその後、新しいURLへの
308永続リダイレクトを返します。一時的なリダイレクトではなく永続的なものにするのは、
一時的なリダイレクトでは、検索エンジンが無効になったURLを正規URLとして保持してしまい、
リダイレクトによってまさに維持しようとしている検索順位を失うことになるためです。このマップには最大500件まで保持され、
古いものから先に削除されます。また、404に向かっていたリクエストに対してのみ参照されます。
gitで自分でファイルを移動して行った名前変更では、リダイレクトは作成されません。マップに何も書き込まれていないためです。 エントリは手動で追加できます。これはリポジトリ内のプレーンファイルであり、両方の側がページパス、つまりURLに表示されるものです。
Search Console 統合では実際に何が行われるのでしょうか?#
読み取りを行います。データは読み取り専用の Search Analytics スコープを通じて、Google から Docsbook へ一方向に流れます。Docsbook が URL を送信したり、インデックス登録をリクエストしたり、Search Console アカウントに何かを書き込んだりすることはありません。また、接続のために必要な操作もありません。Docsbook は docsbook.io 上の Search Console のドメイン プロパティを読み取ります。これは Google の定義によれば「すべてのサブドメイン、プロトコル、サブパスのデータを集約」するもので、そこからサイトに属する URL の行だけに絞り込みます。
管理パネルに表示されるのは、平均掲載順位、表示回数、クリック数、ページがランクインしている検索クエリ、日ごとの推移、そして「改善する価値あり」のセットです。これは掲載順位が 5~20 位で、すでに表示されているものの、まだ成果につながっていないクエリです。期間は 7 日、28 日、30 日です。デフォルトが 7 日なのは、保持される履歴が 30 日分だけであり、同じ期間を比較対象として後ろに確保できるのが 7 日の期間だけだからです。
3 つの制約も隠さず表示されます。Google のデータには約 2 日の遅延があるため、「データの最終日」が常に画面に表示されます。更新は 24 時間に 1 回までです。Google 自体が毎日更新しており、2 回目の取得を行っても同じ数値を返すためにクォータを消費するだけだからです。また、主要な合計値はクエリ行を合計するのではなく、ページ単位から集計されます。Google はプライバシー保護のため、ボリュームの少ないクエリを非表示にするため、クエリの内訳は実際のトラフィックの一部しかカバーしません。Docsbook 自身のドキュメント プロパティで行った独自の測定では、クエリ単位で合計すると 91 回の表示回数だったのに対し、ページ単位で合計すると 413 回でした。これは 1 日分の 1 サイトにおける数値であり、皆さんのサイトでの差の大きさではなく、差が生じる方向性を示すために引用しています。
これらの仕組みの理由(根拠)#
| 仕組み | 情報源が実際に述べていること | 情報源 |
|---|---|---|
| サイトマップは通知するものであり、保証するものではない | 「サイトマップの送信は単なるヒントにすぎません。Google がサイトマップをダウンロードしたり、URL のクロールにサイトマップを使用したりすることを保証するものではありません」 | サイトマップを作成する |
Sitemap: 内の robots.txt は実際の検出経路である |
「Google、Bing、その他の主要な検索エンジンは robots.txt の sitemap フィールドをサポートしています。また、含めることのできるサイトマップの数に制限はありません」 |
robots.txt 仕様 |
| IndexNow は再クロールのヒントであり、インデックス登録ではない | 「URL を送信しても、直ちにインデックス登録されるとは限りません」。検索エンジンは引き続き、「クロール割り当て、スケジュールのロジック、品質シグナルに基づいて URL をクロールすべきかどうかを評価します」 | IndexNow FAQ |
| 1 回の IndexNow 呼び出しにつき 1 つのホスト | 送信本文には単一の host フィールドが含まれ、これに違反した場合に記載されているエラーは「422 — 処理できないエンティティ — ホストに属さない URL の場合」です。1 回の投稿につき最大 10,000 個の URL を送信できます |
IndexNow ドキュメント |
| ドメイン プロパティはすべてのサブドメインを対象とする | 「ドメイン プロパティは、そのプロパティのすべてのサブドメイン、プロトコル、サブパスのデータを集約します」 | Search Console のプロパティ |
| Search Console API は読み取り専用で承認できる | webmasters.readonly は、このメソッドに記載されている 2 つのスコープのうちの 1 つであり、Docsbook がリクエストするスコープです。グループ化の基準となるディメンション(クエリ、ページ、国、デバイス、日付)はすべて dimensions[] の有効な値です(date は、フィルタリング可能なディメンションではなく、メソッドの「'date' と 'hour' も同様に」という節を通じて指定されます) |
検索アナリティクス: クエリ |
| クエリの行数は意図的に過少計上される | 「ユーザーのプライバシーを保護するため、パフォーマンス レポートにはすべてのデータが表示されるわけではありません…ごく少ない回数しか実行されないクエリの一部は追跡しない場合があります」 | Search Console データについて |
noindex には、ページがクロール可能な状態を維持する必要がある |
「noindex ルールを有効にするには、ページまたはリソースが robots.txt ファイルによってブロックされていてはならず、それ以外の点でもクローラーがアクセスできる必要があります」—そのため、noindex ページはサイトマップに残り、許可された状態が維持されます |
インデックス登録をブロックする |
制限と未解決の疑問#
- 現在、顧客サイトにはIndexNowは送信されません。 このプロトコルでは、送信するすべてのURLが同じホストを
共有し、そのホストのルートにキーファイルが必要です。
Docsbookはそのキーを
docsbook.ioのapexにのみホストしているため、プッシュが送信されるのは Docsbook自体のドキュメントと、apex上のショーケースサイトのみです。<owner>.docsbook.ioサイトやカスタムドメインには 送信されません。テナントごとのキーのホスティングは別途必要な作業であり、まだ構築されていません。 - 未解決の疑問:IndexNowが実際にどれほど速いのか。 Docsbookのコードコメントには、 「次回の予定クロールを待つ代わりに数分以内」とあります。IndexNow自身のFAQでは、 「重要な変更がより速く発見され、クロールされる可能性を高める」としか説明されておらず、具体的な期間には 触れていません。数分というのは測定結果ではなく期待値として扱ってください。私たちは測定結果を公開していません。
- GoogleはIndexNowの参加者ではありません。 indexnow.org では、サポート元として「Microsoft Bing、Naver、Seznam.cz、Yandex、Yep」を挙げています。 5つの検索エンジンであり、そのページにもプロトコルのドキュメントにもGoogleは含まれていません。 Googleによる発見は、引き続きサイトマップと通常のクロールによって行われます。
- 未解決の疑問:IndexNowキーがどれほど秘密のものなのか。 Docsbookではキーを 公開識別子として扱っています。キーは公開状態でハードコードされており、FAQが求めるとおり、キーファイルは 認証なしでapexのルートから提供されます(「ログイン不要」であるため、検索エンジンが「ドメインの所有権を 確認」できます)。「秘密ではない」という解釈と矛盾するのは、IndexNow自身のプロトコルページにある 「キーとキーファイルの場所を知っているのは、あなただけと検索エンジンだけであるべきです」 という記述です。あらゆるクライアントが取得できるファイルについて、この2つが完全に両立することはありません。 キーをコピーされた場合にできることには限界があり、「このホストが変更された」と伝えるだけです。しかし、 「構造上公開されている」というのは、そう述べてはいないプロトコルに対する私たちの解釈として扱ってください。
- Search Consoleの対象範囲はDocsbookがホストするホストで止まります。 ドメインプロパティは
docsbook.ioとそのサブドメインを対象とします。自分のカスタムドメイン上のサイトはそのプロパティに 含まれないため、そのサイトの順位は読み取られません。これらの数値を提供するには、顧客ごとのGoogle認証 フローが必要ですが、まだ存在しません。当面は、カスタムドメインについて自分のSearch Consoleアカウントを 使用してください。 - ここでのSearch Consoleの履歴は30日間です。 Googleはこれより大幅に長い期間を保持していますが、 Docsbookではサイトごとに30日間のローリングウィンドウを保存しています。そのため、30日間の表示には比較期間が ありません。
- ここにある機能によってページがランキングされるわけではありません。 発見と再クロールはDocsbookが 自動化できる部分です。クロールされたページがランキングされるかどうかは、コンテンツに対するGoogleの判断であり、 このページ上のタイマーによって変わるものではありません。