画像 SEO の完全ガイド - alt 属性、ファイル名、サイズ最適化で検索流入を増やす
画像 SEO が重要な理由 - Google 画像検索からのトラフィック獲得
Google 画像検索は、Web 検索に次ぐ第 2 の検索エンジンです。Sparktoro の調査によると、Google での全検索の約 20% が画像検索で行われており、特に EC サイト、レシピサイト、旅行サイト、デザイン関連サイトでは画像検索からの流入が全体の 30-50% を占めることもあります。
画像 SEO を最適化するメリット:
- 追加のトラフィック源: テキスト検索とは異なるキーワードで画像検索からの流入を獲得できます。「○○ 画像」「○○ 写真」「○○ イラスト」といった検索クエリに対応します
- リッチリザルトへの表示: 適切に最適化された画像は、Google のリッチリザルト (レシピカード、商品カルーセル、ハウツーステップ) に表示される可能性が高まります
- ユーザー体験の向上: 画像の最適化は同時にページの読み込み速度を改善し、Core Web Vitals のスコア向上にも寄与します。これはテキスト検索のランキングにも好影響を与えます
- アクセシビリティの改善: alt 属性の適切な設定は、スクリーンリーダーユーザーへの情報提供にもなり、Web アクセシビリティの向上に直結します
Google は画像のランキングに、alt テキスト、ファイル名、周囲のテキスト、ページのコンテキスト、画像の品質、構造化データなど複数のシグナルを使用しています。これらを総合的に最適化することで、画像検索での上位表示を実現できます。
alt 属性の最適な書き方 - 検索エンジンとアクセシビリティの両立
alt 属性は画像 SEO の最も重要な要素です。Google は alt テキストを画像の内容を理解するための主要なシグナルとして使用しています。同時に、スクリーンリーダーが画像の代替テキストとして読み上げるため、アクセシビリティにも直結します。
効果的な alt テキストの書き方:
- 画像の内容を具体的に記述する: 「犬」ではなく「公園で走る茶色のゴールデンレトリバー」のように、画像が何を表しているかを具体的に伝えます
- キーワードを自然に含める: ターゲットキーワードを不自然にならない範囲で含めます。ただし、キーワードの詰め込み (keyword stuffing) は Google にペナルティを受ける原因になります
- 簡潔に保つ: 125 文字以内を目安にします。スクリーンリーダーは長い alt テキストを一気に読み上げるため、冗長な記述はユーザー体験を損ないます
- 「画像」「写真」という語を含めない: スクリーンリーダーは既に「画像:」と前置きして読み上げるため、alt テキスト内に「の画像」「の写真」は不要です
alt テキストの良い例と悪い例:
- ❌
alt="画像"- 情報がない - ❌
alt="SEO 画像最適化 画像 SEO 検索エンジン最適化 画像"- キーワード詰め込み - ✅
alt="Google Search Console の画像検索パフォーマンスレポート画面"- 具体的で自然 - ✅
alt="WebP と JPEG の画質比較 - 同じ圧縮率での視覚的な違い"- 内容を正確に伝える
装飾目的の画像 (区切り線、背景パターンなど) には空の alt (alt="") を設定します。これによりスクリーンリーダーが画像を無視し、コンテンツの読み上げがスムーズになります。alt 属性自体を省略するのは HTML 仕様違反であり、アクセシビリティチェッカーでエラーになります。
ファイル名とディレクトリ構造 - URL レベルでの最適化
画像のファイル名は、Google が画像の内容を理解するための重要なシグナルの一つです。適切なファイル名を付けることで、画像検索でのランキング向上が期待できます。
ファイル名の命名規則:
- 内容を表す英語の単語を使用:
IMG_20240315_001.jpgではなくgolden-retriever-running-park.jpgのように、画像の内容を表す単語を使います - ハイフンで単語を区切る: Google はハイフン (
-) を単語の区切りとして認識します。アンダースコア (_) は単語を結合するものとして扱われるため、ハイフンを使用してください - 小文字で統一: URL は大文字小文字を区別するサーバーがあるため、小文字で統一します
- 短く保つ: 3-5 単語程度が適切です。長すぎるファイル名は URL が冗長になり、共有時にも不便です
- 日本語ファイル名は避ける: URL エンコードされて
%E7%94%BB%E5%83%8Fのような文字列になり、可読性が失われます
ディレクトリ構造の最適化:
/images/products/blue-wireless-headphones.webp のように、カテゴリを反映したディレクトリ構造にすることで、Google がサイトの構造を理解しやすくなります。/img/001.jpg のような無意味な構造は避けてください。
画像の URL が変更される場合 (リニューアル時など) は、301 リダイレクトを設定して既存の画像検索ランキングを維持します。画像 URL のリダイレクトを忘れると、画像検索からのトラフィックが一気に失われる可能性があります。
構造化データと画像サイトマップ - Google への明示的な情報提供
構造化データ (Schema.org) と画像サイトマップを活用することで、Google に画像の詳細情報を明示的に伝え、リッチリザルトへの表示確率を高められます。
画像に関連する構造化データ:
- ImageObject: 画像自体のメタデータ (URL、幅、高さ、キャプション、著作権情報) を記述します
- Article の image プロパティ: 記事の構造化データに
imageプロパティを含めることで、Google Discover やリッチリザルトに画像が表示されやすくなります。推奨サイズは幅 1,200 px 以上です - Product の image: 商品の構造化データに複数の画像 URL を含めることで、商品カルーセルに表示される可能性が高まります
- HowTo の image: ハウツー記事の各ステップに画像を含めることで、Google のハウツーリッチリザルトに画像付きで表示されます
画像サイトマップの作成:
<url>
<loc>https://example.com/page</loc>
<image:image>
<image:loc>https://example.com/images/photo.webp</image:loc>
<image:title>画像のタイトル</image:title>
<image:caption>画像の説明文</image:caption>
</image:image>
</url>
画像サイトマップは、JavaScript で動的に読み込まれる画像や、CSS の背景画像として設定されている画像など、Google のクローラーが通常のクロールでは発見しにくい画像を伝えるのに特に有効です。通常の sitemap.xml に <image:image> 要素を追加する形式が最も一般的です。
Core Web Vitals と画像最適化 - LCP と CLS への対策
Core Web Vitals は Google のランキング要因の一つであり、画像は LCP (Largest Contentful Paint) と CLS (Cumulative Layout Shift) の両方に大きく影響します。画像の最適化は SEO とユーザー体験の両面で重要です。
LCP の改善策:
- 適切なフォーマットの選択: AVIF > WebP > JPEG の優先順位で、
<picture>要素を使って最適フォーマットを配信します。AVIF は JPEG の 50% 以下のサイズで同等品質を実現します - 適切なサイズの配信: 表示サイズより大きな画像を配信しない。
srcsetとsizes属性でデバイスに最適なサイズを選択させます - プリロード: LCP 要素となる画像 (ヒーロー画像など) は
<link rel="preload" as="image" href="hero.webp">で優先的に読み込みます - CDN の活用: 画像を CDN から配信し、ユーザーに近いエッジサーバーからの高速配信を実現します
- fetchpriority 属性: LCP 画像に
fetchpriority="high"を設定し、ブラウザに優先的なダウンロードを指示します
CLS の防止策:
- width と height の明示:
<img>タグにwidthとheight属性を必ず設定し、画像読み込み前にブラウザがスペースを確保できるようにします - aspect-ratio の活用: CSS の
aspect-ratioプロパティでコンテナのアスペクト比を固定し、画像読み込み時のレイアウトシフトを防止します - プレースホルダーの表示: 画像読み込み中に低品質のプレースホルダー (LQIP: Low Quality Image Placeholder) やぼかし画像を表示し、読み込み完了後に差し替えます
画像の遅延読み込みとプリロード - 読み込み戦略の最適化
画像の読み込み戦略は、ページの初期表示速度と全体的なユーザー体験に直接影響します。ファーストビューの画像は即座に読み込み、それ以外は遅延読み込みするという基本戦略を、適切に実装することが重要です。
遅延読み込み (Lazy Loading) の実装:
- ネイティブ lazy loading:
<img loading="lazy">属性を使用する最もシンプルな方法です。ブラウザがビューポートとの距離に基づいて自動的に読み込みタイミングを判断します。2026 年時点で全主要ブラウザが対応しています - Intersection Observer API: より細かい制御が必要な場合に使用します。画像がビューポートに近づいた時点で
src属性を設定し、読み込みを開始します。閾値 (threshold) やマージン (rootMargin) を調整して、スクロール時に画像が表示される前に読み込みを完了させます
プリロードの実装:
- LCP 画像のプリロード:
<link rel="preload" as="image" href="hero.webp" type="image/webp">を<head>内に配置します。HTML のパース完了を待たずに画像のダウンロードが開始されるため、LCP が大幅に改善されます - レスポンシブ画像のプリロード:
<link rel="preload" as="image" imagesrcset="small.webp 400w, large.webp 800w" imagesizes="(max-width: 600px) 400px, 800px">で srcset に対応したプリロードが可能です
注意すべきアンチパターン:
- ファーストビューの画像に
loading="lazy"を設定しない。LCP が悪化します - 全画像をプリロードしない。帯域幅を浪費し、本当に重要な画像の読み込みが遅れます
decoding="async"を併用し、画像のデコード処理がメインスレッドをブロックしないようにします
Google の PageSpeed Insights で「画像の遅延読み込み」の警告が出る場合は、ビューポート外の画像に loading="lazy" が設定されていないことが原因です。ファーストビュー以外の全画像に一律で設定することで解消できます。