WEBサイト画像SEOの基本 ── alt属性・次世代フォーマット・遅延読み込みを、公式ガイドで確認する14項目（2026年9月時点）
画像SEOの基本 ── alt属性・次世代フォーマット・遅延読み込みを、公式ガイドで確認する14項目（2026年9月時点）
目次
01 いま最新版は何か — Google公式ガイドが2026年3月に整理した「画像SEO」の骨子
Google公式ガイドが示す、画像SEOの骨子
Google Search Centralが公開している画像SEOのガイドは、2026年3月2日時点で最終更新されています。このガイドが求めているのは、突き詰めると「画像1枚ごとに、何が写っているかをテキストで示す」ことと、「画像そのものを軽く、速く配信する」ことの2つに集約できます。前者の中心は代替テキスト（alt属性）とファイル名で、後者の中心は次世代フォーマットと遅延読み込みです。どちらも技術的には数行のHTML属性を書くだけの作業ですが、「とりあえず全部の画像にaltを書いておけばいい」という理解では、後半で見る「装飾画像」の扱いを取り違えます。
この2つの柱は、担当する部署が分かれやすいという特徴もあります。alt属性やファイル名はコンテンツを書く担当者、次世代フォーマットや遅延読み込みは実装を担当するエンジニアが扱うことが多く、どちらか一方だけを整えても、画像SEOとしては半分しか進んでいません。この記事では、両方の担当者が同じ基準を参照できるよう、公式ドキュメントの記述をそのまま引用しながら整理します。
公式ガイドは、良い代替テキストの例としてalt="Dalmatian puppy playing fetch"を挙げ、alt="puppy"よりも具体的で説明的な書き方を推奨しています。一方で、キーワードを詰め込んだ長い代替テキストは避けるべきだとも明記しており、「詳しく書く」と「キーワードを並べる」は別の作業だという線引きがされています。
この線引きは、favicon（サイトアイコン）のような小さな画像にも当てはまります。favicon自体はページ内で装飾に近い扱いを受けることが多く、複数サイズ・複数形式のファイルを揃える必要があるため、手作業で1つずつ作ると抜け漏れが起きやすい領域です。当サイトの🔧 favicon自動作成ツールのように、必須ファイル一式をまとめて生成できる手段を使うと、フォーマットやサイズの取りこぼしを減らせます。
なぜ「altを埋めればいい」では足りないのか
ファイル名についても、公式ガイドはmy-new-black-kitten.jpgのような短く説明的な名前を推奨し、IMG00023.JPGやimage1.jpgのような連番・汎用名を避けるよう述べています。ここまではよく知られた内容ですが、公式ガイドが対応フォーマットとして挙げているのはBMP・GIF・JPEG・PNG・WebP・SVG・AVIFの7種類で、どれを使うかによって配信速度が変わり、配信速度はページの読み込み体験を左右するCore Web Vitalsの指標にも直結します。alt属性・ファイル名・フォーマット・遅延読み込みは別々の話題に見えますが、実際には「画像を、正しい形で・正しいタイミングで読ませる」という1つの作業の別の側面です。この記事では、それぞれの根拠を公式ドキュメントで確認しながら、自分のサイトで今日から点検できる形に翻訳します。
02 なぜ・背景 — 画像は、ページの中でいちばん重くなりやすい要素
画像は、ページの中でいちばん重くなりやすい
ページの表示速度を測る指標のひとつにLCP（Largest Contentful Paint）があります。web.devの解説記事は、LCP候補として考慮される要素に<img>要素、<svg>内の<image>要素、<video>要素のポスター画像を挙げており、記事のアイキャッチやヒーロー画像が、ページの中でLCP要素になる場面が多くあります。同記事は「サイトはLCPを2.5秒以内に収めることを目指すべき」と述べており、この基準は全ユーザーの75パーセンタイル（下から75%目にあたる利用者の体験）で評価すべきだとも明記しています。画像1枚の読み込みの遅さが、この基準を直接押し上げる要因になり得ます。
画像検索・AI Overviewsが、画像の役割を広げている
archives/107で扱ったとおり、Google画像検索は自身の周年に合わせて機能を拡張し続けており、AI Overviewsが画像を生成して回答に含める場面も増えています。検索結果の中で画像が占める役割が広がるほど、画像に付随するテキスト情報（alt属性・キャプション・周辺のテキスト）が、その画像が何を示しているかをGoogleに伝える唯一の手がかりになります。公式ガイドが「画像の内容と関連性のある画像を選ぶこと」「ロゴのような汎用画像は避けること」と述べているのも、この文脈で読むと理解しやすくなります。画像は単なる装飾ではなく、テキストと同じ重みで評価される情報源として扱う必要があります。
画像に求められる水準が上がっているのは、検索結果の中だけではありません。Merchant Centerの商品画像で扱ったとおり、Google Merchant Centerは2027年1月31日から、商品画像を全カテゴリで500×500ピクセル以上に統一する方針を示しており、この基準を満たさない画像には既に2026年4月14日から警告表示が始まっています。検索結果向けの画像SEOと、ショッピング向けの画像要件は別の仕組みですが、「画像は説明用の添え物ではなく、それ自体が評価対象のコンテンツである」という方向性は共通しています。ECサイトを運営していない場合でも、この動きは画像に求められる水準がサイトの種類を問わず上がっていることの一例として読めます。
03 この記事で出てくる用語
代替テキスト（alt属性）と装飾画像
用語
代替テキスト（alt属性）:画像が読み込まれない場合や、画面読み上げソフトを使っている利用者に、画像の内容をテキストで伝えるHTML属性です。Google公式ガイドは「画像についてのメタデータを提供する上で最も重要な属性」と位置づけており、alt="Dalmatian puppy playing fetch"のように具体的で説明的な文を推奨しています。
用語
装飾画像:情報を伝えることを目的とせず、見た目を整えるためだけに置かれている画像です。web.devのアクセシビリティ学習コンテンツは、装飾画像の例としてUIのアイコンや、本文で既に説明されている内容の視覚的な補助画像を挙げ、「装飾画像である場合は、alt=""（空の代替テキスト）を指定して、支援技術から無視されるようにする」と説明しています。同コンテンツは、alt属性が「空であること」と「そもそも無いこと」は別だとも明記しており、属性が無いと画面読み上げソフトがファイル名などを読み上げてしまう可能性があるとしています。
LCP と 画像サイトマップ
用語
LCP（Largest Contentful Paint）:ページの表示中に、ビューポート内で最も大きな要素が描画されるまでの時間を測るCore Web Vitalsの指標のひとつです。web.devは、画像は読み込みが完了するまで「描画された」とはみなされないと説明しており、読み込みが遅れている画像がある間は、より小さい別の要素が一時的にLCP候補として扱われることがあるとしています。
用語
画像サイトマップ:通常のクロールでは見つけにくい画像のURLを、Googleに直接伝えるための仕組みです。Google公式ガイドは、画像サイトマップが特に有効な場面として「サイトがJavaScriptのコードで読み込んでいる画像のように、通常であれば見つけられない可能性がある画像」を挙げています。1つの<url>タグには最大1,000個の<image:image>タグを含めることができます。
04 型別 — 公式ガイドの適用範囲・測っていないこと・手順
🅰 適用範囲 と 🅱 この記事が測っていないこと
🅰 適用範囲:公式ガイドの推奨事項は、HTMLの<img>タグで配置された画像に対して当てはまります。ガイドは明確に「CSSの背景画像として設定された画像は使用しないこと」と述べており、CSSのbackground-imageで表示している画像は、画像SEOの評価対象になりません。装飾目的の画像をあえてCSSで実装する選択肢は、web.devのアクセシビリティ学習コンテンツも「理想的には、装飾画像はHTMLではなくCSSで含めるべき。この方法なら空のalt属性そのものが不要になる」と述べており、装飾画像をCSS側に寄せることも、alt属性の運用を悩まずに済ませる一つの手段になります。
🅱 この記事が測っていないこと:Google公式ガイドは、良いalt属性を書けば検索順位が何位上がる、といった具体的な影響度は示していません。公式ガイドが述べているのは「役立つ、情報量の多いコンテンツを作ること」という方向性であり、alt属性1つの効果を単独で切り出して測定する手段は、公式ドキュメントの中には用意されていません。また、次世代フォーマットの圧縮効率についても、web.devは「WebPとAVIFは、一般的に旧来のフォーマットより優れた圧縮を提供する」と述べるにとどまり、具体的な圧縮率の数値までは示していません。自社サイトでどれだけ軽量化できるかは、画像ごとに実際に変換して比較する必要があります。同記事はアニメーション画像についても触れており、GIFは256色に制限され、同等の内容を動画形式で配信する場合よりファイルサイズが大幅に大きくなると述べています。06章の比較表では、この点も踏まえてフォーマットごとの向き不向きを整理しています。
🅲 手順 — 画像を1枚ずつ点検する4段階
実際の点検は、次の4段階で進めます。第一に、ページ内の画像を「情報を伝える画像」と「装飾目的の画像」に分類します。第二に、情報を伝える画像には具体的な代替テキストを、装飾目的の画像には空のalt属性を設定します。第三に、画像がファーストビュー（ページを開いた直後に画面に映る範囲）に表示されるかどうかで、読み込み方法を分けます。第四に、配信フォーマットとファイルサイズを確認し、次世代フォーマットへの変換余地があるかを見ます。この4段階を、05章のチェックリストに具体化しています。
第四の段階に関連して、公式ガイドはもう1点、「同じ画像を複数のページで使う場合は、常に同じURLで参照すること。そうすればGoogleが画像をキャッシュして再利用でき、何度もリクエストする必要がなくなる」と述べています。Googleのクロールは2MBで止まるで扱ったとおり、Googlebotが1つのURLにつき取得するバイト数には上限があり、同じ画像を毎回別のURLで配信していると、その都度クロールの対象が増えることになります。画像のファイル名やURLを整理する作業は、代替テキストほど目立ちませんが、クロールの効率にも関わる点検項目です。
注意
web.devのブラウザネイティブ遅延読み込みガイドは、「ページが読み込まれた時点でビューポート内に表示される可能性が高い画像、特にLCP画像には、遅延読み込みを使わないこと」と明確に警告しています。アイキャッチのように、ページを開いた瞬間に見える画像へloading="lazy"を付けると、その画像の読み込み自体が意図的に遅らされ、LCPの数値を悪化させます。同ガイドは、loading="lazy"とfetchpriority="high"を同じ画像に指定しても、画面外にある間は読み込みが遅れたままになるとも述べており、この2つの属性は同時に使う組み合わせではありません。
05 自分のサイトで確認するチェックリスト
チェックリストの4つの観点
ここまでの内容を、今日から手を動かせる作業に翻訳しました。観点は、代替テキストの分類、読み込みタイミングの確認、配信フォーマットの確認、サイトマップとの整合性の4つに分かれます。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。
最初に取りかかるページは、サイトの中でアクセスが多いページ、または画像を多く使っているページから選びます。1ページを最後まで確認したら、次のページに進むより先に、同じ手順を別の担当者が読んでも再現できるかを一度確認しておくと、後で複数人で分担するときに手戻りが少なくなります。以下の14項目は、その手順をそのまま作業者に渡せる形にしたものです。
実務のヒント
配信フォーマットの確認は、ブラウザの開発者ツールの「ネットワーク」タブで画像のリクエストを選び、レスポンスヘッダーのContent-Typeを見るのが最短です。ファイルの拡張子が.pngであっても、サーバー側の設定次第で実際にはWebPが返っていることもあるため、拡張子だけで判断しないようにします。
- ページ内のすべての
<img>タグを、ブラウザの開発者ツールのElementsパネルで一覧にする - 各画像を「情報を伝える画像」と「装飾目的の画像」の2種類に分類する
- 情報を伝える画像のalt属性が、ファイル名の説明ではなく画像の内容の説明になっているか確認する
- 装飾目的の画像には、alt属性そのものを省略せず
alt=""を設定する - ファイル名が連番（
img001.jpg等）になっている画像を3枚書き出し、短く説明的な名前に変える - 記事のアイキャッチなど、ファーストビューに表示される画像に
loading="lazy"が付いていないか確認する - ファーストビューの画像には
loading="eager"とfetchpriority="high"を明示的に指定する - ファーストビューより下に表示される画像を3枚選び、
loading="lazy"が付いているか確認する - 開発者ツールのネットワークタブで、主要な画像5枚の
Content-Typeを書き出す - 次世代フォーマット（WebP・AVIF）に変換できそうな画像を3枚選ぶ
- 主要ページを1つ選び、
srcset属性でレスポンシブ画像に対応しているか確認する - JavaScriptで動的に読み込んでいる画像があるか確認し、あれば画像サイトマップへの掲載を検討する
- PageSpeed InsightsでLCP要素を確認し、それが画像であれば2.5秒以内に収まっているか見る
- sitemap.xmlを開き、
<image:image>タグが主要ページに含まれているか1件確認する
14項目の内訳と、かかる時間の目安
最初の4項目は代替テキストの分類と設定、5番目はファイル名、6番目から8番目は読み込みタイミング、9番目と10番目は配信フォーマット、11番目と12番目はレスポンシブ画像とサイトマップ、13番目と14番目はLCPとサイトマップの最終確認に対応しています。すべてに目を通す時間の目安は1ページあたり20分程度です。特に4番目の「装飾画像に空のalt属性を設定する」は見落としがちですが、alt属性を省略すると画面読み上げソフトがファイル名を読み上げてしまう場合があるため、空にすることと省略することは分けて扱う必要があります。
複数ページを対象にする場合は、まず自社サイトの中でアクセスが多いページ、または商品画像・図解が多く使われているページから始めることをおすすめします。全ページを一度に点検しようとすると途中で止まりやすいため、「今週はトップページと主要な記事ページの5枚」のように、対象を区切って進める方が、14項目を最後まで通しやすくなります。
06 代替・他の選択肢を比較する
フォーマットは何を基準に選ぶか
画像フォーマットの選び方は、画像の性質によって変わります。すべての画像を一律でWebPやAVIFに変換すればよいわけではなく、写真なのか、透過が必要なイラストなのか、アニメーションなのかによって、選ぶべきフォーマットが変わります。フォーマットの選択を間違えると、次世代フォーマットに変換したつもりが、かえってファイルサイズが大きくなる場合もあります。以下は、web.devの解説をもとに整理した比較表です。
| フォーマット | 向いている用途 | 特徴 |
|---|---|---|
| JPEG | 写真・スクリーンショット | 非可逆圧縮。広く対応しているが次世代フォーマットより圧縮効率で劣る |
| PNG | 高い画質を保ちたい画像・透過が必要な画像 | 可逆圧縮。ファイルサイズが大きくなりやすい |
| WebP | 写真・アイコンなど汎用 | 可逆・非可逆どちらにも対応。旧来のフォーマットより優れた圧縮 |
| AVIF | 写真・スクリーンショット | WebPと並ぶ次世代フォーマット。旧来のフォーマットより優れた圧縮 |
| GIF | 非推奨 (アニメーション用途を除く) | 色数が256色に制限される。アニメーションは動画形式の方が軽量 |
点検する手段を比較する
画像SEOの状態を確認する手段も、目的によって使い分けが必要です。
| 手段 | 確認できること | 確認できないこと・注意点 |
|---|---|---|
| ブラウザの 開発者ツール | 個々の画像のalt属性・loading属性・Content-Type | ページ全体のLCP数値までは分からない。1枚ずつの確認になる |
| PageSpeed Insights | LCP・実際のフィールドデータ（75パーセンタイル） | alt属性のようなアクセシビリティ面の適否までは判定しない |
| 当サイトの (🔧 Lighthouse監査ツール・要登録) | 最大3ページをまとめてLighthouse監査 | 利用には無料の会員登録が必要です |
| Search Console | 画像検索での掲載順位・クリック数・表示回数 | 個々の画像がなぜその順位なのかの理由は示されない |
1枚ごとのalt属性や読み込み属性を直したいときはブラウザの開発者ツール、ページ全体の速度を確認したいときは🔧 Lighthouse監査ツールのように、目的に応じて手段を切り替えます。favicon・アイコン類のファイル構成をまとめて整えたい場合は、favicon の現代的な実装で扱ったSVG・manifestの3ファイル構成も参考になります。4つの手段を1つだけ選ぶのではなく、「日常の確認は開発者ツール、公開前の最終確認はLighthouse監査ツール、公開後の効果測定はSearch Console」のように、確認のタイミングごとに使う手段を決めておくと、点検の抜けが起きにくくなります。
07 当サイトで確かめたこと
アイキャッチ画像は、正しく「先に読む」設定になっていた
当サイトのAI Ronブログ記事のうち、公開済みの複数ページで、アイキャッチ画像のHTML出力を実際に確認しました。その結果、アイキャッチ画像にはloading="eager"とfetchpriority="high"が明示的に指定されていました。アイキャッチはページを開いた瞬間に画面に映る、LCP要素になりやすい画像です。04章の注意で扱った「ファーストビューの画像には遅延読み込みを使わない」という原則が、意図してかどうかは別として、この部分については既に守られている形になっていました。
本文中の画像には、読み込み設定が付いていなかった
一方で、本文中に置かれた画像（アイキャッチより下に表示される、記事の説明図にあたる画像）を確認したところ、loading属性そのものが指定されていませんでした。属性が無い場合はブラウザの既定動作であるeager（即座に読み込む）が適用されるため、ページの下の方にあってすぐには画面に映らない画像も、他の画像と同じタイミングで読み込まれている状態でした。あわせて配信フォーマットもレスポンスヘッダーで確認したところ、これらの画像はPNGで配信されており、ファイルサイズは1枚あたり4万バイトから9万バイト程度、WebPやAVIFへの変換は行われていませんでした。ファーストビューの画像を先に読ませる設定は既にできていたので、次の点検対象は「ファーストビューより下の画像に、遅延読み込みと次世代フォーマットを追加できるか」という、05章のチェックリストの8番目・10番目にあたる部分になります。
あわせて、ヘッダーやフッターに共通で表示されるSNSアイコン・ロゴ画像も確認しました。これらの画像には代替テキストがすべて設定されており、装飾目的ではなく「Xでフォローする」「株式会社ツクルン」のように、リンク先の内容を説明する具体的な文になっていました。一方で、これらの共通画像にもloading属性は指定されていませんでした。アイコン類はファイルサイズが小さく、LCPへの影響は本文中の画像ほど大きくないと考えられますが、05章のチェックリストの6番目・8番目を機械的に当てはめるなら、点検対象としては本文中の画像と同じ扱いになります。
08 このテーマの、これまで
画像検索の拡大と、画像が消えた・運ばれてきた2つの回
Google画像検索の周年にあわせた機能拡張と、今週やるべき画像SEOの点検項目を扱った回があります（archives/107）。本記事の02章で扱った「画像検索・AI Overviewsが画像の役割を広げている」という整理は、この回で示した流れの延長線上にあります。また、サムネイル画像が本番環境から消えていたにもかかわらず、仕組みの上ではエラーが1件も記録されていなかった事例を検証した回（archives/132）と、画像147本のうち45本が別の場所から運ばれてきたものだと、時刻の記録から見分けた回（archives/133）もあります。07章で当サイトの画像を実際に確認した際も、この2回と同じように「表示されているように見えることと、正しい設定になっていることは別」という前提で確認を行いました。
特にarchives/132で扱った事例は、画像が本番環境に運ばれる仕組みそのものは用意されていたのに、運ぶ先の指定方法が実際の配置場所と食い違っていたために、画像が届かないまま気づかれずにいた、というものでした。「仕組みを用意すること」と「その仕組みが実際に動いていることを確認すること」は別の作業であるという点は、本記事の05章のチェックリストで、設定するだけでなく開発者ツールやレスポンスヘッダーで実際の出力を確認する項目を繰り返し入れている理由と重なります。
出力はあったのに誰も測らなかった回と、「0件」の意味を確かめた回
datePublishedやog:type、サイトマップなど、出力そのものは存在していたのに、誰も実際の値を測っていなかった4つの事例を扱った回があります（archives/128）。本記事の05章でsitemap.xmlの<image:image>タグを確認する項目を入れたのも、「サイトマップに入っているはず」という思い込みではなく、実際に開いて確認する必要があるという同じ考え方によります。あわせて、「0件」という結果が必ずしも安心を意味しないことを扱った回（archives/130）もあり、次世代フォーマットへの変換が0枚であることや、遅延読み込みの指定が0件であることも、良い結果ではなく「まだ手を付けていない」結果として読む必要があります。
現在の貴方のIPアドレス
このサイトで書いている人
