LighthouseのSEOスコア・Best Practicesの配点と見方｜5カテゴリの採点基準【v13.5.0】

Lighthouseの数値スコアは、採点対象になった監査の重みによる加重平均で決まります。「該当なし」などの監査は重みが0になり、分母から除かれます。本記事の占有率はNavigationモードの既定設定で、重み付き監査がすべて採点対象になった場合の値です。重みは公開されている設定ファイルに数値で書かれているため、「直しても1点も動かない項目」と「1つで2割動く項目」は計測する前に判別できます。この記事では最新版 lighthouse 13.5.0（2026年9月18日リリース）の既定設定を一次情報として、SEO・Best Practicesを含む5カテゴリの実配点と、スコアの色分けや採点カーブの読み方を整理します。

まとめ

• v13.5.0のカテゴリは5つ（performance / accessibility / best-practices / seo / agentic-browsing）。PWAカテゴリはv12.0.0で削除済みです。
• スコアは90以上が緑、50〜89がオレンジ、49以下が赤。Performanceの各指標は、値がp10の位置で90点、中央値の位置で50点になる対数正規カーブで点数化されます。
• Performanceの重みはTBT 30%・LCP 25%・CLS 25%・FCP 10%・Speed Index 10%。INPは重み0で採点されません。
• Best Practicesは21監査・重み合計27で、is-on-https、deprecations、third-party-cookiesの3つが55.6%。CSPやHSTSの監査は重み0で、直しても点は動きません。
• SEOカテゴリはis-crawlableだけで31.00%。is-crawlableが不合格なら、他の監査をすべて通しても緑の90点には届きません。100点でも検索順位は保証されません。
• Agentic Browsingはv13.5.0で7監査になり、AIエージェント向けカタログ（ai-catalog.json）の検査が加わりました。0〜100点ではなく達成数の分数で表示されます。

Lighthouseの5カテゴリと版ごとの違い（v13.5.0時点）

Lighthouseは、Chromeを制御して対象ページを1回読み込み、その過程のトレースとDOMの状態を監査項目に照らして採点します。計測は実行した端末と回線の条件で行われるため、得られるのはラボデータです。実ユーザーの体験を集計したフィールドデータとは別物で、この区別がスコアの解釈をほぼ決めます。

採点対象はperformance、accessibility、best-practices、seo、agentic-browsingの5カテゴリです。2024年4月のv12.0.0でPWAカテゴリが削除されました。「PWAを含む5カテゴリ」「4カテゴリ」という説明は、現行の構成と一致しません。手元のレポートと説明が食い違う場合は、Lighthouseの版に加え、実行モード、選択カテゴリ、PageSpeed Insights側の提供範囲を確認してください。各リリースノートは、そのリリースが載るChromeの版を明記しています。

Chrome 156の安定版は2026年10月20日に出ています（Chromium Dash）。13.5.0のリリースノートは、PageSpeed Insightsへの反映を「2週間以内」としています。Chrome 149以前のDevToolsにはAgentic Browsingカテゴリがありません。

スコアの見方｜90・50の色分けと指標ごとの採点カーブ

90点以上が緑・50点未満が赤になる判定ライン

カテゴリスコアと各指標のスコアは、0〜49が赤（低い）、50〜89がオレンジ（改善が必要）、90〜100が緑（良好）で色分けされます。レポートの描画コードも合格を0.9以上、平均を0.5以上として同じ線を引いています。公式のスコアリング解説は「100の完璧なスコアを達成するのは非常に困難であり、期待されるものではない」と書いています。Performanceでは90点を目安とし、利用者の体験はフィールドデータでも確認してください。

SEOやBest Practicesの監査は、多くが合格か不合格かの2値です。カテゴリスコアは各監査のスコアを重みで加重平均した値なので、重みの大きい監査を1つ落とすと点が大きく下がります。どの監査がどれだけ効くかは後の章の配点表で確認してください。

指標値をスコアに換算するp10・中央値（モバイル／デスクトップ）

Performanceの指標は、計測値をそのまま点にしません。各指標に2つの基準点があり、値がp10ちょうどなら90点、中央値ちょうどなら50点になるよう対数正規カーブを当てはめます。基準点はHTTP Archiveの実サイトの分布から決められ、v13.5.0の各指標ファイルに次の値で書かれています。

読み方の要点は2つです。1つ目は、デスクトップの基準は指標ごとに異なるという点です。LCPの90点基準はモバイルの約半分ですが、TBTは4分の3で、CLSは同じ値です。LCP 2.4秒はモバイルなら90点以上ですが、デスクトップではちょうど50点です。デスクトップのスコアが低く出ても、モバイルより遅いとは限りません。2つ目は、モバイルのLCP 2.5秒とCLS 0.1がCore Web Vitalsの「良好」の基準と同じ値だという点です。ただし、ラボで90点でもフィールドの良好判定は推定できません。実ユーザーの75パーセンタイル値を別途確認してください。

公式解説によると、0.50〜0.92の範囲では指標値とスコアがほぼ直線の関係にあり、0.96付近から伸びが鈍ります。v13.5.0の採点関数でモバイルのLCPを計算すると、60点から80点への20点は約0.7秒の短縮で届くのに対し、95点から98点への3点にも約0.3秒の短縮が要ります。1点あたりに要る短縮幅は、高得点帯で約3倍です。

計測ごとにスコアがぶれる理由と5回中央値

コードを変えていなくても、Performanceスコアは実行のたびに数点動きます。原因は主にLighthouseではなく計測条件の側で、回線の混み具合、端末のCPU負荷、広告やA/Bテストによる配信内容の違いが典型です。DevToolsで計測するなら、拡張機能のスクリプトが混ざらないシークレットウィンドウを使います。

Lighthouseのばらつきの解説文書は「5回の中央値は1回の結果より2倍安定する」としています。改善の効果を判定するときは、1回の点数でなく複数回の中央値で比べてください。CIで自動化する場合はLighthouse CIが中央値の実行を選んでくれます。設定はLighthouse CIの使い方｜lighthouserc・assertの判定とGitHub Actions連携【@lhci/cli 0.15.1】で扱っています。

Lighthouseの実行手段と結果の読み分け（DevTools・PageSpeed Insights・CLI）

Chrome DevToolsのLighthouseパネルで測る手順

対象ページでDevToolsを開き、Lighthouseパネルでモード（Navigation / Timespan / Snapshot）、デバイス、対象カテゴリを選んで実行します。DevTools版はローカル環境やログイン後のページも測れます。DevToolsに載るLighthouseの版はChromeの版で決まり、差し替えられません。

PageSpeed Insightsが返すラボデータとフィールドデータの違い

PageSpeed InsightsはLighthouseによるラボデータと、Chrome UXレポート由来のフィールドデータを並べて表示します。数値がずれるのは異常ではありません。ラボは1回の計測、フィールドは28日間の実ユーザーの集計です。Googleがページエクスペリエンスの評価に使うのはフィールド側のCore Web Vitalsで、判定はしきい値で決まります。合格ラインと実測の方法はCore Web Vitalsとは：LCP・INP・CLSの基準値とweb-vitals・CrUX APIでの測り方【2026年10月】で確認できます。

npx lighthouseによるCLI実行とNode 22.19以上の要件

反復計測やレポートの保存にはCLIが向きます。実行にはNode.jsに加えてChromeのインストールが必要です。lighthouse 13.5.0のpackage.jsonはengines.nodeを>=22.19と宣言しています。

npx [email protected] https://example.com \
  --only-categories=best-practices,seo \
  --form-factor=mobile --output=json --output-path=./report.json

版を@13.5.0のように固定すると、DevToolsの更新に左右されず同じLighthouse版を使えます。比較時はChromeの版、実行端末、スロットリング、配信内容もそろえてください。--only-categoriesに存在しないカテゴリ名を渡すと、v13.0.0以降はエラーになります。

Performanceカテゴリの配点｜TBT30%・LCP25%・CLS25%の重み

採点対象の5指標と重み、採点されないINP・TTIの扱い

Performanceスコアは監査項目ではなく、指標のスコアの加重平均で計算されます。v13.5.0の既定設定ファイルの重みは次の通りです。

TBTとLCPとCLSで80%を占めます。FCPとSpeed Indexも合計20%で、最大20点分に相当します。INPは指標として存在するのに重み0です。ユーザーの実操作が要るINPは、1回のページ読み込みでは代表値が取れないためです。ラボでの近似として働くのがTBTで、重み30が割かれている理由もそこにあります。INPの区間ごとの改善手順はINPとは？Core Web Vitalsの応答性指標の基準値と3区間・改善手順にまとめています。

TTIは重み0の非表示グループに残っており、レポート画面には出ませんがJSON出力には含まれます。各指標の定義はWebパフォーマンス指標の一覧と使い分け｜TTFB・FCP・TBT・Speed Indexの基準で解説しています。

v13で削除された8監査とInsightsへの置き換え

v13.0.0（2025年10月10日）は旧監査を8つ削除しました。ただし全部がPerformanceにあったわけではありません。直前のv12.8.2の既定設定で確認すると、Performanceにあったのは5つ（first-meaningful-paint、no-document-write、offscreen-images、third-party-facades、uses-passive-event-listeners）です。font-sizeはBest Practicesの監査で、preload-fontsとuses-rel-preloadは既定設定に入っていない実験的監査でした。

削除の理由は実務判断に直結します。offscreen-imagesは「オフスクリーン画像はブラウザが既に優先度を下げている」ため結果に影響しにくい、third-party-facadesは「一部の開発者が無関係なサードパーティ製ファサードの使用に懸念を示した」ため、とされました。preload-fontsとuses-rel-preloadは「過剰に推奨してしまうリスク」から無効のままで、v12.8.2の実験的設定にも「preloadの助言はissue #11960が解決するまで保留」と注記があります。preloadを機械的に足す最適化は、v13でも推奨されていません。

代わりに前面に出たのが、cache-insight、lcp-discovery-insight、render-blocking-insightなど17のInsight監査です。v12.8.2の時点で非表示グループに存在しており、v13でinsightsグループへ移されて表示されるようになりました。いずれも重み0で、スコアではなく原因の特定に使う診断情報です。

Best Practicesカテゴリの21監査と配点｜スコアを動かす3項目

4グループの構成と重み合計27の内訳

Best Practicesは21監査で、Trust and Safety（9監査）、User Experience（3監査）、Browser Compatibility（3監査）、General（6監査）の4グループに分かれます。重みの合計は27で、うち8監査が重み0です。表示される項目の約4割はスコアに寄与しません。

スコアの55.6%を占めるis-on-https・deprecations・third-party-cookies

重み5の監査は3つあり、それぞれ27分の5＝18.5%です。合計55.6%で、Best Practicesスコアの過半をこの3監査が決めています。

重み5の3監査に対応する作業は、全リソースのHTTPS配信、非推奨APIの呼び出しの削除、サードパーティCookieへの依存の洗い出しです。次に効くのがpaste-preventing-inputsで、パスワード欄などで貼り付けを禁止するスクリプトを外すだけの作業に11.1%が割かれています。重み1の9監査は設定上の重み合計の33.3%を占めます。ただし、着手順は不合格項目の配点だけでなく、修正工数と利用者への影響を確認して決めます。

重み0で採点されないセキュリティ監査の実務上の扱い

誤解が多いのはここです。csp-xss、has-hsts、origin-isolation、clickjacking-mitigation、trusted-types-xssの5監査は、いずれも重み0です。Content Security PolicyやHSTSを完璧に設定してもスコアは1点も上がらず、未設定でも減点されません。baseline、js-libraries、valid-source-mapsも同じ情報提供枠です。

スコアを上げる目的でCSP導入を計画するのは、投資判断として誤りです。CSPやTrusted Typesは実際の攻撃を防ぐために入れるものです。逆に「Best Practices 100点だからセキュリティは問題ない」という報告が上がってきたら、重み0の5監査を個別に開いて確認してください。100点はこれらが未設定でも成立します。

SEOカテゴリの10監査とスコアの限界｜is-crawlableが31%

is-crawlableに31.00%を割り当てた設計意図

SEOカテゴリは採点対象の10監査と、手動確認扱いのstructured-data（重み0）で構成されます。特異なのはis-crawlableの重みで、設定ファイルには93 / 23という分数がそのまま書かれています。値は約4.043、他9監査の合計が9なので、占有率は4.043÷13.043＝31.00%です。

設定ファイルのコメントには、この監査が落ちたときにSEOカテゴリ自体が不合格になるよう31%以上を確保する、という計算式が書かれています。robots.txtやnoindexなどによって監査対象の全ボットが拒否され、is-crawlableが不合格になれば、document-title、meta-description、canonical、hreflangを全部通しても合格ラインに届きません。SEOスコアが伸びないときに最初に見るのはこの1項目です。

SEOスコア100でも検索順位が上がらない理由

SEOカテゴリが検査するのは、タイトルタグとメタディスクリプションの有無、リンクテキスト、alt属性、canonical、hreflang、HTTPステータス、robots.txtの妥当性といった技術的な最低条件です。コンテンツの品質、被リンク、検索意図との一致は対象外です。

Lighthouse自身がSEOカテゴリの説明に「Lighthouseがここで採点しない多くの追加要因が、Core Web Vitalsのパフォーマンスを含め、検索順位に影響しうる」と書いています。他社ツールが出す「SEOスコア」も、多くは同じ種類の技術チェックを点数にしたものです。SEOスコアは順位の予測値ではなく技術的な足切りのチェックリストです。残る不合格項目がインデックス登録や内容理解を妨げていないと確認できたら、点数だけを追うより、フィールドのCore Web Vitalsと本文の検索意図への適合を優先します。内部施策の全体像から見直したい場合は、SEO内部施策・キーワード設計の支援も用意しています。

v13でfont-size監査が削除された理由

font-size監査（本文が12px未満だと警告）は、v11系ではSEOカテゴリにありました。v12.0.0でBest Practicesへ移され、v13.0.0で削除されています。公式の理由は「小さいフォントは可読性の問題ではあるが、これが今日もSEOの懸念であるという兆候は無い」と「実行と保守の負荷が非常に高かった」の2点です。Best Practicesの監査数がv12.8.2の22から21に減った差分が、このfont-sizeの削除です。Lighthouseのために文字サイズを調整する必要はもうありません。

Accessibilityカテゴリの重み付け（axe-core準拠）と自動検出の限界

Impact×Tagsで決まる76監査の重み

Accessibilityは76監査で、うち18が重み0です。重みはDequeのaxe-coreが各ルールに付けるImpact（深刻度）とTags（分類）の組み合わせで決まり、v13.0.0で設定ファイルに明文化されました。

CriticalとSeriousの是正がスコアに直結します。名前の無いボタンはCritical（重み10）、コントラスト不足はSerious（重み7）です。着手順は、利用者への影響と修正工数も確認して決めてください。

自動検出が保証しない範囲と手動確認が必要な項目

Lighthouseはカテゴリ説明で「自動検出は問題の一部しか検出できず、ウェブアプリのアクセシビリティを保証しない」と明記しています。キーボードだけで操作を完了できるか、スクリーンリーダーの読み上げ順序、代替テキストが画像の内容を正しく説明しているかは、自動では判定できません。alt属性が空文字でもimage-alt監査は通ります。

Accessibility 100点の意味は「機械が検出できる範囲に問題が無い」ことです。WCAG 2.2 AA準拠を要件にするなら、スコアを根拠にせず手動確認の記録を別に残してください。達成基準の範囲はWCAGとは？最新版2.2の4原則・達成基準86件とAA適合の範囲で整理しています。

Agentic Browsingカテゴリ｜v13.5.0で7監査になったAIエージェント向け検査

7監査とagent-discoverabilityグループの構成

agentic-browsingカテゴリは、v13.2.0で試験的に追加され、v13.3.0（2026年5月7日）で既定設定に入りました。AIエージェントがページを見つけ、読み、操作できるかを検査します。v13.5.0ではard-schema監査が加わり、llms-txtとともに新設のagent-discoverabilityグループへまとめられました。

WebMCPの3監査はNavigationモードだけで動きます。v13.5.0では、登録ツールが40個を超えると「推奨しない」という警告が出るようになり、全フォームがWebMCPに対応しているときはwebmcp-form-coverageが該当なしではなく合格と表示されるよう変わりました。CLSがこのカテゴリにも入っているのは、レイアウトが動くページではエージェントのクリック対象がずれるためです。llms.txtの書き方はllms.txtとは？書き方・設置方法とv2の変更点、Googleが効果なしとする理由【2026年9月】で解説しています。

ard-schemaが見るai-catalog.jsonと、仕様側のard.jsonへの改名

ard-schemaは、AIエージェント向けのリソース目録を定めるAgentic Resource Discovery（ARD）仕様に沿ったカタログを検査します。v13.5.0は次の順でカタログを探し、見つかったJSONを仕様の適合テストにかけます。エラーがあれば0点、軽微な警告だけなら0.9点です。13.5.0が同梱するスキーマでは、ルートにspecVersion（値は"1.0"）とentriesが必須で、各エントリーはurlとdataのどちらか一方だけを持つ必要があります。

• robots.txtのAgentmap:行
• HTMLの<link rel="ai-catalog">
• HTTPのLinkヘッダーのrel="ai-catalog"
• いずれも無ければ/.well-known/ai-catalog.json

どれも無いサイトでは監査は「該当なし」になり、減点されません。注意したいのは名前のずれです。ARD仕様はv0.91（2026年8月26日、ステータスはProposal）で、置き場所を/.well-known/ard.json、リンクをrel="ard"に改めました。旧名のai-catalogは参照してもよい扱いに下がり、旧パスだけに置いた目録は「見つからない可能性がある」とされています。13.5.0は旧名しか見ないため、仕様どおりard.jsonだけを置いたサイトは「該当なし」と表示されます。npmの開発版（13.5.0-dev.20261023）では既にard.jsonを先に探し、旧名も読む実装に変わっています。新しく置くならard.jsonを選び、13.5.0の判定が該当なしでも気にしなくて構いません。

fraction表示の読み方と、対応を急がなくてよい条件

このカテゴリはcategoryScoreDisplayModeがfractionで、0〜100点ではなく「判定対象のうちいくつ合格」の分数で表示されます。レポートの集計コードは、該当なしと手動確認の監査を分母から外します。ai-catalog.jsonもWebMCPも持たないサイトでは分母が小さくなるため、分数を他サイトと比べても意味がありません。

公式のカテゴリ説明には「このカテゴリは開発中であり、変更される可能性がある」と書かれています。v13.2.0からv13.5.0までの約4か月半で、監査の追加、グループの再編、判定の変更が続きました。一般的なコーポレートサイトやメディアサイトが、いまWebMCPやARDに工数を割く必要はありません。予約や検索の操作をエージェント経由で提供する計画が具体的にある場合だけ、実装を検討してください。

着手して無駄にならないのは、アクセシビリティツリーの整備です。agent-accessibility-treeはAccessibilityカテゴリの検出結果のうち、ボタン名やフォームラベルなど対象ルールの違反を再利用するため、これらの修正が両カテゴリの改善につながります。

よくある質問

LighthouseのSEOスコアが100なら検索順位は上がりますか？

上がるとは限りません。SEOスコア100は「インデックスされている」ことの証明にもなりません。is-crawlableが検査するのは、そのURLのrobots.txt、robots系メタタグ、HTTPレスポンスのX-Robots-Tagによる拒否指定であり、実際にインデックスされたか、canonicalの指定先が意図どおりかは判定しません。構造化データのstructured-data監査も重み0の手動確認枠です。インデックスの状況はSearch ConsoleのURL検査で確認してください。

LighthouseにTTIやSpeed Indexは残っていますか？

Speed Indexは重み10の採点対象です。TTIは重み0の非表示グループにあり、JSON出力には含まれますが、改善してもPerformanceスコアは動きません。v13で削除されたのは監査項目のほうで、指標の構成は変わっていません。

PageSpeed Insightsの数値がDevToolsのLighthouseと違うのはなぜですか？

ラボ計測の実行環境が違うためです。PageSpeed Insightsはモバイルとデスクトップを別々に測定します。モバイルのラボ計測はGoogle側のサーバーで、既定のモバイル設定（画面412×823・デバイスピクセル比1.75のMoto G Power相当、低速4G相当の回線をシミュレーションで適用）に固定して実行します。DevToolsは手元のマシンのCPUと回線が土台になるため、同じページでも点数がずれます。比べるときはどちらか一方の環境にそろえてください。

Lighthouseは拡張機能版とDevTools版のどちらを使えばよいですか？

DevTools版です。公式の概要ページは「特別な理由がない限り、Chrome拡張機能ではなくChrome DevToolsを使用してください」と書き、理由として、DevToolsではローカルサイトと認証済みページをテストできるが拡張機能ではできない点を挙げています。どちらも無料です。

Lighthouseのカテゴリや監査数が記事の説明と違うのですが？

Lighthouseの版、実行モード、選択カテゴリなどの違いが考えられます。DevToolsに搭載される版はChromeの版で決まるため、本文の表で対応を確認してください。特定の版で検証したい場合は、CLIでnpx [email protected]のように版を固定します。レポートを比べるときも、DevToolsとCLIを混ぜずに一方にそろえるのが確実です。

関連記事

• Core Web Vitalsとは：LCP・INP・CLSの基準値とweb-vitals・CrUX APIでの測り方【2026年10月】
• Webパフォーマンス指標の一覧と使い分け｜TTFB・FCP・TBT・Speed Indexの基準
• Lighthouse CIの使い方｜lighthouserc・assertの判定とGitHub Actions連携【@lhci/cli 0.15.1】
• INPとは？Core Web Vitalsの応答性指標の基準値と3区間・改善手順
• llms.txtとは？書き方・設置方法とv2の変更点、Googleが効果なしとする理由【2026年9月】