ウェブに関する主な指標レポートの見方は？URLグループとデータなし

ウェブに関する主な指標のレポートは、記事ごとの通知表ではなく、似たページをまとめたグループの成績表です。 開いたら「データがありません」と出た人、あるいは「改善が必要」の行に自分の記事が1本だけ載っていて、その1本を直せば済むのか分からない人を想定して書いています。 読み終えるころには、いまの表示が「放っておいてよい状態」なのか「直して検証にかける状態」なのかを、公式ヘルプの記述で判断できるようになります。

このレポートで何も出ない段階なら、先に見る数字は別にあります。どの記事から手を入れるかを決める方法は、記事の最後に書きます。

「ウェブに関する主な指標」と「Core Web Vitals」は同じレポート

名前が2つあって戸惑うかもしれません。Search Console ヘルプのこのレポートのページは、日本語版の見出しが「Core Web Vitals レポート」で、本文の中には「ウェブに関する主な指標レポート」という呼び方も2か所残っています。どちらも同じレポートを指しています。

ヘルプはこのレポートについて、まずこう説明しています。

Core Web Vitals には、URL のパフォーマンスがステータス（低速、改善が必要、良好）別、指標タイプ（CLS、INP、LCP）別、URL グループ（類似するウェブページのグループ）別に示されます。

ステータスの英語名は Poor / Need improvement / Good です。Poor は直訳すれば「不良」ですが、日本語版ヘルプでは「低速」と訳されています。この記事ではヘルプの表記に合わせます。3つ目の「URL グループ別」が、このレポートを読み違えないための鍵です。

「データがありません」は、アクセスの少ないブログでは珍しくない

開いたとたんに「データがありません」と出ると、設定を間違えたように見えます。ヘルプが挙げている理由は2つです。

「データがありません」という画面が表示された場合は、Search Console のプロパティがまだ新しいか、CrUX レポートで利用できるデータが不足しているため、…

CrUX(Chrome ユーザー エクスペリエンス レポート)は、実際にユーザーがページを開いたときのパフォーマンスを匿名化して集めたデータで、このレポートはそれをもとに判定しています。プロパティを作ったばかりの場合は、ヘルプによると結果が出るまでに「プロパティの作成から数日かかることがあります」。何日たっても出ないなら、もう1つの理由、つまりデータが足りていない可能性が高くなります。

データが足りないと何が起きるのかは、ヘルプの「URL グループ」の節を読むと分かります。ただし、ここは日本語版の訳に気をつけたいところです。英語版はこう書いています。

In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report.

「ユーザーのプライバシーを守るため、URL グループがレポートに表示されるには、最低限のデータ量が必要」という意味です。日本語版は同じ箇所が「レポートに表示するデータ量を最小限に抑える必要があります」となっていて、逆の意味に読めます。日本語版のページには AI 翻訳を含む場合があるという注記も付いているので、ここは英語版の意味で読んでください。

そのうえでヘルプは、グループにデータが足りないときの扱いを書いています。Search Console は、同じ protocol://host:port の下にあるすべての URL をまとめた、上位の オリジン グループを作ります。個人ブログなら、https://example.com のように、プロトコルとホスト名が同じ URL 全部をまとめたグループと考えてください(http と https、www の有無が違えば別のグループです)。そして、そのオリジン グループについてはこう書かれています。

オリジン グループに十分なデータがない場合、表示されません（つまり、オリジン グループが複数ある場合を除き、サイトには、このレポートに表示するのに十分なデータがありません）。

つまり、似たページのグループで足りなければブログ全体にまとめ直し、ブログ全体でも足りなければ、このレポートには何も出ません。ヘルプはこの節と「データがありません」の節を結び付けて書いてはいませんが、私は、アクセスの少ないブログで何も表示されないのはこの仕組みのためだと読んでいます。何回の訪問があれば出るのか、具体的な数字はヘルプに書かれていません。

ほかにも、表示の対象を絞る条件が2つあります。

• 「このレポートに表示されるのはインデックスに登録されている URL のみです。このレポートは、インデックスに登録されている URL を網羅したものではありません。」
• 「URL グループのレポート対象のデータ量が LCP と CLS の両方について最低限に満たない場合、URL はレポートから除外されます。」

「データがありません」はエラーではないので、何かを直す必要はありません。測られていない以上、このレポートで良し悪しを判断する段階ではないということです。速度より先に見る数字は何かはページ表示速度はSEOに効くか、Core Web Vitalsより先に見る3つに書きました。

表に出ているURLだけ直しても終わらない理由

データが出ているブログで迷いやすいのは、表に出ている URL の扱いです。「改善が必要」の行を開くと、URL が1本か数本だけ並んでいることがあります。その記事だけが遅いように見えますが、ヘルプはこう説明しています。

表示される各 URL は、それぞれの URL グループを代表するものです。

問題の詳細の表についても「表の各行は、類似する複数の URL を表します。」とあり、表は最大200行です。グループの作り方はこう書かれています。

レポート内の URL は、ユーザー エクスペリエンスが類似するページにグループ化されます。LCP、INP、CLS のステータスはグループ全体に適用されます。

ヘルプは続けて、こうしたグループには共通のフレームワークがあり、成績が悪い原因も同じである可能性が高い、と想定しています。ブログで言えば、同じテーマ・同じテンプレートで出している記事は、まとめて同じ判定を受けやすいということです。表に出た1本は「このグループの代表」なので、直す対象はその1本ではなく、同じ作りの記事全体になります。サンプルの URL をクリックすると同じグループのほかのページが見られ、ヘルプによると並びはインプレッション数の多い順です。

ヘルプ自身も、このレポートは個別の URL を調べる道具ではないと書いています。

ウェブに関する主な指標レポートは、特定の URL のステータスを検出するためではなく、サイトの全体的なパフォーマンスを確認して、サイトの複数のページに影響を与える問題のトラブルシューティングを行うために設計されています。

1ページの数字を見たいときは、ヘルプが案内しているとおり PageSpeed Insights などの外部テストを使います。グループで判定するこのレポートと、基本は1ページ単位の PageSpeed Insights とで数字が合わないのは正常です。2つの違いはページ表示速度はSEOに効くかの「測り方」の節に表でまとめています。

「低速」「改善が必要」「良好」はどう決まるか

ステータスは、3つの指標の値で決まります。ヘルプの表に書かれている範囲はこうです。

Search Central のCore Web Vitals と Google 検索の検索結果についてでは、目標が「INP を 200 ミリ秒未満」「CLS スコアを 0.1 未満」と「未満」で書かれています。上の表は、レポートのヘルプの表の書き方(以下)に合わせています。

読むときに押さえたいのは3点です。

• グループのステータスは、いちばん悪い指標のものになります。ヘルプの例では、モバイルで CLS が「低速」、LCP が「改善が必要」の URL は、モバイルでは「低速」です
• モバイルとパソコンは別々に判定されます。同じ URL がモバイルでは「良好」、パソコンでは「改善が必要」ということもあります
• 表に出る値(グループ LCP など)は、過去28日間で訪問の75%がその値か、それより良い結果だった、という値です。日本語版ヘルプはグループ INP の説明が「この値以上であった」となっていますが、英語版は "had this value or better"(この値か、それより良い)です。ここも英語版の意味で読んでください

75%という線の出どころはweb.dev の Web Vitals の解説にあります。「Core Web Vitals の準拠状況を評価するツールでは、3 つの Core Web Vitals 指標すべてで 75 パーセンタイルの推奨目標値を満たしている場合、ページは合格と見なされます。」とあります(英語版は “should consider a page passing”=合格とみなすべき、です)。裏を返せば、4回に1回までの訪問がしきい値より悪くても「良好」になり得る一方、遅い回線の訪問者が増えれば、ページを変えていなくても判定は動きます。

優先順位について、ヘルプは「低速」から直すよう勧めたうえで、「「改善が必要」の URL は、改善の余地はありますが、「低速」の URL に比べると重要度は下がります。」と書いています。「改善が必要」だけが出ている状態は、急いで手を入れる段階ではありません。

グラフの数と表の数が合わないのは正常

グラフの上のタブの数字と、下の表の行の数字を足したものが合わないことがあります。これもヘルプに説明があります。グラフは1つの URL を、その URL にかかっているいちばん遅い問題で1回だけ数えます。表は、URL にかかっている問題ごとに数えます。

たとえば1つの URL に「低速」の問題と「改善が必要」の問題が1つずつあると、グラフでは「低速」として1回、表では「低速」の行と「改善が必要」の行の両方に数えられます。表の合計のほうが大きく見えるのは、同じ URL が複数の行に出ているからです。また、グラフの上のタブが数えているのは URL グループではなく URL の数です。

直したら[トラッキングを開始]、結果が出るまで28日かかる

ページサイズを小さくする(ヘルプは、リソースを含めて1ページ 500 KB 未満を勧めています)などして直したら、問題の詳細ページで[トラッキングを開始]を押します。ヘルプの「修正を検証する」の節は、判定のしかたをこう書いています。

28 日間、サイトのどの URL でも問題が発生しなければ、その問題は解決したと判断されます。いずれかの URL でその問題が発生したら、問題は未解決と判断されます。

すぐに結果が出ない理由は、続く注記を読むと分かります。

[トラッキングを開始] をクリックしても、Google による能動的なアクション（再インデックス登録など）は行われません。Search Console により、サイトの CrUX データに関する 4 週間のモニタリングが開始（再開）されるだけです。

押したからといって Google が見に来るわけではなく、直したあとのページを実際の訪問者が開き、そのデータが溜まるのを待つ仕組みです。訪問の少ないブログほど、データが溜まるのにも時間がかかります。直す前の数字と比べたいなら、押した日と直した内容を控えておいてください。

検証の状態として、ヘルプには次の6つが挙がっています。

不合格になったら、もう一度直して、検証の詳細ページから[新しい検証を開始]を押すよう案内されています。

何も変えていないのにステータスが変わったとき

記事に手を入れていないのに「良好」が「改善が必要」に変わることがあります。ヘルプはこのケースにも節を設けていて、もともと多くのページが境界の近くにあり、サイト全体に及ぶ小さな変化で境界を越えた可能性を挙げています。例はアクセスの急増や、画像を配信するサービスの遅延です。可能性は高くないとしたうえで、よく使われているブラウザの更新や、遅い回線の訪問者が増えたことも挙げています。

このレポートは実際の訪問のデータで測っているので、ページが変わらなくても、訪問者の側が変われば判定は動きます。ヘルプは、その時期のトラフィックに大きな変動がないかを確かめ、影響を受けたグループの LCP・INP・CLS の数値が境界の上にないかを見るよう勧めています。

このレポートの判定は、順位にどこまで効くか

Google のページ エクスペリエンスのドキュメントは、ランキング システムで Core Web Vitals が使われると書く一方、このレポートで良い結果が出ても上位表示が保証されるわけではないとも書いています。どちらか片方だけで判断しないほうが安全です。公式の文言の読み比べはページエクスペリエンスは順位に効く？に、個人ブログで速度に手を付ける順番はページ表示速度はSEOに効くか、Core Web Vitalsより先に見る3つに書いています。

この記事で引いた公式の文書は、Core Web Vitals レポートのヘルプ(日本語版・英語版)、Search Central の Core Web Vitals のページ、web.dev の Web Vitals の解説、ページ エクスペリエンスのドキュメントの4ページです(2026年10月6日に本文を取得して原文と照合しました)。

よくある質問

ずっと「データがありません」のままです。何か設定が必要ですか

設定で直るものではありません。ヘルプが挙げている理由は、プロパティが新しいか、CrUX のデータが不足しているかの2つです。プロパティを作ってから日がたっているなら、データが不足している可能性が高いです。ヘルプはオリジン グループにも十分なデータがなければ表示されないと書いており、私はアクセスの少ないブログで何も出ないのはこのためだと読んでいます(ヘルプはこの2つを結び付けては書いていません)。1ページの状態を確かめたいなら、PageSpeed Insights などの外部テストを使ってください。

「改善が必要」に出ている記事は1本だけです。その記事だけ直せばいいですか

その1本は、似たページをまとめたグループの代表です。ヘルプは、表に表示される各 URL はそれぞれの URL グループを代表するものだと説明しています。サンプルの URL をクリックして同じグループのほかのページを確かめ、同じ作りの記事全体を直す対象として考えてください。また、ヘルプは「改善が必要」を「低速」より重要度が低いものとして扱っています。

[トラッキングを開始]を押せば、すぐに再評価されますか

されません。ヘルプによると、押しても再インデックス登録などは行われず、CrUX データの4週間のモニタリングが始まる(または再開する)だけです。28日間どの URL でも問題が出なければ解決と判断されます。

INP だけデータが無いグループは、どう扱われますか

ヘルプがレポートに含める条件として挙げているのは、LCP と CLS の両方のデータです。「LCP と CLS のしきい値データがない URL グループはレポートに含まれません」とあり、INP のデータの有無はこの条件に入っていません。

まとめ

• 「ウェブに関する主な指標」と「Core Web Vitals」は同じレポート。日本語版ヘルプの見出しは「Core Web Vitals レポート」で、ステータスの表記は「低速」「改善が必要」「良好」(英語は Poor / Need improvement / Good)
• レポートは記事を1本ずつではなく、似たページをまとめた URL グループで判定する。表に出る URL はグループの代表で、直す対象は同じ作りの記事全体
• グループのデータが足りなければオリジン グループにまとめ直し、それでも足りなければ表示されない。「データがありません」の理由としてヘルプが挙げているのは、プロパティが新しいか、CrUX のデータが不足しているか。エラーではない
• ステータスはいちばん悪い指標で決まり、モバイルとパソコンは別。値は過去28日間で訪問の75%がその値か、それより良い結果だった値。「改善が必要」は「低速」より重要度が低い
• グラフは URL を1回、表は問題ごとに数えるので、合計が合わなくても正常
• 直したら[トラッキングを開始]。再インデックスなどは行われず、28日間の実際の訪問のデータで判定される
• 順位への効き方は、公式が「ランキング システムで使用される」と「上位表示は保証されない」の両方を書いている。片方だけで判断しない

このレポートで迷う原因のほとんどは、表に出た URL を「その記事の成績」として読んでしまうことです。グループの成績表として読めば、「何も出ない」も「1本だけ出る」も「直したのに変わらない」も、同じ仕組みで説明がつきます。

ここから先は、私が作ったツールの話です。

このレポートが「データがありません」のブログで先に効くのは、速度よりも、検索結果に出ている記事のタイトルや中身です。どの記事から直すかを決めるところを自動でやるツールを作りました。サーチコンソールのエクスポートをZIPのまま置くだけで、4.0〜20.5位のページを、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分け、この順に、同じ区分の中ではCTR機会差の多い順に並べて出します。 判定と候補3記事のCTR機会差の確認、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ このツールは、表示速度も Core Web Vitals も一切見ません。読むのはページごとの平均掲載順位・表示回数・CTRで、この記事で書いたレポートの読み方や修正の検証は、Search Console の画面でやってください。また、直したあとの効果を自動で追跡する機能もありません。掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。