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.

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.