Core Web Vitalsとクロールの関係は、公式の文書が別々の仕組みとして書いている。クロールの量に関わるのは、応答時間・エラー・読み込みと描画の速さで、Core Web Vitalsは利用者の体験の測定 ── 担当サイトの数字をどの画面で見るかを確かめる13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — 「速さ」は、クロールの文書と、Core Web Vitalsの文書で、別々に書かれている
   1. クロールの文書が書いていること
   2. Core Web Vitalsの文書が書いていること
2. 02 なぜ・背景 — 同じ「速い」という言葉に、測る場所が3つある
   1. 2つの文書が、別の読者に向けて書かれている
   2. ページ体験は「単独の信号ではない」
   3. 測る場所は3つある
   4. 「関係がある」と「関係があると書かれている」は別
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 「発リンク」と「リンクをたどる」
4. 04 型別 — 適用範囲、書かれていないこと、手順
   1. 🅰 どのサイトが当てはまるか
   2. 🅱 公式が書いていないこと
   3. 🅲 手順1 — 症状を、3つのどれかに分ける
   4. 🅲 手順2 — クロールの統計で、平均応答時間と5xxを見る
   5. 🅲 手順3 — Core Web Vitalsは、実際の利用者の値の画面で見る
   6. 🅲 手順4 — リンクの飛び先を、2つの数字に分けて書く
   7. 🅲 手順5 — 応答が遅い日を、原因の層に分ける
   8. 依頼主から「遅いからクロールされない」と言われたら
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — どの数字から見るか
   1. 状況ごとに、表で並べる
   2. 既存の記事との分け方
   3. 数字を報告するときの書き方
   4. 調べる道具
7. 07 当サイトで確かめたこと — 外から測った応答の最初の1バイトは、0.1〜0.3秒台だった
   1. 2026年11月9日14時台に、手元から測った値
   2. 確かめていないこと
8. 08 このテーマは、ここまで — 速さの話を、画面ごとに分ける
   1. これまでの記事
   2. 今回の記事の位置
   3. 2026年11月9日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書いてあるか — 「速さ」は、クロールの文書と、Core Web Vitalsの文書で、別々に書かれている

「ページが遅いと、Googleがクロールしてくれない」「Core Web Vitalsの点が悪いと、リンクをたどってもらえない」という話は、よく耳にする。この記事は、その話を、公式の文書が書いていることと書いていないことに分けて読む。結論を先に書く。公式の文書は、「速さ」を、クロールの量の話（Googleが取りに来たときの応答時間・エラー・読み込みと描画の速さ）と、検索結果の評価の話（Core Web Vitals）で、別々に書いている。筆者が読んだ範囲では、Core Web Vitalsの指標を名指しして、クロールの量と結ぶ文は見つからなかった。

クロールの文書が書いていること

クロールバジェットの文書は、Googleがサーバーに負担をかけずに取りに来る量を「クロール容量の上限」と呼び、「Every site starts with the same default, conservative crawl capacity limit」と書く（訳: どのサイトも、同じ既定の、控えめなクロール容量の上限から始まる）。上限は、いくつかの要因で上下する。1つ目は、サーバーの健康状態である。応答が安定して速ければ上がり、応答が遅くなったり、5xx（サーバーのエラー）を返したりすれば下がる。文書は、応答時間として、遅延と、最初の1バイトが届くまでの時間（Time-to-First Byte）を挙げている。

同じ文書には、ページの読み込みについての文もある。「If Google can load and render your pages faster, we might be able to read more content from your site」（訳: Googleがページをより速く読み込み、描画できれば、そのサイトからより多くの内容を読めるかもしれない）と書き、サーバーの応答時間と資源を最適化して、速く読み込めるようにすることを勧めている。ここで書かれているのは、Googleが取りに来たときの読み込みであり、Core Web Vitalsの名前は、筆者が読んだ範囲に出てこない。

Core Web Vitalsの文書が書いていること

Core Web Vitalsの文書は、これを「実際の利用者の体験を測る指標の集まり」と書く。英語では「Core Web Vitals is a set of metrics that measure real-world user experience」である（訳: Core Web Vitalsは、実際の利用者の体験を測る指標の集まり）。指標は、最大のコンテンツの表示（LCP）、操作への反応（INP）、レイアウトのずれ（CLS）の3つで、良い目安は、LCPが2.5秒以内、INPが200ミリ秒未満、CLSが0.1未満と書かれている。文書は、これが、ほかのページ体験の要素とともに、検索の中核の評価の仕組みが報いようとするものと合っている、と書く。クロールには、触れていない。

02 なぜ・背景 — 同じ「速い」という言葉に、測る場所が3つある

2つの文書が、別の読者に向けて書かれている

クロールバジェットの文書は、「大規模サイト」の運営者に向けて書かれている。Core Web Vitalsとページ体験の文書は、検索で成功したい運営者全員に向けて書かれている。同じ「速さ」でも、前者はサーバーが応答する速さ、後者は利用者の画面で起きる速さを指す。筆者の読みでは、両者が混ざるのは、「サイトが遅い」という1つの言葉が、2つの意味を持つからである。

ページ体験は「単独の信号ではない」

ページ体験の文書は、「Our core ranking systems look at a variety of signals that align with overall page experience」と書く（訳: 検索の中核の評価の仕組みは、ページ体験全体と合う、さまざまな信号を見る）。さらに「There is no single signal」（訳: 単独の信号は無い）と書き、Core Web Vitals、HTTPS、モバイルでの表示、広告の量、邪魔な全面表示、本文とそれ以外の分け方などを、見るべきこととして挙げる。Core Web Vitalsの点が良くても、それだけで上位に出る保証は無い、とも読める。

測る場所は3つある

測る場所	何の数字か	誰の体験か
クロールの統計情報レポート	Googleが取りに来たときの平均応答時間、合計の取得数	Googleのクローラー
CrUXと、それを使う画面	LCP・INP・CLS（75パーセンタイル）	実際の利用者
PageSpeed Insightsの試験部分など	条件をそろえた1回の測定	試験の機械

「関係がある」と「関係があると書かれている」は別

公式の文書を読むとき、筆者が気をつけているのは、書かれていることと、読み手が頭の中でつないだことを分けることである。たとえば、「サーバーの応答が遅いとクロールが減る」は、クロールの文書に書かれている。「Core Web Vitalsが悪いと順位に響くことがある」も、ページ体験の文書から、ある程度は読める。しかし、「Core Web Vitalsが悪いとクロールが減る」は、2つの文を、読み手がつないだ文である。つないだ文が正しいかもしれないが、台帳には「公式が書く」ではなく「筆者の仮説」と書く。

この分け方は、依頼主への説明でも使える。「遅いと検索に不利になります」と言うより、「応答の遅さは、取りに来る量に関わると書かれています。利用者の体験の数字は、別の評価の材料として書かれています。どちらを直したいかを決めましょう」と言うほうが、次の作業が決まる。

03 用語 — 出てくる言葉を、先にそろえる

「発リンク」と「リンクをたどる」

元の問いの「発リンクのクロール」は、あるページから外へ出るリンクを、Googleがたどることを指す、と筆者は読む。リンクをたどるのは、リンクの飛び先のページを、Googleが取りに行く動作であり、取りに行ったときの応答は、クロールの統計に出る。飛び先のページのCore Web Vitalsは、利用者の体験の数字で、別の場所に出る。この2つを同じ列に並べると、読み違える。

04 型別 — 適用範囲、書かれていないこと、手順

🅰 どのサイトが当てはまるか

クロール容量の話は、文書が「大規模サイト」向けと断っている。担当サイトが小さければ、クロールの量が足りなくて困る場面は、まれだと筆者は読む。公式の文書は、目安として、100万以上のページが週に1回ほど変わるサイト、1万以上のページが毎日のように変わるサイト、Search Consoleで「検出 - インデックス未登録」の割合が大きいサイトを挙げ、これらの数は「おおよその見積もり」で、厳密な閾値ではないと書く。Core Web Vitalsの話は、公開しているサイト全てに当てはまる。ただし、CrUXは、公開されていて、十分な訪問者がいるページや発信元にだけ、データがある、と書かれている。訪問者が少ないサイトは、数字が出ないことがある。

🅱 公式が書いていないこと

• Core Web Vitalsの点が悪いと、クロールの量が減るか（筆者が読んだ範囲で、指標を名指しして結ぶ文は無い）
• リンクの飛び先のCore Web Vitalsが、そのリンクをたどるかどうかを決めるか
• 応答時間が何ミリ秒を超えると、取りに来る量が下がるのか（具体的な値）
• Core Web Vitalsの重みが、ほかのページ体験の信号と比べて、どれだけか

🅲 手順1 — 症状を、3つのどれかに分ける

「遅いから」という言葉で相談されたら、まず症状を分ける。1つ目は、Googleが取りに来ない・来る量が少ない、2つ目は、取りに来たのに登録されない、3つ目は、登録されているが順位が低い、である。1つ目はクロールの統計、2つ目はインデックス登録の画面、3つ目は検索のパフォーマンスで見る。どの症状かを決めずに、速度の数字を見ても、答えに結びつかない。

🅲 手順2 — クロールの統計で、平均応答時間と5xxを見る

Search Consoleのクロールの統計情報レポートは、合計のクロール要求数、合計のダウンロード量、平均応答時間を出す。ヘルプは、サイトの応答が遅ければ、サーバーに負担をかけないよう、Googlebotは要求を絞る、と書く。英語では「If your site is responding slowly to requests, Googlebot will throttle back its requests to avoid overloading your server」である（訳: サイトの応答が遅ければ、Googlebotは、サーバーに負担をかけないよう、要求を絞る）。ホストの状態が緑かを見て、赤なら、robots.txtの取得、DNS、サーバーへの接続を確かめる、と書かれている。

🅲 手順3 — Core Web Vitalsは、実際の利用者の値の画面で見る

Core Web Vitalsは、Search Consoleの専用のレポートや、PageSpeed Insightsの実際の利用者の部分で見る。web.devは、CrUXが実際の利用者のデータを集め、PageSpeed InsightsとSearch Consoleが、それを使うと書く。試験の測定は、INPを測れず、開発中の確認に向く、と書かれている。数字を台帳に書くときは、どちらの値かを、必ず書く。

🅲 手順4 — リンクの飛び先を、2つの数字に分けて書く

「遅いページへのリンク」を点検するときは、飛び先のURLを10本選び、クロールの統計での平均応答時間と、利用者の値のLCPを、別の列に書く。同じ列に並べない。リンクそのものが切れていないかは、リンクの点検の道具で確かめる。

🅲 手順5 — 応答が遅い日を、原因の層に分ける

クロールの統計で、平均応答時間が悪かった日を見つけたら、その日に何が起きたかを、依頼先の担当者や、サーバーの管理者に、3つの問いで聞く。1つ目は、サーバーの負荷が高い時間帯だったか。2つ目は、更新や配信の作業が、その日にあったか。3つ目は、利用者のアクセスが、急に増えたか。Googleのクローラーだけが遅い、ということは考えにくいので、ほかの利用者にとっても遅かった可能性を、まず疑う。

応答時間の数字には、リンクされた資源（画像や部品のファイル）も、それぞれ別の応答として数えられる、とヘルプは書く。ページ1枚が遅いのか、資源が多いのかは、この画面だけでは分けられない。分けたいときは、別の道具で、1ページの読み込みの内訳を見る。

依頼主から「遅いからクロールされない」と言われたら

依頼主や、同僚から、この話を聞くことは多い。筆者なら、否定も肯定もせず、3つを返す。1つ目は、公式の文書が、応答の遅さとエラーが、取りに来る量に関わると書いていること。2つ目は、Core Web Vitalsは、利用者の体験の指標で、クロールの文書には出てこないこと。3つ目は、どちらも、担当サイトで数字を取れるので、数字を見てから話しましょうという提案である。

数字を取る前に、「遅い」の意味を聞く。画面が出るまでが遅いのか、押してから反応するまでが遅いのか、Googleが取りに来ないのか。意味が決まれば、見る画面が決まる。この確認は、10分もかからないが、画面を間違えると、直す作業が、数日むだになる。

05 明日、担当サイトで確認できることチェックリスト

以下は、担当サイトの「遅い」を、クロールとCore Web Vitalsに分けて、見る場所と数字を決める13項目である。1〜4番目はクロールの統計の確認、5〜8番目はCore Web Vitalsの確認、9〜11番目はリンクの飛び先の確認、12〜13番目は記録の確認である。チェックの状態は、使っているブラウザに保存され、サーバーには送られない。

• Search Consoleの設定から、クロールの統計情報レポートを開き、ホストの状態が緑か・赤かを、台帳に書く
• 同じレポートで、直近90日の平均応答時間のグラフを開き、最大の日と最小の日の値を、台帳に書く
• 同じレポートの合計のクロール要求数が、大きく動いた日を3日選び、日付と増減を書く
• 5xxを返したURLの数を、レポートの内訳から読み、0なら0と書く
• Search ConsoleのCore Web Vitalsのレポートを開き、モバイルとパソコンの、良好・改善が必要・不良のURLの数を、台帳に書く
• 不良のURLのうち、記事のURLを3本選び、LCP・INP・CLSのどれが悪いかを書く
• 同じ3本を、PageSpeed Insightsで開き、実際の利用者の値の欄があるか、ないかを書く
• 実際の利用者の値が無いURLは、CrUXにデータが無い、と台帳に書く（訪問者が少ないことがある）
• サイト内のリンクの飛び先を、10本選び、クロールの統計での応答時間と、利用者の値のLCPを、別の列に書く
• リンクの点検の道具で、サイト内のリンク切れの数を数え、0なら0と書く
• 相談を受けた「遅い」の話を、症状（取りに来ない／登録されない／順位が低い）の3つのどれかに、1行で分けて書く
• 台帳の各数字の隣に、画面の名前・測った日・測った範囲（URLの数）を書く
• 次の確認日を台帳に書き、その日に、平均応答時間と不良のURLの数を、もう一度取る

06 代替・他の選択肢 — どの数字から見るか

状況ごとに、表で並べる

症状	最初に見る画面	次に見るもの	公式が書くこと
取りに来る量が減った	クロールの統計	平均応答時間、5xx、ホストの状態	応答が遅い、またはエラーが多いと、取りに来る量を絞る
登録されない	インデックス登録の画面	該当URLの理由	クロールとは別の画面で、理由が書かれる
順位が低い	検索のパフォーマンス	ページ体験、内容の質	ページ体験は単独の信号ではない
利用者が遅いと言う	Core Web Vitals	LCP・INP・CLSのどれか	実際の利用者の体験の指標

既存の記事との分け方

当サイトには、同じ問いを公式ドキュメントで確かめた記事がある（Core Web Vitalsは、クロールやリンク評価に影響するのか ── 公式ドキュメントを確認する（2026年8月時点））。今回の記事は、その結論を繰り返さず、見る画面と数字の置き場所に軸をずらした。クロールの仕組みそのものは、「クロールバジェットを気にすべきサイトの条件 ── 2つの要素を確認する14項目（2026年9月時点）」と、「Search Console クロールの統計情報レポート ── 90日分のGooglebotの動きから読める8指標を確認する14項目（2026年9月時点）」で書いた。

数字を報告するときの書き方

画面をまたいだ報告は、読み手が混乱しやすい。筆者なら、1つの数字に、4つの言葉を添える。どの画面か、いつ測ったか、どの範囲か、誰の体験かである。たとえば「平均応答時間は何ミリ秒（クロールの統計・11月9日・直近90日・Googleのクローラー）」と書く。「LCPは何秒（Core Web Vitalsのレポート・11月9日・モバイルの記事のURL群・実際の利用者）」と書く。この2行は、並べて書かれていても、同じ「遅い」の話ではないと、読み手に伝わる。

範囲の書き方も、大事である。「サイト全体」と書いたら、実際は一部のURLの数字だった、という食い違いは、報告の信用を落とす。数字の隣に、URLの数を書く。

調べる道具

当サイトの🔧 【SEO】WEBサイトの 最大３ページ Lighthouse監査・チェックツール — 試験の測定の値を見る（利用には無料の会員登録が必要です）は、試験の値を見る道具で、実際の利用者の値ではない。リンクの飛び先の確認には、🔧 【UX】WEBサイト内のリンク漏れ・チェックツール — サイト内のリンクを、まとめて確かめるが使える。

07 当サイトで確かめたこと — 外から測った応答の最初の1バイトは、0.1〜0.3秒台だった

2026年11月9日14時台に、手元から測った値

2026年11月9日14時台に、手元のパソコンから、当サイトのトップ、ブログの1本、解説記事の1本を、1回〜2回ずつ開き、応答の最初の1バイトが届くまでの時間を測った。トップは0.24秒、0.13秒、0.16秒、ブログの1本は0.28秒、解説記事の1本は0.21秒、0.21秒、0.22秒だった。3ページとも、状態コードは200だった。この値は、手元の回線から測った少数の値で、Googleが取りに来たときの値ではない。Googleがどう取りに来ているかは、クロールの統計情報レポートで見る値である。

確かめていないこと

• 当サイトのクロールの統計の、平均応答時間と、ホストの状態
• 当サイトのCore Web Vitalsのレポートの、不良のURLの数
• 測った時間帯以外の応答時間

この3つは、この記事を書いた時点では、確かめていない。確かめたら、日付つきで、この章に書き足す。

この章の値は、少数の測定であり、平均や傾向として読まない。クロールの統計の平均応答時間は、数日から数十日の範囲の数字で、1回の測定とは、性質が違う。確かめたら、日付と範囲を添えて、この章に書き足す。確かめるまでは、「手元から測った値」と「Googleが見た値」を、別のものとして扱い、台帳の欄も分ける。報告の文にも、どちらの値かを、必ず書く。

08 このテーマは、ここまで — 速さの話を、画面ごとに分ける

これまでの記事

• 同じ問いを、公式ドキュメントで確かめたのは、「Core Web Vitalsは、クロールやリンク評価に影響するのか ── 公式ドキュメントを確認する（2026年8月時点）」である。
• ラボとフィールドの値の違いは、「PageSpeed Insightsの数字は「ラボ」と「過去28日の利用者」で別物 ── スコアの揺れとフィールドデータの読み方を確認する13項目（2026年10月時点）」で書いた。
• LCPの段階の見方は、「Cloudflareの実ユーザー計測が、LCPを4段階・INPを3段階に分けて見せるようになった。直す前に、いちばん長い段階を決める ── 自社の遅さがどの段階で起きているかを確認する13項目（2026年10月時点）」で書いた。
• INPの悪化が続いた話は、「CrUXの2026年8月分でもINPの悪化が続き、原因は公式にも分かっていない ── 自社の悪化を全体の傾向と切り分けて確認する13項目（2026年10月時点）」で書いた。

今回の記事の位置

これまでは、数字の読み方を、1つの画面の中で書いた。今回は、画面をまたぐ話を、画面ごとに分けた。公式が書くのは、クロールは応答の速さとエラー、検索の評価はページ体験の1つとしてのCore Web Vitalsである。2つを結ぶ文は見つからなかったので、結ぶのは、仮説として台帳に書く。

2026年11月9日 — この記事の確認日

クロールバジェットの文書、Core Web Vitalsとページ体験の文書、クロールの統計のヘルプは、2026年11月9日に開いた内容である。この日以降に文書が変わった場合は、05章の13番目の項目で、書き写した数字と文を、もう一度比べる。