プラットフォーム別の favicon

Next.js はアイコンを、手書きの link タグではなくファイルから解決します。正しいファイル名を正しいディレクトリに置けば、フレームワークが代わりにマークアップを出力します。

React はドキュメントの head に一切手を触れません。アイコンの link は HTML のシェルに置くことになり、それがどのファイルかは、プロジェクトを Create React App と Vite のどちらで生成したかによって決まります。

Vue の単一ファイルコンポーネントは、head に link タグをレンダリングできません。アイコンは index.html で宣言し、そのファイルは Vite ではプロジェクトルートに、Vue CLI では public/ の中にあります。

Angular は、ビルド設定がそう指示した場合にのみ静的ファイルをコピーします。angular.json の assets エントリーにマッチしないファイルは、プロジェクトのどこに置いても dist/ には届きません。

SvelteKit は static/ の中身をすべてビルドのルートへコピーし、ドキュメントのシェルはコンポーネントではなく src/app.html です。アイコンのタグはそこに置くことで、JavaScript が動く前の、配信される HTML に含まれます。

Nuxt はデフォルトで、すべてのページに /favicon.ico への link を挿入します。そのため新規プロジェクトは、public/ にファイルを置くまでその 404 を記録します。残りのアイコンは nuxt.config の app.head ブロックで宣言します。

Vite は珍しく、index.html を静的アセットではなくソースコードとして扱います。ファイルはプロジェクトルートにあり、ビルド時に書き換えられます。public/ の中身はすべて、手を加えられずに出力ルートへコピーされます。

Remix (and React Router framework mode, which is the same route API under renamed packages) does not pick up icons from a special filename. You put files in public/ and return them from the root route's links() export so <Links /> can render them into the document head.

Laravel has no icon convention of its own. Files in public/ are served at the site root, and the link tags belong in your Blade layout's head. Getting the web server's document root wrong is the most common reason a perfectly placed favicon.ico still 404s.

Django does not special-case favicons. Icons are ordinary static files collected into STATIC_ROOT and referenced from your base template with the static template tag. In production the collectstatic step is what makes them reachable.

Rails expects the favicon to go through the asset pipeline. Put the files under app/assets/images and declare them with favicon_link_tag in the application layout so production fingerprinting keeps working.

In ASP.NET Core the web root is wwwroot. Icon files go there, and the link tags go in your layout (MVC/Razor Pages) or App component (Blazor). Static file middleware has to be in the pipeline or every icon 404s regardless of the markup.

Astro は src/ からインポートしたアセットを処理してフィンガープリントし、public/ はそのままの状態でビルド出力へコピーします。アイコンには安定したファイル名が必要なため、public/ に置き、レイアウトからリンクします。

Gatsby は、ここで扱う中で唯一アイコン一式を生成してくれるスタックです。gatsby-plugin-manifest は gatsby-config.js で指定された 1 枚の元画像を受け取り、ビルド時に各サイズ、ウェブアプリの manifest、link タグを生成します。

Hugo は static/ を公開サイトのルートへコピーしますが、head のマークアップは、インストールしたテーマに属します。コツは、themes/ 配下のファイルを編集するのではなく、自分のプロジェクトからテーマのパーシャルをオーバーライドすることです。

WordPress はアイコンファイルのフォルダを求めません。正方形の画像を 1 枚 Site Icon としてアップロードすれば、コアがそれを配信する各サイズに切り抜き、すべてのページに link タグを出力します。

Shopify ではファビコンは、サーバーに置くファイルではなく、画像 CDN を裏側に持つテーマの設定です。どのタグをレンダリングするかはテーマが決め、ほとんどのテーマはちょうど 1 つだけをレンダリングします。

Squarespace はファビコンを browser icon と呼び、それはサイト設定でアップロードする 1 枚の正方形画像です。ファイルシステムも、編集できるテンプレートもないため、その 1 回のアップロードで得られるものがほぼすべてです。

Wix はカスタムファビコンを、ドメインを接続した有料プランに結び付けています。まだ wix.com のサブドメインにあるサイトは、何をアップロードしても Wix 自身のアイコンを表示します。ファイルシステムも、編集できる head もありません。