Image SEO: Google で画像を見つけてもらいやすくする 4 つの修正
参考になる結果ではあるが、公式ではない
ある SEO 実践者は、Image SEO だけで 9,200 人を超える訪問者を得たと報告しています。行ったことは、ファイル名の変更、alt テキストへのキーワード追加、画像圧縮、そして ImageObject スキーマの追加という 4 点でした。
これは画像検索を見直すよいきっかけです。ただし、この 4 つの編集をすれば別のサイトでも 9,200 人の訪問者が生まれる、という証拠ではありません。
画像からの流入は、利用者が何を検索するか、画像がその検索への強い答えになっているか、Google が画像をクロールできるか、そしてリンク先ページが画像に十分な文脈を与えているかで決まります。商品写真、手順図、独自チャート、旅行写真、一般的なストック画像は、同じ条件で競争しているわけではありません。
それでも、この 4 つの修正の方向性は正しいものです。それぞれが解決する問題は異なります。
| 修正 | 改善できること | 保証できないこと |
|---|---|---|
| 説明的なファイル名 | 小さいながら明確な関連性シグナル、アセット管理のしやすさ | 競争の激しいクエリでの順位 |
| 正確な alt テキスト | アクセシビリティと、意味のある画像のテキスト説明 | 画像と無関係なキーワードでの表示 |
| 適切な圧縮とサイズ | 読み込み速度、利用者体験、転送量 | 過度な圧縮後の画質 |
| ImageObject またはページレベルの画像マークアップ | 画像とページ主体の関係をより明確にすること | リッチリザルトや直接的な順位上昇 |
目的は、すべての画像項目にキーワードを詰め込むことではありません。Google が見つけ、理解し、検索者の質問に答えるページへ結び付けられる画像を公開することです。
最初の問題は、たいていメタデータではなく発見可能性
ファイル名を変えたり JSON-LD を追加したりする前に、Google がその画像を実際に見つけられるか確認してください。
Google の画像ドキュメントには、リニューアル時に見落とされがちな重要点があります。実際の HTML の <img> 要素または <picture> 要素を使うことです。Google はそれらの要素の src から画像を検出できます。CSS の背景画像は、Google が同じ方法で CSS 画像をインデックスしないため、画像検索でははるかに使いにくいものです。
マーケティングサイトではよくある失敗です。美しいヒーロー画像を CSS クラスの background-image として追加し、その後チームが別の場所に完璧な alt テキストを入れても、画像が表示されない理由が分からなくなります。CSS 背景画像には alt テキストがなく、その画像はクロール可能なコンテンツモデルの一部にすらなっていない場合があります。
次の短い監査から始めてください。
| 確認項目 | 良い状態 | 危険信号 |
|---|---|---|
| 画像要素 | 意味のある画像が | 画像が CSS 背景としてしか存在しない |
| ソース URL | 画像 URL が | CDN ルール、robots ルール、認証がファイルを遮断している |
| ページへのアクセス | ページが公開され、インデックス可能である | ログイン後、または Google が完了できない操作の後にだけ画像が出る |
| 遅延読み込み | JavaScript のプレースホルダーだけでなく、クロール可能なソース URL がある | 実 URL がスクロールまたはクライアント側イベント後にしか現れない |
| ページの文脈 | 近くのコピーが画像の内容と意味を説明している | トピック文脈のない、ラベルなしアセットのギャラリー |
CDN を使う場合は、そのホストに到達でき、監視されていることを確認してください。画像サイトマップは、通常のページクロールでは見つけにくい画像、JavaScript で表示される画像も含め、Google の発見を助けることがあります。これは発見の補助であり、順位を上げるレバーではありません。
発見可能な画像には、クロール可能な HTML、公開されたソース URL、インデックス可能なページ、関連する周辺文脈が必要です。
修正 1: CMS の都合ではなく、写っているものに合わせてファイル名を付ける
IMG_1048.jpg、final-v7.png、hero-new.webp は、誰にとっても扱いにくい名前です。編集者にはアセットの内容が分からず、小さいながら説明的な文脈も失われます。
画像が実際に何を示すのかが分かる、短く人が読める名前を使ってください。ハイフンで区切った小文字の単語は管理しやすく、ライブラリ全体で一貫性を保てます。
| 弱いファイル名 | より良いファイル名 | 良い理由 |
|---|---|---|
|
|
| 写っている商品と識別できる詳細を示す |
|
|
| 指標、切り口、期間を示す |
|
|
| 図が説明するトピックと一致する |
ファイル名を検索クエリの寄せ集めにしてはいけません。best-cheap-water-bottle-water-bottles-buy-online.jpg は、人にもシステムにも画像の理解を助けません。ただ雑に見えるだけです。
もう一つ実務上の制約があります。既存画像の名前変更は、多くの CMS で URL の変更を意味します。その画像にすでに可視性や被リンクがあるなら、スタックが対応している場合は旧ファイル URL をリダイレクトし、参照を更新し、わずかなファイル名改善のためにページを壊さないでください。まず新規アセットに命名ルールを適用し、通常のコンテンツ保守で価値の高い既存画像を修正します。
修正 2: alt テキストはキーワード欄ではなく説明として書く
alt テキストには 2 つの役割があります。スクリーンリーダー利用者に役立つ説明を与えること、そして画像を描画できない場合にテキスト文脈を提供することです。画像がページの中心にある場合、正確な説明は検索システムが内容を理解する助けにもなります。
簡単に陥る間違いは、ページのターゲットキーワードを繰り返すことです。それではアクセシビリティが悪くなり、編集品質も下がります。
| 画像の役割 | 弱い alt テキスト | より良い alt テキスト |
|---|---|---|
| 商品の詳細 |
|
|
| データチャート |
|
|
| 手順スクリーンショット |
|
|
| 装飾的な区切り |
| 空の alt テキスト: |
良い alt テキストは、すべてのピクセルを説明する必要はありません。近くのコピーに対して画像が追加する情報を述べるべきです。周囲の段落がまったく同じ内容をすでに伝えているなら、alt テキストは短くしてください。画像がチャート、図、手順を含む場合は、すべてのラベルを書き起こすのではなく、要点を説明します。
「alt テキストにキーワードを追加する」という表現が安全なのは、そのキーワードが正確な説明の自然な一部である場合だけです。キーワードは画像をよく説明した結果であり、作業指示ではありません。
修正 3: 画質を悪くせずにバイト数を減らす
画像圧縮は、特にモバイル回線で重い画像がページを遅くするため重要です。ただし、無関係な画像を有用な検索結果に変えるものではありません。それでも、速く読み込まれるページなら、利用者は見つけたコンテンツを見て、使い、滞在しやすくなります。
必要な範囲で最小の寸法を使ってください。幅 700 ピクセルのコンテンツ枠のために幅 4,000 ピクセルの写真をアップロードするのは帯域を無駄にします。プラットフォームが対応しているなら srcset または <picture> でレスポンシブなバリアントを配信し、見た目の品質を保てる場合は WebP や AVIF などの新しい形式を使います。
ここには実際のトレードオフがあります。ぼやけた商品クローズアップや読めないチャートは、軽くなってもページを傷つけます。スマートフォンとデスクトップの両方で、実際に表示されるサイズで確認してください。小さい文字を含む図では、過度に圧縮した写真形式より SVG や丁寧に書き出した PNG の方がよい場合があります。
公開前には次を確認します。
- 意図したコンテナ幅で画像を表示する。
- 200% ズームだけでなく、通常の閲覧距離で比較する。
- ラベル、数値、線がまだ読めることを確かめる。
- パフォーマンスツールでページをテストし、最大の画像リクエストを特定する。
- 最も大きく、最も目立つ画像から修正する。
この順序なら、1 枚の大きすぎるヒーロー画像が大半の問題を起こしているのに、小さなサムネイルを 12 枚最適化してしまう、よくある Image SEO の失敗を防げます。
修正 4: ImageObject マークアップは魔法ではなく関連付けのために使う
ImageObject スキーマは、画像とページの関係をより明示できます。記事ページでは、Google 自身のドキュメントが、primaryImageOfPage で主要画像を示すか、BlogPosting のようなページの主要エンティティに画像を関連付ける方法を示しています。
これは役立つ構造化文脈です。Google 画像がそのアセットを順位付けすること、特別な表示をすること、決まった量のトラフィックを送ることを約束するものではありません。
ブログ記事では、すべてのインライン図に孤立した ImageObject ブロックを追加するより、既存の BlogPosting マークアップ内の image プロパティを使う方がすっきりすることが多いです。最小限の例を示します。
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "How to audit images for Google Images",
"mainEntityOfPage": "https://example.com/blog/image-seo-audit",
"image": {
"@type": "ImageObject",
"contentUrl": "https://example.com/images/image-seo-audit-checklist.webp",
"url": "https://example.com/images/image-seo-audit-checklist.webp",
"caption": "A five-step image SEO audit checklist",
"width": 1600,
"height": 900
}
}
解決する URL を使い、実際のアセットを説明し、利用者がページ上で見られる内容と一致させます。事実でない caption、creator、license、dimensions を主張してはいけません。ライセンスが事業上重要なら、Google は構造化データまたは埋め込み IPTC メタデータによる画像ライセンスメタデータもサポートしています。これは通常の Image SEO とは別の用途です。
マークアップ追加後は、構造化データテストで検証し、レンダリングされたページソースを調べてください。ステージング環境にだけあるスキーマや、プラグインで上書きされるスキーマは、本番ページでは何の役にも立ちません。
4 項目の投稿が見落としていること
世界一強い画像フィールドでも、弱いランディングページは救えません。Google は画像の周りにあるページも理解する必要があります。
見つけてもらいたい各画像について、次を確認してください。
- 画像はページの主題に答えたり、明確にしたりしているか。
- 画像は関連するテキスト、説明的な見出し、役立つキャプションの近くにあるか。
- 独自の画像か。それとも何百ものページに出てくる一般的なストックアセットか。
- Google 画像からクリックした人が、ページ内を探し回らずに有用な答えを得られるか。
- 画像はモバイルで機能し、JavaScript が遅いまたは利用できない場合にも表示されるか。
だからこそ、独自図解、注釈付き商品写真、ビフォーアフター例、データチャートは成果を出しやすいのです。検索者が実際に欲しい情報を持っているからです。装飾的なグラデーションは、スキーマを付けても突然画像検索の機会にはなりません。
証拠を作る 30 日間の Image SEO テスト
金曜の午後にメディアライブラリのすべてのファイル名を変更しないでください。画像意図がありそうなページで、管理されたテストを行います。
第 1 週: 対象を選ぶ
役立つ独自ビジュアルがある 10 から 20 ページを選びます。EC カテゴリまたは商品ページ、チュートリアル、視覚的な解説、地域ページ、比較ページ、事例ページなどです。現在の画像 URL、ページ URL、利用可能な画像インプレッションとクリック、ページトラフィック、既存の画像メタデータを記録します。
第 2 週: 基本を修正する
新規または安全に変更できるアセットでは不透明な名前を置き換えます。正確な alt テキストを追加します。重要な画像がクロール可能な HTML を使い、公開されたソース URL を持ち、不必要に大きくないことを確認します。コンテンツを本当に説明している場合だけ、ページレベルの画像スキーマを追加または修正します。
第 3 週: ランディングページを改善する
画像の近くに直接的な説明、明確な見出し、読者の助けになる場合はキャプションを追加します。チャートなら、その傾向が何を意味するかを説明します。商品写真なら、写真が証明する素材、サイズ、用途、機能を説明します。
第 4 週: 拡大前に測定する
可能なら Search Console の検索タイプレポートに加え、ページ分析と Google 画像でのスポットチェックを使います。インプレッション、クリック、画像クエリのテーマ、ランディングページのエンゲージメント、コンバージョン品質の変化を探します。変更ログを残します。画像のクリックが増えても訪問者がすぐ離脱するなら、ランディングページが視覚的な約束に合っていない可能性があります。
目的は、派手なスクリーンショットではなく再現可能なパターンです。一つでも役立つ結果があれば、Image SEO により大きなコンテンツとアセットのワークフローを投資する価値があるか判断できます。
各修正には異なる役割があります。メディアライブラリ全体へ拡大する前に、組み合わせを測定してください。
AI には棚卸しを任せ、作り話はさせない
大規模サイトの Image SEO は、証拠がメディアライブラリ、HTML、CMS 項目、パフォーマンスレポート、サイトマップ、Search Console に散らばるため、面倒になります。AI は作業を集める助けになります。alt テキストがない画像を一覧化し、一般的すぎるファイル名を見つけ、レンダリング後の画像寸法とソース寸法を比較し、ページを視覚的意図でグループ化し、人による確認のための監査キューを下書きできます。
ただし、見えていない画像の説明を発明したり、同じターゲットフレーズを何百もの alt 属性に追加したりしてはいけません。そうすると監査が、大規模なキーワード詰め込みに変わります。
Auspia の SEO ツール は、チームがウェブサイト全体のレビューから始め、発見事項を焦点の絞られた Image SEO バックログへ変える助けになります。役立つ出力は「すべての画像を最適化した」ではありません。クロールのブロック、文脈不足、過大な配信、弱い説明、壊れたページ関連付けといった、実際の問題があるアセットの優先順位付きリストです。
Image SEO チェックリスト
| 画像を最適化済みと呼ぶ前に | 確認すること |
|---|---|
| 画像は発見可能 | クロール可能な HTML 内にあり、ファイル URL が公開されている |
| ファイル名は有用 | 用語を詰め込まず、画像を説明している |
| alt テキストは正直 | 意味のある画像を説明し、装飾画像には空の alt テキストを使う |
| ページに文脈がある | 関連コピー、見出し、キャプションが画像の役割を説明している |
| 配信が効率的 | 正しい表示サイズ、レスポンシブなソース、許容できる画質 |
| マークアップが正確 | 画像プロパティが、表示され到達可能なアセットを説明している |
| 結果を測定している | Search Console とページ指標を変更前後で比較している |
FAQ
画像ファイル名を変えると Google 画像の順位は上がるか
説明的なファイル名は、妥当な補助シグナルであり、メディアライブラリの衛生状態も改善します。それだけで画像が順位付けされる理由になることはめったにありません。価値の低いアセットを改名するためだけに、確立済みの画像 URL を壊すことは避けてください。
すべての画像の alt テキストにキーワードを入れるべきか
いいえ。alt テキストは意味のある画像を正確に説明すべきです。ターゲットフレーズは、その説明に自然に含まれる場合だけ使います。装飾画像には通常 alt="" を使い、スクリーンリーダーがスキップできるようにします。
ImageObject スキーマは画像を順位付けするか
いいえ。ImageObject と関連するページマークアップは、画像とページの関係を明確にする助けになります。Google 画像での掲載、リッチリザルト表示、トラフィックを保証するものではありません。
画像サイトマップは必要か
常に必要ではありません。Google は通常の HTML クロールを通じて多くの画像を発見できます。画像サイトマップは、一部の JavaScript 実装を含め画像を見つけにくい場合、またはより完全な発見マップが必要な場合に役立ちます。
最初に最適化すべき画像はどれか
すでに需要があり、明確な視覚検索の用途があるページの画像から始めてください。独自の商品画像、図解、チャート、チュートリアル、ビフォーアフター例は、一般的な装飾よりよい候補になりやすいものです。
まとめ
この実践者の 4 項目の教訓は、一つの修正を加えれば実行する価値があります。Image SEO は 4 つの入力欄を埋める作業ではありません。ファイル名、alt テキスト、圧縮、ImageObject マークアップは、クロール可能で有用かつ文脈豊かな画像を、訪問したいと思われるページ上で支える場合に役立ちます。
強いビジュアルアセットの小さな集合から始め、明らかな技術的・編集的な欠点を修正し、ランディングページの結果を測定してください。それにより、よりよい画像ライブラリ、よりよいページ体験、Google 画像へさらに投資するための説明可能な根拠が得られます。
著者: Julian Mercer、Auspia の 14 年のテクニカル SEO 実践者。Julian はクロール可能性、スキーマ、レンダリング、サイトアーキテクチャ、AI が読めるコンテンツの技術的基盤について執筆しています。
