画像の遅延読み込みは検索に不利？公式が見る2つの条件

表示速度を上げるために、サイト中の <img> に loading="lazy" を一括で付けた。そのあとで手が止まります——「スクロールしないと出てこない画像を、Googleはちゃんと見てくれているんだろうか」。

さらに厄介なのが、逆方向の話も同時に聞こえてくることです。ファーストビューの画像に遅延読み込みを付けると表示が遅くなる、という指摘。付けろと言われ、付けるなと言われ、結局どちらの基準で切り分ければいいのかが分からないまま、一括設定のまま放置されているサイトは少なくありません。

この記事では、自社サイトを自分で直せる担当者に向けて、公式ドキュメントに実際に書かれている記述だけを土台に、どの画像に loading="lazy" を付けてよいかを仕分ける手順を整理します。結論から言うと、判断軸は「lazy を使うか使わないか」ではなく、公式が挙げている2つの条件を満たしているかどうかです。

公式が書いているのは「lazy を使うな」ではない

まず土台になる記述を押さえます。Google 検索セントラルの「遅延読み込みコンテンツを Google 検索が認識できるようにする」には、ページ要約としてこう書かれています。

遅延読み込みは、ビューポート（画面に表示されている領域のことです）に入って見える状態になったときにコンテンツを読み込むようにするべきで、その方法としてはブラウザ組み込みの読み込み、IntersectionObserver API、JavaScript ライブラリなどがある。ユーザーの操作に頼らないようにすること。

同じページの本文側には、その理由にあたる記述があります。

ここで挙げた方法は、コンテンツを読み込むためにスクロールやクリックといったユーザーの操作に依存しない。これは、Google 検索があなたのページを操作しないため重要である。

この2文が、遅延読み込みの話でいちばん外してはいけない部分です。公式が問題にしているのは、遅延読み込みという手法そのものではなく、読み込みの引き金がユーザーの操作になっていないかという点です。

具体的に言えば、「画面に入ったら読み込む」仕組み（ブラウザ組み込みの loading="lazy" や IntersectionObserver API）は、公式が名前を挙げている方法です。一方、「ユーザーがボタンを押したら」「スクロールという操作を検知したら」といった、人の操作をきっかけにする作りは、この記述が避けるよう書いている側に入ります。Google 検索はページを操作しない、と明記されているからです。

ここは実装を見れば自分で判別できます。「もっと見る」ボタンを押さないと画像や記事本文が出てこない作りになっていないか。そこがまず1つ目の条件です。

2つ目の条件は「すぐ見える位置には付けない」

同じ公式ページには、もう1つの条件が書かれています。

ユーザーがページを開いたときにすぐ見える可能性が高いコンテンツには、遅延読み込みを追加しないこと。

なお、この文はこのあと「それは（That might cause）……」と続く形になっていて、抜粋できた範囲では何が起きるのかまでは読み取れません。ここでは「すぐ見える位置には付けない」という指示の部分だけを条件として扱い、その先の影響については断定しないでおきます。

表示速度の側から、より具体的に書いている資料もあります。web.dev の「ブラウザレベルの画像の遅延読み込み」には、こうあります。

ユーザーが最初にページを読み込んだときに見えている画像、とくに LCP 画像には、ブラウザ既定の eager 読み込みを使い、すぐ利用できる状態にすること。

LCP（Largest Contentful Paint）は、ページの中でいちばん大きな主要コンテンツが表示されるまでの時間を指す指標です。同じページには loading=lazy を使うのは……の外にある画像だけ、という書き出しの記述も見出し「images visible in the first viewport（最初のビューポートで見えている画像）」とともに置かれていますが、こちらも抜粋は途中で切れているため、区切りの正確な言い回しまでは引用できません。

同じページに載っているコード例のほうは、意図がはっきり読み取れます。最初に並ぶ画像には loading 属性が付いておらず、<!-- offscreen images -->（画面外の画像）というコメントの後ろに並ぶ画像にだけ loading="lazy" が付いています。

つまり公式資料が示している姿は、「全部 lazy」でも「全部 eager」でもなく、画面外の画像にだけ lazy を付けた状態です。一括設定はこのどちらの形にもなっていません。

その前に：一番大きく見える画像がLCPとは限らない

「ファーストビューの主要画像を eager にする」という方針は分かりやすいのですが、実際にやろうとすると最初につまずくのが「どれが主要画像なのか」です。ここで思い込みが入ります。

web.dev の「Largest Contentful Paint（LCP）を最適化する」には、判定のルールがはっきり書かれています。

内在サイズからリサイズされている要素については、報告されるサイズは、可視サイズと内在サイズのうち小さいほうになる。テキスト要素については、LCP はすべてのテキストノードを含む最小の矩形だけを考慮する。すべての要素について、LCP は CSS で適用された margin、padding、border を考慮しない。

そして、実例としてこう書かれています。

この Google 検索結果ページの例では、最大の要素は、画像やロゴが読み込みを終える前に表示されるテキストの段落である。

ここが実務では効いてきます。LCP の対象になるのは画像とは限らず、テキストの段落のこともある。さらに、大きな画像を CSS で小さく表示している場合、面積として数えられるのは小さいほうの値です。余白や枠線も面積には入りません。

「見た目で一番大きい画像＝LCP画像」という決め打ちで eager 化を進めると、本当の対象を外したまま作業を終える可能性があります。次の手順で、そこを含めて仕分けます。

ファーストビュー仕分け6ステップ

ここからは、この記事の独自部分です。公式の2条件と LCP の判定ルールを、実際のページ1枚に通す手順に落とします。1ページあたり10分ほどで終わります。

1. 対象ページを1枚だけ決め、スマートフォン幅で開く。 全ページを同時に見ようとすると終わりません。まず流入の多いページを1枚選びます。幅を狭いほうに合わせるのは、狭い画面ほど「最初に見える範囲」が小さくなり、eager にすべき画像が絞り込みやすくなるためです。
2. スクロールせずに見えている範囲をそのまま画面キャプチャし、写っている画像をすべて書き出す。 記憶で書かない、というのがこの手順の要点です。背景に敷いたビジュアル、ロゴ、アイコン、離脱防止のバナー——キャプチャを取ると、思っていたより多くの画像がこの範囲に入っていることが分かります。
3. 書き出した中から面積が最大の候補を選ぶ。ただし公式のルールで測る。 大きな画像を CSS で縮小表示しているなら、数えるのは表示されている小さいほうです。余白と枠線は面積に含めません。そしてテキストの段落も候補に入れます。見出しや導入文が画像より広い面積を占めているなら、そちらが対象になっている可能性があります。
4. 手順2で書き出した画像の loading 属性を、HTMLソースで1つずつ確認する。 ブラウザでソースを表示し、画像のファイル名で検索すれば見つかります。ここで loading="lazy" が付いていた画像が、修正候補です。
5. スクロールしないと見えない画像側は、読み込みの引き金を確認する。 見るのは「lazy が付いているか」ではなく、人の操作をきっかけにしていないかです。「もっと見る」ボタンを押さないと出てこない、スクロールの検知処理を自前で書いている、といった作りになっていないか。ここが公式の1つ目の条件に対応します。
6. 境界線上の画像は、lazy を外す側に倒す。 画面の高さギリギリにある画像、端末によって入ったり入らなかったりする画像は、判断に時間をかけるほどの差が出にくい部分です。判断コストを使うより eager にしておくほうが、手順としては速く終わります。

6ステップを商品一覧ページに通してみる

抽象的なままだと使いにくいので、よくある構成で1回通してみます。商品一覧ページで、上部に大きなキャンペーン画像、その下に商品カードが30枚並ぶページを想定します。

手順1〜2：スマートフォン幅で開いてキャプチャを取ると、スクロールなしで見えていたのは「ロゴ」「キャンペーン画像」「商品カード2枚」の4点でした。カードが2枚見えていたのは想定外です——設計時の想定では1枚のつもりでした。

手順3：面積が最大なのはキャンペーン画像に見えます。ただし確認すると、この画像は横1600pxの素材を画面幅に合わせて縮小表示していました。公式のルールでは、報告されるのは可視サイズと内在サイズの小さいほう。ここでは表示されている側の値になります。さらに、その下に大きめの文字でキャッチコピーが2行入っており、テキスト段落も候補として書き留めておきます。

手順4：ソースを確認すると、キャンペーン画像にも商品カードの画像にも、一律で loading="lazy" が付いていました。テンプレート側で共通の画像コンポーネントを使っているため、全部に付いた状態です。これが典型的な一括設定の姿です。

修正はこうなります：キャンペーン画像と、見えていた商品カード2枚から loading="lazy" を外す。3枚目以降のカードには残す。ロゴは小さいので優先度は下がりますが、同じ範囲にあるので外す側に含めておきます。

手順5：残りのカードは、無限スクロール式で読み込まれる作りでした。ここは属性の話ではなく、次章の確認事項に進みます。

手順6：ちょうど画面の境目にあった3枚目のカードは、端末によって見えたり見えなかったりします。悩まず eager 側に含めて終わりにします。

かかった時間は10分ほどですが、変わったのは「30枚全部に lazy」から「先頭3〜4枚だけ eager」への切り替えです。作業量としては属性を数カ所外すだけで済みます。

仕分け判定表

手順を毎回思い出さなくていいように、判断を表にしておきます。

いちばん下の行だけ、対処が属性の付け外しではありません。ここは実装そのものを、画面に入ったら読み込む形（ブラウザ組み込みの読み込み、IntersectionObserver API、JavaScript ライブラリ）に寄せる話になります。

見落としやすい3つの周辺項目

仕分けが終わったあとに、あわせて確認しておきたい点が3つあります。

1つ目は無限スクロールです。 公式ページの要約には、こう書かれています。無限スクロールでは、コンテンツのかたまりごとに固有で永続的な URL（例: ?page=12）が必要である。 商品一覧やお知らせ一覧を無限スクロールで実装している場合、2ページ目以降の中身にたどり着く URL が存在しているかを確認します。スクロールでしか到達できない状態は、この記述が求めている形にはなっていません。

2つ目は、画像そのものの置き方です。 「Google 画像検索の SEO ベスト プラクティス」の要約には、Google 検索向けに画像を最適化するには、HTML の画像要素を使い、<img> に src と説明的な alt 属性を含めること、そして CSS 画像は避けること。画像サイトマップを活用することとあります。遅延読み込みの設定を丁寧に詰めても、その画像が CSS の背景として置かれていれば、この記述が勧めている形から外れます。仕分けの過程でソースを開くので、そのついでに確認しておくと二度手間になりません。alt の書き方そのものは画像のalt属性の書き方にまとめています。

3つ目は CDN です。 同じページには、他のドメインの URL を追加できるため、画像をホストするのに CDN（コンテンツ配信ネットワーク）を使える。CDN を使っている場合は、Search Console で CDN のドメインの所有権を確認することが勧められる。そうすれば、見つかったクロールエラーを知らせてもらえるという記述があります。画像を別ドメインから配信しているサイトでは、この所有権確認が抜けていることがあります。

公開前の自己点検リスト

作業が終わったら、次の5点を確認します。すべて自分の環境で確かめられます。

• スクロールせずに見える範囲の画像から loading="lazy" を外した（キャプチャに写っていた画像すべて）
• テキスト段落を含めて面積最大の候補を確認した（「大きい画像＝LCP」で決め打ちしていない）
• 画面外の画像には lazy が残っている（全部 eager に倒していない）
• 人の操作をきっかけに読み込む作りが残っていない
• 無限スクロールを使っている場合、各かたまりに固有の URL がある

なお、この作業で表示が速くなったとしても、それが検索順位の変化として表れるかどうかは別の話です。速度と順位の関係をどう見るかは表示速度を改善しても順位が変わらないときの見方に整理していますので、期待値の置き方はそちらを参考にしてください。

Wemiro では、公開中のページの画像の設定状況を一覧で確認できるようにしています。1ページずつソースを開く前に、一括設定になっているテンプレートを先に見つけたい場合に使えます。

明日から変えられること

長くなったので、持ち帰る形にまとめます。

• 判断軸を「lazy を使うか使わないか」から、公式が挙げる2条件——(1) 読み込みの引き金が人の操作になっていないか、(2) すぐ見える位置に付けていないかに切り替える。
• 「どれが主要画像か」を見た目で決めない。リサイズされた要素は小さいほうの値で数え、余白と枠線は含まず、テキスト段落も候補に入る。
• 一括設定は、公式資料が示す「画面外の画像にだけ lazy」という形にはなっていない。先頭の数枚だけ外すのが実際の修正になる。
• 迷った画像は eager に倒す。判断に時間をかけるより手が早く終わります。

まずは流入の多いページを1枚だけ選んで、スクロールなしのキャプチャを取ってみてください。そこに何枚の画像が写っているかを数えるところから、作業の量が見えてきます。