検索結果のファビコンにSVGとWebPは使えない ── Googleが対応する7つの画像形式を確認する13項目（2026年9月時点）

01 何が起きたか — Googleが対応するファビコン形式を7種類に整理し、SVGとWebPを対象外と明記した

ドキュメントが独立し、対応形式がその場で読めるようになった

検索結果の見出しの横に表示される小さなアイコン、いわゆるファビコンについて、Google Search Centralの公式ドキュメント「favicon」が更新され、対応する画像形式が7種類として明記された。これまでこのページは、対応形式の一覧を外部の参照先（Wikipediaの該当項目）に委ねる形で説明していたが、今回の更新でドキュメント自体に形式名が直接書き込まれた。公式ドキュメントに記載されている形式は、BMP・GIF・ICO・PNG・JPEG・PPM・TIFFの7つである。ドキュメントの最終更新日は2026年8月28日（UTC）と表示されている。

対応する7形式と、除外された2形式

今回の整理でとりわけ確認しておきたいのは、SVGとWebPがこの一覧に含まれていないという点である。SVGはベクター形式で拡大縮小に強く、WebPは圧縮効率の高い次世代画像形式として、どちらもWEBサイトの通常の画像配信では広く採用が進んでいる。しかし、検索結果のファビコンという用途に限っては、この2形式は対応形式のリストに一度も名前が挙がっていない。すでにSVGやWebPでファビコンを実装しているサイトがある場合、検索結果側でどう扱われるかを、この記事のチェックリストで確認できる状態にしておく必要がある。

1ホストにつき使えるファビコンは1つだけ

公式ドキュメントにはもう1点、形式とは別の制約が明記されている。「1つのホスト名に対して使えるファビコンは1つだけ」という制約で、サブディレクトリごとに異なるファビコンを設定しても、検索結果側ではそれぞれ別のアイコンとして扱われることは期待できない、という趣旨である。複数のブランドやサービスを1つのドメイン配下のサブディレクトリで運用しているサイトでは、ディレクトリごとに見た目を変えたファビコンを用意しても、検索結果では意図した通りに出ない可能性がある点を、あらかじめ理解しておく必要がある。サブディレクトリで明確にファビコンを分けたい場合は、サブドメインでホストを分ける設計のほうが、この制約と整合する。

02 なぜ・背景 — Wikipediaへの依存を断ち切るための整理

これまでは外部の一覧を参照する形になっていた

公式ドキュメントを更新した背景として考えられるのは、参照先の変更による記述の不一致を防ぐことである。外部の一覧ページに依存していると、その一覧側の記述が変わった瞬間に、Google側の説明と実際の対応状況がずれる可能性が生じる。今回、対応形式をドキュメント自体に直接書き込んだことで、この参照ずれの余地がなくなった。公式ドキュメントの中だけで、対応形式が完結して読めるようになった点が、今回の変更の実務上の意味である。

なぜSVGとWebPが対象外なのかは、公式には説明されていない

一方で、なぜSVGとWebPが対応形式から外れているのか、その理由は確認した公式ドキュメントのどこにも明記されていない。SVGはベクター画像であり、GoogleがWEBページ内の画像を検索結果に表示する際の処理（Google画像検索での取り扱い）と、ファビコンとして小さく表示する際の処理は、仕組みが異なる可能性がある。ただしこれは推測であり、公式に確認できる情報ではない。「対応していない」という事実と、「なぜ対応していないか」という理由は、切り分けて扱う必要がある。前者は公式ドキュメントで確認できるが、後者は確認できない。理由が推測の域を出ない以上、この記事では「対応形式の一覧に含まれているかどうか」という事実だけを判断基準にして、推測で書けない部分は「公式には明示されていない」と扱う。この姿勢は、faviconに限らずGoogle検索の他のガイダンス全般にも当てはまる考え方で、公式のSEOスタートガイドや検索の仕組みを解説したページでも、推測ではなく確認できる事実を基準にする姿勢が繰り返し示されている。

通常の画像SEOの基準と、ファビコンの基準は別物として扱う

WEBページ内に掲載する画像については、Googleは別のガイド「画像のベストプラクティス」で、ファイル形式そのものよりも、alt属性・ファイル名・周辺テキストによる文脈の伝達を重視する姿勢を示している。この通常の画像SEOのガイドと、今回のファビコンの対応形式一覧を、同じ基準の延長線上にあるものとして扱わないほうがよい。ページ内画像の最適化で普段行っている判断（次世代フォーマットを優先する、軽量化を優先する）を、そのままファビコンにも当てはめると、対応形式から外れる方向に判断してしまう可能性がある。ファビコンは、通常の画像とは別枠のチェック対象として扱う必要がある。

03 この記事で出てくる用語

rel属性の4つの指定値

ファビコンをHTMLで指定する際の<link>タグには、複数のrel属性値が使われる。公式ドキュメントが挙げているのは、icon（推奨される標準の指定）、shortcut icon（歴史的な経緯から互換性のために今も使われる記法）、apple-touch-iconとapple-touch-icon-precomposed（主にAppleのデバイス向けに使われる記法）の4種類である。どのrel属性を使っていても、hrefで指定した先のファイル自体が対応7形式に含まれているかどうかは、別途確認する必要がある。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — 確認すべきタイミングは4つ

この記事の確認作業が必要になるのは、主に4つの場面である。第一に新規サイトを公開するとき、favicon実装を初めて行う段階で対応形式を確認しないまま進めると、後から気づいて手戻りになる。第二にfaviconを更新・リニューアルするとき、デザインを一新するタイミングで形式まで見直す機会になる。第三に既存サイトでSVG形式のファビコンを使っているとき、これがもっとも直接の影響を受ける可能性がある対象になる。第四に、サイトのモダン化対応の一環でPWA（プログレッシブウェブアプリ）用のアイコン設定を行ったとき、manifest.json用のアイコンと、検索結果用のfaviconを混同していないか確認が必要になる。加えてCMSやテーマのデフォルト設定をそのまま使っているサイトも対象になる。CMS側が自動で挿入するfaviconタグは、必ずしも運用者が意識して選んだ形式とは限らず、テーマの初期設定がICOやPNGでない場合、気づかないまま対応形式外のファビコンを配信し続けていることがある。

🅱 この記事が測っていないこと・分からないこと

確認した公式ドキュメントの範囲では、明確にされていない点がいくつかある。第一に、SVGやWebPで実装している既存サイトが、今後どういう扱いを受けるのかという移行的な取り扱いは記載がない。第二に、ファイルサイズの上限も、確認した範囲のドキュメントには数値として明記されていない。第三に、複数のrel="icon"を異なる形式で同時に宣言した場合、Googleがどちらを優先して採用するのかという優先順位の仕組みも、公式には説明が見当たらない。「対応形式である」ことと「実際に検索結果へ表示される」ことの間に、まだ確認できていない条件がある可能性があるという前提で、この記事のチェックリストを使ってほしい。

🅲 手順 — 対応形式を満たす実装の流れ

実際の対応は、次の4段階で進める。第一に画像の準備として、正方形（1:1）の元画像を用意し、48x48ピクセルより大きいサイズで書き出す（公式ドキュメントが示す最小要件は8x8ピクセルだが、推奨はそれより大きいサイズである）。第二にファイル形式の選定として、BMP・GIF・ICO・PNG・JPEG・PPM・TIFFのいずれかで保存する（多くのサイトではPNGまたはICOが扱いやすい）。第三にHTMLへの記述として、<link rel="icon" href="/path/to/favicon.png">の形で、相対パスまたは絶対パスを指定する（CDN経由のホスティングも許可されている）。第四にクロール可能性の確認として、そのURLがrobots.txtでブロックされていないか、実際にブラウザで開けるかを確認する。

絶対URL・相対URL・CDN経由、いずれの指定方法も許可されている

href属性の指定方法についても、公式ドキュメントは複数の書き方を許可している。/favicon.icoのような相対パスでも、https://example.com/favicon.icoのような絶対URLでも構わないとされ、さらにCDN（コンテンツ配信ネットワーク）経由でホスティングしたファイルを指定することも許可されている。画像配信をCDNに任せている構成のサイトでは、faviconだけを自ドメインに置き直す必要はない。ただし、CDN側のURLが将来変わる可能性がある構成の場合、前段で触れた「URLの安定性」の条件との兼ね合いを、CDNの運用ルールとあわせて確認しておいたほうがよい。URLの設計そのものについては、サイト全体のURL構造を扱った公式ガイドにも関連する記述がある。

URLは変えない。安定性が条件に含まれている

実装した後の運用でもう一点、見落としやすい条件がある。公式ドキュメントは「ファビコンのURLは安定していなければならない（頻繁にURLを変更しないこと）」と明記している。サイトリニューアルのたびにファビコンのファイル名やパスを変更していると、Google側が新しいファビコンを認識し直すまでに時間がかかる可能性がある。デザインの中身を差し替える場合でも、ファイルのURLパス自体は変えずに済む運用にしておくほうが、確認の手間を減らせる。

05 明日、自分のサイトで確認できることチェックリスト

まず何を数えるか

ここまでの内容を、実際に手を動かせる作業に翻訳した。観点は、宣言している形式の確認、画像そのものの仕様確認、クロール可能性の確認、複数宣言時の整理の4つに分かれる。

• 自分のサイトのHTML<head>内にある<link rel="icon">タグをすべて書き出す
• 宣言している画像ファイルの拡張子を確認し、BMP・GIF・ICO・PNG・JPEG・PPM・TIFFの7種類に含まれているか照合する
• SVG形式（type="image/svg+xml"）のみでファビコンを宣言していないか確認する
• WebP形式のファビコンを宣言していないか確認する
• faviconの画像ファイルを開き、縦横比が正方形（1:1）になっているか確認する
• faviconのピクセルサイズを確認し、48x48ピクセルより大きいサイズになっているか確認する
• faviconのURLを直接ブラウザの新しいタブで開き、正しく画像が表示されるか確認する
• robots.txtを開き、faviconファイルのパスがDisallowでブロックされていないか確認する
• rel="icon"に加えて、rel="shortcut icon"などの旧式の記法が重複して残っていないか確認する
• rel="apple-touch-icon"・rel="apple-touch-icon-precomposed"の画像が、PNGなど対応形式で用意されているか確認する
• manifest.json（PWA用アイコン設定）とファビコンの役割を混同していないか、それぞれのファイルを見比べて確認する
• 直近1ヶ月以内にfaviconのURLを変更していないか確認する（URLの安定性が公式の条件に含まれるため）
• Search Consoleの「URL検査」ツールで対象ページをテストし、取得やクロールに関するエラーが出ていないか確認する

13項目の内訳と、かかる時間の目安

13項目は4つの観点に対応している。それぞれにどの項目が入り、目安としてどれくらいの時間がかかるかを、以下の表にまとめた。

すべてに目を通す時間の目安は1サイトあたり30〜45分程度である。多くのサイトでは<head>タグを開いて宣言を書き出す最初の作業がもっとも重要で、そこで対応形式外の宣言が見つかれば、以降の作業の優先度が一気に上がる。

ファビコンが検索結果に出ない、形式以外の原因

対応形式で正しく実装しても、検索結果に反映されるまでには別の条件も関わってくる。03章で触れたとおりGooglebot-Imageがそのファイルをクロールできることが前提になるため、robots.txtでファビコンのパスがブロックされていないかは、形式の確認とあわせて見ておく必要がある。robots.txtの記述ルールそのものについては、別の記事でnoindex・nofollow・robots.txtがそれぞれ何を止めているのかを整理している(noindex・nofollow・robots.txtは、それぞれ何を止めているのか)。また、サイトを公開したばかりでクロール自体がまだ十分に行われていない場合や、ファビコンを設置してから日が浅い場合は、対応形式に沿っていても表示までに時間がかかることがある。「形式は正しいのに表示されない」ときは、形式以外の条件を順番に切り分けることになる。

06 代替・他の選択肢（表で）

対応する7形式と、対象外の2形式の違い

公式ドキュメントに明記されている7形式と、対象外とされているSVG・WebPを、特徴とあわせて以下の表にまとめた。

この表から分かるのは、「WEBサイトの画像として優れているかどうか」と「検索結果のファビコンとして対応しているかどうか」は、別の基準で判断されているということだ。SVGとWebPは通常の画像配信では積極的に採用が勧められる形式だが、ファビコンという特定の用途に限っては、その評価がそのまま当てはまらない。

rel属性の使い分け

faviconを宣言する<link>タグのrel属性は、対象とするデバイスや互換性の観点で使い分けられている。

07 自社サイトで確認したこと — 対応形式の外側にある宣言が残っていないかの記録

2種類のfaviconが、同時に宣言されていた

当サイトのトップページのHTML<head>を実際に開いて確認したところ、<link rel="icon" href="/favicon.ico" sizes="48x48">に加えて、<link rel="icon" href="/icon.svg" type="image/svg+xml">も同時に宣言されていた。ICOは対応7形式に含まれているが、SVGは今回確認した公式ドキュメントの対応表には含まれていない。2つのrel="icon"宣言が並んでいる状態で、Googleがどちらを採用するのかという優先順位は、04章で触れたとおり公式には明記されていない。「対応していない形式を宣言している」のではなく、「対応形式と非対応形式を両方 宣言している」状態であることを確認した。

PWA用のアイコンと、検索結果用のファビコンが別の仕組みで管理されていた

あわせて<link rel="manifest" href="/manifest.json">も確認できた。これはPWA（プログレッシブウェブアプリ）としてホーム画面に追加した際のアイコン設定を担うファイルで、検索結果のファビコンとは別の仕組みである。03章で触れたとおり、この2つを混同すると、manifest.json側だけを対応形式で整えて満足してしまい、検索結果用のrel="icon"宣言の見直しが漏れることがある。「PWA用のアイコンが正しく表示されている」ことと、「検索結果のファビコンが対応形式で宣言されている」ことは、別々に確認する必要があるという点は、05章のチェックリスト11番目にそのまま反映している。

08 このテーマの、これまで

faviconを刷新した記録と、今回の確認の関係

当サイトでは以前、favicon一式をモダンな構成に整理し、SVGを含む複数形式・複数サイズを用意した記録がある(archives/74)。その際は、ブラウザのタブでの見え方やダークモードでの表示を主な確認対象にしていた。今回、検索結果という別の表示面を基準にして見直すと、当時は意識していなかった「対応形式かどうか」という条件が新たに出てきたことになる。favicon一式は一度作って終わりではなく、Googleが対応形式を明記するような更新があるたびに、どの表示面を対象にした確認かを分けて見直す必要がある、という点が、この記事を通じて確認できたことである。

「配置したはずのファイルが届いていない」は、favicon以外でも起きていた

当サイトでは、記事内に配置したはずの画像ファイルが、実際には本番環境に届いていなかった、という記録もある(archives/132)。今回のfaviconの確認とは別件だが、「宣言している場所」と「実際にファイルが存在する場所」がずれていても、エラーが出るとは限らないという点は共通している。faviconについても、<link>タグの宣言だけを確認して満足せず、07章で行ったように、宣言先のURLを実際に開いてファイルが存在するかまで確認することが必要になる。