画像SEOを監査するとき、alt属性だけを確認して終わってはいけません。
画像が検索結果に出るためには、Googleが画像を発見でき、画像URLへアクセスでき、画像の内容と掲載ページの文脈を理解できる状態が必要です。さらに、遅延読み込みや画像サイズによって表示を遅くしていないか、実際にGoogle画像検索から表示・クリックされているかまで確認する必要があります。
Googleも画像SEOについて、「画像を検出・インデックス登録できる状態」と「画像のランディングページの最適化」を大きな柱として案内しています。
この記事では、画像SEOを「発見・アクセス・理解・配信・計測」の5層に分け、SEO・Web担当者が問題箇所と修正優先順位まで判断できる監査方法を整理します。
画像SEO監査では「発見・アクセス・理解・配信・計測」の5層を確認する
画像SEOの問題は、「altがない」といった1項目だけでは判断できません。
テクニカルSEOの全体像を先に確認したい場合は、テクニカルSEOの全体像を参照してください。本記事では、その中でも画像資産に限定した技術監査に絞って実務手順を整理します。
たとえば、altが正しくても画像URLが404なら検索対象として扱えません。画像URLが正常でも、JavaScriptの実装によってGoogleが画像を認識できなければ発見性に問題があります。
一方、Googleから正常に認識されていても、画像サイズが過大だったり、ファーストビュー画像まで遅延読み込みしたりすれば、ページ表示上の問題につながります。
まず、以下の5層に分けて監査してください。
| 監査層 | 主な確認項目 | 問題がある場合 |
|---|---|---|
| 発見 | img要素、src、srcset、画像サイトマップ | Googleが画像自体を見つけにくい |
| アクセス | HTTP状態、robots.txt、画像URL | クロール・インデックス登録を妨げる |
| 理解 | alt、ファイル名、周辺本文、構造化情報 | 画像の意味やページとの関係が伝わりにくい |
| 配信 | 画像形式、サイズ、レスポンシブ、lazy load | 表示速度やユーザー体験を悪化させる |
| 計測 | Search Console画像検索 | 問題修正後の成果を判断できない |

画像SEOはaltだけでなく、画像の発見、アクセス、意味理解、配信状態、画像検索での成果まで順番に確認します。
重要なのは、上から順番に確認することです。
「Googleが取得できない画像」のaltを修正しても、根本問題は解決しません。最初に発見・アクセスの致命的な問題を除外し、その後に意味・速度・流入を確認します。
STEP1|まず監査対象の画像URLを一覧化する
画像SEO監査の最初の作業は、対象ページと画像URLの棚卸しです。
全ページを目視するのではなく、クローラーやCMSの出力データなどを使い、最低でも以下を一覧化します。
- 掲載ページURL
- 画像URL
- img要素のsrc
- srcsetの有無
- alt属性
- width・height
- loading属性
- 画像形式
- HTTP状態
- ページ内のおおよその表示位置
ECサイトなど画像数が非常に多い場合は、最初から全画像を同じ深さで確認する必要はありません。
問い合わせや購入につながるページ、検索流入の多いページ、商品・サービスの主要画像、記事内の独自図解などから優先的に確認すると効率的です。
STEP2|Googleが画像を発見できるHTMLになっているか確認する
最初の技術監査では、画像がGoogleから発見できる形でHTMLへ出力されているか確認します。
Googleは、標準的な<img>要素のsrc属性で指定された画像を検出できます。<picture>やsrcsetを利用する場合でも、Googleはsrcによる代替URLを用意することを推奨しています。一方、CSSの背景画像はGoogle画像検索のインデックス対象として扱われません。
したがって、検索対象にしたい商品画像、事例写真、図解などが次のようになっていないかを確認します。
<div style="background-image:url(example.webp)"></div>
検索対象にしたい重要画像なら、基本は次のように画像要素として出力します。
<img
src="/images/example.webp"
alt="画像の内容を説明する代替テキスト"
width="1200"
height="675"
>
JavaScriptで画像を後から生成している場合も注意が必要です。
Googleは、遅延読み込み後のレンダリングされたHTML内で、画像URLが<img>要素のsrcとして確認できる状態かをSearch ConsoleのURL検査で確認する方法を案内しています。
STEP3|画像URLのHTTP状態とクロール可否を確認する
次に、画像ファイルそのものへGoogleがアクセスできるか確認します。
優先して確認するのは次の項目です。
| 確認項目 | 正常の目安 | 優先度 |
|---|---|---|
| 画像URL | 実ファイルへ到達できる | 高 |
| HTTP状態 | 正常な画像は原則2xx | 最優先 |
| robots.txt | 検索対象画像をブロックしていない | 最優先 |
| CDN | Googleからアクセス可能 | 高 |
| リダイレクト | 不要な多段転送がない | 中 |
| URL変更 | 差し替えのたびに無意味に変更しない | 中 |
Googleのクロール仕様では、4xxを返すURLはインデックス登録の対象にならず、継続的な5xxはクロールにも影響します。
また、robots.txtでGooglebot-Imageをブロックすると、Google画像検索から画像を除外できます。つまり、検索対象にしたい画像が意図せず画像ディレクトリ単位でブロックされていないかを確認する必要があります。
CDNを利用している場合も、HTML側のページだけを見るのではなく、実際の画像配信ドメインまで確認してください。
STEP4|alt属性は「空かどうか」ではなく画像の役割で判定する
alt監査で最も多い誤りは、「空のaltをすべてエラーにする」ことです。
alt属性は、画像の意味と役割によって書き分けます。
Googleは、代替テキストを画像について説明する重要な情報として利用すると説明しており、画像周辺の本文やページ内容なども組み合わせて画像を理解します。同時に、キーワードを不自然に羅列する方法は推奨していません。
W3Cのガイドでも、意味のある写真や図は内容を簡潔に説明し、リンク画像ならリンク先や機能を説明します。一方、純粋な装飾画像や、同じ内容が近接テキストですでに説明されている画像では、alt=""が適切なケースがあります。
監査時は次のように分類すると判断しやすくなります。
| 画像の役割 | altの考え方 |
|---|---|
| 商品・施設・人物など意味のある写真 | 何が写っているかを文脈に合わせて簡潔に説明 |
| グラフ・図解 | 図が伝えている中心内容を説明 |
| リンク・ボタン画像 | リンク先または操作内容を説明 |
| 装飾画像 | alt=""を検討 |
| 本文と完全に重複する画像 | 空altが適切な場合がある |

alt属性は一律に埋めるのではなく、画像がページ内で担う役割によって判断します。
たとえば、「SEO」という単語だけを入れるより、「画像SEO監査で確認する5項目のフロー図」のように、画像そのものの意味が伝わる記述の方が実務的です。
STEP5|ファイル名・周辺本文・構造化情報を確認する
画像の意味はalt属性だけで決まりません。
Googleは、画像周辺の本文、ページタイトル、キャプションなどから画像の情報を取得します。また、IMG00023.JPGのような一般的なファイル名より、内容を説明する簡潔なファイル名を推奨しています。
そのため、重要画像では以下をまとめて確認します。
- 画像が内容に関連する本文の近くに配置されているか
- ファイル名が意味不明な連番だけになっていないか
- ページタイトルと画像テーマが一致しているか
- 必要に応じてキャプションがあるか
- Article、Productなど該当する構造化データの画像指定が正しいか
og:imageなどで代表画像が適切に指定されているか
GoogleはprimaryImageOfPageや、BlogPostingなどのimageプロパティ、og:imageなどを、ページの代表画像を伝える方法として案内しています。
ただし、「構造化データを入れれば画像検索順位が上がる」と単純化してはいけません。
構造化データは、対象コンテンツと仕様が一致する場合に利用し、画像の発見可能性・内容・ページ品質などとは分けて監査します。
STEP6|WebPだけを正解にせず、実際の配信状態を監査する
画像形式の監査では、「JPEGだからNG」「WebPならOK」と機械的に判定しないことが重要です。
Google検索が現在サポートしている形式には、BMP、GIF、JPEG、PNG、WebP、SVG、AVIFがあります。Googleはファイルの拡張子と実際の形式を一致させることも推奨しています。
したがって監査では、形式だけでなく次を確認します。
- 表示サイズに対して元画像が極端に大きくないか
- 不要に大容量な画像を配信していないか
srcsetやpictureで端末に応じた画像を配信できているか- width・heightで画像領域を事前に確保できているか
- 品質を落としすぎて画像が不鮮明になっていないか
WebPやAVIFは画像軽量化の有力な選択肢ですが、画像SEO監査では「形式名」より、「必要な画質を保ちながら不要な転送量を減らせているか」を評価してください。
STEP7|lazy loadは「付いているか」より「付ける場所」を確認する
遅延読み込み、いわゆるlazy loadも、一律に付ければよいわけではありません。
Googleは、正しく実装されていない遅延読み込みではコンテンツを認識できなくなる可能性があると説明しています。また、ユーザーのスクロールやクリックなどの操作を必須条件にしないこと、ページを開いた直後に表示される可能性が高いコンテンツには遅延読み込みを実装しないことを案内しています。
監査では画像を2種類に分けます。
ファーストビューやLCP候補画像
- 不要な
loading="lazy"が付いていないか - 画像取得開始が遅れていないか
- 過大なファイルを配信していないか
ページ下部の画像
- 必要に応じて遅延読み込みされているか
- スクロールやクリックをしなくてもGoogleが取得できる実装か
- レンダリング後のHTMLに画像URLが存在するか

lazy loadは画像すべてに一律適用せず、ファーストビューかページ下部かで判断します。
lazy loadの監査は、HTMLソースだけで完結させず、必要に応じてSearch ConsoleのURL検査でレンダリング結果まで確認するのが安全です。
STEP8|画像サイトマップが必要なサイトか確認する
画像サイトマップは、すべてのWebサイトに必須というものではありません。
Googleは、通常のクロールだけでは発見しにくい画像、たとえばJavaScript経由で到達する画像などを伝える方法として画像サイトマップを案内しています。既存のXMLサイトマップに画像情報を追加する方法と、画像用サイトマップを分ける方法のどちらも利用できます。
特に確認価値が高いのは、以下のサイトです。
- ECで商品画像が大量にある
- 不動産・求人・旅行など写真が検索価値を持つ
- JavaScriptで画像を読み込んでいる
- CDNなど別ドメインから大量の画像を配信している
- 重要画像が通常クロールで発見しにくい
一方、すでに重要画像が標準的な<img src>で発見できている小規模サイトなら、画像サイトマップだけを最優先で追加する必要はありません。
STEP9|Search Consoleで画像検索の表示回数・クリックを確認する
技術監査だけで終わらず、最後に実際の画像検索流入を確認します。
Google Search Consoleの検索パフォーマンスでは、検索タイプを「画像」に切り替えることで、Google画像検索におけるクリック数、表示回数、CTR、クエリなどを分析できます。
ここで重要な注意点があります。
Search Consoleの「画像」検索タイプで[ページ]を確認した場合、表示されるのは検索された画像ファイルのURLではありません。ユーザーが画像検索からクリックして到達したランディングページです。
そのため、次の順番で分析します。
- 検索タイプを「画像」に変更する
- クエリを確認する
- 流入しているランディングページを確認する
- 改善対象ページと照合する
- 修正前後の期間を比較する
画像URL単位の技術監査と、Search Consoleのランディングページ単位の成果分析を分けて管理すると、原因と成果を混同しにくくなります。
画像SEOの修正優先順位は「検索不能」から直す
大量の問題が出た場合は、次の順番で修正します。
| 優先度 | 問題例 | 理由 |
|---|---|---|
| 最優先 | 404・403、robots.txtブロック | Googleが画像へ正常にアクセスできない |
| 高 | 重要画像がCSS背景のみ、JS後もsrcに現れない | 画像を発見・処理しにくい |
| 高 | ファーストビュー画像の不適切なlazy load | 重要画像の表示を遅らせる可能性がある |
| 中 | 意味のある画像のalt欠落・不適切なalt | 内容理解とアクセシビリティに影響 |
| 中 | 過大画像・レスポンシブ配信不足 | 不要な通信と表示負荷につながる |
| 中 | ファイル名・周辺文脈不足 | 画像テーマを伝える情報が弱い |
| 条件付き | 画像サイトマップ・構造化情報 | サイト構造やコンテンツ種別により必要性が変わる |
| 計測 | Search Console確認不足 | 改善後の成果を判断できない |

画像SEOでは、altや画像形式の調整より先に、Googleが画像を取得できない問題を修正するのが基本です。
「すべての画像をWebPにする」より、まずGoogleから取得できない重要画像を直す方が優先です。
画像SEO監査でよくある4つの誤解
alt=””はすべてSEO上の問題
違います。
装飾画像などでは空のaltが適切な場合があります。画像の役割を判断せず、一括で文章を入力しないことが重要です。
WebPでなければGoogleに評価されない
違います。
Google検索はJPEG、PNG、WebP、AVIFなど複数の画像形式をサポートしています。形式だけではなく、画質、転送量、表示サイズ、レスポンシブ配信まで確認します。
すべての画像にlazy loadを付ければ速くなる
違います。
Googleは、ページを開いた直後に表示される可能性が高いコンテンツには遅延読み込みを実装しないよう案内しています。
Search Consoleで画像URLごとの流入がそのまま分かる
違います。
画像検索の[ページ]で表示されるのは、画像URLではなくユーザーが到達したページです。画像URLの技術監査とは別に管理してください。
画像SEO監査チェックリスト
公開前・リニューアル後・定期監査では、最低限以下を確認します。
- 重要画像が
<img src>で発見可能か - 画像URLが正常なHTTP状態を返すか
- robots.txt等で意図せずブロックしていないか
- JavaScript・lazy load後もレンダリングHTMLに画像URLが存在するか
- 意味のある画像に適切なaltがあるか
- 装飾画像に不要なaltを付けていないか
- ファイル名と周辺本文が画像内容と一致しているか
- 画像の形式と拡張子が一致しているか
- 表示サイズに対して画像が過大でないか
- srcset・pictureなどのレスポンシブ配信が必要か
- ファーストビュー画像を不必要にlazy loadしていないか
- 画像サイトマップが必要なサイト構造か
- 該当する構造化データで画像指定が正しいか
- Search Consoleの検索タイプ「画像」で流入を確認したか
- 修正前後の表示回数・クリック・クエリを比較できる状態か
まとめ
画像SEO監査では、alt属性だけを見るのではなく、「Googleが画像を発見できるか」「画像URLへアクセスできるか」「画像の意味を理解できるか」「適切に配信できているか」「画像検索から成果が出ているか」の5層で確認します。
最優先なのは、404やrobots.txt、発見できないHTML構造など、Googleが画像を正常に取得できない問題です。その後にalt、周辺文脈、ファイル名、画像形式、サイズ、lazy load、画像サイトマップなどを確認します。
最後にSearch Consoleの検索タイプを「画像」へ切り替え、修正したページの表示回数やクリックがどう変化したかを追跡してください。
画像SEOは「画像を軽くする作業」ではありません。検索エンジンが画像を発見・理解でき、ユーザーへ高速に届けられ、その成果を計測できる状態まで整えることが技術監査のゴールです。
参考文献・データ元
この記事で参照した情報を確認できます。
- Google Search Central「画像の SEO ベスト プラクティス」/最終更新:2026年3月3日。画像の発見、対応形式、alt、ファイル名、周辺文脈、構造化情報の確認に使用。URL: https://developers.google.com/search/docs/appearance/google-images?hl=ja
- Google Search Central「読み込みの遅いコンテンツを修正する」/最終更新:2025年12月18日。lazy loadとレンダリング確認に使用。URL: https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading?hl=ja
- Google Search Central「Image sitemaps」/最終更新:2025年12月10日。画像サイトマップの用途・仕様確認に使用。URL: https://developers.google.com/search/docs/crawling-indexing/sitemaps/image-sitemaps
- Google Search Consoleヘルプ「Google におけるパフォーマンス」。画像検索の検索タイプ、クリック・表示回数、ランディングページの扱い確認に使用。URL: https://support.google.com/webmasters/answer/10268906?hl=ja
- Google Crawling Infrastructure「How HTTP Status Codes Affect Google’s Crawlers」/最終更新:2026年2月4日。HTTP状態の判定に使用。URL: https://developers.google.com/search/docs/crawling-indexing/http-network-errors
- W3C Web Accessibility Initiative「An alt Decision Tree」/更新:2024年5月13日。情報画像・機能画像・装飾画像のalt判断に使用。URL: https://www.w3.org/WAI/tutorials/images/decision-tree/
‹ 親記事: テクニカルSEOとは?クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト
関連記事
- › INDEX削除(インデックス削除)とは?検索結果から消える仕組みと対処法
- › Core Web Vitals改善ガイド|LCP・INP・CLSの原因特定と優先順位付け
- › SEO内部リンクの監査方法|孤立ページ・リンク深度・アンカー偏りをどう直すか
- › SEOのインデックス監査方法|Search Consoleで未登録・除外・重複URLを診断する
- › JavaScript SEOの監査方法|レンダリング・内部リンク・インデックス差分を確認する
- › クロールバジェットを監査する方法|ログ・URL群・無駄クロールから改善優先度を決める
- › 構造化データのSEO監査方法|実装後のエラー・内容不一致・重複を検証する手順
- › hreflangのSEO監査方法|相互参照・canonical・noindexの確認手順
- › ファセットナビゲーションのSEO監査方法|絞り込みURL・クロール・重複を制御する
- › SEOのリダイレクト監査方法|チェーン・ループ・誤転送・リンク残存を検出する
- › robots.txt・meta robotsのSEO監査方法|クロール許可とindex制御の矛盾を確認
- › ページネーションのSEO監査方法|一覧分割・canonical・内部リンク・クロールを確認
- › サイト移行後のSEO監査方法|リダイレクト・canonical・サイトマップ・順位変動を確認
- › 404・soft 404のSEO監査方法|リンク切れ・消失URL・誤判定を優先度順に修正
- › SEOリリース前チェックの作り方|noindex・canonical・robots・リダイレクトの事故を防ぐ
- › JobPosting構造化データの監査方法|求人情報・給与・勤務地・期限の不一致を確認
- › サイト内検索結果ページのSEO監査方法|noindex・クロール・重複URL・内部リンクを確認
- › サイトリニューアルでSEO評価を落とさない移行方法|URL・301・計測・公開手順
- › サービス終了ページは削除すべき?301・404/410・残す場合のSEO判断基準



