画像SEOと代替テキスト：ワークフロー全体を最適化する

説明用の例：コーヒーマシンのページが、大きな画像を CSS 背景として使い、分かりにくいファイル名とモデル説明の不足を抱えているとします。画像配信、アクセシブルな代替情報、周囲の文脈を確認します。robots.txt だけではこれらの問題を診断できません。

画像SEOは、公開後にalt欄へキーワードを置く作業ではありません。選定、命名、書き出しサイズ、近くの文章、HTML埋め込み、CDN配信、メタデータ、サイトマップに及ぶ判断の連なりです。良い流れは、表示速度とアクセシビリティを守りながら、画像の発見を改善します。

Googleは複数のシグナルから画像を理解します

代替テキストは重要ですが、それだけではありません。検索エンジンは次の情報も使えます。

• 画像掲載ページの内容と見出し。
• 画像に近い段落、キャプション、タイトル。
• ファイル名と画像URL。
• alt属性。
• 構造化データとOpen Graph。
• 画像や掲載ページへのリンク。
• ファイル自体の視覚的分析。

そのため、「バーカウンターに置かれたX200コーヒーマシン」の画像は、実際にX200を扱うページの、設計や使い方を説明する段落の近くに置くべきです。文脈のない総合ギャラリーに入れて長いaltを書いても、同じ明確さは得られません。

クローラーが見つけられるHTML要素を使う

Google Search Centralは、<img>要素のsrc属性にURLを指定することを推奨しています。CSS背景は装飾向けであり、Google Imagesで発見してほしいコンテンツ画像の埋め込みには適していません。

基本的な例です。

<img
  src="/images/x200-black-coffee-machine.webp"
  alt="Black X200 coffee machine beside a burr grinder"
  width="1200"
  height="800"
>

レスポンシブ画像ではsrcset、sizes、<picture>も使えますが、中心となる要素に有効なimg srcを残す必要があります。ソースとレンダリング後のHTMLを確認し、起こりにくい操作の後にしかURLが現れない状態になっていないか確認してください。

純粋な装飾画像はCSSに置けます。画像ファイルだからといって、すべての模様、背景アイコン、区切り線を画像サイトマップに加えないでください。

画像の目的に応じた代替テキストの書き方

代替テキストは、画像を見られない人が、その画像が伝える情報や機能を理解するためのものです。すべての種類に適した単一の書式はありません。

情報を持つ画像

内容の理解に必要なことを説明します。例えば、次のように書きます。

alt="Chart showing organic clicks rising from 1,200 to 1,850 in three months"

直後の段落ですべての数値を説明しているなら、スクリーンリーダーで繰り返し聞かされないよう、altを短くできます。

商品画像

商品と、有用な視点や種類を示します。

alt="Side view of blue AirFlow running shoe with white rubber sole"

すべての画像で「安くて正規品のランニングシューズを購入」と繰り返す必要はありません。前面、背面、靴底の詳細は情報が異なるため、altも変える必要があります。

機能を持つ画像

画像がボタンやリンクなら、altで動作や移動先を説明します。

<a href="/cart">
  <img src="/icons/cart.svg" alt="Open shopping cart">
</a>

装飾画像

スクリーンリーダーが無視できるよう、alt=""を使います。

<img src="/decor/divider.png" alt="">

アクセシビリティの観点で、alt属性がないことと空のaltは同じではありません。空のaltは、画像に情報がないことを明示する判断です。

文字を含む画像

可能なら、重要な文字は実際のHTMLにしてください。画像内の文字は拡大縮小、翻訳、アクセス、更新が難しくなります。ロゴはよくある例外で、altは通常、組織名や、ホームページへリンクする場合の機能を表します。

最適化に見えて逆効果になる代替テキスト

よくある問題は次のとおりです。

• 画像にないキーワードや地名を列挙します。
• すべての商品画像に同じaltを使います。
• 文脈が明確なのに、すべてを「〜の画像」で始めます。
• キャプションや本文の代わりに200語の段落を書きます。
• ファイル名を整えず、自動でaltにします。
• AIが物体だけを説明し、記事内の画像の目的を見落とします。

モデルは「ボードの横に立つ人」と認識できても、監査手順の説明写真なのか、登壇者の肖像なのかを知るのは編集者です。良いaltには、視覚的内容と文脈上の役割の両方が必要です。

ファイル名とURL構造

x200-black-coffee-machine.webpは、DSC00991.webpよりも軽い手掛かりを与え、管理もしやすくなります。実務上のルールは次のとおりです。

1. 短くても区別できる名前にします。
2. 実際の説明語を使い、キーワードを詰め込みません。
3. 読みやすいようハイフンを使います。
4. 拡張子を形式に合わせます。
5. 画像が変わらないなら、デプロイのたびにURLを変えません。

数千画像のライブラリでは、商品コード、種類、撮影方向からx200-black-front.webp、x200-black-side.webpのように命名します。一貫したルールは、DAM、CDN、コンテンツチームによるファイル重複を防ぎます。

多言語サイトで、文字や市場固有の内容を含む画像を使うなら、ファイル名を現地化できます。言語に依存しない同じ画像を複数ロケールで使うなら、URLを安定させるとキャッシュが効率化します。altとキャプションは掲載ページに応じて翻訳します。

形式と圧縮率を選ぶ

すべての場合に優れる形式はありません。

• JPEG： 写真向けで広く対応していますが、アルファ透過には向きません。
• PNG： 透過や精細な線が必要な画像に適しますが、写真では重くなりがちです。
• WebP： 多くの画像で圧縮効率が高く、現代のブラウザで広く対応しています。
• AVIF： 同等品質で小さくなることが多いですが、エンコード時間と代替配信の仕組みを検討する必要があります。
• SVG： ロゴ、アイコン、ベクター図に適しています。ユーザーから受け取る場合は、安全な処理が必要です。

実際の表示寸法に近いサイズで書き出してください。600ピクセルの枠に5,000ピクセルの元画像は不要です。ただし、高精細画面向けの高密度版は用意します。元画像をダウンロードさせて縮小するのではなく、メディアパイプラインで複数サイズを生成してください。

圧縮で文字、商品の輪郭、重要な細部をつぶすべきではありません。削減率だけでなく、複数の画面で目視確認してください。

レスポンシブ画像は容量削減だけのためではありません

srcsetを使うと、ブラウザがビューポートと画素密度に応じてファイルを選べます。

<img
  src="/images/audit-dashboard-800.webp"
  srcset="/images/audit-dashboard-480.webp 480w,
          /images/audit-dashboard-800.webp 800w,
          /images/audit-dashboard-1280.webp 1280w"
  sizes="(max-width: 720px) 100vw, 720px"
  alt="Dashboard listing SEO issues by priority"
  width="1280"
  height="800"
>

sizesが誤っていると、不必要に大きなファイルを選ぶことがあります。HTMLにsrcsetがあるかを見るだけでなく、モバイルとデスクトップのNetworkで実際に読み込むリソースを測定してください。

同じコンテンツの変種には、同じURLを保ちます。バージョンのクエリを頻繁に変えると、キャッシュ効率が下がり、ログに多数の画像アドレスが生まれます。

Width、height、CLS

widthとheight属性は、読み込み前にブラウザが縦横比を計算するのを助けます。CSSでレスポンシブにもできます。

img {
  max-width: 100%;
  height: auto;
}

領域を確保しないと、画像が現れた際に下の内容が押し下げられ、Cumulative Layout Shiftが増えます。切り抜き用のコンテナでは、明確なaspect-ratioと適切なobject-fitを使ってください。

Core Web Vitals最適化ガイドでは、ヒーロー画像のLCPへの影響と、不安定な寸法のCLSへの影響を説明しています。

適切な場所で遅延読み込みを使う

遅延読み込みは、画面外の画像の読み込みを後回しにします。

<img src="/images/step-8.webp" alt="..." loading="lazy">

ただし、最初の画面のヒーロー画像やLCP画像を不用意に遅らせるべきではありません。重要なリソースはブラウザが早く発見できるようにし、状況に応じてfetchpriority="high"を使い、URLをJavaScriptの裏に隠さないことが必要です。

原則は次のとおりです。

• LCPになりそうな主要画像は即時読み込みにします。
• ギャラリーや下部の画像は遅延読み込みにします。
• 重いスクリプトですべてを遅延読み込みにしません。
• プレースホルダーの縦横比を合わせます。
• 低速回線と実機で確認します。

メディアパイプラインを変更した後は、Page Speed CheckerでLCP、CLS、転送された画像のバイト数を測定してください。

キャプションと周辺の内容

すべての画像にキャプションが必要なわけではありません。出典、結果、時点、人物、注目すべき点を説明するときに役立ちます。グラフではデータの範囲、前後比較の写真では比較条件を記載できます。

画像は関連する段落の近くに置きます。「6段階の手順」の図が対応する見出しから3画面離れていれば、文脈が弱まり、読者が追いにくくなります。

画像に重要なデータがあるなら、HTML本文で結論を要約するべきです。アクセシビリティもSEOも、完全にピクセルへ依存するべきではありません。

代表画像、Open Graph、構造化データ

検索結果や共有時のサムネイルは、複数のシグナルから自動選択されます。サイトは次の方法で優先画像を示せます。

• og:image。
• Article、Productなど適切なschema型のimage属性。
• primaryImageOfPage。
• 本文中の主要画像。

極端な縦横比を避け、関連性が高く高解像度の画像を選びます。すべての記事に汎用ロゴを使ったり、縮小すると小さな文字が消える文字中心の図を使ったりするのは避けてください。Social Preview CheckerでSNS表示を確認します。

構造化データのすべての画像URLはアクセス可能である必要があります。CDNがボットを遮断し、Cookieを要求し、期限切れURLを使うなら、構文が正しくても画像を取得できません。

画像サイトマップはいつ使いますか？

通常のHTMLでは見つけにくい画像、複雑なアプリで読み込む画像、重要な画像ライブラリがあるサイトに役立ちます。完全に別の仕組みを作らず、既存のページ用サイトマップにimageタグを追加することもできます。

画像サイトマップでも、次の問題は解決できません。

• 画像が遮断されています。
• URLがエラーを返します。
• 画像がページに関連していません。
• ファイルが小さすぎる、または品質が低い状態です。
• 掲載ページがnoindexになっています。

画像が別ドメインのCDNにあるなら、Search Consoleでそのドメインを確認し、適切なクロール情報を得てください。安定した、正しいプロトコルの絶対URLを使います。

CDN、キャッシュ、アクセス権

CDNは遅延を減らしますが、次の場合にはSEOの問題を起こすことがあります。

• 直リンク保護がGooglebotや空のリファラーを遮断します。
• 署名付きURLが数分で期限切れになります。
• サイズ変更のたびに不安定なURLが生成されます。
• ヘッダーのMIMEタイプが誤っています。
• オリジンにファイルがあるのにキャッシュが404を返します。
• CDNのrobots.txtが画像ディレクトリを遮断します。

可能なら、Cookieなしで、複数のユーザーエージェントや地域から要求して確認します。CDNログで、ボットが200と正しいサイズ、コンテンツタイプを受け取っているかを見てください。

不要なのに、JPEGからWebPへの変更だけを理由に、画像庫全体のパスを変えないでください。コンテンツネゴシエーションや、明確なリダイレクトとサイトマップを伴う更新も可能ですが、キャッシュ、画像の被リンク、クロールのコストを考慮してください。

テンプレート別の画像監査

ホームページ、ブログ、カテゴリ、商品、ランディングページ、多言語ページから抽出します。各テンプレートで次を確認してください。

1. コンテンツ画像はimg srcですか、CSS背景ですか？
2. Altがあり、目的に合い、それぞれ異なりますか？
3. ファイル名は説明的で、URLは安定していますか？
4. Widthとheightで領域を確保していますか？
5. LCPはどの画像で、遅延読み込みになっていませんか？
6. モバイルで実際に読み込むファイルの容量はいくらですか？
7. キャプションと周辺の内容に十分な文脈がありますか？
8. 画像URLは200と正しいMIMEタイプを返しますか？
9. 代表画像がOGとschemaにありますか？
10. サイトマップに戦略的画像が記載されていますか？

その後、規模に応じて優先順位を付けます。20,000商品でaltがないカードコンポーネントは、テンプレートの修正対象です。名前の悪いブログ画像10枚なら、個別に編集できます。

SEO Checkerで基本的なページ属性を確認し、無料SEO監査で共通コンポーネントの変更前に反復する問題を見つけられます。

チーム間の画像受け渡し手順

持続可能な画像SEOには、明確な責任分担が必要です。

• 撮影・デザイン： 整った元データ、適切な切り抜き、利用権を用意します。
• コンテンツ： 画像を選び、文脈に応じた代替テキストとキャプションを書きます。
• フロントエンド： HTML画像、レスポンシブソース、寸法、読み込みを実装します。
• バックエンド・DAM： ファイルを命名し、変種を生成し、メタデータを保持し、URLを安定させます。
• DevOps・CDN： キャッシュ、MIMEタイプ、クロールアクセス、エラー監視を管理します。
• SEO： 戦略的なランディングページ、サイトマップルール、テスト、測定を定義します。

画像の用途を知らない人が最後にaltを加えるだけでは、品質をそろえにくくなります。同じ画像でも文脈によって説明を変える必要があるため、CMSは使用箇所ごとにaltを入力できるようにするべきです。

結果を測定する

ページ群ごとに、変更前後を追跡してください。

• Search Consoleの画像検索でのクリックと表示回数。
• Google Imagesからランディングページへの訪問。
• LCP、CLS、画像の合計バイト数。
• alt不足やURLエラーの割合。
• クロールされた戦略的画像数。
• 画像から始まったセッションのコンバージョン。

今日altを変えれば明日トラフィックが増えるとは考えないでください。画像の再クロールと再処理が必要です。結果はクエリの視覚的な需要にも左右されます。実装が完璧でも、法律記事の画像流入は料理レシピより少ない場合があります。

まとめ

良い画像SEOは、有用な画像を適切な文脈のページへ置き、クロール可能なHTMLで配信することから始まります。代替テキストは画像の役割を説明し、ファイル名、キャプション、schema、サイトマップがシグナルを補います。レスポンシブサイズ、圧縮、読み込み方法が、速く安定した体験を保ちます。

Altをキーワードの置き場にせず、小さな画面へ巨大な元画像を送らず、主要画像をCSS背景だけにしないでください。コンテンツ、フロントエンド、CDNが共通の手順を使えば、アクセシビリティやCore Web Vitalsを犠牲にせず、画像が発見される可能性を高められます。

参考資料：Google Search Centralの画像SEO、web.devのレスポンシブ画像、W3Cの代替テキスト。