サイトをデプロイして、ブラウザで確認してみたものの、タブに表示されるのはあの無機質な四角いデフォルトアイコン——そんな経験、開発者なら誰しもあるはずです。大半のケースはfaviconのファイルパス問題に尽きます。ブラウザはアイコンをリクエストしたものの、サーバー側でその場所を解決できず、黙って404を返している状態です。

根本原因を掘り下げる前に、まずは応急処置から入りましょう。現場で毎週のように目にする最も典型的な修正パターンを紹介します。

即効解決策：絶対パスを使う

トップページではfaviconが表示されるのに、下層ページでリンク切れになる場合、原因は相対パスにあります。HTMLを書き換えて、ルートからの絶対パスを指定しましょう。

問題のある相対パスの記述を以下のように修正します：

<!-- Broken: depends on current URL depth -->
<link rel='icon' href='assets/favicon.ico'>

<!-- Fixed: always resolves from the domain root -->
<link rel='icon' href='/assets/favicon.ico'>

先頭のスラッシュ（/）を付けることで、ユーザーがトップページにいようと、ブログの深層ページにいようと、ブラウザは必ずhttps://yoursite.com/assets/favicon.icoを参照してくれます。（念のため補足しておくと、このスラッシュ一つ抜けのせいで、2026年になっても数え切れないほどの開発時間が無駄になっています。）

そもそもなぜファイルパスが壊れるのか

パス解決は魔法ではありません。厳密な文字列のパース処理です。/blog/post-1/というURLのページでhref='images/icon.png'という指定を見つけると、ブラウザはそれを/blog/post-1/images/icon.pngと解釈します。imagesディレクトリがルートにあるなら、このリクエストは失敗するでしょう。

静的ビルドの罠

Next.jsやViteのようなモダンなフレームワークを使っている場合、ビルド結果がローカルの開発環境と一致するとは限りません。フレームワークはアセットを/dist/や/_next/static/にコンパイルすることがあります。ルートに配置されることを前提にパスを手動でハードコードしていると、本番ビルドでパスが壊れます。

Linuxサーバーでの大文字小文字問題

macOSやWindowsのファイルシステムは大文字小文字を区別しませんが、Linuxは厳密に区別します。ローカルでFavicon.icoというファイル名で作業し、Ubuntuサーバーにデプロイしてfavicon.icoとしてリクエストすると404になります。これは現場で毎日のように見かけるトラブルです。ファイル名は常に小文字に統一しましょう。

MIME Typeの設定漏れ

パスが正しくても、サーバーがファイルを正しく配信できていないケースがあります。.icoファイルには適切なMIME Typeが必要です。サーバーがtext/plainとして送信してしまうと、ブラウザはそれを拒否します。NginxやApacheの設定で、.icoに対してimage/x-iconが指定されているか確認してください。

大手ブランドはどう対応しているか

例えば、はてなブログやZennのような国内の大手サービスでも、faviconはルートからの絶対パスで配信されています。ユーザーが/articles/tech/how-to-xxxのような深い階層のページに直接ランディングすることを前提に、href='/favicon.ico'のように指定することで、常にファイルを見つけられるようにしています。また、アイコンを更新する際はクエリパラメータでキャッシュバスティングを行い、ユーザーに古いロゴが表示されないように工夫しています。

2026年に向けた予防策

ファイルの場所を推測するのはやめましょう。以下のルールでfaviconのワークフローを標準化してください：

サイトの移行やリストラクチャリングを行う際、パスエラーはほぼ確実に発生します。favicon移行チェックリストに従って、ユーザーが気づく前に壊れたリンクを発見しましょう。アイコンが全く読み込まれない原因についてさらに詳しく知りたい場合は、favicon 404エラーの修正ガイドを参照してください。

パスエラーは地味ですが、必ず直面する問題です。スラッシュを確認し、大文字小文字を揃え、ビルド結果を検証する。これらを徹底すれば、何時間もかけて作ったアイコンがブラウザのタブにちゃんと表示されるようになります。