商品画像のAI検索対策｜写真・alt・商品データをそろえる手順

商品画像のAI検索対策は、写真に写る商品、alt属性の説明、ページの文章、Googleへ送る商品データをそろえることから始めます。 写真へ検索語を詰め込んでも、色違いの画像や開けないURLが残っていれば、商品の情報は食い違ったままです。

対象は、通販サイトで商品を登録する担当者と、画像の修正を制作会社へ依頼する担当者です。まず一つの商品を選び、画像の内容から配信設定まで順に点検すると、何を誰に直してもらうかを整理できます。

ここではGoogleのAIによる概要・AIモードと、Google検索・Merchant Centerの公式資料を使います。確認日は2026年10月26日です。以下の青い陶器マグ、商品番号、修正例は説明用の架空の例で、実在商品の仕様や検索成果を示すものではありません。

商品画像のAI検索対策は、Googleが取得できる画像と説明から始める

最初に整えるのは、実際の商品が分かる写真と、その内容を文章でも確認できるページです。 そのうえで、Googleが画像ファイルへアクセスできるかを確かめます。写真が鮮明でも説明が別の商品を指していれば、購入前の確認に使いにくくなります。

説明用の図です。商品と画面は架空の例で、実際の販売物や管理画面を示すものではありません。

例えば、青いマグのページに白いマグの写真が残っているなら、先に写真の参照先を直します。「AIに読み取られやすい説明」を考える前に、販売するものと見せるものの対応を確認する作業です。

画像を差し替える人と商品データを管理する人が別なら、商品番号を共通の目印にします。同じ名前の色違いがある店では、商品名だけで依頼すると取り違えが起きるためです。

GoogleのAI検索に、画像専用の追加要件はあるか

Googleは、AIによる概要やAIモードのために特別な追加の技術要件は設けていないと説明しています。重要な内容を文章で伝え、必要に応じて高品質の画像を添えることが、サイト側の基本として示されています。[1]

したがって、画像だけでAI向けの別ページを作ることから始める必要はありません。既存の商品ページで、何の商品か、どの色か、どこまでが販売物かを確かめられる状態にします。画像のaltへ「AI検索対策」と入れる作業でもありません。

この案内はGoogleのAI機能についてのものです。すべてのAIサービスが同じ画像形式や取得条件を使うとは判断できず、他社の機能へ登録する場合はその仕様を別に確認します。

また、基本を整えることと回答への採用は同じではありません。修正の完了条件は、まず写真と説明の一致に置き、AIでの紹介は後から観測する項目として分けておきます。

画像検索・AI回答・商品掲載を、同じ成果として数えない

画像を直した後に確認する場所は、目的によって異なります。Google画像検索に写真が出ること、AIの回答に商品が紹介されること、商品掲載に主画像が出ることは、同じ出来事ではありません。

例えば、画像検索で写真を見つけられても、特定の質問へのAI回答に採用された証拠にはなりません。逆に、AI回答に商品名が出ても、その写真が使われたとは限らないため、見えたものをそのまま記録します。

社内の報告では、「画像の取得確認」「商品掲載の状態」「AI回答での観測」を別の欄にすると混同を減らせます。画像の取得確認を終えた日を、AIでの掲載が始まった日として書き換えないことが大切です。

購入まで調べる場合も、注文記録との対応を別に確認します。画像を変えた翌日に売上が増えても、広告や値引きなどが同時に変わっていれば、画像だけの効果とは判断できません。

最初は一つの商品で、画像と説明の食い違いを探す

最初の対象には、担当者が仕様を確認でき、色違いを含む商品を一つ選ぶと点検しやすくなります。売れ筋であっても元画像や仕様書が手元にない商品なら、先に確認できる商品で手順を固める方法があります。

架空の例では、商品番号を MUG-BL-01、販売対象を青い陶器マグ一個とします。商品ページ、画像の登録画面、商品データの一覧を開き、どの場所もこの商品を指しているかを比べます。

見つけた問題は「画像が悪い」とまとめず、「主画像だけ白色」「底面写真のaltが正面と同じ」「古い画像URLが商品データに残る」のように書きます。この粒度なら、撮り直し・文章の修正・登録先の変更を分けて依頼できます。

点検前の画面とURLも残しておくと、差し替え後に何が変わったかを確かめられます。全商品への一括変更は、一商品で修正と確認の手順が通ってから範囲を決めます。

実際に売る商品と、写真の色・形・付属品をそろえる

商品写真は、買うと届くものを確かめるための情報です。 色、形、素材の見え方だけでなく、写真の小物が商品に含まれるかも確認します。説明が正しくても写真が別のセットを示していれば、読む人は判断に迷います。

説明用の図です。商品と画面は架空の例で、実際の販売物や管理画面を示すものではありません。

青いマグ一個を売る例なら、主画像でマグ本体を確認できるようにし、取っ手や底面などは追加の写真で補います。撮影に使ったスプーンや敷物が別売りなら、その区別も商品ページで伝えます。

撮影担当へ依頼する際は、「明るく撮る」だけでなく、「青色の商品一個」「取っ手を含む全体」「付属品なし」と対象を指定します。見栄えの相談と、何を販売するかの確認を同じ依頼書へ残すためです。

主画像は、その商品を見分けられる写真にする

主画像には、販売する商品そのものが分かる写真を選びます。Merchant Centerの主画像も、具体的な販売対象を示すことが基本で、店のロゴや準備中の案内を代わりにするものではありません。[3]

点検するときは、写真を小さく表示して、商品全体と特徴を読み取れるかを見ます。青いマグなら、取っ手が切れていないか、口の形が見えるか、背景と輪郭が重なっていないかが確認項目になります。

白い背景にすれば必ずよいという判断ではありません。白い商品が背景に溶け込むなら、光や背景の調整が必要です。背景の選択より、販売対象を識別できるかを先に確認します。

また、単品と二個セットで同じ写真を使っている場合は、数量の伝わり方も見直します。写真だけで販売数を誤解しそうなら、商品ごとの写真と本文を照合し、登録担当と販売条件を確認します。

色や素材が違う商品には、対応する写真を用意する

色や素材が違う商品では、選んだ種類に合う写真を表示します。Merchant Centerも、各バリエーションの色や仕上げなどを表す画像を案内しています。[3] 青色を選んだのに白色の写真が残る状態は、altの書き換えだけでは直りません。

確認は、最初に開いた状態だけで終えず、色の選択肢を切り替えて行います。青から白へ変えたとき、主画像、追加画像、商品名の色表記がそろって変わるかを見ます。スマートフォンでも同じ操作を試します。

写真がない色について、別の色を加工しただけで実物どおりと判断しないことも必要です。色味や素材の反射は画面でも変わるため、撮影した元の商品と登録先を確かめ、確認できない写真は保留にします。

修正依頼には「青の画像へ変更」だけでなく、対象の商品番号と選択状態を書きます。ページの初期画像を変えるのか、色を選んだ後の画像を変えるのかが分かれば、担当者が確認すべき操作もそろいます。

追加画像で、別の角度・細部・使用場面を伝える

追加画像は、主画像だけでは分からないことを補うために選びます。角度を増やすこと自体を目的にせず、購入前に確かめたい点を一枚ずつ対応させると、撮り直しの依頼も具体的になります。

青いマグの例なら、横から見た取っ手、内側の色、底面の形を別々に示せます。机に置いた写真は使用時の雰囲気を伝えますが、寸法を正確に示す資料の代わりにはしません。

追加写真の例	写真で伝えること	文章で補うこと
横から見た写真	取っ手と本体の形	外寸や持ち方の注意
内側の写真	内面の色と形	容量、使用条件
机に置いた写真	使用時の見え方	周囲の小物は付属しないこと

Merchant Centerの追加画像には、主画像と異なる角度や使用場面などを示す用途があります。[4] 実際に送る画像では、追加画像側の要件も確認し、ページで使える写真をすべて無条件に送れるとは考えないようにします。

alt属性は、商品画像の内容とページの文脈を説明する

alt属性には、その画像がページで伝えている情報を、短い文章で書きます。 画像が見えない場合にも意味が通るかを考えると、商品名や検索語の繰り返しから離れて、写真の役割を説明しやすくなります。

説明用の図です。商品と画面は架空の例で、実際の販売物や管理画面を示すものではありません。

altは、HTMLの画像要素に付ける代替テキストです。CMSでは「代替テキスト」「画像の説明」などの欄が対応することがありますが、欄の名前だけで判断せず、保存した内容が実際のaltに反映されるかを制作担当に確認します。

すべての写真に同じ説明を入れるより、正面、底面、使用場面で伝える内容を分けます。一方、商品情報を持たない飾りの画像まで、無理に商品の説明に変える必要はありません。

商品名だけでなく、その写真で分かる特徴を書く

情報を伝える画像の代替テキストは、視覚的に示している意味を伝えるものです。W3Cの解説でも、画像を置いた目的や周囲の文章に応じて説明を考えることが示されています。[5]

青いマグの正面写真なら、例えば「青い陶器マグを正面から見た写真。右側に丸い取っ手がある」と書けます。これは説明用の例で、実際の写真が左向きなら向きを変え、取っ手が写っていないならその説明を削ります。

「人気」「高品質」「おすすめ」といった評価を足しても、写真の内容は詳しくなりません。材質や容量も、写真から分からないことを見た目だけで推測せず、確認済みの商品仕様として本文へ書きます。

判断に迷うときは、その写真を見せずに説明文だけを読み、写真のどの情報を伝えたかったかが分かるかを確認します。説明が長くなる場合は、画像が担う情報を絞るか、周囲の本文へ詳しい説明を分けます。

正面・背面・細部の写真で、説明を使い分ける

複数の写真があるときは、同じ商品を写していても、それぞれの役割に合う説明を付けます。商品名を十回繰り返すより、どの部分を確かめる写真なのかが分かる方が、画像を順に読む際にも役立ちます。

例えば正面写真には全体の形、底面写真には底の形、取っ手の拡大写真には接合部の様子を説明できます。写真にない傷や耐久性まで補わず、写っている範囲と確認済みの仕様を区別します。

同じ写真が一覧ページと詳細ページにある場合も、周囲に何が書かれているかを見ます。商品名がすぐ隣にあり、画像が同じリンクの飾りとして置かれている場合などは、重複を読み上げない設計が適切なことがあります。[6]

装飾画像には空のaltを使う考え方がありますが、商品の見た目という重要な情報まで一律に消すことは避けます。ページ内の役割を確認し、一覧の画像、詳細の写真、操作ボタンの画像をまとめて同じ設定へ変えないようにします。

キーワードの列挙をやめ、読み上げても意味が通る文にする

altを検索語の置き場所として使うと、画像の説明から離れやすくなります。Googleも、画像の文脈に合う有用な説明を求め、キーワードを詰め込む書き方を避けるよう案内しています。[2]

例えば「マグ 人気 陶器 おしゃれ 青 ギフト 通販」では、写真に何が写っているかが曖昧です。「青い陶器マグの取っ手を横から見た写真」とすれば、その画像の役割が伝わります。ギフト用の包装が写っていないなら、ギフトという用途は商品説明側で扱います。

検索数がある言葉でも、商品と関係のない語は追加しません。「AI検索対策」という語も、マグの写真を説明するaltには不要です。この記事の題材と、実際の商品画像に必要な説明を混同しないようにします。

一括生成したaltを使う場合は、写真を並べて読み直します。全画像に同じ色や角度が書かれていないか、見えない仕様を断定していないかを確認し、誤りがあるものは商品ごとに修正します。

写真の近くに、商品仕様と条件を文章で載せる

サイズ、素材、付属品、使えない条件は、商品ページの文章でも確認できるようにします。 画像内の小さな文字だけで伝えると、画面の大きさや画像の表示状態によって読み取りづらくなります。alt一つへ仕様の全文を押し込む必要もありません。

説明用の図です。商品と画面は架空の例で、実際の販売物や管理画面を示すものではありません。

商品担当が確認した仕様を本文へ置き、写真はその対象を示す役割にすると、どこを更新すればよいかも明確になります。画像だけを作り替えたために、本文の旧仕様が残ることも防ぎやすくなります。

点検では、写真の中にある文字を抜き出し、同じ意味の情報がページの文章にもあるかを見ます。一字一句の一致より、数量、対象の色、使用条件が食い違っていないことを確認します。

画像内にしかないサイズ・素材・注意点を本文にも載せる

商品の寸法図が一枚の画像になっているなら、必要な寸法を文章や表でも示します。GoogleのAI機能向けの案内も、重要な内容をテキストで利用できるようにすることを挙げています。[1]

青いマグの例では、口径、高さ、容量、使用上の注意が候補になります。ただし、図の数字が古い可能性があるなら、そのまま転記せず、現在の商品仕様書と照合します。文字として書き直すだけで情報が正しくなるわけではありません。

説明用に容量を「300ml」と決めた商品でも、満水時か推奨使用量かで意味が変わります。実際の登録では、数字と一緒にその条件を残します。写真の見た目から容量を推定して埋めることはしません。

文章を追加した後は、スマートフォンで画像を拡大しなくても必要な条件を読めるかを見ます。画像の認識能力を予想するより、購入者がページ上で確認できる情報を増やすことを優先します。

画像・キャプション・商品説明で、同じ対象を示す

写真の近くには、何を示す画像か分かる説明を置きます。Googleは、画像の主題を理解する際に周囲の文章も使うと説明しています。[2] 画像と関係のない文章が近くにあるなら、掲載位置から見直す余地があります。

例えば、青いマグの下に「白いマグの底面」と書かれていれば、altだけが正しくても不一致が残ります。画像、画面に見えるキャプション、本文の見出しを並べ、同じ商品と同じ部分を指すかを確認します。

キャプションは、画像の下などに見える補足文です。altと同じ文章を必ず繰り返すものではなく、写真で示す特徴や、見落としたくない条件を短く添える用途があります。

商品Q&Aを追加する場合も、写真で答えられることと仕様書が必要なことを分けます。問い合わせを説明へ変える手順は、AIに商品をすすめてもらうための商品情報の整え方で扱っています。リンク先の説明と合わせて、まず対象商品を確かめます。

ファイル名は簡潔にし、名前変更だけを目的にしない

画像のファイル名は、担当者が内容を見分けられる短い名前にすると管理しやすくなります。Googleも説明的な名前を案内していますが、画像の主題を知る小さな手掛かりとして扱っています。[2]

新しく登録するなら、例えば mug-blue-front.webp と mug-blue-base.webp のように、商品・色・角度をそろえる方法があります。これは運用例で、英語の名前やこの順序が検索の必須条件という意味ではありません。

すでに公開している画像では、名前を変えるとURLも変わることがあります。本文、商品データ、代表画像の参照先が旧URLのままなら、命名を整えるために不具合を増やしてしまいます。

そのため、効果が確認できない一括改名から始めず、差し替えが必要な画像や新規登録時に命名をそろえます。URLを変更する場合は、使っている場所を一覧にしてから切り替え、旧画像を先に消さないようにします。

Googleが商品画像のURLを取得できるか確かめる

商品ページで見えている画像について、ファイルの参照先とアクセス条件を確認します。 担当者のブラウザで見えることだけでは、Googleが同じ画像を取得できるかは決まりません。ログイン中だけ表示される画像や、期限付きのURLも点検対象です。

説明用の図です。商品と画面は架空の例で、実際の販売物や管理画面を示すものではありません。

ここからはHTMLや配信設定が関わるため、編集権限のある制作担当者と進めます。商品担当は、対象ページ、商品番号、問題の画像、発生する操作を渡せば、設定を調べる範囲を具体的にできます。

最初からサイト全体の制限を外すのではなく、商品画像の配信先を特定します。公開する商品画像と、社内用の素材や未公開データを同じ条件で扱わないことも、修正範囲を決めるうえで必要です。

商品画像はimgのsrcで参照されているか確認する

Googleの画像検索向けの説明では、標準的なHTMLの img 要素と、その画像URLを指定する src が基本です。CSSの背景画像はインデックスしないと案内されています。[2]

見た目では同じ写真でも、商品画像として置かれているのか、背景の装飾として置かれているのかは異なります。制作担当には「主画像のHTMLにimgとsrcがあり、そのURLが現在の商品画像を返すか」を確認してもらいます。

簡略化した例は、<img src="/images/mug-blue-front.webp" alt="青い陶器マグの正面"> です。これは説明用のコードで、実際のサイトでは画像サイズなど既存の設定を保ったまま調整します。

画像の位置や見た目を変える必要がない場合もあります。背景として実装した理由を確認し、商品情報として必要な写真が適切な画像要素で提供されるかを検討します。Googleの仕様を、他社AIの実装まで含む説明には広げません。

スマホ向けのsrcsetやpictureにも、srcの参照先を残す

画面の幅に応じて画像を出し分ける仕組みでも、基本の画像URLを確認します。Googleは srcset や picture を使う場合にも、img の src を用意する方法を示しています。[2]

商品担当が見るポイントは、パソコン用の写真だけ正しくて、スマートフォン用に古い写真が残っていないかです。青いマグへ差し替えた後も小さい画像だけ白色なら、端末別の参照先が更新されていない可能性があります。

確認時には、初めからスマートフォンの幅でページを開きます。パソコンで読み込んだ後に画面を狭めるだけでは、最初に配信された画像を見続ける場合があるため、別に開いた状態も比べます。

制作担当へ渡す記録には、端末幅、色の選択状態、見えた画像を添えます。複数の画像候補のうち、どれを表示したかが分かると、撮影素材の問題なのか出し分け設定の問題なのかを調べやすくなります。

画像用CDNとrobots.txtで、取得を妨げていないか見る

商品ページと画像を別の配信先で管理している場合は、画像側も確認します。CDNは画像などを配信する仕組みで、ページが開けても、画像の配信先でアクセスを制限していることがあります。

Merchant Centerの画像仕様は、GooglebotとGooglebot-imageが取得できる設定を求めています。[3] 制作担当には画像URLの応答、ログイン要求、robots.txt、配信側の制限を確認してもらいます。利用中の保護設定を一括で解除する依頼にはしません。

画像サイトマップを使う場合は、商品ページとは別ドメインの画像URLも記載できます。Googleの案内に沿って、画像の配信先のドメインもSearch Consoleで確認できる状態にします。[7] サイトマップへの記載自体が、取得や表示を保証するわけではありません。

また、毎回変わるURLや短時間で失効するURLを商品データへ入れないようにします。画像を一度開けた記録だけでなく、継続して取得できる参照先を使っているかを担当者間で確認します。

商品画像の画質・速度・ファイル形式を確認する

画質と表示速度は、実際の商品ページで両方を確認します。 画像を小さくすることだけを目標にすると、商品の細部が分からなくなります。反対に、元写真をそのまま大量に載せれば、必要な画像が見えるまでの負担が増える場合があります。

説明用の図です。商品と画面は架空の例で、実際の販売物や管理画面を示すものではありません。

最初に見るのは、商品の輪郭や素材感が分かるか、スマートフォンで必要な大きさまで確認できるかです。その後、配信する画像の大きさや圧縮方法を制作担当と調整します。

Webページの表示、Google検索、Merchant Centerでは、確認する仕様の範囲が異なります。「この形式ならAIに強い」と一つにまとめず、どの用途へ送る画像かを明確にしてから形式を決めます。

ぼけた画像と、必要以上に重い画像を見直す

画像の改善は、元の写真に十分な情報があるかを見るところから始めます。小さな画像を大きく表示しても、もともと写っていない細部までは確かめられません。圧縮率の変更だけで解決しない場合は、元画像や撮影素材へ戻ります。

青いマグなら、取っ手の輪郭、釉薬の模様、底面の状態など、説明に使う部分を見ます。細部を見せたい写真で模様がつぶれているなら、その画像だけ配信サイズや圧縮を見直す方法があります。

一方、ページには小さくしか表示しない画像へ、大きな撮影データを毎回送る必要があるかも検討します。端末に応じた画像の配信や圧縮は、表示を確かめながら調整し、全写真を同じ条件で強く圧縮しないようにします。

修正の前後には、同じ商品と同じ操作で見比べた記録を残します。速度の測定値だけで合格にせず、商品を選ぶための細部が読めることを、商品担当の確認項目にも入れます。

Web検索とMerchant Centerの対応形式を混同しない

画像形式は、用途ごとの公式一覧を確認します。2026年10月26日に確認したGoogle検索とMerchant Centerの案内では、対応形式の一覧が同じではありません。[2][3]

用途	公式資料に記載された形式
Google検索の画像	BMP、GIF、JPEG、PNG、WebP、SVG、AVIF
Merchant Centerのimage_link	JPEG、WebP、PNG、GIF、BMP、TIFF

例えば、サイトの高速化のためにAVIFを使っていても、そのURLを商品データへそのまま送れるとは判断しません。商品データには、その用途で対応する形式のURLを用意できるかを確認します。

拡張子だけを変えても、ファイルの中身は変わりません。.jpg という名前のPNGを作るような変更は避け、変換後の実ファイルとURLを確かめます。配信側が形式を自動で切り替える場合も、登録先へ何が返るかを制作担当に確認します。

形式をそろえる作業は、商品画像の内容を変える作業とは別です。同じ青いマグの写真が各用途に使われるかを、変換後にも見直します。

画像サイズの要件は、対象と適用日をセットで読む

Merchant Centerは、2027年1月31日から、すべての商品で500×500ピクセル以上とする新しい画像サイズ要件を告知しています。また、1500×1500ピクセル以上を推奨しています。適用日と推奨値を分けて読む必要があります。[3][4]

新要件の適用前については、画像が小さすぎる場合の公式ヘルプに、衣料品以外は100×100以上、衣料品は250×250以上と記載されています。ただし、テレビで表示するYouTubeショッピング広告は500×500以上です。[8] 一般の商品画像と、特定の掲載先の条件を分けて確認します。

今から素材を用意する場合は、推奨サイズを見据えた鮮明な元画像を保管し、商品データ用とページ表示用に必要な画像を用意する方法が取れます。ただし、小さい写真を単純に拡大しただけで品質が足りるとは判断しません。

作業表には「対象：Merchant Center」「条件：新しい最低サイズ」「適用：2027年1月31日」と分けて書きます。将来の変更を、今日の不承認理由として誤って伝えないためです。

商品ページとMerchant Centerで、同じ画像を説明する

商品ページで使う画像と、Merchant Centerへ登録した画像URLを並べて確認します。 ページだけを差し替えても、商品データが旧URLを参照していれば、両方の情報はそろいません。

説明用の図です。商品と画面は架空の例で、実際の販売物や管理画面を示すものではありません。

Merchant Centerは、Googleへ商品情報を登録・管理するサービスです。商品データを外部のECシステムから送っている場合には、管理画面で直した内容が次の同期で戻らないか、元の登録先も確認します。

青いマグの例なら、商品番号を軸に、主画像、追加画像、ページ上の代表画像を一覧にします。すべて同一ファイルである必要はありませんが、同じ販売対象を説明していることを確かめます。価格や在庫も食い違う場合は、画像以外の担当へ別の修正項目として渡します。

image_linkとadditional_image_linkを役割で分ける

主画像のURLは image_link、追加画像は additional_image_link で送ります。[3][4] 名前だけを覚えるより、どの写真を商品の入口にし、どの写真で不足する情報を補うかを決めてから登録すると整理しやすくなります。

架空のマグなら、全体が分かる正面写真を主画像、取っ手や底面の写真を追加画像とする例が考えられます。商品ページで並べた順番をそのまま使う場合でも、先頭がキャンペーン用のバナーになっていないかを確認します。

登録後は、文字列としてURLが入ったことだけで終えず、その参照先が意図した写真を返すかを見ます。色違いの商品番号へ同じ画像をコピーした箇所があるなら、個別に開いて照合します。

外部システムが画像URLを自動出力する場合は、修正すべき元の欄を担当者に確認します。Merchant Centerだけを手で直しても、次回のデータ送信で戻る運用なら、元データの修正と送信後の確認を一組にします。

商品写真の販促文字と、AI生成画像のメタデータを確認する

Merchant Centerの主画像には、販促用の文字や後から重ねたロゴなどの制限があります。[3] 商品ページのキャンペーン画像を主画像に流用する場合は、画像に価格、割引、購入を促す文などが重なっていないかを確認します。

ここでいう制限と、商品そのもののパッケージに印刷された文字は区別します。文字がある画像を機械的に全部削除するのではなく、何が商品本来の表示で、何を後から加えたかを確かめます。

生成AIで作った画像をMerchant Centerへ送る場合は、AI生成を示すメタデータを保持する要件もあります。公式資料ではIPTCのDigitalSourceTypeなどが挙げられています。[3][4] 画像変換や圧縮の後に、必要な情報が失われていないかを制作担当に確認します。

なお、この記事の図は手順を説明するためのイラストです。そのまま実在商品の写真として登録するものではありません。商品の形や色を生成画像で補う場合も、販売する実物と一致するかは別に確認が必要です。

Product.imageやog:imageが、古い商品写真を指していないか見る

本文の写真以外にも、ページには画像の参照先が残ることがあります。商品を表す構造化データの Product.image や、ページの代表画像を示す og:image が、旧画像や店のロゴを参照していないかを制作担当と確認します。[2][3]

例えば、画面には青いマグが見えているのに、構造化データだけ白いマグのURLなら不一致です。見た目の差し替えと同時に、ページの裏側で参照する画像も照合する必要があります。

ただし、代表画像を指定したことは、Googleが必ずその画像を使う保証ではありません。Googleは複数の情報を基に画像を選ぶと説明しているため、指定の正しさと実際の表示を分けて確かめます。[2]

構造化データ全体の書き方や検査は、商品ページの構造化データの記述例と確認方法で扱っています。ここでは画像URLに対象を絞り、価格や在庫の設定を不必要に書き換えないようにします。

商品画像の修正後は、取得・説明・成果を分けて確認する

修正の完了は、対象商品を開き直し、画像と文章と登録URLが一致したことを確かめて判断します。 AIの回答に出るまでを、画像差し替え作業の完了条件にすると、何が直ったかを共有しにくくなります。

説明用の図です。商品と画面は架空の例で、実際の販売物や管理画面を示すものではありません。

確認は、パソコンと、初めからスマートフォン幅で開いたページの両方で行います。主画像だけでなく、追加写真、色の切り替え、本文の注意書きまで見ます。確認した商品番号と日時を残せば、別の担当者が同じ状態を確かめられます。

未確認の項目があれば、その理由と担当を残します。「画像確認済み」の一言で、配信設定や商品データまで確認したことにしないようにします。何が終わり、何が残るかが分かる記録が必要です。

実画像・alt・周辺本文・登録URLを一商品ずつ照合する

確認表は、一枚の写真を一行にすると使いやすくなります。対象ページと商品番号を表の上に書き、次のように画像の役割ごとに照合します。以下は青いマグを使った記入例です。

対象	修正前の問題	確認する組み合わせ
主画像	白色の写真が残る	青色の実画像・正面のalt・主画像URL
底面写真	altが正面と同じ	底面の実画像・底面のalt・近くの説明
使用場面	小物の扱いが不明	写真・付属品の説明・追加画像URL

実際の表には、修正後のURL、確認日、確認者も足します。URLはページ全体のものだけでなく、問題の画像ファイルへ戻れるものを残します。写真の取り違えを後から調べるためです。

確認者が制作担当と別なら、依頼文を見ずに商品ページを読んでも販売対象が分かるかを確かめます。作業の事情を知っている人だけが理解できる説明なら、商品名や付属品の表現をもう一度直します。

取得エラーと商品画像の不承認を、別々に直す

画像が期待どおり表示されないときは、まず起きている問題を分けます。URLが開けない問題と、画像内容が登録先の要件に合わない問題では、調べる相手も修正方法も異なります。

画像URLがエラーになるなら、参照先、配信設定、期限、アクセス制限を制作担当と確認します。別の商品が返るなら、商品番号と画像の結び付けを商品登録担当が確認します。どちらも「AIに認識されない」という一つの原因へまとめないようにします。

Merchant Centerで画像に関する問題が示された場合は、その通知の対象商品と理由を読みます。写真が取得できるから要件を満たすとは限らず、反対に、画像内容を直してもURLが開けなければ確認は進みません。[3]

修正後は、同じ対象で再確認し、通知や表示状態がどう変わったかを残します。反映を待っている状態と、修正が足りない状態を区別できないときは、直した箇所と時刻を担当者へ渡して調査を続けます。

変更日と対象商品を残し、AI引用や購入への効果は別に測る

画像を直したら、対象商品、変更日、修正内容を記録し、その後の表示や訪問を別に追います。まず「青い商品に青い写真が出る」「説明と仕様が一致する」という確認結果を残すと、検索成果が変わらない期間でも作業内容を説明できます。

AI回答を観測する場合は、質問文、サービス、言語、日時、表示された商品やリンクを保存します。写真が表示されたかも独立した項目にします。一度の回答を、その商品が常に紹介される証拠として扱わないことが大切です。

訪問や購入を比較する際には、価格変更、在庫切れ、広告、季節の影響など、同時期の変更も記録します。画像の修正と成果の増減が重なっただけで、原因を確定しないようにします。

商品ページからAI経由の購入までの全体像は、ECサイトのLLMO対策で確認できます。まず一商品の照合表を完成させ、同じ問題がある商品へ順に広げることが、次の具体的な作業になります。