Favicons nach Plattform

Next.js löst Icons aus Dateien auf statt aus link-Tags, die du von Hand schreibst. Leg den richtigen Dateinamen ins richtige Verzeichnis, und das Framework erzeugt das Markup für dich.

React fasst den Head des Dokuments nie an. Deine Icon-Links kommen in die HTML-Hülle, und welche Datei das ist, hängt davon ab, ob das Projekt mit Create React App oder mit Vite erzeugt wurde.

Eine Vue-Single-File-Component kann keinen link-Tag in den Head rendern. Die Icons werden in index.html deklariert, die unter Vite im Projektstamm und unter Vue CLI in public/ liegt.

Angular kopiert statische Dateien nur, wenn die Build-Konfiguration es vorgibt. Eine Datei, die der assets-Eintrag in angular.json nicht erfasst, erreicht dist/ nie, egal wo im Projekt du sie ablegst.

SvelteKit kopiert alles in static/ in den Stamm des Builds, und die Dokumenthülle ist src/app.html statt einer Komponente. Icon-Tags gehören dorthin, damit sie im ausgelieferten HTML stehen, bevor irgendein JavaScript läuft.

Nuxt fügt standardmäßig auf jeder Seite einen Link auf /favicon.ico ein, sodass ein neues Projekt dafür einen 404 protokolliert, bis du eine Datei in public/ legst. Die übrigen Icons werden im app.head-Block von nuxt.config deklariert.

Vite ist ungewöhnlich, weil es index.html als Quellcode statt als statisches Asset behandelt: Sie liegt im Projektstamm und wird zur Buildzeit umgeschrieben. Alles in public/ wird unverändert in den Ausgabestamm kopiert.

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 verarbeitet aus src/ importierte Assets und versieht sie mit einem Fingerprint, kopiert public/ aber genau so in die Build-Ausgabe, wie es sie vorgefunden hat. Icons brauchen stabile Dateinamen, also kommen sie in public/ und werden aus einem Layout verlinkt.

Gatsby ist der einzige Stack hier, der den Icon-Satz für dich erzeugt. gatsby-plugin-manifest nimmt ein einzelnes, in gatsby-config.js benanntes Quellbild und erzeugt zur Buildzeit die Größen, das Web-App-Manifest und die link-Tags.

Hugo kopiert static/ in den Stamm der veröffentlichten Website, doch das Head-Markup gehört zu dem Theme, das du installiert hast. Der Trick besteht darin, das Partial des Themes aus deinem eigenen Projekt zu überschreiben, statt Dateien unter themes/ zu bearbeiten.

WordPress will keinen Ordner voller Icon-Dateien. Du lädst ein einziges quadratisches Bild als Site Icon hoch, und der Core schneidet es auf die ausgelieferten Größen zu und gibt die link-Tags auf jeder Seite aus.

Bei Shopify ist das Favicon eine Theme-Einstellung, die vom Bild-CDN gestützt wird, keine Datei, die du auf einen Server legst. Das Theme entscheidet, welche Tags gerendert werden, und die meisten Themes rendern genau einen.

Squarespace nennt das Favicon ein Browser-Icon, und es ist ein einzelnes quadratisches Bild, das in den Website-Einstellungen hochgeladen wird. Es gibt kein Dateisystem und keine Vorlage zum Bearbeiten, dieser eine Upload ist also das meiste, was du bekommst.

Wix bindet das eigene Favicon an einen kostenpflichtigen Tarif mit verbundener Domain. Eine Website, die noch auf einer wix.com-Subdomain liegt, zeigt Wix' eigenes Icon, egal was du hochlädst. Es gibt kein Dateisystem und keinen Head zum Bearbeiten.