Google の s2 favicon 取得エンドポイントは、裸のドメインを domain パラメータで渡すと、内部の faviconV2 では http スキームの URL キーへ正規化されることがある。サイト本体が HTTPS canonical で、HTTP から HTTPS へ正常に恒久リダイレクトしていても、Google 側の favicon キャッシュは http キーと https キーで反映状態が別々に見える。

実例として、HTTPS 側は正しい新アイコンを返すのに裸ドメイン指定（＝http キー）だけが古いまま、という状態が長く続いた。最終的な原因は「http スキーム側の URL が favicon 専用クローラにクロールされていなかった」こと。Google は内部的に http の URL キーで favicon をキャッシュしており、http 側が再クロールされるまで裸ドメインの結果は更新されなかった。http 側がクロールされたタイミングで反映された。つまり、リダイレクト設定が正しくても、favicon の反映は http キーのクロール待ちに律速されうる。

判断基準

• 自分のアプリや検証コードで Google favicon API を呼ぶなら、裸ドメインではなく scheme 付きの URL を渡す。具体的には domain_url パラメータ、または domain に scheme 付き URL を渡せる経路を使い、HTTPS canonical の favicon キャッシュを見る。
• 裸ドメインの結果が古い／デフォルトアイコンでも、scheme 付き HTTPS URL の結果が正しいなら、配信ファイル自体は採用可能で、問題は外部キャッシュの URL キー差分（http キーの未反映）として切り分ける。
• 裸ドメイン表示まで揃えたい場合は、HTTPS だけでなく http スキーム側の URL（ルートと favicon パス）が、favicon 専用クローラに発見・取得される状態になっているかを確認する。https へ恒久リダイレクトしていても、リダイレクト元の http URL 自体が一度クロールされないと http キーのキャッシュは更新されない。
• Search Console で再クロールを依頼する対象は canonical の HTTPS ホームページにするが、これはページのインデックス更新であって favicon 専用クローラの http キー再取得を早める手段ではない。favicon は別系統で遅延しうる（インデックスとクロール系統が分かれている既存知見を参照）。公式に即時反映させる手段はなく、http 側のクロール待ちになることがある。

検証

外部から通常の取得と Googlebot / Googlebot-Image 相当の取得を行い、http ホームページ・favicon・アイコン本体がすべて 1 回の恒久リダイレクトで HTTPS の正常応答へ到達するかを見る。次に Google favicon キャッシュで裸ドメイン指定（http キー）と scheme 付き HTTPS 指定のレスポンスを比べる。HTTPS 指定だけ正しい場合は、サイト配信ではなく Google 側 http キーの favicon キャッシュ（＝http 側クロール待ち）として扱う。