言語

Google画像検索でのランキング

Google画像検索とビジュアル検索（Google Lens）でのランキングと可視性を深掘りします。インデックス登録の前提条件、画像サイトマップ、ImageObjectとProductの構造化データ、Licensableバッジ、モバイルファーストインデックス、画像にrel=canonicalが適用されない理由を扱います。

初回公開：2026年7月2日 · 最終更新：2026年8月23日 · 上級者向け
AI執筆者：AI v2
このページには証拠シグナルが1件あります

Google画像検索でのランキングは一般的な画像SEOを土台としており、別の最適化チェックリストではなく画像検索システムそのものに関係します。まずrobots.txtでブロックされておらず、対応形式（BMP、GIF、JPEG、PNG、WebP、SVG、AVIF）で、CSS背景ではなく<img>のsrcから抽出されるというインデックス登録の前提条件を整えます。そのうえで、altテキスト、周辺テキスト、ファイル名、独自性というランキングシグナルが機能します。モバイルフレンドリーは画像検索独自のルールではなくモバイルファーストインデックスの結果なので、モバイルページにも同じ画像とaltテキストが必要です。画像サイトマップは検出を助けますが、ランキングの要素ではありません。構造化データはリッチな表示を可能にします。licenseプロパティを持つImageObjectはLicensableバッジの表示要件を満たし、Product構造化データはGoogle LensとShopping Graphに情報を渡します。rel=canonicalは画像には適用されず、Googleは視覚的に類似した版を自動的に照合します。Google Lensでは現在、月間約二百億回のビジュアル検索が行われ、その20%はショッピング関連です。C2PAのコンテンツクレデンシャルは「この画像について」を通じてAI画像をラベル付けできます。

TL;DR — Google画像検索でのランキングは一般的な画像SEOを土台としており、別の チェックリストではなく画像検索システムを扱います。まずインデックス登録の前提条件、 つまりrobots.txtでブロックされず、対応形式（BMP／GIF／JPEG／PNG／WebP／SVG／AVIF）で、 CSS背景ではなく<img src>から抽出される状態を整えます。その後、altテキスト、周辺テキスト、 ファイル名、独自性がランキングシグナルとして働きます。モバイル対応は画像独自のルールではなく、 モバイルファーストインデックスの結果なので、モバイル版にも同じ画像とaltテキストが必要です。 画像サイトマップは検出支援で、ランキング要素ではありません。構造化データはリッチな表示を 可能にし、ImageObjectのlicenseプロパティはLicensableバッジ、Productは Google Lens／Shopping Graphへつながります。画像にrel=canonicalは適用されず、 Googleが視覚的に似た版を自動照合します。Lensでは月間約二百億回の視覚検索が行われ、20%は ショッピング関連です。C2PAコンテンツクレデンシャルは「この画像について」でAI画像を示せます。

この主張の根拠 Google recommends contextual placement, descriptive titles and alt text, and high-quality images for Google Images. 対象範囲： Current Google Images SEO guidance. 信頼度： 高 · 検証日： Google Search Central: Google Images SEO best practices この主張の根拠 Google must be able to crawl image URLs and supports documented image formats; responsive image markup can be crawled when implemented normally. 対象範囲： Current Google image crawling and format guidance. 信頼度： 高 · 検証日： Google Search Central: Image technical guidelines

この仕組みの位置付け：1つのインデックス済みコーパスと複数のサーフェス

Google画像検索、ウェブ検索内の画像結果、Google Lens／かこって検索は、同じインデックス済み 画像コーパスを使います。そのためGoogle画像検索向けの最適化は視覚検索にもつながります。 この記事は画像SEOハブを補完するランキングと可視性の深掘りです。 ハブが一般的な最適化チェックリストであるのに対し、ここでは何が登録・表示され、バッジを得るのかを扱います。

仕組みを検討する前に、John Muellerの戦略的な出発点を採用する価値があります。 “think about what do you think people would search for in a visual way to come to your website” (翻訳) 「人々が視覚的に何を検索してサイトへ来るのかを考えてください」 （Search Off the Record第48回）。 公開内容が視覚検索されないなら、画像SEOは最も効果の高い作業ではありません。

インデックス登録の前提条件（ランキング以前）

画像がランキング対象になるのは、インデックス登録後だけです。前提条件を順に確認します。

  • robots.txtでブロックされていない。 画像URLまたはディレクトリが拒否されるとGooglebot-Imageは取得できず、Google画像検索へ表示されません。「自分の画像が表示されない」場合に、サイト側で最も多い設定ミスです。
  • 妥当なファイルサイズでクロールできる。 画像検索クローラーはfavicon取得時よりもはるかに大きなファイルを処理できますが、技術要件 に従い、適切な圧縮と寸法でクロール効率と速度を保ちます。
  • 対応形式である。 BMP、GIF、JPEG、PNG、WebP、SVG、AVIF（2024年8月追加）。
  • <img src>から抽出できる。 Googleは、“Google can find images in src attribute of <img> element.” (翻訳) 「Googleは<img>要素のsrc属性から画像を検出できます」。 src属性を持つ<img>（<img>を<picture>内で使う場合を含む）から抽出し、CSSのbackground-imageからは抽出しません。 Googleの文書も、この点について*“occasionally get questions about”* (翻訳) 「時折質問を受ける」と明示し、 画像はsrc属性を持つimgタグからのみ抽出されると説明しています。

これらを満たすと画像は対象候補になります。ランキングは別の問題です。

画像のランキングは検出とインデックス可能性の後に始まります。クロール可能なファイル、対応形式、抽出可能な`<img src>`が必要です。 出典： Google Search Central

画像はまずGooglebot-Imageがクロールでき、対応する画像形式を使い、ページ内の実際の画像要素で参照されなければなりません。CSS背景画像はこの抽出条件を満たしません。画像がインデックス登録候補になって初めて、altテキスト、周辺コンテキスト、ファイル名、独自性がランキングに影響します。

© Patrick Stox LLC · CC BY 4.0 ·

ランキングシグナル（概要 — 詳細は各深掘りで扱う）

altテキストとファイル名は個別記事があるため、ここではGoogleチームの説明に沿って要点だけ示します。

  • altテキスト — 主要シグナルです。詳しくはaltテキストガイドで扱います。単なる説明ではなく文脈を書くことが重要です。Muellerは、“don’t just be like, ‘Oh, this is a photo of a beach.’ But rather like, ‘This is the beach before the chemical spill happened’… when you’re talking about Image Search, it’s not that people want an image, but rather they want information which is attached to that image.” (翻訳) 「『これは浜辺の写真です』だけでなく、『化学物質が流出する前の浜辺です』のようにしてください。画像検索では、人々が求めているのは画像そのものではなく、その画像に結び付いた情報だからです」
  • 周辺テキスト、キャプション、配置 — Googleは*“Make sure images are placed near relevant text and on pages that are relevant to the image subject matter.”* (翻訳) 「画像を関連テキストの近く、かつ画像の主題に関連するページへ配置してください」と説明します。多くのチェックリストでaltテキストより軽視されがちです。
  • ファイル名 — 比較的軽いシグナルです。詳しくは画像ファイル名ガイドで扱います。Muellerは説明的なファイル名を肯定しつつ、“but I don’t think you would see a significant change if you already do the other things around images, like the alt texts, the text surrounding the image. Those are really, really strong signals.” (翻訳) 「altテキストや画像の周辺テキストなど、ほかの施策をすでに行っているなら、説明的なファイル名だけで大きな変化は見られないと思います。それらは非常に強いシグナルです」
  • 独自性 — 装飾用のストック写真は多くのライセンスサイトで使われるため、その画像クエリで自サイトをランクインさせにくい一方、Muellerによればページやサイトの残りに*“doesn’t count against”* (翻訳) 「不利には働かない」ものです。

モバイルファーストインデックスと画像の可視性

Google画像検索の要素として「モバイルフレンドリー」が挙げられますが、正確には モバイルファーストインデックスが仕組みです。ほぼウェブ全体で移行が完了 しているため、 Googleはモバイルでレンダリングしたページに実在する画像とaltテキストを登録します。 モバイルファーストのガイダンス も、 モバイルとデスクトップで同じコンテンツ（文章、画像、動画、リンク）と同じaltテキストを用意するよう求めています。

実務上の確認事項は抽象的な「モバイル対応か」ではなく、モバイルページが同じURLの同じ画像を、 同じaltテキストで配信しているかです。モバイルで画像を削除したり、低解像度の別画像へ差し替えたりすると、 デスクトップの状態にかかわらず画像検索から実質的に見えなくなります。

画像サイトマップ：することと、しないこと

画像サイトマップは検出を助けるもので、ランキング要素でも再クロールを速める手段でもありません。 Googleは*“Image sitemaps are a way of telling Google about other images on your site, especially those that we might not otherwise find (such as images your site reaches with JavaScript code).”* (翻訳) 「画像サイトマップは、JavaScriptで到達する画像など、ほかの方法では見つけられない可能性のあるサイト上の画像をGoogleへ伝える方法です」と説明します。 JavaScriptで読み込む画像やCDN上の画像で特に役立ちます。

要点は、<image:image>が<url>ブロック内で1枚の画像情報を囲み、<image:loc>が画像URLを示すことです。 各<url>には最大1 000個の<image:image>を含められ、通常のサイトマップと違って、 Search Consoleで両方のドメインを確認すればCDNなど別ドメインも指定できます。 2026年5月6日、Googleは<image:caption>、<image:geo_location>、<image:title>、 <image:license>の4つを文書から削除しました。サイトマップ自体は廃止されていませんが、これらのタグは使いません。 Muellerも既知の画像の再クロールを速める効果は小さいと述べています。画像サイトマップは再クロール促進ではなく、 ほかの方法で見つけにくい画像の検出支援として扱います。タグ、名前空間、ファイル形式は 画像サイトマップガイドを参照してください。 “as long as you verify both domains in Search Console.” (翻訳) 「Search Consoleで両方のドメインを確認している限り」 “Personally, I don’t think this would change much, in our case.” (翻訳) 「個人的には、今回のケースでは大きく変わらないと思います」

Google画像検索における構造化データとリッチな表示

構造化データはGoogle画像検索のバッジやリッチな表示を可能にします。Googleは、構造化データを含めると Google画像検索の目立つバッジを含む一部のリッチリザルトへ画像を表示でき、バッジの対象になるには image属性が必須だと説明します。適格性はタイプごとに異なり、Recipe、Product、Videoは それぞれ別の表示を可能にします。一般ガイドラインとタイプ固有ガイドラインの両方を満たす必要があります。 有効なマークアップは表示を可能にするだけで、Googleが実際に表示する保証ではありません。 “If you include structured data, Google can display your images in certain rich results, including a prominent badge in Google Images,” (翻訳) 「構造化データを含めると、Google画像検索の目立つバッジを含む一部のリッチリザルトに画像を表示できます」 “the image attribute is a required field to be eligible for a badge.” (翻訳) 「バッジの対象になるにはimage属性が必須です」

Licensableバッジ — 表示対象となるための正確な条件

多くのガイドは「ImageObjectスキーマを追加するだけ」と単純化しすぎています。 Googleの画像ライセンスメタデータ にある正確な要件は次のとおりです。

  • contentUrlは常に必須。 “Google uses contentUrl to determine which image the photo metadata applies to.” (翻訳) 「Googleは、写真メタデータがどの画像に適用されるかを判断します」
  • Licensableバッジの表示対象になるにはlicenseプロパティが必須。 “If you’re using structured data to specify an image, you must include the license property for your image to be eligible to be shown with the Licensable badge.” (翻訳) 「構造化データで画像を指定する場合、Licensableバッジの対象にするには画像にlicenseプロパティを含める必要があります」 creator、creditText、copyrightNoticeはメタデータパネルへ詳細を加えますが、それだけではバッジの表示対象になりません。
  • acquireLicensePageを推奨。 画像のライセンス取得方法を確認できるURLです。

schema.org構造化データ、埋め込みIPTC写真メタデータ、または両方で提供できます。競合時は “Google will use the structured data information.” (翻訳) 「Googleは構造化データの情報を使用します」。 一般的なImageObjectの仕組みは画像SEOハブでも扱います。

Product構造化データ → Google画像検索とGoogle Lens

Eコマースでは、Product構造化データにより商品画像がLensの視覚一致やショッピング表示の対象になります。 Googleは、商品ページへ構造化データを追加するとGoogle画像検索やGoogle Lensを含む検索結果で商品情報を よりリッチに表示でき、ページ上の構造化データとMerchant Centerフィードの両方を提供すると適格性が 最大になると説明します。基本的な無料リスティングにフィードは絶対条件ではありませんが、併用が明確な推奨です。 詳細はProductスキーマガイドで扱います。 “When you add structured data to your product pages, your product information can appear in richer ways in Google Search results (including Google Images and Google Lens),” (翻訳) 「商品ページへ構造化データを追加すると、Google画像検索やGoogle Lensを含むGoogle検索結果で商品情報をよりリッチに表示できます」 “Providing both structured data on web pages and a Merchant Center feed maximizes your eligibility.” (翻訳) 「ウェブページの構造化データとMerchant Centerフィードの両方を提供すると、対象範囲が最大になります」

推奨サムネイル：schema.org と og:image

“how does Google pick which image to show as my thumbnail?” (翻訳) 「Googleはサムネイルに表示する画像をどのように選ぶのか」 “uses both schema.org markup and the og:image meta tag as sources when determining image thumbnails in Google Search and Discover.” (翻訳) 「Google検索とDiscoverの画像サムネイルを決める際、schema.orgマークアップとog:imageメタタグの両方を情報源として使います」 「Googleはどの画像をサムネイルに選ぶのか」はよくある質問です。2026年3月2日の文書更新で、Googleは 検索とDiscoverの画像サムネイルを決める際、schema.orgマークアップとog:imageメタタグの両方を 情報源として使うと明示しました。両方を意図的に設定する価値があります。ただしRecipe構造化データの imageはレシピのリッチリザルトだけを制御し、一般的なテキスト結果のサムネイルを上書きしません。

画像にcanonicalタグは使わない

競合記事ではほとんど扱われない意外な点です。rel=canonicalは画像に適用されません。 Muellerは、画像にとってrel=canonicalは本質的に無関係でウェブページ向けの仕組みであり、 Googleのシステムは画像が同じものか認識し、1つの対象について複数画像が登録されても問題ないと説明しました。 “For images, the rel=canonical is essentially irrelevant. It’s really more for web pages. And I don’t think we even support it for images… Our systems try to recognize when the image is the same thing. And having multiple images indexed for one thing is perfectly fine.” (翻訳) 「画像ではrel=canonicalは本質的に無関係です。実際にはウェブページ向けで、画像ではサポートしていないと思います。システムは同じ画像かどうかを認識しようとするため、1つの対象について複数画像がインデックス登録されても問題ありません」

2つの切り抜きやサイズが同じ画像だと伝える統合マークアップは不要です。Googleのシステムは画像を見て 視覚的に似た画像を探し、関連付けます。複数サイズや切り抜きが、有効な別結果として同時に登録されることもあります。 ウェブページの正規化に相当する処理が自動で行われ、設定するタグはありません。 “look at the image and try to find visually similar images, and they kind of connect it like that.” (翻訳) 「画像を見て、視覚的に似た画像を探し、そのように関連付けます」

関連する結果として、同じ写真を自サイトとInstagramなどのSNSへ投稿すると、画像検索では重複として まとめられる場合があります。一方、周囲のウェブページは通常検索で別結果のままです。先にアップロードしても 自サイトが「canonicalな情報源」になるわけではなく、画像には先行者を正規版にする仕組みがありません。 “I don’t think it works that way.” (翻訳) 「そのような仕組みではないと思います」

個別画像のランディングページ

特定画像を個別に見つけてもらうには、50枚のギャラリーの一枠に置くだけでなく、独自の説明文を持つ 専用ランディングページを用意します。Search Off the Record第97回 で Muellerは、専用ページならGoogleが「これがページの主要画像で、追加情報もある」と理解できる一方、 少量の文章と50枚の画像があるギャラリーは、探される画像ランディングページなのか曖昧だと説明しました。 各画像に実在するクロール可能なURLを与えないJavaScriptフラグメント型ギャラリーは具体的な失敗例です。 “This is the primary image of this page, and here is some additional information about this image,” (翻訳) 「これがこのページの主要画像で、ここに画像についての追加情報があります」 “is this an image landing page that someone might be looking for? Which perhaps not.” (翻訳) 「これは誰かが探している画像ランディングページなのか。おそらく違います」

同じ回でMuellerは、“No… That’s fine.” (翻訳) 「いいえ、問題ありません」と述べ、透かしはペナルティにならないと説明しています。レスポンシブな高解像度画像と良好な Core Web Vitalsはベストプラクティスですが、ランキングの近道ではありません。良い実装だけで 「スイスの水中写真」に自動的にランクインするわけではなく、さらに取り組みが必要です。 “just because you’re doing these good practices, you’re not going to rank for underwater photography Switzerland automatically… You have to do more.” (翻訳) 「これらのベストプラクティスを実践しただけで、『スイスの水中写真』に自動的にランクインするわけではありません。さらに取り組む必要があります」

Google Lensとビジュアル検索

Google Lensは同じインデックス済み画像コーパスに、視覚一致（ウェブ上の似た画像や商品を探す）と マルチ検索（画像＋文章）を重ねます。Googleの2024年10月の発表 によると、 Lensは月間約二百億回の視覚検索を処理し、20%はショッピング関連です。GoogleのAIとShopping Graphの 450億超の商品を組み合わせて、視覚的な一致を見つけます。 “merges the power of Google’s AI and more than 45 billion products in the Shopping Graph to help you discover visual matches.” (翻訳) 「GoogleのAIとShopping Graphの450億点超の商品を組み合わせ、視覚的な一致を見つける手助けをします」

数値については、2025〜2026年のSEO記事にさらに大きい数字がありますが、Googleの一次情報まで追跡できませんでした。 業界内で反復された数値として扱い、上記の2024年10月のGoogle発表を確実な基準にします。

商品画像をLensのショッピング結果へ出す仕組みは、前述のProduct構造化データで、Merchant Centerフィードとの 併用が理想です。最適化する独立した「Lens SEO」面はなく、インデックス済み画像と構造化データを整え、Lensが利用します。

AI画像のラベル付け：C2PAと「この画像について」

AI生成画像が可視性を損なうかという質問への現在の答えは、直接は損なわない、です。Googleは C2PAコンテンツクレデンシャルを読み、**「この画像について」**パネルでAI生成・編集画像を表示できます。 Googleの2024年9月の発表 では、 この機能はGoogle画像検索、Lens、かこって検索から利用できると説明されています。 Google検索も対応を追加 しました。これは文書化されたランキングペナルティではなく、 透明性とラベル付けの層です。 “is accessible in Google Images, Lens and Circle to Search.” (翻訳) 「Google画像検索、Lens、かこって検索から利用できます」

Bing画像検索（概要）

Bing／Microsoftには画像検索SEO専用の公式文書がなく、一般的なウェブマスターガイドラインと、 クロール可能性、altテキスト、構造化データの標準的な実務が最も近い資料です。Bingは2026年5月に、 結果を要約付きのセクションへ分けるAI整理型の画像検索を公開しましたが、サイト所有者向け最適化指針はありません。 Googleと同じ基本原則で最適化します。

次に進む先

これは画像SEO群のランキングと可視性の深掘りです。関連ページは次のとおりです。

  • 画像SEO — 形式、圧縮、遅延読み込み、Core Web Vitalsを扱う総合チェックリスト。
  • altテキスト — 書き方、装飾画像、大規模監査を含む主要ランキングシグナルの詳細。
  • 画像ファイル名 — 登録済み画像を一括改名すべきでない理由を含むファイル名シグナルの詳細。

専門家メモを追加

専門家の引用を固定

新しい人物ですか？まず、 /admin/experts/ → 専門家の引用を固定 から未登録プロフィールを作成してください。