Favicon-Audit-Checkliste für Entwickler (2026)

Ein Favicon-Audit bestätigt, dass deine Site alle Icon-Dateien ausliefert, die Browser und Mobile-Plattformen erwarten, HTML-Tags auf erreichbare URLs zeigen und /favicon.ico an der Domain-Root existiert. Checkliste auf Production laufen lassen, nicht localhost, vor jedem Branding-Deploy oder Domain-Umzug.

Das ist ein entwicklerorientierter Durchlauf für PR-Templates, QA-Tickets oder CI-Skripte. Kombiniere mit Favicon Check für automatische Discovery und Open Graph Check für Share-Metadata.

Wann ein Favicon-Audit laufen soll

Audit auslösen bei:

• Launch neuer Site oder Subdomain
• Rebrand von Logo oder Farben
• Framework-Migration (WordPress zu Next.js, CRA zu Vite)
• PWA-Install-Support
• Nutzer melden falsches Tab-Icon oder unscharfe Homescreen-Shortcuts
• Merge von Head-Tag-Änderungen mehrerer Teams

Volles Audit bei reinen Content-Deploys überspringen, außer CMS ändert document head.

Phase 1: Deklarierte Icons inventarisieren

Favicon Check öffnen, kanonische Produktions-URL eingeben:

• Jeder link rel="icon"-Eintrag
• apple-touch-icon-Tags
• Verlinktes Web-App-Manifest und Icon-Array
• HTTP-Status pro URL
• Ob /favicon.ico an der Site-Root antwortet

Ergebnisse im Ticket dokumentieren. Beispieltabelle:

Zuerst automatischer Scan, dann manuelle Checkliste.

Phase 2: HTML-Head-Audit

Seitenquelltext der Startseite (nicht nur DevTools Elements).

Pflichtchecks

• Mindestens ein link rel="icon" mit korrektem type und sizes
• Icons mit root-relativem oder absolutem HTTPS-URL
• Keine doppelten widersprüchlichen rel="icon" von Plugins oder Legacy-Templates
• apple-touch-icon bei 180×180
• link rel="manifest", wenn PWA-Icons nötig
• Tags im Roh-HTML ohne JavaScript

Red Flags

• Staging-Domain in href (staging.example.de)
• Relative Pfade ohne führenden Slash (icons/favicon.png)
• HTTP-URLs auf HTTPS-Site (Mixed Content)
• Data-URIs für große Icons (schwer zu debuggen)

Referenz: Favicon per HTML einbinden.

Phase 3: Dateiformat- und Größen-Audit

Jedes Icon aus dem Scan herunterladen und Pixel prüfen.

Master mindestens 512×512. Kleine Quellen nie hochskalieren. Siehe Favicon-Größen-Leitfaden und Favicon unscharf.

Phase 4: Root-Fallback-Audit

Browser und Tools rufen https://deinedomain.de/favicon.ico ab, auch bei PNG-Deklaration in HTML.

• /favicon.ico liefert 200
• Content-Type image/x-icon oder image/vnd.microsoft.icon
• Datei zur aktuellen Marke (kein Host-Platzhalter)
• Kurze Redirect-Kette (direktes 200 bevorzugt)

ICO bewusst weggelassen? Risiko dokumentieren: E-Mail-Clients und Legacy-Crawler zeigen Generics.

Phase 5: Web-Manifest-Audit

Für PWAs und Android-Homescreen-Branding:

curl -s https://example.de/site.webmanifest | jq .

• Gültiges JSON, keine trailing commas
• icons-Array mit 192×192 und 512×512
• Jedes src liefert 200 auf Production
• purpose korrekt (any, maskable bei Adaptive Icons)
• Manifest im HTML-Head verlinkt

Tab-Favicon allein reicht nicht für Manifest-Anforderungen.

Phase 6: Cross-Browser- und Device-Spot-Checks

Automatische Scans verpassen Rendering-Sonderfälle. Sauberes Profil oder Inkognito:

• Chrome Desktop-Tab bei 100 % und 125 % Zoom
• Firefox Tab-Icon
• Safari macOS Tab (und angehefteter Tab falls relevant)
• iOS Safari Zum Home-Bildschirm-Vorschau
• Android Chrome Install oder Homescreen
• Lesezeichenleisten-Icon nach Speichern

Schritte: Favicons testen vor Launch.

Phase 7: Cache- und CDN-Audit

Nach Icon-Änderungen verursacht stale Cache falsche QA-Fails.

• CDN HTML und Static Assets purgen
• Cache-Header auf Icon-URLs (Cache-Control sinnvoll)
• Dateien nach Rebrand versionieren oder umbenennen (favicon-2026.ico)
• Inkognito zeigt neues Icon auf Production

Nutzer sehen noch alte Icons: Favicon wird nicht angezeigt.

Phase 8: Host- und Routing-Audit

• www und Apex liefern korrekte Icons (oder 301 auf kanonisch)
• Subpath-Deploys: base-Prefix in Icon-URLs
• Auth-Walls blockieren /favicon.ico nicht (Staging manchmal 401)
• robots.txt blockiert Icon-Pfade nicht (selten)

Phase 9: Framework-spezifische Audit-Notizen

Next.js App Router

app/icon.png, app/favicon.ico oder metadata.icons im Root-Layout. Keine doppelten next/head-Tags. Guide: Favicon in Next.js.

WordPress

Site Icon im Customizer aktiv, Theme überschreibt nicht. Root-ICO wenn Host erlaubt. Guide: Favicon in WordPress.

Vite / React SPA

Icons in public/, Tags in index.html, korrekte base in vite.config. Guide: Favicon in Vite/React.

Phase 10: Open-Graph-Trennung

Favicons und OG-Bilder teilen Marke, nicht Dateien oder Tags.

• og:image zeigt auf 1200×630 (oder passend zur Plattform)
• Favicon-Tags referenzieren nicht die OG-Image-URL
• Beide Scans bestanden: Favicon Check und Open Graph Check

Stakeholdern erklären: Favicon vs. Open-Graph-Bild und Open Graph Tags erklärt.

Copy-Paste-Developer-Checkliste

FAVICON-AUDIT - Production-URL: _______________

[ ] Favicon-Check-Scan - alle Icons 200
[ ] Seitenquelltext - Tags im Roh-HTML
[ ] /favicon.ico - 200 an Domain-Root
[ ] 16x16 + 32x32 PNG deklariert
[ ] apple-touch-icon 180x180
[ ] Manifest-Icons 192 + 512 (bei PWA)
[ ] Keine Staging-URLs in href
[ ] HTTPS, kein Mixed Content
[ ] CDN/Cache nach Änderung gepurgt
[ ] Inkognito-Tab-Test - Chrome + Safari
[ ] iOS-Homescreen-Vorschau
[ ] Android-Shortcut-Icon
[ ] OG-Scan separat (Open Graph Check)
[ ] Dokumentierte Ausnahmen: _______________

In PR-Beschreibung oder Release Notes abzeichnen.

Audit-Teile automatisieren

CI kann prüfen:

# Beispiel: Fail wenn favicon.ico fehlt
curl -sf -o /dev/null -w "%{http_code}" https://example.de/favicon.ico | grep -q 200

Homepage-HTML nach required rel-Werten parsen. HEAD-Request pro Icon-URL.

Automation findet 404s, nicht Unschärfe oder falschen Crop. Manuelle Spot-Checks bei Releases behalten.

Häufige Audit-Fails (Ranking)

1. 404 auf apple-touch-icon - iOS-Homescreen wirkt kaputt
2. Fehlendes /favicon.ico - E-Mail und Legacy zeigen Globus
3. Nur Client-Favicon-Tags - Crawler sehen nichts im Seitenquelltext
4. Falscher Base-Pfad bei SPA - Icons 404 auf verschachtelten Routen
5. Stale CDN-Cache - Team denkt Deploy ist fehlgeschlagen
6. Doppelte Tags - unvorhersehbare Browser-Wahl
7. Hochskaliertes Mini-PNG - unscharfe Tabs überall

Fix-Reihenfolge: Statuscodes, dann Dimensionen, dann Cache.

Release gate: when to block deploy

Treat favicon audit failures as release blockers when:

• Rebrand or logo change is in the release notes
• Head template or layout files changed
• CDN or domain migration is part of the deploy
• PWA manifest icons were added or removed

Non-blocking exceptions (document in PR):

• Copy-only CMS update with no head changes
• Backend API deploy with no HTML surface
• Internal admin tool not linked from public marketing site

When in doubt, run Favicon Check. A two-minute scan is cheaper than a post-launch hotfix.

Audit-Ergebnisse dokumentieren

Speichere pro Release kurz:

• Production-URL und Datum
• Scan-Screenshot oder Liste der Icon-URLs mit Status
• Offene Ausnahmen mit Ticket-Link
• Wer visuellen Spot-Check signiert hat

Das hilft bei „Icon war gestern noch ok“-Reports drei Wochen später. Cache-, CDN- und Content-Probleme lassen sich so schneller eingrenzen.

Sonderfall: mehrsprachige Sites

Bei hreflang-Setups mit /en/ und /de/ sollten Favicon-Tags auf allen Sprachvarianten identisch sein. Scan jede Locale-Root-URL:

• https://example.com/en/
• https://example.com/de/

Unterschiedliche Icons pro Sprache sind selten und verwirren Nutzer, die zwischen Locales wechseln. Wenn du bewusst unterschiedliche Marken-Icons nutzt, dokumentiere das im Audit-Ticket.

Integration in Pull-Request-Templates

Füge in .github/pull_request_template.md einen Block ein:

### Favicon (if head/branding changed)
- [ ] Favicon Check on production/preview URL
- [ ] /favicon.ico returns 200
- [ ] iOS home screen spot check (if mobile audience)

Kleine Erinnerung im PR verhindert, dass Icon-Änderungen in großen Releases untergehen.

Audit-Ergebnisse mindestens ein Quartal aufbewahren. Bei Rebrand-Beschwerden lässt sich so nachvollziehen, welcher Stand zum Launch-Zeitpunkt freigegeben war.

Ein Satz im PR reicht oft: „Favicon Check auf https://… OK, siehe Screenshot.“

FAQ

Wie oft Favicon-Audit als Entwickler?

Bei jedem Deploy mit Icon-, Manifest-, Head-, CDN- oder Domain-Änderung. Quartalsweise bei stabilen Sites sinnvoll.

Welche Tools für Favicon-Audit?

Favicon Check für URL-Scan, Browser-Inkognito für Sichtcheck, curl/jq für Manifest, Bildeditor für Pixel.

Auditiert Lighthouse Favicons?

Lighthouse kann fehlende Icons melden, validiert aber nicht jede Größe und Manifest-Einträge. Eigene Checkliste plus Favicon Check.

Favicon-Audit in CI oder manuelles QA?

CI für HTTP 200 und Tag-Präsenz. Manuelles QA für visuelle Qualität und Mobile-Homescreen.

Minimum für bestandenes Favicon-Audit?

/favicon.ico 200, ein PNG-Icon-Tag, apple-touch-icon 180×180 bei Mobile-Publikum. PWAs zusätzlich Manifest 192 und 512.

Favicon-Audit nach Merge zweier Codebases?

Production scannen, Seitenquelltext gegen Legacy-Templates diffen, doppelte Head-Ausgabe entfernen, Scan auf kanonischer Domain wiederholen.

Favicon-Audit auf Staging oder Production?

Staging findet Deploy-Bugs früh bei öffentlichen URLs. Finale Freigabe muss Production mit Production-CDN und DNS sein.

Wer owned Favicon-Audit, Design oder Engineering?

Engineering owned Tag-Korrektheit und HTTP-Status. Design owned Crop und Lesbarkeit bei 16×16. QA owned Cross-Browser-Spot-Checks.

Fazit

Ein Developer-Favicon-Audit hat zehn Phasen: automatischer Scan, HTML-Quelle, Dateigrößen, Root-ICO, Manifest, Browser, Cache, Routing, Framework-Details und OG-Trennung. Copy-Paste-Checkliste bei jedem Branding-Release.

Mit Favicon Check auf Production starten, 404s fixen, Device-Spot-Checks gehen. Open Graph Check dazu, wenn dasselbe Release Share-Metadata betrifft.