Google favicon S2サービスの代替案を比較

ドメインを2,000件掲載するダッシュボードでは、各行に1つのアイコンが必要です。Google favicon service S2の代替案を検討しているなら、まず高速なキャッシュ済みプレビューが必要か、そのサイトが実際に公開している最も正確なfaviconが必要かを判断してください。Google S2は前者に、favicon直接探索は後者に適しています。

faviconがSearch結果に表示されるかは別の問題です。引用したGoogle Searchのドキュメントはfaviconの表示要件を扱っていますが、S2が利用できることを保証する契約ではありません。安定したURLに自分のfaviconを公開し、icon linkで宣言してください。Googleによると、表示対象となるfaviconは正方形で少なくとも8×8ピクセルである必要があり、48×48ピクセルより大きいものを推奨しています。また、再クロールには数日から数週間かかることがあります。表示対象であっても、Search結果に表示される保証はありません。Googleのfaviconドキュメントにはルールが記載されています。

Google favicon service S2の代替案：比較表

選択肢	仕組み	忠実度と制御	主なトレードオフ
Google S2	よく参照される`google.com/s2/favicons` endpointへ、ドメインとサイズの指定を付けてリクエストします。	ホスティングされたプレビューを返します。元のファイルではなく、制御の自由度は低いです。	実装はシンプルですが、引用されたガイドにはS2 APIを保証する記述がありません。キャッシュ済み結果がブランド変更に追いつかない可能性があります。
favicon直接探索	ページを取得し、icon linksとmanifestへの参照を解析してから、候補ファイルを取得します。	SVG、PNG、ICO、およびサイト運営者が選んだ形式を保持できます。	parsing、redirectの処理、validation、caching、および安全でないリクエストへの対策が必要です。
DuckDuckGo icon service	サードパーティのlookupを利用します。通常は`icons.duckduckgo.com/ip3/`にドメインをパスとして指定して利用します。	ホスティングされたアセットを返します。サイト運営者が現在公開しているソースにアクセスできる保証はありません。	フォールバックとして有用ですが、可用性とキャッシュ状態は自分の制御外にあります。
`Mzu favicondl`	選択したfavicon候補を手動でダウンロードし、内容を確認・変換できます。	運用者が元のアセットを選び、複数の出力形式を生成できます。	一度限りの処理やレビュー中心のワークフローに最適ですが、bulk runtime lookup APIとして位置づけられているわけではありません。

HTMLのrel='icon'リンクは、アイコンリソースを示します。アイコンの選択にはtype、size、mediaの指定が関係するため、crawlerが最初のURLをそのまま採用するのは適切ではありません。WHATWGのlink relationドキュメントが、この関係性を定義しています。

各オプションを使う場面

素早いホスト型プレビューにはGoogle S2を使う

社内ダッシュボード、リンクプレビュー、管理画面など、識別しやすいキャッシュ済み画像があればよい用途ではS2を選びます。リクエスト処理が簡潔になり、ローカルでの変換を避けられます。

レスポンスは便宜的なデータであり、正本となるブランド情報として扱わないでください。キャッシュミス時のplaceholderを用意し、取得時刻を記録し、キャッシュの鮮度が重要な場合は単一ソースに依存しない設計にしてください。S2で画像を取得しても、そのドメインがGoogle Searchのfaviconの表示対象として適格になるわけではありません。

精度と制御が重要な場合はdirect discoveryを使う

自分で管理しているサイトや、既知のドメインではdirect discoveryを使ってください。HTML parserでホームページを解析し、icon linkの候補を収集します。type、size、mediaのヒントを尊重したうえで、標準的な/favicon.icoパスはfallbackとしてのみ試します。この方法ならSVGを維持でき、選択したアイコンをローカルにキャッシュできます。

from urllib.parse import urljoin

def icon_candidates(page_url, discovered_hrefs):
    candidates = [urljoin(page_url, href) for href in discovered_hrefs]
    candidates.append(urljoin(page_url, '/favicon.ico'))
    return list(dict.fromkeys(candidates))

リクエスト数の上限を設け、private networkのtargetをブロックしてください。拡張子だけを信頼せず、status、content type、file signatureを検証してください。本番運用向けのfavicon APIチェックリストで、これらの不正アクセス防止策を説明しています。

副次的なホスト型fallbackにはDuckDuckGoを使う

任意のthird-partyサイトの取得が面倒하거나、originがcrawlerをブロックしている場合はDuckDuckGoを使います。可能ならdirect discoveryを優先してください。サイト自身が指定した選択肢を確認できるためです。

ホスト型のレスポンスが、完全版・最新版・vector版として提供される保証はありません。availabilityとキャッシュの鮮度は制御できないため、差し替え可能なfallbackとして扱ってください。endpointの挙動とより詳しいformat比較については、DuckDuckGo favicon APIと代替手段の比較を参照してください。

手動ダウンロードと変換にはMzu favicondlを使う

単発の抽出やデザインの引き渡し、あるいは誰かが候補を選ぶ小規模なレビュー主導のワークフローでは、Mzu favicondlを利用してください。選択したPNG、SVG、ICOへの変換は簡単ですが、自動化された大量参照には別の要件があります。

例えば、チームはmodernなブラウザ向けのSVG、より広範なクライアント向けのPNGまたはICO、ホーム画面向けのApple touch iconを、それぞれ書き出せます。この方式では、不透明なproxy cacheより、意図的な選択を優先できます。

推奨

普遍的なランキングではなく、必要な管理・制御の要件に応じて選んでください。

独自ドメイン：安定したURLでiconを公開し、icon linkで宣言してください。不要な変更は避けてください。Google Searchでiconの掲載が認められるかどうかに関わるのは、この方式です。
third-partyのiconディレクトリ：まずdirect discoveryを使用し、サイト運営者が意図したSVGまたはraster assetを取得してください。
ホスト型fallback：サイズ指定のプレビューにはS2、ICO重視のfallbackにはDuckDuckGoを使ってください。どちらを主役にもせず、両方をサポートしてください。
プライバシー重視またはofflineのシステム：third-party serviceを使わず、originから直接取得するか、local workflowを利用してください。

cacheはcanonical domain単位で構成し、asset typeと取得日を保存してください。すべてのダウンロードを検証し、中立なfallbackも維持してください。これらの詳細のほうが、iconを提供するhostnameより重要です。

結論

google favicon service s2 alternativeとして何が最適かは、目的によって変わります。速度重視ならS2、別のホスト型fallbackとして使うならDuckDuckGo、精度と制御を重視するならdirect discovery、手動ダウンロードと変換ならMzu favicondlです。本番環境では、サイト運営者がホストするassetをデフォルトとし、外部サービスは差し替え可能なfallbackとして扱ってください。Google Searchでのvisibilityを得るには、proxy経由ではなく、自分のiconを公開してください。