画像SEO

TL;DR — 画像SEOとは、ページ上の画像を検索のために役立てることです。Google画像検索に表示され、ページを遅くしないよう速く読み込まれる状態にします。基本は、説明的なファイル名を使い、よいaltテキストを書き、画像が巨大にならないよう圧縮し、WebPのような最新形式を選び、ページ上部の大きな画像を「遅延読み込み」しないことです。これらに魔法のランキング上昇効果はありません。画像を見つけてもらいやすくし、ページを速く保つための方法です。

画像SEOとは

Webページに画像を置くと、検索エンジンは2つの有用なことを行えます。画像検索（Google画像検索、Bing Images、Google Lens）に表示して、訪問者をページへ送れます。また、ページの一部として画像を読み取り、主にaltテキストを通じてページの内容を理解します。

検索エンジンは、あなたのように写真を「見る」ことができない点が問題です。ファイル名、altテキスト、画像の周囲にある言葉、ファイルそのものという、こちらが与える手がかりに頼ります。画像SEOとは、よい手がかりを与え、画像がページを極端に遅くしないようにすることです。

重要なのは次の数点

• 適切な形式を使い、圧縮する。 WebPとAVIFは、見た目を悪化させずに古いJPEGよりファイルを大幅に小さくする最新形式です。小さなファイル = 速いページです。速いページは、形式そのものではなく速度が重要だから、ランキングに役立ちます。
• 説明的なファイル名を付ける。 golden-retriever-puppy.jpg は IMG_0042.jpg より多くのことをGoogleに伝えます。これは新しい画像で行い、古い画像をすべて遡ってリネームしないでください（詳しくはAdvancedタブで説明します）。
• よいaltテキストを書く。 画像の短い説明です。画像検索に表示されるための主な手がかりであり、アクセシビリティにも必要です。詳しくは別のaltテキストガイドで扱います。
• 上部の大きな画像を遅延読み込みしない。 「遅延読み込み」はスクロールして画像の近くまで来るまで読み込みを遅らせます。ページ下部の画像には有効ですが、ページ上部のメイン画像には不向きです。Googleがページ速度を計測する画像だからです。
• できるときは独自の画像を使う。 通常の検索ではストック写真でも問題ありませんが、同じストック写真が他の1 000サイトにもあるため、画像検索では目立ちにくくなります。

多くの人が最も間違えること

WebPやAVIFを使ってもSEO上の「上昇効果」はありません。 形式を変えればランキングが上がると考える人がいますが、Googleは直接そうではないと述べています。最新形式が行うのはページを速くすることで、実際に役立つのは速度です。ファイル名の変更も同じで、新しい画像には役立ちますが、ライブラリ全体のリネームはよい結果より害をもたらすことがあります。

Googleの正確な引用、形式のトレードオフ、構造化データ、画像サイトマップ、Discover、遅延読み込みのルールを知りたい場合は、Advancedタブへ移動してください。

TL;DR — 画像SEOには2つの別々の目標があります。(1) altテキスト、ファイル名、ページの文脈、独自性によって、画像検索（Google画像検索 / Lens / Bing）で上位表示すること。(2) 画像は通常LCP要素になるため、ページパフォーマンスを高めることです。Googleは <picture> 内を含む <img> をインデックスしますが、CSS背景はインデックスしません。BMP、GIF、JPEG、PNG、WebP、SVG、AVIFに対応しています。WebPやAVIFに直接のランキング上昇効果はありません（Mueller）。得られるのは速度 → Core Web Vitalsです。既存ファイルを一括リネームしないでください。ネイティブの loading="lazy" は画面下では安全ですが、LCP画像には決して使いません。そこには fetchpriority="high" を付けます。2025年5月以降は、同じ画像を常に同じURLで参照します。構造化データ（ImageObject、Product/Articleの画像配列）はリッチリザルトを可能にし、画像サイトマップは発見を助けます。altテキストについては別の詳しい記事があります。

画像SEOは1つではなく2つの仕事

これは私が何度も戻ってくる枠組みであり、ほとんどすべての「画像SEOチェックリスト」が曖昧にしている点です。目標は2つに分かれ、それぞれ必要な作業が異なります。

1. 画像検索でのランキング。 Google画像検索、Bing Images、Google Lensで画像固有の検索に見つけてもらうことです。altテキスト、ファイル名、画像周辺のテキスト、構造化データ、画像の独自性が影響します。
2. ページパフォーマンス。 画像はページでほぼ常に最も重い要素です。Googleの公式ドキュメントも、画像は*“often the largest contributor to overall page size.”* (翻訳)「ページ全体のサイズに最も大きく寄与することが多い」と述べています。そのため、遅いLargest Contentful Paint（LCP）の主な原因になり、LCPはCore Web Vitalsにつながり、Web検索のランキングシグナルになります。

この2つを分けると、テーマ全体が明確になります。altテキストとファイル名は主に画像検索のための施策です。形式、圧縮、読み込み戦略はパフォーマンスのための施策です。どちらも重要ですが、同じレバーではありません。

検索量も現実のものです。画像検索とビジュアル検索は検索活動全体の意味ある割合を占め、Google Lensは急速に成長しています。最適化された画像は防御策にとどまらず、トラフィック源になります。

Googleが画像を発見し、インデックスする仕組み

画像がそもそもインデックスに入るかどうかを決める仕組みがいくつかあります。

• インデックスされるのはHTMLの <img> だけ。 Googleは、“Google parses the HTML <img> elements (even when they’re enclosed in other elements such as <picture> elements) in your pages to index images, but doesn’t index CSS images.” (翻訳)「Googleは、画像をインデックスするためにページのHTML <img> 要素（<picture> など他の要素に囲まれていても）を解析しますが、CSS画像はインデックスしません」と説明しています。CSSの background-image にしか存在しない画像は画像検索から見えません。見つけてもらいたいものは <img> に置きます。
• フォールバックの src を必ず用意する。 srcset や <picture> を使う場合も、通常の src を残します。レスポンシブ属性を*「理解しないブラウザーやクローラーもある」*ためで、src がGoogleの頼る安全網になります。
• 対応形式： BMP、GIF、JPEG、PNG、WebP、SVG、AVIF（AVIF対応は2024年8月に追加）。拡張子は実際のファイル形式と一致させます。
• マークアップとともに文脈も重要。 対応したマークアップで画像が発見されますが、発見後にGoogleが画像自体と組み合わせて内容を理解するのは、周囲のテキスト、キャプション、タイトル、その他のメタデータです。
• URLの一貫性（2025年5月の更新）。 Googleは現在、表示場所が変わっても同じ画像を同じURLで参照するよう推奨しています。Googleの広報担当者は、“We updated the Google Image SEO best practices to clarify that URLs for images should be referenced consistently for easier crawling on larger websites.” (翻訳)「大規模サイトでクロールしやすくするため、画像のURLは一貫して参照すべきだと明確にするようGoogle Image SEOのベストプラクティスを更新しました」と説明しました。これはクロール効率の話です。同じ画像に同じURLを使えば、異なるCDNパスやクエリ文字列で同じ画像を再取得せず、Googleがキャッシュして再利用できます。

ファイル形式：SEO上昇ではなく速度で選ぶ

最初に消すべき神話は、「次世代」形式に直接のランキング上昇効果はないということです。MuellerはAVIFに*“SEO boost”がないことを確認しており、同じ論理がWebPにも当てはまります。“WebP images are fine for Image Search,”* (翻訳)「WebP画像は画像検索に問題ありません」と言っていますが、「問題ない」は「より良い」ではありません。Googleはコンテナー形式を使ったことだけで評価しません。

最新形式が実際に行うのはファイルを小さくすることで、ページを速くし、Core Web Vitalsに役立てることです。これは間接的な利点です。したがって、次の長所で選びます。

• AVIF — 最高の圧縮率（JPEGより50 %以上小さくなることが多い）。ブラウザー対応が確認できる場所で、フォールバック付きで使います。
• WebP — JPEGより25–35 %小さく、ほぼすべてのブラウザーが対応しています。現在の写真向け安全なデフォルトです。
• JPEG — 写真向けの普遍的なフォールバックです。
• PNG — 透明度や輪郭の鋭いグラフィックが必要な場合に使います。
• SVG — ロゴやアイコン向けです（ベクター、無限に拡大縮小でき、小さい）。
• GIF — 単純でない用途では避け、代わりに動画またはアニメーションWebP/AVIFを使います。

きれいな実装は、最新形式用の <source> 要素と <img src> フォールバックを持つ <picture> です。古いブラウザーでも適切に低機能化し、Googleにはインデックスする src が残ります。

新しい画像には説明的なファイル名、古い画像は一括リネームしない

ファイル名は小さいながらも実際の関連性シグナルです。Googleのベストプラクティスは短く説明的な名前を使うことです。“the filename can give Google clues about the subject matter of the image” (翻訳)「ファイル名は画像の主題についてGoogleに手がかりを与えられます」。そのため golden-retriever-puppy.jpg は IMG00023.JPG よりよく、image1.jpg のような一般的な名前は機会損失です。

ただし、ここで多くの人がつまずきます。既存ファイルを遡ってリネームしないでください。 Muellerは、一括リネームした新しい画像をGoogleのシステムが認識するには*“is going to take a lot of time for Google’s systems to see”* (翻訳)「Googleのシステムが認識するまで長い時間がかかる」と明確に述べています。altテキストと周囲の文脈がすでによければ効果は*“minimal… maybe no visible effect at all”* (翻訳)「最小限で、目に見える効果がないかもしれません」。Gary Illyesは画像URL移行によるシグナル損失を*“in line with web search results, which is a few weeks.”* (翻訳)「Web検索結果と同じく、数週間程度」と表現しました。つまり、新しい画像には説明的な名前を付けます。しかし、わずかな効果のために全サイトをリネームして数週間混乱させる作業はしません。

altテキスト（短い説明）

altテキストには独立した詳しい記事があるため、ここで完全な内容を繰り返すつもりはありません。要点は、altテキストが画像メタデータで最も重要な要素ですが、実際の効果はWeb検索ランキングではなく、画像検索とアクセシビリティにあることです。Googleはコンピュータービジョンとページの文脈に加えてaltテキストを読み取ります。文脈に合わせて書き、キーワードを詰め込まず、装飾だけの画像には alt="" を使います。完全なルール、引用、監査ワークフローはaltテキストガイドにあります。

圧縮、遅延読み込み、Core Web Vitals

画像がLCPを決めることが多いため、ここが画像SEOとCore Web Vitalsの重なる部分です。

• すべてを圧縮する。 表示寸法に合わせて画像を適切なサイズにし、圧縮します。多くのページにとって、これが最大のパフォーマンスレバーです。
• ネイティブの遅延読み込みは画面下なら安全。 <img> に loading="lazy" を付ける方法はGoogleが推奨しており、クロール可能です。壊れるのは、実際のURLを data-src に隠し、src を公開しないJavaScript実装です。インデックスされないリスクがあります。ネイティブの loading="lazy" またはIntersectionObserverを使い、クリックやスワイプではなく、見えるときに画像が読み込まれるようにします（“Google Search does not interact with your page” (翻訳)「Google検索はページを操作しません」）。
• LCP画像は決して遅延読み込みしない。 最も多く破られるルールです。画面上部で最大の画像（通常はヒーロー）は、loading="eager" と fetchpriority="high" で早く読み込みます。LCP画像の遅延読み込みは理由なくLCPを数百ミリ秒遅らせることがあります。

レスポンシブ画像

異なるビューポート向けに解像度を変える srcset + sizes と、アートディレクションや形式切り替えに使う <picture> を利用します。次の2点を混同しないでください。

• フォールバックの src を必ず含める。 上記のとおり、クローラーと古いブラウザーには必要です。
• すべての候補に到達できるようにする。 フォールバックの src に適用するアクセスルール（ブロックされていない、認証の背後にない、無効なURLではない）は、各 srcset/<picture> 候補にも適用されます。発見できない候補は、フォールバックが正常でも役に立ちません。
• URLをページと一貫させる。 画像サイトマップに置く画像URLは、ページが実際に使うURLと同じにします。モバイルとデスクトップで異なる画像URLを配信しないでください。Googleはモバイルファーストのクローラーであり、新しいURLのランキング履歴を再構築する間、異なるURLが一時的に画像トラフィックを失わせます。

画像の構造化データ

構造化データは、画像関連のリッチリザルトとバッジを可能にします。

• license プロパティ付きの ImageObject によって、Google画像検索のライセンス可能バッジの対象になります。必須フィールドは contentUrl と、creator、creditText、copyrightNotice、license のうち少なくとも1つです。バッジ自体には license + acquireLicensePage を追加します。
• ProductとArticleの構造化データでは、複数のアスペクト比（一般的には16:9、4:3、1:1）を持つ画像配列が求められます。画像を含むリッチリザルトには image プロパティが必須です。
• サムネイルを制御する。 Googleのサムネイル選択は自動ですが、primaryImageOfPage スキーマ、メインエンティティの image プロパティ、または og:image メタタグで影響を与えられます。GoogleはSearchとDiscoverのサムネイルにschema.orgマークアップと og:image の両方を使います。

対象となるマークアップは表示を保証しません。構造化データによってバッジ、画像配列の扱い、サムネイルが可能になっても、実際に表示するかどうかはGoogleがページごとに判断します。

ここは、より広い構造化データのテーマと画像SEOが重なる場所でもあります。商品、記事、画像のリッチリザルトを動かすマークアップは同じ仕組みです。

画像サイトマップ

画像サイトマップは発見のためのツールです。CDNでホストする画像、大規模なギャラリー、通常のクロールでは画像が見つからない可能性があるJavaScript中心のサイトで特に役立ちます。注意点が2つあります。Googleが現在サポートしているのは <image:image> と <image:loc> だけです（<image:caption>、<image:title>、<image:geo_location>、<image:license> は2022年5月6日に非推奨になりました。ただしBingは現在も使うので、両方に1つのサイトマップを配信するなら残します）。また、画像サイトマップの <image:loc> だけはクロスドメインURLを使える場所です。CDNホスティングには便利ですが、Search ConsoleでCDNドメインを確認してください。仕組みの詳細は画像サイトマップの記事にあります。これは約束ではありません。画像サイトマップはGoogleが見落とす可能性のある画像の発見を助けますが、送信したからといってクロール、インデックス、ランキングは保証されません。

Discoverと大きな画像

DiscoverやGoogleの各種サーフェスで大きな画像プレビューの対象になるには、<meta name="robots" content="max-image-preview:large"> を追加し、大きな画像（幅1 200px以上、高解像度、できれば16:9）を使います。Google自身のケーススタディでは、大きなプレビューを有効にしたことで実際のCTR向上が記録されています（食品ブログはDiscoverからCTR +79 %、ニュースサイトは6か月でCTR +30 % / クリック +332 %）。画像変更の中では、直接測定できる上振れがある数少ない例です。

ストック画像と独自画像

Muellerの立場は率直に引用する価値があります。ストック写真は*“doesn’t matter for web search directly,”* (翻訳)「Web検索には直接関係しません」が、“for image search, if it’s the same image as used in many places, it’ll be harder.” (翻訳)「画像検索では、多くの場所で使われている同じ画像だと難しくなります」。別の発言では、“uniqueness isn’t equivalent to higher quality” (翻訳)「独自性は高品質と同じではありません」とも述べています。自分で撮影した写真だからといって自動的に上位表示されるわけではありません。Web検索だけを気にするならストックを自由に使い、画像検索での可視性が重要なら独自画像を使います。唯一無二の画像には競合する同一画像がないからです。

新しい論点：AI画像のラベル（C2PA / IPTC）

新しく、多くのガイドが見落としているため、取り上げておく価値があります。GoogleはIPTCの著作権フィールドを読み取り、Google画像検索で帰属クレジットとして表示することがあります（無料のブランド露出です）。またIPTC / C2PAメタデータを使ってAI生成画像を識別し、「この画像について」機能で「AI生成」ラベルを表示します。カメラのEXIF（ISO、絞り、GPS）にランキング効果があるという文書化された情報はありません。パフォーマンスのために削除しても、著作権フィールドは保持します。この領域はまだ変化しています。

次に進む場所

このハブは地図です。詳しい記事と関連トピックは次のとおりです。

• altテキスト — alt 属性の完全版です。なぜ画像検索のためでWeb検索のためではないのか、アクセシビリティと法的な重要性、書き方のルール、装飾画像、リンクされた画像のアンカーテキスト、大規模監査を扱います。独立記事にする価値があるほど深いサブトピックです。
• Google画像検索でのランキング — Google画像検索とLensでの可視性を深掘りします。インデックス要件、ライセンス可能な画像、上位ページが今も繰り返す神話を扱います。
• 画像形式 — JPEG、PNG、WebP、AVIFを詳しく比較します。それぞれが実際に得意なことと、形式を切り替えただけではランキング要因にならない理由を説明します。
• Core Web Vitals — 画像SEOのパフォーマンス側はこちらです。圧縮、LCP、fetchpriority は、画像の帽子をかぶったCore Web Vitalsの作業です。
• 構造化データ — ImageObject、Product/Articleの画像配列、og:image によるサムネイル制御は、より広い構造化データの話の一部です。
• 画像サイトマップ — 発見の仕組み、Googleでは非推奨だがBingでは残るタグ、クロスドメインCDN URLを扱います。

AIによる要約

Advanced版の要点をまとめます。

• 画像SEOは2つの仕事です。 (1) altテキスト、ファイル名、ページの文脈、独自性で決まる画像検索（Google画像検索 / Lens / Bing）でのランキング。(2) 画像は通常LCP要素としてCore Web Vitalsに影響するためのページパフォーマンス。
• 発見の仕組み： Googleは <picture> 内を含む <img> をインデックスしますが、CSS背景はインデックスしません。フォールバックの src を必ず残し、対応形式はBMP、GIF、JPEG、PNG、WebP、SVG、AVIFです。
• 形式に直接のランキング上昇効果はありません（MuellerはAVIFについて説明し、WebPは「問題ない」と述べています）。利点は速度です。圧縮にはAVIF/WebP、透明度にはPNG、アイコンにはSVGを選びます。
• ファイル名： 説明的な名前は新しい画像に役立ちます。既存画像を一括リネームしないでください（効果は最小限またはなく、数週間の混乱が生じる — Mueller。シグナル損失は「数週間程度」— Illyes）。
• altテキストは主に画像検索に役立ち、Webランキングには役立ちません。独立記事で扱います。
• 遅延読み込み： ネイティブの loading="lazy" は画面下では安全です。data-src にURLを隠すJSは危険で、LCP画像は決して遅延読み込みしません。そこには fetchpriority="high" を使います。
• URLの一貫性（2025年5月）： 同じ画像をどこでも同じURLで参照し、モバイルとデスクトップのURLを一致させます。
• 構造化データ： ImageObject + license はライセンス可能バッジを、Product/Articleは複数アスペクト比の画像配列を可能にします。primaryImageOfPage / og:image はサムネイルに影響します。
• 画像サイトマップは発見に役立ちます（CDN、大きなギャラリー、JSサイト）。Googleが残したのは <image:image> / <image:loc> だけです（残りは2022年5月に非推奨、Bingは今も使います）。
• Discover： max-image-preview:large + 幅1 200px / 16:9の画像。CTR向上が文書化されています。
• ストックと独自性： ストックはWeb検索には問題ありませんが、画像検索では難しくなります。独自性 ≠ 高品質です。AI画像のラベルはC2PA/IPTCによって発展中で、EXIFはランキング要因ではありません。

公式ドキュメント

検索エンジンによる一次資料です。

Google

• Google Images best practices — 中核となる参照資料です。<img> による発見、対応形式、説明的なファイル名、altテキスト、レスポンシブ画像、URLの一貫性、優先画像の選択、インラインリンクからのオプトアウトを扱います。
• Image sitemaps — 対応する <image:image> / <image:loc> タグ、CDN向けのクロスドメインURL、URLごとの1 000画像制限。
• Image license structured data — ImageObject、必須/推奨フィールド、ライセンス可能バッジ。
• Article structured data — 推奨される画像配列とアスペクト比（16:9、4:3、1:1）。
• Product snippet structured data — 商品画像の推奨事項。
• Fix lazy-loaded content — ネイティブの loading="lazy" / IntersectionObserverと、操作をきっかけにした読み込みがGoogleからコンテンツを隠す理由。
• Robots meta tag — max-image-preview — SearchとDiscoverで大きな画像プレビューを可能にする方法。
• Large images case study — 大きなプレビューを有効にしたGoogle自身のCTR向上データ。
• Prevent images appearing in search — robots.txt（Googlebot-Image）、X-Robots-Tag: noindex、Removalsツール。
• Mobile-first indexing best practices — モバイルとデスクトップで画像URL、altテキスト、ファイル名を一致させる方法。

Bing / Microsoft

• Being a part of the Bing Image Search ecosystem — Bingの画像発見と使用するメタデータ（Googleが非推奨にした画像サイトマップタグをBingは今も使う点に注意）。
• Bing Visual Search — オブジェクトレベルのビジュアル検索と、Bingが画像を一致させるために役立つ要素。

ソースからの引用

Googleによる記録に残る発言です。ページに引用箇所が表示される場合、リンクは引用部分へ移動するディープリンクになっています。

Googleのドキュメント — 発見とファイル名

• “Google parses the HTML <img> elements (even when they’re enclosed in other elements such as <picture> elements) in your pages to index images, but doesn’t index CSS images.” (翻訳)「Googleは、画像をインデックスするためにページのHTML <img> 要素（<picture> など他の要素に囲まれていても）を解析しますが、CSS画像はインデックスしません。」 引用へ移動
• “The filename can give Google clues about the subject matter of the image.” (翻訳)「ファイル名は画像の主題についてGoogleに手がかりを与えられます。」 引用へ移動

Google広報担当者 — URLの一貫性（2025年5月）

• “We updated the Google Image SEO best practices to clarify that URLs for images should be referenced consistently for easier crawling on larger websites.” (翻訳)「大規模サイトでクロールしやすくするため、画像のURLは一貫して参照すべきだと明確にするようGoogle Image SEOのベストプラクティスを更新しました。」 報道

John Mueller、Google — 形式にSEO上の上昇効果はない

• AVIFについて：AVIFファイルを使っても**「SEO上の上昇効果」はありません**。利点はページ速度を通じた間接的なものです。 報道
• WebPについて：“WebP images are fine for Image Search.” (翻訳)「WebP画像は画像検索に問題ありません。」 報道

John Mueller、Google — ファイルを一括リネームしない

• “If you change all of the filenames across the website, then it’s going to take a lot of time for Google’s systems to see” (翻訳)「Webサイト全体のファイル名を変えると、Googleのシステムが認識するまで長い時間がかかります」。altテキストと周囲の文脈がすでにあれば、効果は*“minimal effect, maybe no visible effect at all”* (翻訳)「最小限で、目に見える効果がないかもしれません」。 SEJの報道

John Mueller、Google — ストック画像と独自画像

• ストック写真は*“doesn’t matter for web search directly,”* (翻訳)「Web検索には直接関係しません」が、“for image search, if it’s the same image as used in many places, it’ll be harder.” (翻訳)「画像検索では、多くの場所で使われている同じ画像だと難しくなります」。 報道
• “Uniqueness isn’t equivalent to higher quality” (翻訳)「独自性は高品質と同じではありません」。自分で撮影した写真だからといって、ページや画像が必ず上位表示されるわけではありません。 報道

John Mueller、Google — 画像ストリーミング

• ストリーミングで画像を埋め込むことは、“a great way to prevent your images from being found through search engines” (翻訳)「検索エンジンに画像を見つけられないようにするすばらしい方法」です。つまりSEOには適していません。 報道

Gary Illyes、Google — 画像移行によるシグナル損失

• 画像URL移行によるシグナル損失は、“in line with web search results, which is a few weeks.” (翻訳)「Web検索結果と同じく、数週間程度」です。 報道

画像SEOチートシート

要素 — それぞれが行うこととベストプラクティス

早見表

• 対応形式：BMP、GIF、JPEG、PNG、WebP、SVG、AVIF（AVIFは2024年8月以降）。
• Googleは <img>（<picture> 内を含む）をインデックスしますが、CSSの background-image はインデックスしません。
• WebP/AVIFに直接のランキング上昇効果はない。利点は速度 → Core Web Vitalsです。
• EXIF（ISO/絞り/GPS）：ランキング効果はない。IPTC著作権フィールドはクレジットとして表示されることがあります。
• C2PA/IPTC：Googleの「この画像について」でAI生成画像をラベル付けするために使われます。発展中の仕組みです。

メンタルモデル

画像SEOは1つではなく2つの仕事です。 ほとんどすべての「画像SEOチェックリスト」はこの2つを混同しており、その混同が「ファイル名を変えよう」「ランキングのためにWebPへ変えよう」という神話を広め続ける理由です。実際の2つの目標に分ければ、それぞれの助言が正しい箱に収まります。

1. 画像検索でのランキング。 Google画像検索、Bing Images、Google Lensで画像固有の検索に見つけてもらうことです。ここで使うレバーはaltテキスト、ファイル名、画像周辺のテキスト、構造化データ、画像の独自性です。ページの読み込み速度には影響しません。

2. ページパフォーマンス。 画像はページでほぼ常に最も重い要素で、遅いLargest Contentful Paint（LCP）の主な原因になります。LCPはWeb検索のランキングシグナルであるCore Web Vitalsにつながります。ここで使うレバーは形式、圧縮、読み込み戦略です。画像がGoogle画像検索に表示されるかどうかには影響しません。

なぜ分けることが実務で重要なのか：

• 形式の神話を終わらせる。 WebPやAVIFは画像検索で上位表示させるためのものではありません。パフォーマンス側のレバー（小さなファイル → 速いLCP → Core Web Vitals）であり、画像検索側のレバーではありません。形式変更でランキング上昇を期待するのは、パフォーマンスのツールで画像検索の問題を解決しようとすることです。
• 一括リネームの神話を終わらせる。 ファイル名は画像検索側のシグナルで、しかも小さなものです。既存ライブラリ全体をリネームしてもパフォーマンス側にはまったく影響せず、Muellerの見解ではaltテキストと文脈がすでによければ画像検索への効果は「最小限で、目に見える効果がないかもしれません」。2つの箱のうち1つだけで小さな効果を得るために、数週間混乱させることになります。
• 遅延読み込みを置く場所が分かる。 loading="lazy" はパフォーマンス側の判断（画面外の画像を遅らせて読み込みを助ける）であり、2つの箱が交わる場所に厳格な例外が1つあります。LCP画像です。そこを遅延読み込みすると、画像検索側では何も得ずにパフォーマンス側を悪化させます。
• altテキストと圧縮が代替できない理由が分かる。 altテキストはほぼ完全に画像検索側のレバー（アクセシビリティも含む）で、圧縮はほぼ完全にパフォーマンス側のレバーです。完璧なaltテキストがあってもLCPがひどいページはあり、LCPが非常に速くてもaltテキストがなく画像検索で見えないページもあります。一方を直しても他方は直りません。

この分け方を診断に使います。画像が「うまくいかない」ときは、まずどちらの仕事に失敗しているかを決めます。Google画像検索に表示されないなら、altテキスト、ファイル名、独自性を確認します。ページが遅いなら、形式、圧縮、遅延読み込みの選択を確認します。パフォーマンスのレバーで画像検索の問題を直そうとする（またはその逆）のが、このテーマで最もよくある無駄な作業です。

継続KPI：画像検索の可視性と画像主導のページ速度

画像SEOは2つの仕事なので、健全性の確認も同じように分かれます。画像検索の可視性を見る指標と、パフォーマンス/Core Web Vitals側を見る指標です。

画像検索の表示回数とクリック数（Search Console）

• 指標 — Google画像検索からの表示回数とクリック数。検索トラフィック全体に占める割合として時間を追って記録します。
• 何を示すか — altテキスト、ファイル名、ページの文脈、画像の独自性が、2つの仕事のうち最初の仕事である画像検索の可視性を実際に獲得しているかどうか。全体のトラフィックが増えているのにImagesの割合が横ばいまたは低下しているなら、Web検索側に比べて画像検索側が軽視されています。
• 取得方法 — Search Console → 検索結果レポート → 検索タイプ：画像でフィルタします。同じページと日付範囲で、デフォルトのWebフィルターと表示回数/クリック数/CTR/掲載順位を比較します。
• 基準 / 現実的な範囲 — 普遍的な目標割合はありません。画像の多いサイト（レシピ、商品写真、ストック/ポートフォリオサイト）は、文字中心のB2Bブログより明らかに大きなImagesの割合を期待すべきです。初回確認時に自分の基準値を作り、固定値を追うのではなく傾向を見ます。
• 頻度 — 継続確認として四半期ごと。大規模な画像変更（大量リネーム、CDN移行、新しいaltテキスト対応）の数週間後にも再確認します。Illyesの移行によるシグナル損失の見解では、落ち着くまでの期間は「数週間程度」です。

画像の多いテンプレートに絞ったCore Web Vitals合格率

• 指標 — 実ユーザーのページ読み込みでLCP（および全体のCWV）に合格した割合。LCP要素が通常画像になるテンプレート（商品ページ、ブログのヒーロー画像、ギャラリー）に限定します。
• 何を示すか — 画像SEOのパフォーマンス側、つまり圧縮、形式の選択、正しい遅延読み込みが実環境で機能しているか。LCP画像を遅延読み込みしないルールと形式/圧縮の選択が機能していることを示すフィールドデータの証拠です。
• 取得方法 — PageSpeed InsightsまたはSearch ConsoleのCore Web Vitalsレポート（CrUXベース）を使います。サイト全体の平均ではなく、テンプレート/ページグループごとに分けてください。平均に隠れて、性能の悪いテンプレートが見えなくなることがあります。
• 基準 / 現実的な範囲 — Googleが公開する「良好」なLCP基準は、75パーセンタイルで2,5秒以下です。推測ではなく、文書化された実数として合否ラインにします。画像の重量とホスティングに完全に依存するため、それを超える正直な「典型値」はありません。
• 頻度 — CrUXのフィールドデータは28日間の移動期間なので、毎月確認します。画像形式、圧縮パイプライン、遅延読み込み実装を変更した直後にも再確認します。

時間を使う価値のある資料

私の関連記事

• Image SEO: 12 Actionable Tips for More Organic Traffic — Ahrefsの画像SEOガイド（ファイル名、altテキスト、形式、圧縮、サイトマップ、レスポンシブ画像、スキーマ、遅延読み込み、CDN）。
• The Beginner’s Guide to Technical SEO — より広い技術SEOの中で画像とCore Web Vitalsが占める位置。
• JavaScript SEO Issues & Best Practices — レンダリング側と、JavaScriptフレームワークが残す空のalt属性。
• Ahrefs Site Audit Study — alt属性の欠落が最も一般的な技術的問題だった100万以上のドメイン調査（80,4 %のサイト）。

私の講演

• “Image SEO”（Vismeウェビナー、2021年）— 検索向けに画像を最適化するための私の専門講演。

公式

• GoogleのGoogle Images best practices — このページ全体の標準的な参照資料。
• GoogleのLarge images case study — 大きな画像プレビューを有効にした実際のCTR向上データ。

業界の資料

• Google on Image Filenames & a Surprising SEO Mistake（Search Engine Journal）— altテキストがすでによければ一括リネームは「最小限で、目に見える効果がないかもしれない」というMuellerの記録セッションの助言。
• Google Shows How to Use Alt Text for SEO（Search Engine Journal）— altテキストは主に画像検索のシグナルであり、Webランキングの直接要因ではないというMuellerの説明。
• Google Updates Image SEO Best Practices: URL Consistency（Search Engine Land）— 同じ画像に同じURLを使うという2025年5月の更新の報道。
• Google Uses Schema.org + og:image for Thumbnails（Search Engine Land）— SearchとDiscoverで優先画像シグナルを扱う2026年3月の更新。
• Fetch Priority API（web.dev）— LCP画像に fetchpriority="high" を使う標準的な解説。「ヒーローを決して遅延読み込みしない」という説明の参照資料です。
• Let’s Talk Image SEO（Search Off the Record、Google、2022年10月）— Lizzi SassmanとJohn Muellerが画像の命名、altテキスト、クロール頻度について直接話しています。
• Image SEO: Multimodal AI（Search Engine Land）— AIによる視覚理解が画像検索の最適化をどう変えているか。
• Image Migrations and Lost Signals（GSQI）— 画像URL変更時の数週間程度のシグナル損失についてのGary Illyesの説明。

自分でテスト：画像SEO

このハブで扱った神話と仕組みについての短い5問です。それぞれ答えを選んでから、確認してください。

変更履歴