2026年10月8日に、GoogleChrome web-vitalsの現行READMEを再読しました。READMEは実利用者のWeb Vitalsを測るライブラリとして、Core Web VitalsのLCP・INP・CLS、診断用のFCP・TTFB、標準ビルドとattributionビルド、onLCP・onINP・onCLSを案内しています。これは現行ライブラリの計測仕様であり、実サイトの端末別p75、改善効果、検索順位、合否を保証するものではありません。
検索に出ないページと、検索には出るものの操作しにくいページでは、調べる場所が違います。テクニカルSEOは、検索エンジンが情報を取得・理解できる状態と、読者が支障なく使える状態を整える仕事です。
技術的な最低条件を満たしたあとも、内容が検索する人の用事に合わなければ成果は決まりません。この記事では公開・登録の切り分けから入り、古い資料に残りやすいFIDと、現在のCore Web Vitalsの測り方まで確認します。集客全体の優先順位はSEOの全体像で扱います。
30秒で要点
- 「取得できるか」「登録対象か」「どのURLを代表にするか」「使いやすいか」を分けて調べる。
- robots.txt、noindex、canonicalは役割が異なる。秘密を守る仕組みには認証・認可が必要。
- 現行のCore Web VitalsはLCP・INP・CLS。良好判定は端末別の75パーセンタイルで見る。
- INPはクリック・タップ・キー操作から次の描画までを扱う。通信の完了時間でも、全操作の平均でもない。
- 実利用データで問題を探し、条件をそろえた検証で原因を追う。良好スコアは順位の保証ではない。
どこから読むか — 自分の状況から選ぶ
この記事は技術面の基礎を扱います。個別のタグ・ステータス・申告はそれぞれ別の記事にあります。
タグを入れたのに効かない。 正規URLの扱いはcanonicalタグは「指示」ではない、多言語の対応付けはhreflangは順位を上げるタグではない、更新日の申告はsitemapのlastmodは何を書く？。
URLの出し分け・閉じ方を決めたい。 リダイレクトと削除の使い分けは301・302・404・410の使い分け、検索結果が地域で分岐する話は検索結果は世界で一つではなくなった。
技術の前に役割を決めたい。 サイトに何をさせるかは集客より先に整えるべきWebサイトの役割。
最初に、検索に出したいURLを一つ決める
サイト全体の点数を見る前に、重要な商品・サービス・記事から代表ページを一つ選びます。公開したいURLと、ログイン後の会員ページや社内資料を混ぜないことが出発点です。
Googleの技術的な最低要件は、Googlebotがアクセスでき、正常なHTTP 200応答を返し、インデックス可能な内容があることです。HTTP 200はリクエストが正常に処理されたことを示す応答であり、本文の有用性や検索掲載を保証しません。
表が収まらない場合は、横にスクロールできます
| 確認すること | 調べる対象 | 見つけた問題に対する判断 |
|---|---|---|
| 公開してよい内容か | 個人情報、会員限定・社内向け情報 | 非公開なら認証・認可でアクセスを制限する |
| 本文を取得できるか | 応答、robots.txt、本文表示に必要な資源 | 公開対象を誤って遮断していないか確認する |
| 検索から外す指定がないか | HTMLのrobots meta、HTTPヘッダー | 意図せぬnoindexを調べる |
| 代表URLが一貫しているか | canonical、転送、内部リンク、サイトマップ | 同一・類似内容への指定が食い違っていないか調べる |
| 読者が操作できるか | モバイル表示、入力、表示速度、配置のずれ | 実際に使う流れで支障を切り分ける |
robots.txt、noindex、canonicalを使い分ける
robots.txtは、クローラーが取得する場所を制御するファイルです。遮断したURLがほかのページから発見されると、本文を取得しないまま検索結果に現れる場合があります。「クロールを止める」と「検索から消す」は同じではありません。公開ページを検索対象から外すなら、HTMLやHTTPヘッダーのnoindex指定を検討します。Googlebotがページを取得して指定を読めることが必要です。robots.txtで遮断してからnoindexを置いても、読み取れない問題が残ります。noindex自体に閲覧を制限する働きはありません。
canonicalは、同じ内容や非常によく似た内容を持つ複数URLのうち、代表にしてほしいURLを示します。Googleが最終的に選ぶため、指定どおりになる保証はありません。内部リンクやサイトマップも同じ代表URLにそろえます。内容も用途も違うページを、順位を集めたいという理由だけで同じcanonicalにしないでください。廃止する重複URLからの恒久転送は別の判断です。「登録済み」と「いま公開されている」を分けて確認する
管理権限のあるサイトでは、Search ConsoleのURL検査を使います。最初に表示されるのはGoogleが把握している登録版の情報です。ライブテストは現在のURLの取得可能性を調べますが、登録や検索への掲載を約束せず、Googleが選ぶ正規URLも予測できません。
結果には確認日時、検査したURL、登録版かライブ版かを添えて残します。サイトマップも発見を助けるものなので、送信完了を全ページ登録完了と扱わないことが大切です。
Core Web Vitalsの3指標と判定条件
Core Web Vitalsは、読者のページ体験を測る指標群です。web.devの定義による現行の3指標と良好の目安は次のとおりです。
表が収まらない場合は、横にスクロールできます
| 指標 | 見ている体験 | 良好の目安 |
|---|---|---|
| LCP：Largest Contentful Paint | 画面内で最も大きな画像やテキストなどの要素が表示されるまで | 2.5秒以内 |
| INP：Interaction to Next Paint | 操作に対して次の描画を返すまでの応答性 | 200ミリ秒以下 |
| CLS：Cumulative Layout Shift | 予期しない配置のずれの程度 | 0.1以下のスコア |
INPは200ミリ秒を超え500ミリ秒以下が要改善、500ミリ秒を超えると不良の範囲です。
これらは、手元の高性能PCで一度測った値への合格ラインではありません。モバイルとデスクトップを分け、対象データの75パーセンタイル、つまり小さい順に並べた下から75%の位置の値で判断します。3指標すべてが良好の範囲であることを確認します。
平均と75パーセンタイルの違いを、仮想のINPデータで見てみます。同じ端末区分の、測定できた100回の訪問があり、80回は150ミリ秒、20回は600ミリ秒だったとします。小さい順の75番目は150ミリ秒です。一方、平均は (80 × 150 + 20 × 600) ÷ 100 = 240 ミリ秒になります。平均を判定欄に入れると結論が変わりますし、75パーセンタイルが良好でも、遅かった20回の体験が消えるわけではありません。
これは集約を説明する計算例で、実測値ではありません。実際のレポートでは対象期間、端末、URL単位かサイトのオリジン単位か、データの有無を確認します。測定対象は全利用者と必ず一致するものではなく、INPでは対象となる操作がない訪問に値が出ない点にも注意が必要です。
FIDからINPへ変わったのは、名前だけではない
INPは2024年3月12日にFIDを置き換え、FIDのサポートは2024年9月9日に終了しました。「FID 100ミリ秒以下」という古いチェックリストを、そのまま現行の応答性の判定に使わないでください。
FIDが扱ったのは、最初の入力から処理が始まるまでの待ち時間です。INPの説明では、訪問中のクリック・タップ・キー操作について、入力待ち、イベント処理、次の描画までを含めます。スクロールやホバーそのものは対象ではなく、注文処理などのネットワーク通信が完了するまでの全時間でもありません。
ここには二段階の集約があります。まず一回の訪問について、通常は最も遅い操作を基にINPを求めます。操作が多い訪問では、50回の操作ごとに一つの最も遅い値を除く扱いがあります。そのあと、訪問をまたいだデータの75パーセンタイルを見ます。訪問内の全操作を単純平均してから「INP」と呼ぶと、指標が変わってしまいます。
INPが表示されない場合も、0ミリ秒の良好という意味ではありません。クリック・タップ・キー操作がなく、測定対象がなかった可能性を調べます。
実利用データで探し、操作を再現して原因を追う
フィールドデータは、実際の利用者から集めた測定値です。ラボデータは、端末や通信、操作を設定した検証から得る値です。両者は観測している条件が異なります。CrUX（Chrome User Experience Report）は、対象となるChrome利用者の体験を集計した公開データです。
表が収まらない場合は、横にスクロールできます
| 方法 | 判断に使えること | それだけでは分からないこと |
|---|---|---|
| CrUX由来のフィールドデータ | 対象利用者で体験の問題が起きているか | 具体的にどの処理が原因か |
| 自社での実利用計測（RUM） | 計測設計に応じたページ・操作の状況 | 全利用者の完全な代表性、未計測の動作 |
| 通常のLighthouse読み込み測定 | 読み込み時の問題やTBTなどの診断材料 | 操作後のINP、その後の利用全体 |
| 操作を再現するラボ検証 | 再現したクリックや入力の遅延原因 | 再現しなかった操作や端末の体験 |
TBT（Total Blocking Time）は、長い処理がメインスレッドをふさぐ程度を見る診断指標です。web.devはTBTをINPの手掛かりとしつつ、代替の測定値ではないと説明しています。「ラボではINPを測れない」と一括りにせず、入力を行う検証かを確認します。
たとえば実利用データでフォームの操作が遅い疑いがあれば、同じ入力と端末条件を再現し、どの処理が次の描画を妨げているかを調べます。詳しい改善手段はWebパフォーマンス完全ガイドで扱います。ラボで改善を確かめたあとも、実利用データで変化と副作用を追います。
手元の資料と計測を、一ページから更新する
まず古い設計書やダッシュボードから、FID、getFID、onFID、getLCPなどの表記を検索します。web-vitalsの公式READMEでは、現在の利用例としてonLCP・onINP・onCLSが示されています。最新版という言葉だけで更新せず、利用中のバージョン、読み込み方法、送信・保存・表示の項目まで確認します。
名称を変えただけのFIDとINPのデータを一本の推移に結合すると、測る対象が違うことを隠してしまいます。切替日を残し、同じ指標・条件で比較できる区間を選びます。個人情報を含むURLや操作内容を収集する場合は、必要性と取得範囲も見直してください。
最小の確認記録は、次の六項目です。
- 対象URLと、公開・検索掲載の意図。
- 取得状態、noindex、Googleが選んだ正規URL。
- 使用したツール、確認日時、データの対象期間。
- 端末区分、URLまたはオリジン、LCP・INP・CLSと欠測の有無。
- 再現した操作、変更箇所、ラボで確認できた範囲。
- 変更後に実利用データを見直す担当者と時期。
GoogleはCore Web Vitalsをランキングシステムで使用すると説明していますが、良好なスコアでも上位表示を保証しません。改善の成功条件は、読者の具体的な支障が減ったかと、検索の変化を観測できる状態にしたかに置きます。点数だけを追って、公開設定や本文の問題を見落とさないようにしてください。