A ce titre, il communiquait des informations sur le référencement Google aux webmasters.
Mais, de mon point de vue, il était finalement perçu comme celui qui cherchait toujours à faire peur sur certaines pratiques SEO, à brouiller les pistes, avec cette impression de langue de bois où trier le vrai du faux était devenu un sport détesté et contesté par la communauté SEO.
Et puis, après son départ de chez Google en Juin 2016, même un peu avant, nous avons commencé à découvrir un autre personnage : John Mueller.
Et avec lui, nous avons découvert, avec toute sa bonhomie, un autre style de communication dans lequel les SEO ont vite senti une volonté de leur apprendre des choses, de vraies choses, sur l’optimisation pour le moteur Google.
S’appuyant sur son style direct, il répondait à tout le monde en disant ce qui est, ce qu’il faut faire ou ne pas faire pour mieux se classer sur Google. Et ce, sans pour autant révéler le coeur de l’algorithme de ranking de Google (qu’il ne connaît pas d’ailleurs).
Par la suite, avec sa popularité qui grandissait au sein de la communauté des webmasters, John Mueller a lancé les Hangouts SEO hebdomadaires au cours desquels les webmasters peuvent lui poser des questions en direct qu’il s’efforce de répondre.
C’est un événement qui apportait son lot de précisions, de confirmations et de démentis ou d’infirmations, avec toujours la volonté de tirer tout au clair, sans jamais chercher à embrouiller qui que ce soit.
De tous ces Hangouts de 2018, SearchengineJournal.com a sélectionné les 36 meilleures réponses de John Mueller (parmi des centaines d’autres) à même d’éclairer le communauté SEO sur des optimisations du référencement.
Voici donc les 36 réponses sur le référencement Google les plus importantes de John Mueller, classées par thématiques clés.
Mobile-First
- Les sites qui attendent toujours d'être basculés vers l'index mobile-First ne sont pas forcément prêts.
Bien qu'une grande partie des sites a maintenant migré vers l'index mobile-First, les sites qui n’ont pas encore été déplacés ne sont pas forcément prêts pour cela.
- Une fois qu'un site a été déplacé vers l'index mobile-First, la parité du contenu ne sera pas un problème parce que la version desktop ne sera plus utilisée pour l'indexation.
La parité du contenu entre la version mobile et la version desktop d'un site est importante pour que ce contenu migre vers l'index mobile-First.
Une fois que le site a été basculé, la parité a moins d'importance, car ce ne sera que la version mobile qui sera utilisée pour l'indexation.
- Assurez-vous que les versions mobiles ne sont pas trop simplifiées et incluez le contenu pertinent qui aide Google à comprendre la page.
Les versions mobiles d'un site ne devraient pas être trop simplifiées au point qu'elles influent sur la capacité de Google à comprendre clairement ce dont parle votre site.
Veillez à conserver le contenu pertinent et les éléments descriptifs. En outre, maintenez le texte ALT (pour le référencement des images) sur la version mobile des pages sur un site.
Le contenu
- Il n'existe aucune différence dans la façon dont le contenu qui est dans le code HTML est traité selon qu'il est visible ou non par défaut
Google ne traite pas le contenu dans le code HTML différemment en fonction de s’il est visible sur la page par défaut.
Ce n’est pas un problème d'inclure le contenu secondaire qui est masqué lors du chargement de la page tant qu'il est dans le code html.
- Utilisez l’URL canonique (rel=canonical) par rapport au “noindex” pour le contenu dupliqué.
Lorsqu'une page a une balise meta “noindex”, cela signifie que tous les signaux seront supprimés pour cette page.
En ce qui concerne le contenu dupliqué, John Mueller recommande d'utiliser un rel = Canonical sur la version préférée de la page afin que les signaux pour les deux versions de page puissent être combinés plutôt que de supprimer les signaux de la page ayant la balise “noindex”.
- Google peut indexer les pages dupliquées mais il affichera seulement la page la plus pertinente.
Pour les pages dupliquées qui existent sur différents sites sans rel=canonical en place, Google indexera les deux versions de la page, mais ne montrera que la plus pertinente dans les résultats de recherche en fonction de la pertinence et des facteurs de personnalisation, comme l'emplacement.
L’exploration (Crawling)
- Assurez-vous que les scripts dans l'en-tête de la page ne se ferment pas prématurément.
Les scripts qui insèrent des éléments non-Head (comme les divs et les iframes) dans l'en-tête de page peuvent les faire fermer prématurément.
Cela pourrait signifier que Googlebot n'est pas en mesure d'analyser les liens hreflang (site multilingue) parce qu'il suppose que l’en-tête a déjà été fermé.
Vous pouvez vérifier ce problème potentiel en testant les pages avec l'outil de test des résultats enrichis de Google en utilisant la visualisation du code.
- Googlebot n'utilise pas les cookies lorsqu'il retourne à l'analyse d'un site.
Googlebot ne rejoue pas les cookies fournis lorsqu'il revient explorer un site.
Si vous utilisez des cookies pour regrouper les utilisateurs pour les tests A/B, assurez-vous que Googlebot est placé dans le même groupe afin qu'il voit une version cohérente des pages sur votre site.
- Le budget de crawl n'est qu'un problème pour les grands sites.
Googlebot est capable de très bien analyser des sites avec “quelques centaines de milliers de pages”.
Seuls les grands sites avec un volume de pages plus élevé devraient être préoccupés par les problèmes de budget de crawl.
L’indexation
- Servir une réponse 410 peut supprimer plus rapidement des pages de l'index de Google qu'une réponse 404.
À long terme, les erreurs 410 et 404 ont le même impact, car elles suppriment les pages de l'index et poussent à les explorer moins fréquemment.
A court terme, cependant, une erreur 410 peut encourager à supprimer une page de l'index en 2 jours par rapport à une erreur 404.
- Les pages liées bloquées par robots.txt peuvent toujours être indexées.
Google peut toujours indexer les pages qui sont bloquées par robots.txt, si elles ont des backlinks.
John Mueller recommande d'utiliser plutôt la balise noindex pour ces pages.
- L'indexation peut être retardée si la balise canonique pointe vers une redirection au lieu de la version préférée.
Assurez-vous que les balises canoniques pointent vers la version préférée d'une page plutôt que vers une page qui redirige la page préférée.
Utiliser le Canonical vers une redirection peut signifier qu'il faut plus de temps à Google pour indexer la version préférée de la page.
Javascript
- Servir du JavaScript critique dans l’en-tête peut bloquer le rendu.
Le JavaScript qui est considéré comme critique est celui qui est susceptible d'être d'une taille de fichier importante.
En tant que tel, le JavaScript critique ne doit pas être servi dans l’en-tête parce que cela peut retarder le rendu, ce qui signifie que l'utilisateur devra attendre plus longtemps pour voir n'importe quel contenu.
Le contenu prioritaire doit être servi aux utilisateurs le plus rapidement possible.
- Affichez les pages entièrement rendues à Googlebot en utilisant le rendu dynamique (Dynamic Rendering).
En implémentant le Dynamic Rendering, vous pouvez servir la version entièrement restituée d'une page à Googlebot.
Cela permettra de surmonter le délai entre l'indexation initiale et le rendu d'une page.
- Il y aura un délai entre l'indexation initiale et le rendu prévisible pour l'avenir .
Le rendu JavaScript est un processus lourd de ressources et ne peut pas se produire en même temps que l'indexation initiale de la page avec le système actuel de Google.
Par conséquent, il y aura un délai entre l'indexation initiale du HTML et le rendu pour un avenir prévisible.
Linking
- Le PageRank passe toujours pour les liens qui ne sont pas visibles par défaut.
John Mueller a confirmé que Google traite et passe le PageRank pour tous les liens dans le HTML d'une page, indépendamment du fait que les liens ne soient pas visibles (non cliquables) par défaut sur la page.
- Un mauvais maillage de liens internes sur mobile peut affecter la façon dont les pages sont indexées et classées.
Surveillez la liaison (pointage de lien) interne sur la version mobile de votre site, car mal fait, cela peut avoir un impact sur la façon dont Google indexe et ranke une page après qu'elle a migré sur l’index mobile-first.
Vous pouvez utiliser des outils pour vérifier la liaison interne sur mobile en analysant les sites avec un user-agent mobile.
- Google ignore les liens manuellement et algorithmiquement.
Google utilise des algorithmes pour ignorer les liens, ainsi que des méthodes manuelles.
L’équipe Web Spam de Google peut prendre des actions manuelles pour empêcher des sites de passer du PageRank.
Internationalisation
- Plusieurs options sont disponibles pour fournir différentes versions de pages de produits par pays.
John Mueller dit qu'il y a plusieurs options dès lors qu'il s'agit de servir différentes versions de pays pour les pages produits.
Avoir toutes les versions sur la même page et utiliser des redirections IP pour servir la version correcte signifie que Googlebot ne verra que la version américaine (par exemple) ou du pays d'hébergement du site.
L'utilisation de pages de destination séparées avec hreflang signifiera que la valeur de la page est diluée.
Une autre option est de servir les éléments en fonction du pays en utilisant JavaScript et de les bloquer pour qu'ils ne soient pas explorés.
- Assurez-vous que chaque version de pays d'une page a une balise canonique claire et qu’un hreflang est implémenté entre les versions canoniques équivalentes
John Mueller recommande de ne pas spécifier les canoniques entre les versions équivalentes de pays d'une page, car Google n'indexera probablement que la version préférée.
Au lieu de cela, il a déclaré qu'il devrait y avoir une version canonique claire pour chaque version de pays et un hreflang devrait être mis en œuvre entre chaque version canonique équivalente.
- Hreflang est un signal mineur de canonicalisation.
Lorsque Google choisit la version canonique d'une page, hreflang est utilisé comme un signal mineur.
Hreflang doit être renforcé avec des signaux cohérents sous la forme de :
- Fichiers sitemap.
- Maillage interne.
- Rel = canonical
- Fichiers sitemap.
Données structurées
- Les données structurées sont utilisées uniquement par Google si un site est considéré comme de haute qualité et digne de confiance.
- Google doit considérer un site comme de haute qualité et digne de confiance avant qu'il n'affiche des données structurées telles que des extraits enrichis (rich snippets) dans les résultats de recherche.
En plus de cela, les données structurées doivent être ajoutées correctement d'un point de vue technique et appliquées au contenu pertinent.
- Les dates de publication et de modification des données structurées sont recommandées pour les articles.
John Mueller recommande d'ajouter le balisage de date pour les articles car cela permet à Google d'extraire la date correcte de la page plus facilement.
- Vérifiez le balisage des avis et des notations.
Pour que Google affiche le balisage des notations dans les résultats de recherche, il doit refléter le sujet principal de la page et les avis réels de l'utilisateur.
Par exemple, le balisage des notations sur une page sur un modèle de voiture devrait être sur cette voiture spécifique et il devrait être ouvert à quiconque de soumettre des avis et pas de témoignages triés à la volée.
L’architecture du site
- L’importance de la page est plus déterminée par la profondeur du clic que par la structure de l'URL.
Lors de la détermination de l'importance d'une page, Google donne plus de poids au nombre de clics qu'il faut pour arriver à une page plutôt que sur ce à quoi ressemble la structure de l'URL.
- L'utilisation de sous-répertoires est plus recommandée que les sous-domaines sauf si les pages sont sensiblement différentes du reste du site.
Google voit les sous-domaines et sous-répertoires dans une grande partie, de la même manière.
Cependant, Mueller recommande de garder les pages ensemble sur le même site dans la plupart des cas et utiliser un sous-domaine lorsque ces pages sont sensiblement différentes du reste du site.
- Tout nouveau contenu doit être lié tout en haut dans l'architecture du site.
Cela peut faire une grande différence pour Google si le nouveau contenu est lié soit à partir de la page d'accueil, soit tout en haut dans l'architecture du site.
Par exemple, vous voudrez peut-être envisager d'ajouter une section «nouveaux produits» ou «nouveaux articles» sur la page d'accueil d'un site.
Vitesse de chargement
- Google utilise des données de l’expérience utilisateur pour déterminer la vitesse de chargement de la page.
Avec Speed Update, John Mueller a révélé que Google utilise maintenant des métriques de l'expérience utilisateur réelles de Chrome pour déterminer la vitesse de chargement de la page, à côté d'un certain nombre d'autres facteurs.
- Google utilise une échelle de valeurs pour évaluer le délai de chargement de la page.
Avec la Speed Update, Google évalue maintenant la vitesse sur une échelle où plus une page est rapide, plus Google peut en tenir compte.
Avant cette mise à jour, Google différait uniquement entre les pages chargées dans une plage de temps normal et les pages très lentes.
- Améliorez la vitesse de chargement de la page en chargeant les scripts après le rendu.
Le temps de chargement peut être amélioré en incorporant des scripts qui ne se chargent qu’après le rendu de la page.
Cela est particulièrement utile si les scripts sont uniquement requis pour la fonctionnalité.
Pertinence et qualité
- Mettez l'accent sur l'amélioration de la pertinence des sites qui ont souffert après la mise à jour de l’algo le 1er Août 2018.
John Mueller recommande que les sites touchés par la mise à jour du 1er août 2018 devraient se concentrer sur l'amélioration de leurs pages afin qu'elles soient plus pertinentes pour les utilisateurs du moteur de recherche.
Cependant, il est utile de garder à l'esprit que cela peut prendre un certain temps pour les algorithmes de Google de comprendre l'impact des changements dans la pertinence des pages et du site dans son ensemble.
- Considérez le “Noindex” pour le contenu de faible qualité et le contenu généré par l'utilisateur.
Les sites qui disposent d'un grand nombre de contenu généré (forums et autres Q&A) par l'utilisateur doivent examiner le tracking des pages qui sont de faible qualité, de sorte que des règles peuvent être mises en place pour le “noindex” de ces pages.
- Google ne prend en considération que les pages indexées lors de l'évaluation de la qualité du site.
Les pages ayant le “Noindex” ne réduisent pas l'évaluation de Google sur la qualité globale d'un site, car il ne s'agit que des pages indexées qui sont prises en considération.
Les images
- Les images Lazy-Loading doivent utiliser la balise noscript ou le balisage.
Afin d'aider Googlebot à traiter les images à chargement paresseux, John Mueller recommande d'utiliser une balise noscript ou de les marquer avec des données structurées.
- N'oubliez pas de rediriger les anciennes URL d'image vers les nouvelles URL lors de la migration vers un nouveau CDN, ainsi que la mise à jour des liens incorporés dans la page Web.
Ceci est particulièrement important pour les images parce qu'elles ne sont pas analysées aussi régulièrement que les pages Web, de sorte que tous les signaux doivent être alignés afin que Google puissent traiter le changement d'URL le plus vite possible.
- Les balises Image doivent avoir un tag “A” et un élément “href” afin de voir ces images comme des liens.
Une image est considérée comme un lien par Google si elle un tag “a” et un élément “href”. Par exemple, utiliser une balise d'image pour pointer vers une image sur un autre site ne sera pas considéré comme un lien par Google.
