blog
開発メモ検索結果にファビコンが出ない原因は、www有無の二重ホストだった
他社から相談を受けた案件で、「PCのブラウザタブにはファビコンが表示されるのに、Google・Yahooの検索結果では表示されない」という問い合わせがありました。検索結果は既定の地球アイコンのままです。先方の第一声は「こちらの設定は問題なさそうだが、Google側のトラブルではないか」というものでした。
先に結論から
原因はファビコンのファイルではありませんでした。同じサイトが「www あり」と「www なし」の2つのホスト名で開ける状態になっていたのが正体です。
Googleは検索結果に出すファビコンを、ホスト名ごとに1つだけ持ちます。入口が2つに割れていると、どちらに紐づければよいかが決まらず、既定の地球アイコンに落ちます。ファイルをいくら調整しても直りません。
自分のサイトが同じ状態かどうかは、4つのURLを叩くだけで分かります。
curl -sI http://www.example.jp/ | head -1
curl -sI https://example.jp/ | head -1
curl -sI https://www.example.jp/ | head -1
4本のうち200が返るのが1本だけなら正常です。今回の相談先は、次のように200が2本ありました。
| 叩いたURL | 返ってきたもの | 読み方 |
|---|---|---|
http://example.jp/ |
301 → https へ | 常時SSLは効いている |
http://www.example.jp/ |
301 → https へ | 同上 |
https://example.jp/ |
200 | ここが2本目の入口 |
https://www.example.jp/ |
200 | どちらも生きている＝未正規化 |
以下は、ファイルを疑って外すまでの経緯と、実際に効いた切り分けの手順です。
まずファイルサイズを疑った。そして外れた
実装は<link rel="shortcut icon" href="/favicon.ico">で、コメントに「32×32」とありました。定番の疑いどころとして「検索結果のファビコンは大きめのサイズが要求され、タブ用の小さい.icoだと弾かれる」という説を最初に検討しています。
Google公式の現行ガイドラインを確認すると、要件は「正方形で最低8×8px」であり、48px超は”推奨”であって”必須”ではありません。32×32はこの要件を満たしています。
とはいえ「要件は満たしているが実務上は弾かれる」という可能性も残るため、決め手として、正常に検索結果へファビコンが表示されている同一運営元の姉妹サイトのfavicon.icoをダウンロードして比較しました。結果は同じ32×32・同じ4286バイト。ファイル自体はほぼ同一で、片方は表示され片方は表示されないという状況です。ここでサイズ・ファイル形式説は外れました。
同じサイトが2つのホスト名で開ける状態になっていた
curlでの突き合わせで真因が判明しました。検索結果に出ているURLは非wwwのexample.jp/xxx形式でしたが、トップページのcanonicalタグはhttps://www.example.jp/を指していました。しかもhttps://example.jp/とhttps://www.example.jp/の両方が200で応答しており、どちらか一方へ301で寄せる処理が入っていませんでした。.htaccessはhttp→httpsの強制はしていましたが、www有無の正規化はしていない書き方だったのが原因です。なお、www統一の301を入れたつもりでも一部の区画だけ素通りしていた例は子ディレクトリの.htaccessは親のRewriteを継承しない話に書きました。
さらに悪いことに、canonicalタグ自体もサイト内部で統一されていませんでした。トップページなど大半のページはwwwを指す一方、検索結果に出ていたページを含む一部のページ群だけが非wwwを指しており、サイト内でcanonicalの向きが割れていました。
Googleは検索結果に出すファビコンを「サイト（＝ホスト名単位）につき1つ」として扱います。これも同じGoogle公式ガイドラインに明記されている挙動で、「Google Searchは1サイト（ホスト名で定義される）につき1つのfaviconしかサポートしない」とされています。ホストがwww有無で二重化し、canonicalも割れている状態では、検索結果に出ている非wwwホストに対してどのfaviconを紐づければよいかが確定できず、既定アイコンに落ちていたと考えられます。正常に表示されていた姉妹サイトは、トップページも検索結果も内部canonicalも全部wwwで統一されていました。差はそこだけです。
正常な1サイトと並べると、原因は一気に絞れる
切り分けで実際に効いたのは、次の4つです。
- 正常に表示されている同型サイトを1つ見つけて、疑っている要素をバイト単位で突き合わせる。今回はfavicon.icoを両方curlで取得し、ファイル種別とバイト数を比較して「ファイルはシロ」と即断できました。これがないと延々サイズ調整の袋小路に入り込みます。
- curlでクローラのUAを名乗って取得する。
curl -sI -A "Googlebot-Image/1.0"で200・Content-Typeを確認し、UA別に挙動が変わるサーバー設定の可能性も切り分けました。 - http/https・www/非wwwの4象限をcurlで叩く。
curl -sIを4パターンで実行し、どこで301が入りどこが素通しかを一覧にすると、ホスト正規化の有無が一目で分かります。 - head内のlinkタグは生HTMLで確認する。WebFetchのようなMarkdown変換を通すツールは
<head>内のlinkタグを落とすことがあり、「タグが無い」という誤った判断につながります。今回もWebFetchでは「faviconタグ無し」と誤答しました。curlで取得した生HTMLをgrepするのが確実です。
検索結果にファビコンが出ない相談は、まずホストの正規化を疑う
「検索結果にファビコンが出ない」という相談は、ファビコンのファイル自体を調べ始めて外れるケースがあります。今回の一件で確認できたのは、サイト側のホスト正規化（www有無・http/httpsの一本化）とcanonicalタグの一貫性が崩れていると、ファイルが要件を満たしていても表示が壊れうるということでした。faviconはホスト名単位で紐づくため、「どちらのURLでも同じページが開ける」状態そのものが表示を壊す側に働きます。
なお、修正方向（www統一にするか非www統一にするか）は本記事の時点では決めていません。検索結果側は既に非wwwで索引されている一方、サイト内部の多数派はwww。どちらを採るにせよ既存の評価を一部持ち越す一方通行の意思決定になるため、インフラ側の手順も絡む判断としてクライアントの判断待ちで保留にしています。診断で確定できたのは「原因はファビコンではなくホストの二重化である」というところまでで、直したら実際に表示されるかどうかは未検証です。
※本記事の記述は2026年7月時点のものです。
