Wenn Google plötzlich kein Favicon mehr zeigt

Christopher Zechendorf

24.08.2026

Share:

Das Favicon verschwand aus den Google-Ergebnissen -- ohne dass an der Website etwas kaputt war. Wie wir die Ursache in den strukturierten Daten gefunden haben.

Ein Schaden, den kein Monitoring meldet

„Seit ungefähr zehn Tagen fehlt unser Favicon in den Google-Ergebnissen.” Mehr stand nicht in der Mail – dazu ein Screenshot der Trefferliste, auf dem neben dem Domainnamen statt des vertrauten Symbols der graue Standard-Globus prangte. Die Website selbst lief einwandfrei: keine Fehlerseite, kein Ausfall, keine Warnung im Monitoring, keine einzige Beschwerde von Besuchern.

Trotzdem ist genau das ein ernstzunehmender Schaden. Das kleine Symbol links vom Suchergebnis ist auf mobilen Geräten das erste, was ein Nutzer von einer Marke sieht – und es ist ein Vertrauenssignal. Der Kunde, ein Betreiber aus dem medizinischen Bereich, schätzte den Klickratenverlust auf fünf bis acht Prozent. Bei einer Seite, die den Grossteil ihrer Besucher über die organische Suche gewinnt, ist das kein kosmetisches Problem.

Dieser Artikel beschreibt, wie wir die Ursache gefunden haben – und warum sie fast nie dort liegt, wo man sie zuerst vermutet: beim Favicon selbst.

Die Herausforderung

Der erste Verdacht des Kunden war naheliegend: In den strukturierten Daten der Seite war ein Logo hinterlegt, das sich als Favicon offensichtlich nicht eignet – ein breites Wortmarken-Logo im Format 300 × 80 Pixel. „Kannst Du das mal testweise entfernen?” Die Datei fand er auf dem Server nicht, weil moderne TYPO3-Installationen Erweiterungs-Assets unter einem generierten Pfad veröffentlichen und nicht mehr dort liegen, wo man sie vor Jahren gesucht hätte.

Das eigentliche Problem an dieser Fehlerklasse ist ein anderes: Google erklärt nicht, warum es ein Symbol nicht anzeigt. Es gibt keine Fehlermeldung, kein Protokoll, kein Prüfwerkzeug, das „Icon abgelehnt, Grund X” ausgibt. Man sieht nur das Ergebnis – und muss von dort rückwärts arbeiten.

Hilfreich ist deshalb ein Blick darauf, was Google in der Trefferliste überhaupt zusammensetzt. Die Zeile über dem eigentlichen Suchergebnis besteht aus drei Bestandteilen, die aus unterschiedlichen Quellen stammen:

• Das Website-Symbol – vorrangig aus dem <link rel="icon"> im Quelltext, ersatzweise aus /favicon.ico im Web-Root.
• Der Website-Name – aus den strukturierten Daten, den Open-Graph-Angaben und dem Titel der Startseite.
• Die Attribution, also die Herkunftszeile – hier wertet Google unter anderem das Organisationslogo aus den strukturierten Daten (publisher.logo) aus.

Diese drei Quellen sind nicht sauber getrennt. Wer ein Logo in den strukturierten Daten ausliefert, das den Anforderungen nicht genügt, kann damit auch die Symbolauswahl beeinflussen – und genau das war hier passiert.

Unsere Lösung

1. Systematisch ausschliessen statt raten

Bevor man an Ursachen glaubt, muss man alles ausschliessen, was ein Favicon trivial zerstört. Wir haben jede dieser Möglichkeiten einzeln gegen das Produktivsystem geprüft:

Diese Tabelle ist der eigentliche Kern der Arbeit. Sechs Prüfungen, sechs unauffällige Ergebnisse – und damit die Gewissheit, dass die Ursache nicht in der Auslieferung, sondern in den Angaben liegt.

2. Die eigentliche Ursache: ein Logo unterhalb der Mindestgrösse

Das in den strukturierten Daten hinterlegte Organisationslogo war 300 × 80 Pixel gross. Google verlangt für dieses Feld ein quadratisches Bild von mindestens 112 × 112 Pixel. Das ausgelieferte Wortmarken-Logo war weder quadratisch noch hoch genug – es erfüllte die Vorgabe also gleich zweifach nicht.

Interessant wurde es beim zeitlichen Zusammenhang. Der Kunde datierte das Verschwinden auf Mitte Juli. Ein Blick in die Release-Historie zeigte: Rund neun Tage vorher war ein Deployment ausgeliefert worden, das einen alten, ins Leere laufenden Asset-Pfad korrigiert hatte. Vorher lieferte die Logo-Adresse aus den strukturierten Daten einen 404 – Google konnte sie also gar nicht auswerten und fiel auf das verlinkte Favicon zurück. Seit diesem Deployment war das Logo abrufbar, und Google hatte plötzlich ein zwar erreichbares, aber nicht regelkonformes Bild in der Hand. Der Abstand von neun Tagen entspricht exakt dem üblichen Zeitversatz, bis Google eine Seite erneut besucht.

Das ist die unangenehmste Variante eines solchen Fehlers: Eine Korrektur hat ein Folgeproblem sichtbar gemacht, das vorher durch einen anderen Defekt verdeckt war. Wer nur die Änderungen der letzten Tage vor dem Symptom durchsieht, findet die Ursache nicht.

3. Zweite Schwachstelle: ein 16-Pixel-Icon und ein leerer Fallback-Pfad

Parallel dazu fanden wir zwei weitere Schwachpunkte, die für sich genommen nicht der Auslöser waren, die Lage aber verschlechterten:

• Das verlinkte Favicon war eine 16 × 16 Pixel grosse Datei mit 318 Byte – technisch zulässig, aber weit unterhalb der von Google empfohlenen 48 Pixel. Wenn Google zwischen mehreren Kandidaten wählen muss, ist ein derart kleines Icon der schwächste davon.
• Unter der klassischen Fallback-Adresse /favicon.ico im Web-Root lag überhaupt nichts. Der seit Jahrzehnten etablierte Ersatzpfad lief ins Leere.

Die Ursache für den fehlenden Fallback war aufschlussreich: Das Container-Image der Anwendung kopierte beim Bauen zwar den Quellcode, nicht aber die statischen Dateien aus dem öffentlichen Verzeichnis – dieses Verzeichnis wird beim Bauen neu erzeugt. Sowohl /favicon.ico als auch die robots.txt waren im Repository korrekt gepflegt und landeten trotzdem nie im ausgelieferten Container. Ein Fehler, den man in keinem Quelltext sieht, sondern nur, indem man das Ergebnis abruft.

4. Der Randfund: eine Seitenadresse, die es nicht gibt

Beim Durchsehen der strukturierten Daten fiel ein weiterer Defekt derselben Fehlerklasse auf. Die Seitenadresse im JSON-LD wurde aus der Basis-URL und dem Seitenpfad zusammengesetzt. Für die Startseite ist dieser Pfad schlicht „/” – heraus kam eine Adresse mit doppeltem Trenner, die einen Fehlercode zurücklieferte statt der eigentlichen kanonischen Startseiten-URL.

Für Google heisst das: Die Seite gibt in ihren eigenen strukturierten Daten eine Adresse an, die nicht existiert. Das schwächt jedes Signal, das an dieser Adresse hängt – und niemand bemerkt es, weil kein Besucher diese URL je aufruft. Unterseiten waren nicht betroffen, weil dort ein echter Pfad vorhanden ist.

5. Die Korrekturen

Umgesetzt haben wir vier Änderungen:

1. Quadratisches Organisationslogo. Ein 512 × 512 Pixel grosses Logo, abgeleitet aus einer bereits vorhandenen quadratischen Vorlage, ersetzt das Wortmarken-Logo im Feld publisher.logo. Wichtig dabei: Wir haben das Artikelbild von diesem Logo entkoppelt. Vorher speiste eine einzige Pfadangabe beide Felder – das Artikelbild darf durchaus die breite Wortmarke sein, das Herausgeberlogo muss quadratisch sein.
2. Favicon in mehreren Auflösungen. Die Icon-Datei enthält jetzt die Grössen 16, 32, 48, 96 und 192 Pixel. Das Aussehen bleibt identisch, und – wichtig – der Dateiname und damit die URL blieben unverändert, damit keine bestehende Verlinkung bricht.
3. Web-Root aufgeräumt. /favicon.ico und eine echte robots.txt inklusive Verweis auf die Sitemap werden jetzt tatsächlich ausgeliefert. Das Root-Icon wird dabei aus derselben Quelldatei kopiert wie das verlinkte – eine Datei, kein Auseinanderdriften.
4. Startseiten-URL im JSON-LD korrigiert, sodass sie mit der kanonischen Adresse übereinstimmt und einen 200er liefert.

6. Gegen Rückfälle absichern

Solche Defekte schleichen sich lautlos wieder ein – beim nächsten Logo-Austausch, beim nächsten Redesign. Deshalb sichern automatisierte Tests die Anforderungen jetzt fest ab: Ein Test liest das Inhaltsverzeichnis der Icon-Datei aus und besteht nur, wenn mindestens ein quadratischer Eintrag mit 48 Pixel oder mehr enthalten ist. Ein zweiter prüft, dass das hinterlegte Organisationslogo quadratisch und mindestens 112 Pixel gross ist.

Damit schlägt ein Rückschritt künftig in der Continuous Integration fehl – und nicht erst Wochen später, unbemerkt, im Google-Index.

Das Ergebnis

Vier Tage nach dem Release kam die Rückmeldung des Kunden: „Ist wieder in den SERPs, danke!”

Diese vier Tage sind der Teil, der beim Erwartungsmanagement am meisten Aufmerksamkeit braucht. Änderungen am Website-Symbol wirken nicht sofort. Google übernimmt sie erst beim nächsten eigenen Besuch der Seite, und dieser Zeitpunkt lässt sich nicht erzwingen – man kann eine erneute Indexierung der Startseite in der Search Console anstossen und danach warten. Wer am Tag nach dem Deployment nachsieht und nichts erkennt, zieht sonst den falschen Schluss und beginnt, an einer bereits korrekten Lösung weiterzuschrauben.

Nachgelagert bestätigt hat sich auf dem Produktivsystem: das quadratische Logo für den Googlebot abrufbar, das Icon unter unveränderter Adresse in hoher Auflösung, /favicon.ico und /robots.txt erreichbar, und die Startseiten-URL in den strukturierten Daten identisch mit der kanonischen Adresse.

Zwei ehrliche Einschränkungen gehören dazu:

• Ohne Vektorvorlage gibt es Grenzen. Für dieses Logo existierte keine Vektordatei mehr, die grösseren Icon-Grössen mussten aus der 16-Pixel-Variante hochgerechnet werden. Das funktionierte hier nur deshalb sauber, weil die Grafik ausschliesslich aus geraden Kanten besteht. Bei Rundungen, Farbverläufen oder weichen Kanten wäre das Ergebnis sichtbar unscharf geworden. Wir haben deshalb um die Originaldateien gebeten – eine Bitte, die sich für jede Marke lohnt, bevor sie gebraucht wird.
• Der Browser-Tab hinkt hinterher. Weil die Icon-Adresse bewusst unverändert blieb, behalten wiederkehrende Besucher das alte Symbol im Tab, bis ihr Browser-Cache abläuft. Ein bewusst eingegangener Kompromiss – Google ist davon nicht betroffen.

Dass es sich um ein Muster und nicht um einen Einzelfall handelt, zeigte sich kurz darauf in einem völlig anderen Projekt: Auf der von uns betreuten Weinplattform VINUM tauchten in der automatisierten Auswertung der Produktions-Logs rund 250 fehlgeschlagene Zugriffe pro Woche auf /favicon.ico und weitere rund 95 auf das iOS-Symbol apple-touch-icon.png auf – exakt dieselben fehlenden Fallback-Pfade im Web-Root, nur dass sie sich dort als Log-Rauschen bemerkbar machten statt als verschwundenes Symbol. Auch hier war die Ursache dieselbe Lücke im Bau des Container-Images.

Die Checkliste zum Mitnehmen

Wer prüfen will, ob die eigene Website in dieser Hinsicht sauber aufgestellt ist, kommt mit fünf Punkten sehr weit:

1. Organisationslogo in den strukturierten Daten: quadratisch, mindestens 112 Pixel Kantenlänge – besser 512.
2. Verlinktes Favicon: quadratisch, mindestens 48 Pixel. Ein 16-Pixel-Icon aus den Nullerjahren reicht heute nicht mehr.
3. /favicon.ico im Web-Root: muss erreichbar sein, auch wenn im Quelltext ein anderer Pfad verlinkt ist. Dasselbe gilt für apple-touch-icon.png.
4. Gültige robots.txt mit echtem Inhalt und einem Verweis auf die Sitemap – eine leere oder fehlende Datei ist kein Ersatz.
5. Adressen in den strukturierten Daten müssen mit der kanonischen Adresse übereinstimmen und einen 200er liefern – gerade auf der Startseite, wo Pfadlogik gern Sonderfälle produziert.

Und der wichtigste Punkt überhaupt: Prüfen Sie das nicht nur im Quelltext, sondern rufen Sie die Adressen tatsächlich ab. Die drei gravierendsten Befunde in diesem Fall waren im Repository korrekt gepflegt und trotzdem im Live-Betrieb nicht vorhanden.

Fazit

Ein verschwundenes Favicon ist kein Grafikproblem. Es ist ein Symptom dafür, dass die Signale, die eine Website über sich selbst aussendet, nicht mehr zusammenpassen – und diese Signale liegen heute in strukturierten Daten, in Auslieferungspfaden und in Build-Prozessen, nicht in einer Bilddatei. Solche Schäden melden sich nicht: kein Fehler im Monitoring, keine Beschwerde, nur langsam sinkende Klickzahlen.

Sie vermuten, dass Ihre Website Sichtbarkeit verliert, ohne dass irgendetwas offensichtlich kaputt ist? Sprechen Sie uns an – wir sehen uns Ihre Suchdarstellung und die technischen Signale dahinter systematisch an und sagen Ihnen, woran es liegt.