John Mueller de Google a partagé un cas où une page d’accueil HTTP restante provoquait des problèmes inattendus de nom de site et de favicon dans les résultats de recherche.
Le problème, décrit par Mueller sur Bluesky, est facile à ignorer car Chrome peut automatiquement mettre à niveau les requêtes HTTP vers HTTPS, ce qui rend la version HTTP facile à ignorer.
Ce qui s’est passé
Mueller a qualifié l’affaire de « bizarre ». Le site utilisait HTTPS, mais une page d’accueil HTTP par défaut du serveur était toujours accessible sur la version HTTP du domaine.
Mueller a écrit :
« Une page d’accueil cachée provoquant des problèmes de nom de site et de favicon dans la recherche. C’était étrange. Le site utilisait HTTPS, mais il restait une page d’accueil HTTP par défaut du serveur. »
La partie délicate est que Chrome peut mettre à niveau les navigations HTTP vers HTTPS, ce qui rend la version HTTP facile à manquer lors d’une navigation normale. Googlebot ne suit pas le comportement de mise à niveau de Chrome.
Mueller a expliqué :
« Chrome met automatiquement à niveau HTTP vers HTTPS afin que vous ne voyiez pas la page HTTP. Cependant, Googlebot le voit et l’utilise pour influencer la sélection du nom du site et du favicon. «
Le système de noms de sites de Google extrait le nom et le favicon de la page d’accueil pour déterminer ce qu’il faut afficher dans les résultats de recherche. Le système lit les données structurées du site Web, les balises de titre, les éléments de titre, og:site_name et d’autres signaux sur la page d’accueil. Si Googlebot lit une page HTTP par défaut du serveur au lieu de la page d’accueil HTTPS réelle, il fonctionne avec les mauvais signaux.
Comment vérifier cela
Mueller a suggéré deux façons de voir ce que Googlebot voit.
Tout d’abord, il a plaisanté en disant que l’on pouvait utiliser l’IA. Puis il se corrigea.
Mueller a écrit :
« Pas d’attente, curl sur la ligne de commande. Ou un outil comme le test de données structurées dans la Search Console. »
En cours d’exécution curl http://yourdomain.com à partir de la ligne de commande afficherait la réponse HTTP brute sans la mise à niveau automatique de Chrome. Si la réponse renvoie une page par défaut du serveur au lieu de votre page d’accueil réelle, c’est le problème.
Si vous souhaitez voir ce que Google a récupéré et rendu, utilisez l’outil d’inspection d’URL dans la Search Console et exécutez un test en direct. La documentation sur les noms de sites de Google indique également que les noms de sites ne sont pas pris en charge dans le test des résultats enrichis.
Pourquoi c’est important
L’affichage des noms de sites et des favicons dans les résultats de recherche est quelque chose que nous documentons depuis que Google a remplacé pour la première fois les balises de titre par des noms de sites en 2022. Depuis lors, le système a traversé de multiples difficultés de croissance. Google a étendu la prise en charge des noms de sites aux sous-domaines en 2023, puis a passé près d’un an à corriger un bug où les noms de sites sur les pages internes ne correspondaient pas à la page d’accueil.
Cette affaire introduit une nouvelle complication. Le problème ne venait pas des données structurées ni de la page d’accueil HTTPS elle-même. Il s’agissait d’une page fantôme dans la version HTTP, que vous n’auriez aucune raison de vérifier car votre navigateur ne l’a jamais affichée.
La documentation sur les noms de sites de Google mentionne explicitement les pages d’accueil en double, y compris les versions HTTP et HTTPS, et recommande d’utiliser les mêmes données structurées pour les deux. Le cas de Mueller montre ce qui peut mal se passer lorsqu’une version HTTP contient un contenu différent de la page d’accueil HTTPS que vous aviez l’intention de diffuser.
La solution pour résoudre les problèmes de nom de site ou de favicon dans les résultats de recherche est de vérifier directement la version HTTP de votre page d’accueil. Ne vous fiez pas à ce que Chrome vous montre.
Regarder vers l’avenir
La documentation sur les noms de site de Google précise que les données structurées du site Web doivent se trouver sur « la page d’accueil du site », définie comme l’URI racine au niveau du domaine. Pour les sites exécutant HTTPS, cela signifie que la page d’accueil HTTPS est la source prévue.
Si le nom de votre site ou votre favicon apparaît incorrect dans les résultats de recherche et que votre page d’accueil HTTPS contient les données structurées correctes, vérifiez si une version HTTP de la page d’accueil existe toujours. Utilisez curl ou le test en direct de l’outil d’inspection d’URL pour le visualiser directement. Si une page par défaut du serveur se trouve là, la supprimer ou la redirection HTTP vers HTTPS au niveau du serveur devrait résoudre le problème.
