Favicon und Websitename in der Google-Suche

Wenn in den Google-Suchergebnissen neben dem eigenen Seitentitel ein falsches oder generisches Symbol auftaucht, oder wenn statt des eigentlichen Markennamens nur die nackte Domain zu sehen ist, liegt das fast immer an denselben, gut behebbaren Ursachen: Das Favicon erfüllt Googles technische Mindestanforderungen nicht, es ist für den Crawler gar nicht erreichbar, oder die Signale, aus denen Google den Websitenamen ableitet, widersprechen sich.

Beides, das kleine Icon und der Name neben der URL, sind Teil dessen, was Google als Website-Identität in den Ergebnissen zusammensetzt. Beide Elemente werden unabhängig von Rankingfaktoren verarbeitet, folgen aber klaren technischen Regeln. Dieser Artikel geht beide Fälle einzeln durch: was Google technisch verlangt, woran die Anzeige typischerweise scheitert und wie lange eine Korrektur braucht, bis sie sichtbar wird.

Warum Google ein falsches oder gar kein Favicon anzeigt

Bevor an Feinheiten wie Bildgröße gedacht wird, lohnt sich der Blick auf die banalsten Ursachen, denn sie erklären die meisten Fälle in der Praxis.

Der häufigste Grund ist schlicht, dass Google die Datei noch nicht neu verarbeitet hat. Eine neue Domain oder ein frisch getauschtes Icon braucht einen erneuten Crawl-Durchlauf, bevor die Änderung überhaupt im Suchindex ankommt. Bis dahin zeigt Google entweder gar kein Icon, ein generisches Platzhaltersymbol, oder die zuletzt bekannte, ältere Version.

Der zweitwichtigste Grund ist eine Blockade durch robots.txt. Viele Projekte blockieren pauschal ganze Verzeichnisse wie /assets/ oder /static/, ohne zu bedenken, dass genau dort auch die Icon-Datei liegt. Ist die Ressource für den Crawler gesperrt, kann Google sie nicht abrufen und zeigt folgerichtig nichts an, selbst wenn die Datei im Browser einwandfrei lädt, weil der Browser sie direkt vom Server holt und robots.txt dabei ignoriert.

Ein dritter, seltener beachteter Grund ist ein instabiler HTTP-Status. Liefert die Icon-URL zeitweise einen Serverfehler, eine lange Weiterleitungskette, oder verlangt sie eine Anmeldung, wertet Google sie als nicht zuverlässig abrufbar und fällt auf ein Standardsymbol zurück, statt eine unsichere Ressource dauerhaft zu cachen.

Diese technischen Anforderungen muss das Favicon erfüllen

Google dokumentiert für die Anzeige in der Suche eigene, von den klassischen Browser-Konventionen leicht abweichende Vorgaben. Wer nur ein altes 16x16-Pixel-ICO aus Zeiten der Favicon-Frühzeit einbindet, erfüllt sie in der Regel nicht mehr.

Als Format akzeptiert Google gängige Bildformate wie ICO, PNG, WebP oder SVG. Entscheidend ist weniger das Format selbst als die Auffindbarkeit und die Größe der Datei.

Bei der Größe gilt: Das Bild sollte quadratisch sein, und Google empfiehlt eine Kantenlänge, die ein Vielfaches von 48 Pixeln ist, damit das Icon auch bei höherer Bildschirmauflösung nicht verwaschen wirkt. Ein zu kleines Icon, etwa nur 16x16 Pixel, wird zwar von manchen Browsern im Tab akzeptiert, in der Google-Suche jedoch häufig gar nicht erst berücksichtigt.

Referenziert wird das Icon entweder explizit über ein Link-Element im HTML-Kopf mit dem Attribut rel="icon", oder implizit über die Standardablage unter /favicon.ico im Wurzelverzeichnis der Domain, falls kein Link-Element vorhanden ist. Fehlt beides, oder verweist das Link-Element auf eine nicht existierende Datei, bleibt Google nur der Rückgriff auf das Standardverzeichnis, und schlägt dieser Rückgriff fehl, erscheint gar kein Icon.

Wichtig ist außerdem die Stabilität der URL. Google cacht das Favicon anhand seiner URL. Wird die URL bei jedem Deployment durch einen wechselnden Versionsparameter verändert, etwa favicon.png?v=482, sieht Google bei jedem Crawl technisch eine neue, unbekannte Ressource, was die Auslieferung eines konsistenten Icons erschwert, statt sie zu beschleunigen. Eine stabile Adresse, die nur bei einer tatsächlichen Änderung des Bildes einmalig aktualisiert wird, ist verlässlicher.

Schließlich muss die Ressource ohne Weiterleitungskette, mit dem Statuscode 200 und über dasselbe Protokoll wie die Seite selbst erreichbar sein: Läuft die Website unter https, aber das Icon liegt weiterhin unter einer http-Adresse, wird der Abruf durch gemischte Inhalte in vielen Konfigurationen blockiert oder als unsicher eingestuft.

Ebenfalls relevant ist die Herkunft der Ressource. Liegt das Icon auf einer separaten Auslieferungsdomain, etwa einem CDN mit eigenem Hostnamen, muss dieser Host für den Crawler ebenso frei zugänglich sein wie die eigentliche Website. Eine robots.txt auf der CDN-Domain, die dort pauschal alles blockiert, wirkt sich genauso aus wie eine Blockade im Hauptverzeichnis der Website selbst, wird aber leicht übersehen, weil sie an einer anderen Stelle liegt als die robots.txt, die man üblicherweise prüft. In seltenen Fällen setzt ein Server außerdem einen X-Robots-Tag-Header direkt auf die Bilddatei, der eine Indexierung dieser einzelnen Ressource untersagt, ohne dass irgendetwas davon im sichtbaren HTML oder in der robots.txt zu erkennen wäre; ein Blick in die tatsächlichen Antwort-Header der Icon-URL deckt das zuverlässig auf.

Warum Google einen anderen Websitenamen als erwartet anzeigt

Der Name, der in der Suche neben der URL oder unter dem Titel erscheint, wird nicht aus einer einzelnen Quelle gelesen, sondern aus mehreren Signalen zusammengesetzt, die im Idealfall übereinstimmen. Widersprechen sie sich, entscheidet Google nach eigenem Ermessen, welchem Signal vertraut wird, und im ungünstigsten Fall lautet die Entscheidung schlicht die reine Domain.

Die häufigste Ursache ist Inkonsistenz: Der Titel-Tag der Startseite nennt einen Markennamen, das strukturierte Markup einen anderen, und die Meta-Angabe für den Website-Namen einen dritten. Für einen Algorithmus, der zwischen konkurrierenden Signalen wählen muss, ist die naheliegendste, konfliktfreie Lösung, einfach den Domainnamen zu verwenden, weil dieser eindeutig und nicht interpretationsbedürftig ist.

Eine zweite Ursache ist schlicht fehlende Historie. Eine sehr junge Domain hat noch nicht genug Crawl-Zyklen durchlaufen, um Google ausreichendes Vertrauen in einen bestimmten Markennamen aufbauen zu lassen, weshalb übergangsweise die Domain angezeigt wird.

Eine dritte, oft übersehene Ursache betrifft Subdomains und Ländervarianten. Wenn de.beispiel.com und www.beispiel.com unterschiedliche Namen oder unterschiedliches Markup ausgeben, behandelt Google sie unter Umständen als eigenständige Einheiten mit eigenen, sich widersprechenden Namenssignalen, statt als eine zusammenhängende Marke.

Wie der Websitename technisch gesteuert wird

Um dem Algorithmus ein möglichst eindeutiges Signal zu liefern, gibt es drei zusammenwirkende Stellschrauben, die alle auf denselben Namen zeigen sollten.

Die erste ist strukturiertes Daten-Markup vom Typ WebSite, in dem die Eigenschaft "name" den offiziellen Namen der Website trägt. Ergänzend erlaubt dieser Typ die Eigenschaft "alternateName" für eine gebräuchliche Kurzform oder Abkürzung, wenn der offizielle Name lang oder sperrig ist, etwa wenn eine ausgeschriebene Rechtsform als offizieller Name dient, im Alltag aber eine kürzere, bekanntere Bezeichnung verwendet wird. Beide Felder zusammen geben Google die Wahl zwischen der formalen und der gebräuchlichen Variante, statt nur eine starre Möglichkeit vorzugeben.

Die zweite Stellschraube ist der Titel-Tag der Startseite selbst. Er sollte den gewünschten Markennamen enthalten, idealerweise an einer erkennbaren, wiederkehrenden Position, etwa am Satzende nach einem Trennzeichen. Wechselt der Markenname im Titel-Tag von Unterseite zu Unterseite, verwässert das die Konsistenz, aus der Google eine feste Marke ableiten könnte.

Die dritte Stellschraube ist das Meta-Tag og:site_name, ursprünglich für die Vorschau in sozialen Netzwerken gedacht, das aber ebenfalls als Signal für den Website-Namen mit einbezogen wird. Nennt dieses Tag einen anderen Namen als das WebSite-Markup, entsteht erneut ein Widerspruch, den Google auflösen muss, meist zulasten der Klarheit der Anzeige.

Entscheidend ist, dass diese drei Quellen denselben Namen tragen. Ein einzelnes starkes Signal überzeugt selten so gut wie drei übereinstimmende schwächere Signale.

Wie lange es dauert, bis eine Korrektur sichtbar wird

Für keinen der beiden Fälle, weder Favicon noch Websitename, gibt es eine von Google zugesicherte Frist. Beide hängen von einem erneuten Crawl der betroffenen Seiten sowie einer separaten Verarbeitung dieser speziellen Signale ab, die nicht mit der gewöhnlichen Indexierung einer Seite gleichzusetzen ist.

In der Praxis vergehen zwischen einer Korrektur und der sichtbaren Änderung in der Suche typischerweise mehrere Tage bis mehrere Wochen. Wird über die Search Console eine Indexierung für die Startseite angefordert, beschleunigt das zwar häufig den nächsten Crawl dieser einen Seite, garantiert aber nicht, dass Favicon oder Name im selben Zug aktualisiert werden, da diese Elemente über eigene, vom Seiteninhalt getrennte Verarbeitungsschritte laufen.

Wer die Änderung mehrfach wiederholt, etwa das Icon innerhalb kurzer Zeit erneut austauscht, weil die erste Anpassung noch nicht sichtbar ist, verlängert die Unsicherheit eher, als sie zu verkürzen: Jede neue Version beginnt den Beobachtungszyklus erneut. Geduld und eine einmalige, korrekte Umsetzung führen zuverlässiger zum Ziel als wiederholtes Nachjustieren.

Mobile und Desktop-Suche zeigen die Website-Identität unterschiedlich

Ein Icon, das auf dem Smartphone neben dem Websitenamen erscheint, ist in der Desktop-Suche nicht automatisch genauso präsent, und umgekehrt gilt dasselbe. Google hat die Anzeige von Favicon und Websitename ursprünglich eingeführt, um mobile Suchergebnisse stärker wie eine vertraute App- oder Browser-Oberfläche wirken zu lassen, bei der Nutzer Symbole zum schnellen Wiedererkennen gewohnt sind. Auf dem Desktop wirkt dasselbe Element eher wie eine ergänzende Randinformation neben dem klassischen blauen Titel.

Diese unterschiedliche Gewichtung bedeutet in der Praxis, dass eine Kontrolle nur auf einem Gerät ein unvollständiges Bild liefert. Wer feststellt, dass das Icon auf dem Smartphone korrekt erscheint, sollte trotzdem separat auf dem Desktop nachsehen, und umgekehrt, bevor eine Änderung vorschnell als endgültig fehlgeschlagen gilt. Zusätzlich zeigen bestimmte Ergebnistypen, etwa Rich-Ergebnisse oder Ergebnisse mit zusätzlichen Bildvorschauen, die Website-Identität an anderer Position oder mit anderer Größe als ein gewöhnliches Textergebnis, was beim Vergleich zwischen zwei Suchanfragen leicht zu Verwirrung darüber führt, ob sich tatsächlich etwas verändert hat.

Fehlerdiagnose: eine Schritt-für-Schritt-Checkliste

Bevor eine Änderung als fehlgeschlagen gilt, lohnt sich eine systematische Prüfung, denn die Ursache liegt fast immer in einem der folgenden Punkte:

• Die Icon-URL direkt im Browser aufrufen und prüfen, ob sie lädt, ohne Anmeldung verlangt und tatsächlich ein Bild zurückgibt.
• Die robots.txt der Domain öffnen und nachsehen, ob ein Disallow-Eintrag versehentlich den Pfad des Icons oder ein übergeordnetes Verzeichnis erfasst.
• Den HTTP-Statuscode der Icon-URL mit einem einfachen Werkzeug prüfen, um sicherzugehen, dass kein Fehler, keine Weiterleitungskette und kein wechselnder Versionsparameter vorliegt.
• Größe und Format der Datei kontrollieren: quadratisch, mindestens in einem Vielfachen von 48 Pixeln, in einem von Google unterstützten Format.
• Das Link-Element im HTML-Kopf mit rel="icon" auf Vorhandensein und korrekten Pfad prüfen, insbesondere wenn es erst per JavaScript nachträglich eingefügt wird, denn dann kann es beim ersten Abruf des Crawlers fehlen.
• Titel-Tag, WebSite-Markup und og:site_name auf denselben Markennamen prüfen und Abweichungen vereinheitlichen.
• Nach der Korrektur einige Wochen abwarten und die Anzeige in der Suche periodisch, aber nicht täglich, kontrollieren.

Häufige Fehler, die die Anzeige verhindern

Neben den bereits genannten Grundursachen tauchen in der Praxis einige wiederkehrende Stolperfallen auf, die für sich genommen unauffällig wirken, aber die Anzeige zuverlässig verhindern.

Ein nicht quadratisches Icon wird von Google in der Regel verworfen, statt es zurechtgeschnitten anzuzeigen, weshalb ein rechteckiges Logo immer in eine quadratische Fläche eingepasst werden muss, notfalls mit Rand.

Ein Icon, das ausschließlich als Teil einer Web-App-Manifest-Datei für Startbildschirm-Symbole definiert ist, aber nirgends direkt im HTML-Kopf als rel="icon" verlinkt wird, wird von der klassischen Suchindexierung häufig übersehen, weil diese das Manifest nicht auf dieselbe Weise ausliest wie eine mobile App-Installation.

Unterschiedliche Favicons je Sprachversion oder Subdomain, die eigentlich zur selben Marke gehören, erzeugen für Google widersprüchliche Signale darüber, welches Icon zur Marke gehört, was die Anzeige insgesamt unzuverlässiger macht, statt sie zu verbessern.

Ein Favicon, das per JavaScript erst nach dem ersten Laden der Seite in den HTML-Kopf eingefügt wird, steht dem Crawler beim ersten, entscheidenden Abruf oft noch nicht zur Verfügung, selbst wenn es im Browser für menschliche Besucher normal sichtbar ist.

Und schließlich: ein Icon, das als Data-URI direkt im HTML eingebettet ist, statt als eigene, referenzierbare Datei vorzuliegen, lässt sich von Google technisch schwerer als stabile, zwischenspeicherbare Ressource behandeln als eine gewöhnliche Bilddatei mit fester Adresse.

Ein weiterer, leicht übersehener Fehler betrifft transparente PNG-Dateien mit viel Leerraum um das eigentliche Motiv. Technisch ist die Datei quadratisch, doch das sichtbare Logo darin nimmt nur einen kleinen mittigen Bereich ein. In der winzigen Darstellungsgröße der Suchergebnisse schrumpft dieses ohnehin kleine Motiv weiter, bis es kaum noch erkennbar ist, während ein Icon, das die quadratische Fläche bewusst ausfüllt, bei gleicher Dateigröße deutlich lesbarer bleibt.

Bei international ausgerichteten Websites mit mehreren länderspezifischen Domains oder Verzeichnissen kommt gelegentlich ein weiterer Fall hinzu: Wird für jede Sprachversion versehentlich ein eigenes, leicht abweichendes Icon ausgeliefert, obwohl es sich inhaltlich um dieselbe Marke handelt, entstehen dieselben widersprüchlichen Signale wie bei unterschiedlichen Websitenamen je Subdomain. Nur wenn bewusst unterschiedliche Marken oder Tochterlabels hinter den einzelnen Länderversionen stehen, ist ein eigenes Icon pro Domain tatsächlich korrekt; bei einer einzigen, länderübergreifenden Marke sollte dieselbe Bilddatei überall eingebunden werden.