Google検索に意図しない画像が出るとき｜サムネイルの決まり方と、差し替え後に反映されるまで
Google検索に意図しない画像が出るとき｜サムネイルの決まり方と、差し替え後に反映されるまで
自社名で検索したら、スマホの検索結果に何年も前の画像が出ている。差し替えたはずなのに変わらない。この相談は定期的にいただきます。
先に結論を書きます。Google検索のサムネイルは「og:imageで指定するもの」ではありません。 SNSのシェアカードとは別の仕組みで、Googleはページの中身から自動で選びます。だから、やるべきことは「タグを書き換える」ことではなく、出したい画像をGoogleが選べる状態にすることです。
具体的には次の4つを満たしてから、再クロールを待ちます。
- 出したい画像を、ページ本文の中に十分な解像度で置く
- 構造化データの
imageに、同じ画像を入れる - その画像がクローラーから取得できる場所にある（robots.txtで遮断されておらず、叩けば200が返る）
max-image-preview:largeを許可している
この記事では、この4つの根拠と確認手順、そして「差し替えたのに変わらない」ときに実際に何が起きているかを、自社サイトと制作案件の実測値とあわせて書きます。
—
1. まず区別する。「SNSのカード」「検索のサムネイル」「検索のアイコン」は別物
相談を受けるとき、この3つが混ざっていることがとても多いです。触る場所も、反映の速さも違います。
| 出る場所 | 何を見て決まるか | 反映のされ方 |
|---|---|---|
| LINE・X・Facebookなどのシェアカード | og:image（明示指定） |
各SNSのデバッガーで再取得すれば即時 |
| Google検索結果のサムネイル | ページ内の画像・構造化データの image をGoogleが選択 |
再クロール待ち。数日〜2週間程度 |
| 検索結果のタイトル横の小さなアイコン | ファビコン（favicon.ico など） |
再クロール待ち。サムネイルとは別枠 |
og:image を直せばGoogle検索のサムネイルも変わる、と思って作業すると、いつまでも結果が出ません。Googleが og:image を絶対に見ないとまでは言い切れませんが、指定したとおりに出る保証はないので、当てにしない設計にするのが実務的です。
逆に言えば、SNSカードだけを急いで直したいなら og:image の差し替えとデバッガー再取得で当日中に終わります。ここは切り分けておくと、対応の期待値がぶれません。
—
2. 「画像は200で表示されているのに、検索には出ない」が起こる仕組み
一番わかりにくいのがこの状態です。ブラウザで画像URLを開けば普通に表示される。なのにGoogleは使ってくれない。
原因のほとんどは、画像を置いているホストがクローラーに開放されていないことです。人間のブラウザとクローラーでは、見えているものが違います。
とくに起きやすいのが、WordPressを裏方に回した構成（表示側と管理側でドメインを分ける構成）です。管理側のサブドメインは、検索結果に管理側と表示側が二重に載るのを防ぐため、意図的に全面遮断するのが定石になります。ここで見落としやすいのが、記事の画像参照が遮断した側のドメインを指したまま残るという点です。画像そのものは200で配信されているので、ブラウザでは何の問題も見えません。しかしGoogleからは取得できない。自社ブログの移行時に実測したところ、記事168本すべてで、検索サムネイル・構造化データの画像が効かない状態になっていました。
したがって、こうした構成変更では遮断するドメインを決めた時点で「そのドメインに残る参照物」を洗い出すのが正しい進め方です。洗い出す対象は、og:image だけではなく、本文中の <img>、構造化データの image、一覧ページやカテゴリページのサムネイルまで。ここを片方だけ直すと、直したつもりで半分残ります。
対処の方針は2つあります。
| 方針 | 内容 | 向く場面 |
|---|---|---|
| 遮断を緩める | 管理側ドメインのrobots.txtで画像だけ許可する | 構成が今後も変わらない場合 |
| 自己ホスト化する | 公開ドメイン側に画像を書き出して、そちらを参照する | 管理側を将来入れ替える可能性がある場合 |
自社では後者を選びました。理由は、管理側は将来の置き換え候補であり、画像をそのドメインに依存させると、入れ替えのタイミングで全記事の画像参照が一斉に壊れるからです。公開ドメインから配信するほうが、構成の変化に強くなります。
実装で決めた数値
- 検索・シェア用は 1200×630 / JPEG 品質82 に縮小圧縮して公開ドメイン配下へ書き出し
- 生成は差分方式（取得元が同じで実ファイルがあればスキップ）。何が起きてもビルドは止めない
- アイキャッチが無い記事は、既定の画像へ退避させる（画像なしにしない）
- 増えた容量は167本で +11.25MB（平均69KB）
容量を心配されることがありますが、圧縮して書き出す前提なら、記事100本規模で十数MBです。判断を止めるほどの数字にはなりません。
—
3. 本文の画像とサムネイル用の画像は、同じファイルを使い回さない
洗い出しの対象には、本文中の <img> も必ず入ります。そしてこのとき「もう1200×630の画像を作ってあるのだから、本文にもそれを使えばいい」と考えると、記事の見た目が変わってしまいます。
1200×630はワイドに切り抜いた比率です。本文の画像を同じ比率に切り抜けば、もともと写っていたものが切れる。だから本文用は別に生成するのが正解です。
- 本文用は 幅1600px・元の縦横比を維持（元より大きくは引き伸ばさない）・品質90
- 縦横比が0.01以上変わったら例外を出して書き込まない安全弁を入れる
この安全弁は、意図しない切り抜きが静かに本番へ流れるのを防ぐためのものです。画像の差し替えは、壊れても目に見えるエラーが出ません。だから機械的に検知できる条件を先に決めておきます。
副産物として、ページの軽量化がかなり効きました。
| 元画像 | 書き出し後 | |
|---|---|---|
| 1枚あたり平均 | 931KB | 231KB（−75.1%） |
本文の1枚目は多くの場合ファーストビューに入るので、ここは表示速度の評価に直結する部分です。画像を検索向けに整えると、速度改善もついてくると考えて差し支えありません。
差し替え後の検証は「ビルドが終わってから」
静的に書き出す構成では、ファイルを直しただけでは本番は変わりません。ビルドが完了して、配信の前段にあるキャッシュが切れて、はじめて実際のHTMLが変わります。ビルド中に確認すると「反映されていない」と誤診します。確認の前に、ビルドの完了時刻を見るのを手順に入れておくと、無駄な調査をしなくて済みます。
—
4. ECカート・CMSでは「管理画面のどこかに入れた古い画像」が使われることがある
化粧品を扱うECの案件で、検索結果に出るサムネイルが商品ではなく人物写真になっていました。テーマのファイルをいくら探しても、その画像を指定している箇所がありません。
出どころは、カート管理画面のブランド設定に2年近く前から入っていた画像でした。ページ個別の画像が無いときのフォールバックとして、システムが自動で使っていたのです。
この構造は珍しくありません。WordPressでもECカートでも、「サイト全体の代表画像」を設定する場所があり、それがページ単位の指定より後ろで効いています。探す順番はテーマのコードより先に、管理画面の全体設定です。
実装は、テンプレート側でページの種類ごとに出し分けました。
- トップなど、ページ固有の画像を持たないページ → 新しい代表画像を出す
- 商品ページ・記事ページ → 従来どおり各ページの画像を維持する
全ページを一律で新しい画像に置き換えないのが重要です。商品ページのサムネイルが全部同じ会社ロゴになったら、検索結果での見え方は明らかに悪くなります。
もう一点、テンプレート関数が返す画像URLが //cdn.example.com/... のようにスキーム（https:）を欠く場合があります。この形式は取得できないクローラーがあるため、https: が含まれているか確認して、無ければ付ける処理を入れておきます。
—
5. 差し替えの実務手順と、確認コマンド
ここまでを手順にまとめます。
手順1. 今どの画像が使われているか確定させる
見た目ではなく、クローラーが受け取るHTMLを見ます。
curl -s https://example.com/page/ | grep -o '<meta property="og:image[^>]*>'
curl -s https://example.com/page/ | grep -o '"image":[^,]*'手順2. その画像URLが200を返すか確認する
curl -o /dev/null -w "%{http_code}\n" https://example.com/img/xxx.jpg手順3. 画像を置いているホストがクローラーに開放されているか確認する
curl -s https://画像のホスト/robots.txtここで Disallow: / が出たら、200でも検索には使われません。第2章の話です。
手順4. プレビューサイズの許可を確認する
<meta name="robots" content="max-image-preview:large"> が出ているか。大きなサムネイルを出したいなら必要です。
手順5. 出したい画像を本文と構造化データの両方に入れる
Googleが選ぶのはページの中身からです。「本文にはロゴしか無いのに、構造化データだけ商品写真」という状態では、期待どおりに出ません。本文と構造化データで同じ画像を指すのが素直な設計です。
手順6. 直したらインデックス登録をリクエストし直す
ここは順番に注意が要ります。インデックス登録をリクエストした後にコードを直すと、Google側には修正前のスナップショットが固定されるからです。実案件でも、構造化データを直したのにSearch Consoleに古い内容のエラーが残り続けたことがあり、調べるとリクエストが修正の40分前でした。コードは正しいのに、管理画面だけが古い状態です。
構造化データや画像を直したら、リクエスト済みであっても打ち直す。 これで解消します。
反映までの期間の考え方
再クロールのタイミングはこちらでは決められません。実案件では数日〜2週間程度を見込んでご案内しています。「明日には変わります」とは言えない領域なので、キャンペーンや新商品の告知に合わせるなら、逆算して2週間前には差し替えを終えるのが安全です。
なお、SNSでシェアしたときのカードは og:image を直せば当日から新しくなります。急ぐ場面ではこちらを先に押さえておくと、実害を減らせます。
—
6. 検索結果のアイコン（ファビコン）は別枠。未設定のまま気づかないことが多い
サムネイルとは別に、検索結果のタイトル横に出る小さなアイコンがあります。これはファビコンで、サムネイルとは別の話です。
これは設定漏れが最も起きやすい項目です。多店舗のサイト群を点検した際には、27サイトすべてでファビコンが1つも設定されていないという結果でした。未設定でもエラーは出ず、サイトの見た目にも困らないので、点検しない限り気づきません。サイトを増やすときは、公開チェック項目に入れておくのが確実です。
WordPressの場合、サイトアイコン未設定だと /favicon.ico がWordPress標準のロゴ画像へ転送されることがあります。つまり自社と無関係のアイコンが検索結果に出ている状態です。対処はサイトアイコンの設定か、実ファイルの設置です。実ファイルがあればそちらが優先されるので、テーマのPHPを触らずに済みます。
確認は1行です。
curl -o /dev/null -w "%{http_code} %{redirect_url}\n" https://example.com/favicon.icoなお、ブラウザのファビコンキャッシュは非常にしつこく、設定後もご自身の画面では古いアイコンが残ります。これは異常ではありません。検索結果への反映は、こちらも再クロール待ちです。
—
まとめ
- Google検索のサムネイルは
og:imageの指定で決まるものではない。Googleがページの中身から選ぶ - やることは4つ。本文に置く／構造化データの
imageに入れる／クローラーが取得できる場所に置く／max-image-preview:largeを許可する - 「画像は200なのに出ない」は、画像ホストがrobots.txtで遮断されているケースが多い。表示側と管理側でドメインを分ける構成では特に起きやすい
- 検索用（1200×630）と本文用（元の比率を維持）は別に書き出す。使い回すと構図が切れる
- 意図しない画像の出どころは、テーマのコードより先に管理画面の全体設定を疑う
- 直したらインデックス登録をリクエストし直す。反映は再クロール待ちで、数日〜2週間を見込む
検索結果の見え方は、順位と違って自分で直せる部分が多い領域です。ただし「直したのに変わらない」の多くは、直す場所を間違えているか、Googleがまだ見に来ていないかのどちらかです。どちらなのかを切り分ける手順を持っておくと、無駄な作り直しをせずに済みます。