Favicon et nom du site dans les résultats Google

Quand un favicon n'apparaît pas dans les résultats Google, qu'une icône générique s'affiche à la place, ou que le nom du site est erroné, tronqué ou remplacé par le nom de domaine brut, ce n'est presque jamais un problème de classement : c'est un problème de configuration technique que Google traite séparément du reste du référencement. Deux mécanismes indépendants sont en cause, l'un pour l'icône, l'autre pour le nom de site, et chacun répond à ses propres exigences, avec ses propres délais et ses propres points de blocage.

Ce guide traite ces deux points un par un : les critères techniques qu'un favicon doit remplir pour être repris par Google, les raisons les plus courantes pour lesquelles il ne l'est pas, la manière dont Google détermine le nom de site à afficher, et les données structurées qui permettent de l'orienter. Aucun de ces réglages n'améliore le positionnement, mais un favicon absent ou un nom de site incohérent dégrade la confiance perçue et, en bout de chaîne, le taux de clic.

Comment Google choisit le favicon affiché

Pour qu'une icône apparaisse à côté d'un résultat, Google doit d'abord pouvoir la trouver, puis la juger conforme à ses critères. Deux méthodes permettent de la déclarer : la placer à l'emplacement par défaut, à la racine du domaine sous forme de fichier favicon.ico, ou la référencer explicitement dans le head de la page d'accueil au moyen d'une balise link rel="icon". La seconde méthode est préférable, car elle fonctionne même si le fichier n'est pas à la racine et permet de fournir plusieurs tailles pour différents contextes d'affichage.

L'image doit être carrée. Google recommande une taille d'au moins 48 par 48 pixels, idéalement un multiple de 48 (96x96, 144x144), pour rester nette sur les écrans à forte densité de pixels. Les formats les plus anciens et les plus largement reconnus, comme ICO, PNG, GIF ou JPEG, restent le choix le plus sûr : certains formats d'image plus récents ne sont pas toujours pris en charge pour cet usage précis, même s'ils s'affichent normalement dans un navigateur, ce qui est un piège fréquent pour les sites ayant converti l'ensemble de leurs images vers un format plus léger.

• L'image doit rester visuellement stable dans le temps ; changer de favicon trop souvent retarde sa prise en compte par Google.
• Elle doit représenter le site ou la marque, pas une image générique ou un caractère isolé difficile à distinguer en petite taille.
• Elle doit être accessible sans redirection multiple ni erreur HTTP, et sans blocage par robots.txt.

Le robots.txt, cause fréquente d'un favicon absent

La cause la plus banale d'un favicon absent dans les résultats n'est pas le fichier lui-même mais son accessibilité. Beaucoup de fichiers robots.txt contiennent des règles larges héritées d'un CMS, comme un Disallow sur tout un dossier d'assets ou sur un répertoire d'icônes généré automatiquement, qui bloquent sans le vouloir le chemin exact du favicon. Google ne devine pas le contenu d'une ressource qu'il n'a pas le droit d'explorer : si le fichier est disallow, l'icône ne sera tout simplement jamais reprise, quelle que soit sa qualité par ailleurs.

Vérifier ce point est rapide : ouvrir le fichier robots.txt du domaine, repérer les règles Disallow, et comparer leur portée avec l'URL exacte du favicon, celle indiquée dans la balise link ou l'emplacement par défaut. Un test manuel, en chargeant l'URL du favicon directement dans un navigateur en navigation privée, confirme aussi qu'elle répond avec un code 200 et le bon type de contenu, plutôt qu'une redirection vers une page de connexion ou une erreur 404 renvoyée silencieusement par certains pare-feux applicatifs.

• Une règle Disallow portant sur un dossier entier est plus risquée qu'une règle ciblée sur un fichier précis.
• Un favicon servi depuis un CDN ou un sous-domaine séparé doit être vérifié à part : le robots.txt du domaine principal ne protège pas cette ressource, mais celui du CDN peut la bloquer de son côté.

D'où vient le nom de site affiché par Google

Sur mobile, et de plus en plus sur desktop, Google remplace l'URL brute d'un résultat par un nom de site plus lisible, affiché au-dessus du titre à côté du favicon. Ce nom n'est pas toujours celui attendu : Google peut afficher le nom de domaine sans extension, une ancienne raison sociale, ou une variante orthographique différente de celle utilisée dans la communication de la marque.

Google construit ce nom automatiquement à partir de plusieurs sources combinées, sans qu'aucune ne soit décrite comme prioritaire à elle seule : les données structurées de type WebSite présentes sur la page d'accueil, le contenu de la balise title de cette même page, et plus largement la façon dont d'autres sites et pages font référence au vôtre. Quand ces sources se contredisent, par exemple un nom dans le title, un autre sur le logo, un troisième dans des liens externes anciens, Google tranche selon son propre traitement, et le résultat peut surprendre.

Les données structurées WebSite et Organization

Le signal le plus direct que l'on puisse fournir est un balisage JSON-LD de type WebSite sur la page d'accueil, avec un champ name correspondant exactement au nom que l'on souhaite voir apparaître, et un champ url pointant vers l'adresse canonique de cette même page. Ce balisage doit être présent sur la page d'accueil du domaine racine ou du sous-domaine concerné, www ou non selon la version canonique retenue, et pas seulement sur des pages internes.

Un balisage Organization complémentaire, avec le même champ name et une propriété logo pointant vers une image carrée de bonne résolution, renforce la cohérence de l'ensemble sans garantir à lui seul l'affichage du nom : il agit comme signal de cohérence de marque plutôt que comme commande directe. Une fois ce balisage en place, un outil de validation des données structurées permet de vérifier qu'il est syntaxiquement correct et bien détecté, ce qui reste une étape distincte de son adoption effective par Google dans les résultats de recherche.

Le cas des sites qui hébergent plusieurs marques sous un même nom de domaine, comme une marketplace ou un groupe de médias, mérite une attention particulière : si chaque marque interne dispose de sa propre page d'accueil logique, seule celle du domaine racine porte en général le balisage WebSite consulté pour le nom global, et les tentatives de dupliquer ce balisage sur des sous-sections avec des noms différents produisent des signaux contradictoires plutôt qu'une personnalisation utile.

Un contrôle minimal du balisage de la page d'accueil se résume à ces deux blocs :

• "@type" : "WebSite", avec "name" pour le nom exact voulu et "url" pour l'adresse canonique de la page.
• "@type" : "Organization", avec le même "name" et un champ "logo" pointant vers une image carrée de bonne résolution.

Aligner les signaux de marque sur la page d'accueil

Au-delà des données structurées, Google recoupe ce qu'il lit avec le reste de la page. Un title de page d'accueil qui commence par une formule marketing longue plutôt que par le nom de marque, une balise og:site_name absente ou différente, un logo dans l'en-tête sans texte alternatif cohérent : chacun de ces détails est un signal faible, mais leur accumulation dans une direction homogène augmente la probabilité que Google retienne la bonne forme du nom.

• Faire commencer le title de la page d'accueil par le nom de marque exact, plutôt que de le placer en fin de chaîne.
• Renseigner og:site_name avec la même valeur que le champ name du balisage WebSite ; Google ne cite pas explicitement cette balise comme source pour cette fonctionnalité, mais d'autres plateformes s'en servent, et la cohérence ne coûte rien.
• Utiliser la même graphie partout, majuscules, espacement, présence ou non d'un article : "MaMarque", "Ma Marque" et "MAMARQUE" sont trois signaux différents aux yeux d'un système qui recoupe du texte.
• Éviter de faire figurer la raison sociale légale complète, forme juridique incluse, là où le nom commercial est attendu.

Comment vérifier ce que Google affiche réellement

Avant de corriger quoi que ce soit, il est utile de constater précisément ce que Google affiche aujourd'hui, plutôt que de se fier à un souvenir ou à une capture d'écran ancienne. Une recherche du nom de la marque, effectuée depuis un navigateur non connecté au compte du site pour éviter les biais de personnalisation, montre le favicon et le nom de site tels qu'ils apparaissent réellement pour un internaute neutre, sur mobile comme sur desktop, car les deux surfaces peuvent diverger légèrement l'une de l'autre pendant une période de transition.

• Comparer le favicon affiché dans les résultats avec celui visible dans l'onglet du navigateur sur le site lui-même : un écart confirme que Google utilise une ressource différente de celle vue par un visiteur ordinaire.
• Vérifier le rendu sur plusieurs appareils si possible, car Google peut avoir mis à jour l'affichage sur mobile avant de le généraliser sur desktop, ou inversement selon les déploiements.
• Noter la date de la dernière modification du favicon ou du balisage avant de conclure à un échec : un changement vieux de quelques jours seulement n'a souvent simplement pas encore été repris par l'exploration.

Le délai de mise à jour de Google : pourquoi rien ne change tout de suite

Corriger le balisage ou débloquer le favicon dans le robots.txt ne produit aucun effet immédiat. Google doit recrawler la page concernée, retraiter les signaux, puis mettre à jour l'affichage mis en cache dans son index, un enchaînement qui prend généralement plusieurs jours, parfois plusieurs semaines pour un domaine peu crawlé. Un ancien favicon peut ainsi continuer à s'afficher un moment après correction, ce qui n'indique pas un échec de la correction elle-même.

Demander une nouvelle exploration de la page d'accueil via l'outil d'inspection d'URL peut légèrement accélérer le recrawl, sans garantir un délai précis ni une file d'attente prioritaire. La bonne pratique reste de corriger une fois, correctement, puis de vérifier périodiquement le rendu réel dans les résultats, plutôt que de multiplier les changements de favicon ou de balisage en attendant un effet visible, ce qui retarde souvent la stabilisation du signal plutôt que de l'accélérer.

Erreurs fréquentes qui cassent le favicon ou le nom de site

La plupart des cas problématiques se ramènent à une poignée de causes récurrentes, souvent invisibles tant qu'on ne les cherche pas spécifiquement.

• Un favicon enregistré dans un format d'image récent, pas toujours reconnu pour cet usage précis même s'il s'affiche très bien dans le navigateur, ce qui masque le problème lors d'une vérification visuelle rapide.
• Une balise link rel="icon" absente de la page d'accueil, alors que le favicon.ico par défaut à la racine, lui, est bloqué ou inexistant.
• Un manifeste d'application (manifest.json) qui définit des icônes pour l'installation, sans balise link rel="icon" classique en secours, une configuration valide pour un navigateur mais insuffisante pour la reprise du favicon par Google.
• Plusieurs balisages WebSite contradictoires sur des pages différentes du même domaine, par exemple après une fusion de sites ou un changement de plateforme qui a laissé un ancien balisage actif.
• Un changement de nom de marque répercuté sur le logo et la charte visuelle, mais oublié dans le balisage structuré et dans le title de la page d'accueil, qui continuent de pointer vers l'ancien nom pendant des mois.
• Un favicon à fond transparent conçu uniquement pour un affichage clair, qui devient illisible ou invisible dès que l'interface de résultats bascule en thème sombre, faute d'avoir été testé sur les deux fonds.