深夜の稼働

太平洋時間の午前3時、本番サイトは営業時間中のどの時点よりも多くのリクエストを処理しています。ユーザーからではありません。ボットからです。

Googlebotが21,000ページをクロールし、Bingbotが10,000ページをクロールし、包括的なナイトチェックが15,000件のブログ記事と企業ページを処理しています。ウォームパスが翌日のトラフィックに備えてCloudflareエッジキャッシュを準備しています。これらの夜間プロセスを合わせると、すべての人間の訪問者を合計したよりも多くのページにアクセスしています。

日中に構築するサイトは、最も重要なサイトではありません。最も重要なのは、午前3時にクローラーが見るサイトです。

クロール国勢調査

毎日、ボットが過去24時間に何を見たかを数えるクロール国勢調査を実施しています。この国勢調査では、CloudflareのアナリティクスAPIをユーザーエージェントでフィルタリングして使用します。数値は、検索エンジンが何を重視しているかを物語っています。

Google:     21,463  (67%)
Bing:       10,620  (33%)
Combined:   32,083

Jobs:       16,111  (50% of all crawls)
Blog:       298
Locale:     1,233
Programmatic: 257
Companies:  14

求人がクロールバジェットの半分を消費しています。Googlebotは1日あたり10,654件の求人ページをクロールしています。求人サイトマップには上限がなく、対象となるすべての求人情報が含まれています。クロールバジェットの配分は、Googleがサイト上で最も価値が高いと考えるコンテンツを示しています。

ブログ記事は最も質の高いコンテンツであるにもかかわらず、1日あたりのクロール数はわずか298回です。クロール投資の比率（求人はブログの50倍）とコンテンツ投資の比率（ブログは求人の100倍の労力がかかる）は一致しません。検索エンジンは、最も労力をかけたものではなく、大規模にインデックスできるものをクロールします。

企業ページはサイトマップに7,000以上のページがあるにもかかわらず、1日あたりわずか14回しかクロールされていません。これはクロールバジェットの枯渇問題です。求人ページがバジェットの大部分を消費しているため、企業ページはほとんど発見されません。夜間データがこの問題を明らかにしました。国勢調査がなければ、7,000の企業ページがクローラーにとって事実上見えない状態であることを知る由もなかったでしょう。

410が教えてくれること

国勢調査はHTTPステータスコードも追跡しています。最も興味深いステータスは410（Gone）です。

Google 410s:  7,614  (35.5% of crawls)
Bing 410s:    4,494  (42.3% of crawls)

クローラーリクエストの3分の1以上が、410を返す期限切れの求人ページにヒットしています。これらは、クローラーが最初に発見した時点では存在し、インデックスされ、その後削除された求人です。410は「このページは存在していましたが永久に削除されました。リクエストを停止してください」とクローラーに伝えます。

410の割合は減少傾向にあります。先週のGoogleの数値は8,858でしたが、今週は7,614です。クローラーは学習しています。検索エンジンがインデックスを更新するにつれ、ゴーストリクエストの数は日々減少しています。しかし学習は遅く、Bingの410率（42.3%）はGoogleの410率（35.5%）よりも高くなっています。Bingの方が削除シグナルの処理が遅いためです。

410のトレンドは、最も明確な夜間シグナルです。検索エンジンがサイトの現在の状態にどれだけの速度で収束しているかを教えてくれます。410率の上昇は、クローラーが適応できる速度よりも速くコンテンツを削除していることを意味します。410率の低下は、インデックスが追いついていることを意味します。均衡状態は410がゼロ、つまりクローラーがリクエストするすべてのページがまだ存在している状態です。

524問題

Cloudflareは、オリジンサーバーがタイムアウトウィンドウ内に応答しない場合に524を返します。大量デプロイの日（87コミット）に、国勢調査は以下を示しました。

Google 524s:  68  (0.3%)
Bing 524s:    0

24時間で68回のオリジンタイムアウト。それぞれが、Googlebotがページをリクエストし、CloudflareがRailwayにリクエストを転送し、Railwayが時間内に応答しなかったことを意味します。最も可能性の高い原因は、頻繁なデプロイ中のRailwayワーカーの再起動でした。各デプロイでアプリケーションが再起動され、リクエストがタイムアウトする短い期間が発生します。

クロールの0.3%で、Googleは壊れたサイトを見たことになります。524エラーはアプリケーションログには一切表示されませんでした。エラー発生時にアプリケーションが動作していなかったためです。このエラーはCloudflareとRailwayの間の空間にのみ存在し、クロール国勢調査を通じてのみ可視化されました。

翌朝、524のカウントはゼロに落ちました。デプロイが止まり、ワーカーが安定していました。夜間データは、問題が一時的なデプロイの連続によるものであり、構造的な問題ではないことを確認しました。

ウォームパス

クローラーが到着する前に、ウォームパスが実行されます。すべてのブログ記事、すべてのロケールバリアント、そして50の企業ページをCloudflareのエッジキャッシュ経由でフェッチします。目的は、Googlebotがページにアクセスした際に、オリジンレンダリングを待つのではなく、キャッシュされたレスポンスを取得できるようにすることです。

この違いは重要です。キャッシュされたブログ記事は80msで返されます。キャッシュされていないブログ記事はオリジンから1.5秒かかります。Googlebotには1秒あたりのリクエスト数で測定されるクロールレートバジェットがあります。レスポンスが速ければ、同じ時間枠でより多くのページがクロールされます。ウォームキャッシュは実効クロールカバレッジを2倍にします。

ウォームパスはユーザーには見えません。午前2時にキャッシュされたブログ記事の恩恵を受ける人間の訪問者はいません。しかし、ウォームパスは、Googlebotが夜間ウィンドウで300件のブログ記事を発見するか、600件を発見するかを決定します。人間にはメカニズムが見えなくても、SEOへの影響は確実です。

夜が明かすもの

毎朝、夜間ログを読みます。パターンはいつも同じで、ほとんどグリーン、いくつかの異常、調査に値するものが1つか2つ。このリズムは退屈です。しかし価値はその退屈なリズムの中にあります。

退屈な夜とは、デプロイが何も壊さず、クローラーが期待通りのものを見つけ、キャッシュが機能し、サイトが翌日のトラフィックに備えられていることを意味します。興味深い夜とは、何かが変化したことを意味します。新しいエラーパターン、機能しなくなったキャッシュルール、ランキングシグナルの変化を示すクロールバジェットのシフトなどです。

クロール国勢調査は、7,000の企業ページがGoogleから見えていないことを教えてくれました。日中のメトリクスではこれを発見できなかったでしょう。ユーザーアナリティクスは企業ページのトラフィックがゼロであることを示しており、需要が低いためだと考えていました。国勢調査は企業ページのクロール数がゼロであることを示しました。つまり、Googleはまだページを評価すらしていないのです。問題は需要ではなく、発見にありました。

524の分析は、Railwayのデプロイがオリジンタイムアウトウィンドウを作り出し、Googlebotがそれに遭遇していることを教えてくれました。アプリケーションモニタリングではこれを発見できなかったでしょう。タイムアウト中にアプリケーションが動作していないためです。問題はデプロイと利用可能状態の間のインフラストラクチャのギャップに存在していました。

410のトレンドは、BingがGoogleよりも削除シグナルの処理が20%遅いことを教えてくれました。これはSEOにとって重要です。期限切れの求人ページがBingのインデックスに長く残り、Bingを利用するサービス（DuckDuckGo、Yahoo）で検索するユーザーに古い結果を提供する可能性があるためです。

これらのインサイトはすべて夜間データから得られました。日中はユーザーの行動を教えてくれます。夜はあなたが見ていない間にインフラストラクチャが何をしているかを教えてくれます。どちらも重要ですが、SEOにとっては夜の方がより重要です。

FAQ

クロール国勢調査はどのように実施していますか？

国勢調査では、CloudflareのGraphQLアナリティクスAPI（httpRequestsAdaptiveGroups）をユーザーエージェントパターン（%Googlebot%と%bingbot%）でフィルタリングして使用しています。URLパスのプレフィックスでページを分類し、ステータスコードを集計します。スクリプトは30秒で実行され、GoogleとBingのクロール動作を並べて比較するレポートを生成します。

クロールデータにGoogle Search Consoleを使わないのはなぜですか？

Google Search Consoleは2〜3日の遅延があり、粒度も限られたクロール統計を報告します。Cloudflareの国勢調査はリアルタイム（過去24時間）で、Google Search Consoleでは報告されないステータスコード、コンテンツカテゴリ、キャッシュステータスを含みます。Google Search Consoleはトレンドの把握に有用で、国勢調査は運用上の意思決定に有用です。

ウォームパスはCloudflareのコストを増加させますか？

いいえ。Cloudflareのキャッシュは、ソースに関係なく任意のリクエストによって作成されます。ウォームパスは通常のリクエストクォータにカウントされる標準的なHTTPリクエストを使用します。無料プランでは、キャッシュされたレスポンスにリクエスト制限はありません。ウォームパス中のオリジンリクエストはRailwayの帯域幅にカウントされますが、15,000ページで平均50KBとすると、ウォームパス1回あたり約750MBです。

クローラーの動作が変わったらどうなりますか？

国勢調査は、変更に関係なくクローラーの動作をそのまま捉えます。クロールパターンの変化（求人ページの増加、ブログページの減少など）は、次の国勢調査で即座に反映されます。複数日のトレンドデータにより、その変化が一回限りの異常なのか、持続的な変化なのかが明らかになります。

ソース

この記事は、2026年3月以降、Cloudflare GraphQL APIを通じて収集された日次クロール国勢調査データに基づいています。国勢調査ツール：~/Projects/Utility/crawl_census.py。ナイトチェックツール：~/.claude/skills/nightcheck/。