サーチコンソールでCLSが100%不良と表示される原因を解説

Googleサーチコンソールを開いて、ページのCLSが100%不良と表示されているのを見つけたら、多くの場合はテンプレートを共有する複数のページがひとつのURLグループとしてまとめて評価されているだけです。サイト全体が壊滅的に悪いわけではなく、共通のヘッダーや広告枠、画像の表示位置など、テンプレート内のわずか1箇所が原因になっているケースがほとんどです。CLSはページの読み込み中や表示後に要素が意図せず動いてしまう度合いを数値化した指標で、Core Web Vitalsと呼ばれる3つの指標のひとつに含まれます。この記事では、なぜ100%という極端な数字が表示されるのかという仕組みの部分と、実際にCLSを悪化させている具体的な原因、そして自分のサイトでその原因を特定して直していく手順までを順番に説明します。

CLSの判定基準は0.25超で不良になります

CLS(Cumulative Layout Shift、累積レイアウトシフト)は、ページの読み込み中や表示後に、意図しない要素の移動がどれくらい起きたかを合計した指標です。Googleが提唱するCore Web Vitalsという3つの指標のうちの1つで、残る2つはLCP(Largest Contentful Paint、最大コンテンツの描画時間)とINP(Interaction to Next Paint、応答性の指標)です。INPは2024年3月にFID(First Input Delay)から置き換わりました。

記事を読もうとタップした直前に広告が表示されてボタンの位置がずれ、誤って別の場所を押してしまった経験は多くの人にあるはずです。ああいった現象の積み重ねを数値化したものがCLSだと考えると分かりやすいでしょう。判定の基準は次の表の通りです。

サーチコンソールの「ウェブに関する主な指標」レポートでは、この判定に基づいてモバイルとパソコンそれぞれで、不良URL・改善が必要なURL・良好URLの件数と割合がグラフで表示されます。ここで不良の割合が100%になっている状態が、この記事で扱うテーマです。

サーチコンソールでCLS不良が100%と出るのはURLグループ単位の判定が主因です

サーチコンソールの「ウェブに関する主な指標」レポートは、個別のURLを1本ずつ採点しているわけではありません。似たテンプレートやレイアウトを持つURL同士を1つのURLグループとしてまとめ、グループ単位で代表的な評価を表示する仕組みになっています。

ブログの個別記事ページがすべて同じテンプレート(共通のヘッダー、サイドバー、広告枠、フッターなど)を使っている場合を考えてみてください。そのテンプレートに含まれるどれか1つの要素、たとえば広告のスペースが確保されていない、共通ヘッダーの読み込みでガタつく、といった問題が原因でCLSが悪化していると、テンプレートを共有するすべてのURLが同じ不良判定を受けます。実際に問題があるのはテンプレートの中のたった1箇所であっても、そのテンプレートを使う数百、数千のページすべてが不良に分類され、結果として不良URLの割合が100%近くまで跳ね上がります。

逆に言えば、原因を1箇所直すだけで大量のページがまとめて改善するということでもあります。数字だけを見て慌てる前に、この集計の仕組みを理解しておくと対応の優先順位がつけやすくなります。

CrUXの実測データを28日間の移動平均で評価しています

サーチコンソールが参照しているのは、Chrome UX Report(CrUX)と呼ばれる、実際にChromeを使っている匿名ユーザーの実測データです。開発者が手元の環境でPageSpeed Insightsのラボデータを確認して良好な数値が出ていても、実際のユーザーの通信環境や端末性能、キャッシュの状態によっては、フィールドデータ側で悪い数値が観測されることがあります。格安SIMや低速回線、型落ちのスマートフォンでアクセスしてくるユーザーが多いサイトほど、フィールドデータ上のCLSは悪化しやすい傾向にあります。

評価の対象期間は直近28日間のローリング集計で、ページを訪れたユーザーの75パーセンタイルにあたる体験が判定基準になります。少し前にCLSの原因を取り除く改修をしたとしても、直近28日間のデータがすべて入れ替わるまでは、レポート上は不良のまま表示され続けます。この仕様を知らずに、直したのにいつまでも改善されないと戸惑うケースは珍しくありません。

アクセス数が少ないサイトほど数値が極端に振れます

公開して間もないサイトや、インデックスされているページ数自体が少ないサイトの場合、CrUXに蓄積されるサンプル数も少なくなります。サンプル数が少ない状態で、たまたま観測された少数のセッションでレイアウトシフトが起きていると、それだけで判定が不良に振れやすくなり、母数が小さいためパーセンテージが100%や0%といった極端な値として表示されやすくなります。アクセス数が増えて評価対象のデータが十分に蓄積されてくると、数値は徐々に実態に近い形へ落ち着いていきます。

画像と広告のサイズ未指定がCLS悪化の最大要因です

CLSを悪化させる原因の中でもっとも多いのが、画像や動画にサイズが指定されていないケースです。imgタグやvideoタグにwidth属性・height属性、あるいはCSSでの縦横比指定がないと、ブラウザは画像が読み込まれるまでその画像が占めるスペースを確保できません。読み込みが完了した瞬間にスペースが急に生まれ、前後のテキストやボタンが押し出されるようにレイアウトが変化します。

対策はシンプルです。すべてのimgタグにwidth="800" height="450"のようにサイズを明記しておけば、ブラウザは画像の実ファイルが届く前から必要なスペースを予約できます。レスポンシブデザインでCSS側から幅を可変にしている場合でも、HTML側にwidthとheightさえ書いておけば、ブラウザがそこから縦横比を自動計算してスペースを確保してくれます。最近はaspect-ratio: 16 / 9;のようにCSSのaspect-ratioプロパティで縦横比を固定する方法も広く使われるようになりました。以前はpadding-topのパーセント指定でアスペクト比を固定するやり方が主流でしたが、aspect-ratioのほうが記述が短く、モダンブラウザでは十分にサポートされています。

表示速度改善のためにloading="lazy"属性で画像を遅延読み込みさせているサイトも多いはずですが、この場合もwidthとheightの指定を省略してはいけません。指定を省略すると、画像が実際に読み込まれた瞬間にスペースがゼロから確保され、その分だけ下の要素が押し下げられます。逆に、ファーストビューに表示される画像には遅延読み込みを設定しないことも大切です。最初にユーザーの目に入る範囲の画像まで遅延させると、今度はLCP(最大コンテンツの描画時間)が悪化してしまいます。

広告も見落とせない原因です。Googleアドセンスなどの広告枠は、実際に広告が配信されて表示されるまで高さが確定しないことがよくあります。レスポンシブ広告やアンカー広告のようにサイズが可変な広告ユニットは、読み込まれた瞬間に周囲のコンテンツを押し下げ、CLSの数値を大きく悪化させます。広告を表示する枠にあらかじめmin-height: 250px;のようなCSSで最低限の高さを確保しておけば、広告の読み込み前後でレイアウトが大きく動くことを防げます。複数サイズの広告ユニットを使っている場合は、実際に配信されうる最大サイズを基準にスペースを確保しておくと安心です。

Webフォントと埋め込みコンテンツもレイアウトシフトを引き起こします

Webフォントを使っているサイトでは、フォントファイルのダウンロードが完了するまでの間、ブラウザはシステムに標準搭載されたフォールバックフォントで文字を表示します。フォントの読み込みが完了した瞬間に文字が置き換わり、文字幅や行間が変化することで、テキストの折り返し位置がずれてレイアウトシフトが発生します。読み込み中に文字を非表示にする挙動をFOIT、フォールバックフォントで一旦表示してから置き換わる挙動をFOUTと呼びます。

対策としては、@font-faceの記述にfont-display: swap;を指定する方法が広く使われています。font-display: swapを指定すると、フォントの読み込みが完了するまではフォールバックフォントで即座に文字を表示し、完了後にWebフォントへ差し替える挙動になります。ただしフォールバックフォントとWebフォントの文字幅の差が大きいと、置き換わったタイミングでレイアウトシフトが発生することがあるため、size-adjustのようなCSSプロパティで両者の見た目上のサイズを近づける調整も効果があります。重要なフォントファイルはlink rel="preload"で早い段階から読み込みを始めておくと、切り替えのタイミングが早まり影響を抑えられます。

YouTube動画の埋め込みや、X(旧Twitter)、Instagramの投稿埋め込み、Googleマップの埋め込みといった外部サービスのiframeも、サイズが確定するまでにタイムラグがあるとレイアウトシフトの原因になります。埋め込みコンテンツを配置する際は、あらかじめ表示領域の縦横比をCSSで固定しておく必要があります。

Cookie同意バナーとWordPressのプラグインも見落としやすい原因です

ページの読み込み後、JavaScriptによって画面上部や下部に動的にバナーやポップアップが挿入されるケースにも注意が必要です。Cookie同意バナーや、メルマガ登録の呼びかけ、アプリインストールを促すバナーなどが、既存のコンテンツの上に重なるのではなく、コンテンツを押し下げる形で挿入されると、その分がそのままCLSとしてカウントされます。これらの要素はposition: fixedやposition: stickyでレイアウトのフローから切り離し、既存コンテンツを押し下げないようにするのが基本の対策です。どうしてもコンテンツの一部としてバナーを挿入する必要がある場合は、あらかじめそのバナー用のスペースを空の枠として確保しておき、挿入後もサイズが変わらないようにしておきます。

要素を動かす表現をする際に、topやleft、width、heightといったレイアウトに影響するプロパティでアニメーションさせると、それ自体がレイアウトシフトとして計測されてしまうことがあります。視覚的な動きを表現したいときは、レイアウトに影響を与えないtransformプロパティ(translate、scaleなど)やopacityを使うのがベストプラクティスです。

WordPressを使っているサイトでは、テーマやプラグインの実装が原因でCLSが悪化しているケースも多く報告されています。人気テーマのCocoonではカルーセル機能がCLS悪化の原因になりやすいことが知られていますし、その他のテーマでもスライダー系プラグインや目次自動生成プラグイン、SNSシェアボタンを表示するプラグインが、読み込み完了後にレイアウトへ影響を与えることがあります。原因の切り分けには、プラグインを1つずつ無効化しながら計測し直す方法が有効です。FontAwesomeのようなアイコンフォントを使っている場合も、アイコンの読み込みが完了する前後でスペースが確保されずテキストがずれることがあるため、可能であればSVGアイコンに置き換えてサイズを固定しておくと安定します。

自分のサイトの原因はPageSpeed InsightsとDevToolsで特定できます

原因の候補が分かったところで、実際に自分のサイトのどこに問題があるのかを特定していく手順を見ていきます。

まずサーチコンソールの「ウェブに関する主な指標」レポートを開き、CLSの不良に分類されているURLの例をいくつか確認します。同じテンプレートを共有しているURL群であることが多いので、代表的な数ページをピックアップして次のステップに進みます。

ピックアップしたURLをPageSpeed Insights(pagespeed.web.dev)に入力し、モバイルとパソコンの両方で分析します。「診断」の項目に「レイアウトシフトを引き起こした要素を回避してください」といった指摘が出ていれば、どの要素が原因かが具体的にリストアップされます。ここで名指しされた要素こそが、直すべき対象です。

さらに詳しく調べたいときは、Chromeブラウザの検証ツール(DevTools)を開き、Performanceタブでページの読み込みを記録します。Experienceのレーンに赤いバーとしてレイアウトシフトが発生したタイミングが表示され、このバーをクリックするとシフト前後の要素のスクリーンショットや、原因となった具体的なDOMノードが確認できます。Google公式のChrome拡張機能「Web Vitals」を使えば、閲覧中のページのLCP、CLS、INPをリアルタイムに確認することもできますし、開発者向けにはweb-vitals JavaScriptライブラリをページに読み込ませて、レイアウトシフトが発生するたびにコンソールへ詳細情報を出力させる方法もあります。

CLSの原因はデバイスによって異なることがあるため、モバイルとパソコンは両方それぞれ個別に確認しておきましょう。モバイルではハンバーガーメニューの開閉アニメーションが原因になっている一方、パソコンでは横並びの広告枠が原因になっている、という例も実際に見られます。

修正後は「修正を検証」から28日間のモニタリングが必要です

原因を特定して修正を行った後の確認にも、いくつか押さえておくべきポイントがあります。

サーチコンソールの問題詳細画面にある「修正を検証」ボタンを押すと、Googleはそこから28日間、対象のURLで同じ問題が再発しないかをモニタリングします。この28日間に問題が発生しなければ、正式に解決済みとして扱われます。つまり修正してから結果が反映されるまで、最短でも数週間はかかるということです。

PageSpeed Insightsのラボデータ(シミュレーション環境での計測)は修正後すぐに改善を確認できますが、サーチコンソールが参照しているフィールドデータ(実ユーザーの計測値)は28日間の移動平均であるため、反映には時間差があります。慌てずに数週間単位で経過を見守る必要があります。

1つのテンプレートを直したつもりでも、トップページやカテゴリーページ、固定ページなど別のテンプレートに同種の問題が残っているケースもあります。サーチコンソールのURLグループを一つひとつ確認し、他のグループにも同じ問題が残っていないかをチェックしておくと安心です。

CLSは検索順位への影響より離脱率への影響のほうが大きいといえます

CLSを含むCore Web Vitalsは、Googleの検索アルゴリズムにおけるページエクスペリエンスの評価要素の1つとして使われています。ただしコンテンツの質や関連性といった他の要素に比べると、影響度は限定的だとGoogle自身も説明しています。とはいえCLSが悪いページはユーザーにとって単純にストレスが大きく、記事を読もうとタップした瞬間に広告が表示されてボタンの位置がずれ、誤って別の場所を押してしまうといった誤クリックや離脱の増加に直結します。検索順位を上げる施策というよりユーザー体験の改善という観点で、優先度をつけて取り組む価値は十分にあります。

不良URLが1件でもあるとサイト全体の評価に影響するのか気になる方もいるはずです。サーチコンソールの表示はあくまでURLグループ単位、指標単位での集計であり、サイト全体としての単一のスコアがあるわけではありません。ただしCore Web Vitalsが検索順位に影響しうる要素の1つである以上、不良判定を受けているURLグループについては優先度をつけて改善していくのが望ましい対応です。

小規模サイトで数値が不安定に動くのは、前述の通りアクセス数やCrUXのサンプル数が少ないサイトほど、少数のユーザー体験によって判定が大きく振れやすくなるためです。サイトの成長とともにデータが蓄積されれば、数値は徐々に安定していく傾向にあります。過剰な対策に手を広げるより、まずはサイズ未指定の画像や広告といった明らかな原因から着実に潰していくほうが結果的に近道になるでしょう。

サーチコンソールでCLSの不良判定が100%と表示されると強い不安を感じるかもしれませんが、その多くは似たテンプレートを共有するURLがグループ化されて一括評価される仕組みに起因しています。実際には1つか数個の共通要素、たとえばサイズ未指定の画像や広告枠、Webフォント、動的に挿入されるバナーなどを直すだけで、多数のページがまとめて改善するケースが少なくありません。まずはPageSpeed InsightsやChrome DevToolsで、実際にどの要素がレイアウトシフトを引き起こしているのかを具体的に特定すること。そして画像や広告、埋め込みコンテンツにはあらかじめ表示スペースを確保しておくこと。この2点を意識するだけで、CLSの数値は着実に改善していきます。改善後はサーチコンソール側の反映に数週間かかる仕様であることも踏まえて、焦らず数週間単位で経過を見守っていく必要があります。