Création de liensSEO mobile

Liaison interne pour l’indexation Mobile-First et Mobile-Only

Il y a trois ans, j’ai écrit un article pour le blog Moz expliquant comment les dernières nouvelles sur l’indexation mobile d’abord auraient un impact sur les stratégies de liens internes, en particulier pour les sites plus importants.

“À ce jour, vous avez probablement entendu tout ce que vous pouvez supporter sur l’indexation mobile first”, ai-je plaisanté dans mon introduction. Je ne savais pas.

Ce n’est que maintenant – à l’été 2021 – que Google est censé, peut-être, finaliser le déploiement du mobile-first. Même en août 2021, Google explore toujours très activement des sites avec Googlebot desktop*.

Comme pour les récents retards dans le déploiement de Core Web Vitals, le problème ici pour Google est qu’ils impossible de pousser les changements qui aggravent leurs résultats. Comme Mike King l’a souligné en mars sur iPullRank, il existe toujours une grande disparité entre les versions mobile et de bureau du Web, en particulier en ce qui concerne les liens.

Je n’ai pas besoin de persuader la plupart des référenceurs qu’ils devraient se soucier des liens, mais je dois peut-être vous rappeler que les liens internes sont, pour la plupart des pages, une partie beaucoup plus importante de la façon dont ils tirent leur force que les liens externes. Sur un site même vaguement établi, il n’est pas déraisonnable de penser que l’inclusion d’une page de destination dans votre top nav va générer des liens plus percutants que la plupart des campagnes de relations publiques numériques ne pourraient jamais l’espérer. Et pourtant, les sites ont tendance à se concentrer de manière disproportionnée sur ces derniers, ce qui est peut-être ce qui nous amène aujourd’hui à cette énigme.

Dans cet article, je vais souligner certaines des causes courantes des disparités entre les liaisons internes mobiles et de bureau, quand vous devriez vous en soucier et ce que vous pouvez faire pour résoudre ces problèmes sans jeter UX sous le bus.

*(merci à Dom Woodman et à la richesse des données à portée de main pour m’avoir confirmé que c’est toujours le cas !)

Une brève histoire du mobile-first

En 2015, les référenceurs avaient deux mois d’avertissement pour se préparer à ce que l’industrie surnommait « Mobilegeddon ». Ce n’était pas la première fois que Google tenait compte de la convivialité mobile dans son classement, mais c’était probablement la première fois qu’ils essayaient d’en faire toute une histoire comme moyen de guider les webmasters – un signe des choses à venir.

Environ 18 mois plus tard, en novembre 2016, nous avons eu l’expression “Mobile-first indexing”. Au cours des années suivantes, les référenceurs ayant accès à plusieurs propriétés de la Search Console se sont familiarisés avec le flux régulier d’e-mails les informant des sites passant au nouveau paradigme.

E-mail de l'équipe de la console de recherche Google concernant l'indexation axée sur les mobiles.

Au cours de cette période, certains référenceurs, dont le regretté Russ Jones, moi-même dans le post susmentionné sur le blog Moz, et mon ancien patron Will Critchlowa commencé à s’inquiéter de l’impact potentiel sur le linkgraph :

Tweet de John Muller de Google sur l'indexation axée sur les mobiles.

L’impression générale à l’époque était que Google utilisait pour l’instant un index hybride, mais que le “mobile uniquement” était déjà en route.

Avance rapide jusqu’en mars 2020, et Google a averti que nous avions six mois pour nous préparer au bilan final de l’index des ordinateurs de bureau. Cela a d’abord suggéré un déploiement en septembre 2020, puis c’est devenu mars 2021, puis, comme je l’ai mentionné ci-dessus, cette date a également semblé passer sans incident.

Nous devrions supposer, cependant, que cela arrive toujours, ou peut-être déjà en grande partie ici, et en tant que tel, que nos sites mobiles doivent présenter la version de la vérité que nous voulons que Google voie.

Les rôles des liens internes

Les liens internes, comme tous les autres liens, remplissent plusieurs fonctions vitales :

  • Permettre aux moteurs de recherche de découvrir de nouvelles URL

  • Transmettre des indices sur la pertinence du sujet, via leur texte d’ancrage et l’URL source

  • Transmission d’autorité, via PageRank ou équivalent

C’est bien sûr sans même entrer dans leurs rôles dans l’expérience utilisateur, qui est un sujet pour un autre article. (Bien que si vous voulez en savoir plus sur les liens internes, je vous recommande ce tableau blanc vendredi.)

Une disparité dans les liens internes entre les versions de bureau et mobiles est donc susceptible d’avoir des implications de grande envergure. (Cela vaut également pour les deux autres versions, telles que le rendu et le HTML brut.) Dans la plupart des cas, l’une des deux versions sera celle dont le ou les praticiens SEO du site étaient satisfaits, et en tant que tel, l’autre ne le sera pas. être.

À ce stade, la meilleure pratique courante, du moins pour vos principaux modèles, consiste à produire régulièrement une liste de liens à partir des deux versions de la page et à rechercher les écarts.

Cela dit, certaines différences ont plus d’impact que d’autres. À des fins d’illustration, j’ai comparé les versions de bureau et mobile de cinq pages d’accueil, et dans le reste de cet article, je discuterai de certaines des différences les plus intéressantes que j’ai notées et de ce que je recommanderais aux sites respectifs. Juste pour être clair : je ne suis impliqué dans aucun de ces sites, ni ne les lance.

Les cinq pages d’accueil que j’ai consultées étaient :

  • https://www.amazon.co.uk/ — le site britannique du mastodonte mondial de l’e-com

  • https://www.optimizely.com/ — le logiciel CRO bien connu

  • https://www.ebuyer.com/ — un site de commerce électronique d’électronique

  • https://www.zoopla.co.uk/ — un site immobilier britannique, similaire au Zillow américain

  • https://www.nytimes.com/ — un journal grand format américain

Fait intéressant, parmi ceux-ci, deux n’avaient aucune différence à discuter – félicitations à Optimizely et Zoopla pour leur attention en 2018. Pour les trois autres, lisez la suite…

Exemples moins nocifs

Ancrer des liens dans une page

La page d’accueil d’Amazon UK renvoie à elle-même pas moins de six fois, avec un texte d’ancrage tel que “retour en haut”, “voir les détails du produit” et “page suivante” (dans un carrousel). Ces liens sont tous uniques au bureau, bien que la version mobile ait un lien “Haut de page” au lieu du lien “Retour en haut”.

Liens d'ancrage sur la version de bureau d'Amazon UK.
Liens d'ancrage sur la version mobile d'Amazon UK.

Amazon Royaume-Uni desktop (en haut) par rapport à Amazon UK mobile (en bas)

Vous n’avez probablement pas besoin d’être trop préoccupé par des liens comme ceux-ci du point de vue du référencement. Il n’y a pas de différence dramatique dans l’optimisation ou le ciblage impliqué par les différents textes, et les pages liées à elles-mêmes ne vont probablement pas remodeler le linkgraph.

Liens vers des pages non indexées

Liens vers des pages non indexées sur le bureau Amazon UK.
Liens vers des pages non indexées sur Amazon UK mobile.

Ordinateur de bureau Amazon UK (en haut) et mobile Amazon UK (en bas)

Le lien de navigation principal vers la catégorie “Fournitures pour animaux de compagnie” sur la page d’accueil d’Amazon UK est fourni avec différentes balises de suivi internes sur mobile et sur ordinateur :

  • Bureau : www.amazon.co.uk/gp/browse.html?node=340840031&ref_=nav_em__ps_t2_0_2_14_24
  • Mobile: www.amazon.co.uk/gp/browse.html?node=340840031&ref_=navm_em__pets_0_3_17_11

D’un point de vue SEO général, ce n’est pas un moyen idéal de gérer le suivi des liens internes – ces deux URL ont une balise canonique pointant vers la page indexée réelle, mais il y a toujours une dilution inutile et un budget de crawl gaspillé ici, par rapport au simple suivi de la cliquez sur un lien à l’aide d’un écouteur d’événements JavaScript.

Cependant, d’un point de vue spécifique de la parité mobile/ordinateur de bureau, ce n’est pas un gros problème. Comme je l’ai dit, ils partagent tous les deux une balise canonique pointant vers le même endroit, nous nous retrouvons donc avec un comportement équivalent.

Une règle similaire s’applique lors de la création de liens vers des pages telles que “mon compte” ou “panier” – il peut y avoir des différences dans les implémentations de bureau et mobiles, mais comme les deux pages sont bloquées par noindex et/ou robots.txt, ce n’est pas grave.

Texte d’ancrage

Ebuyer a quelques instances du même élément utilisant un texte d’ancrage différent sur mobile et sur ordinateur :

Texte d'ancrage affiché sur la version de bureau Ebuyer.
Texte d'ancrage affiché sur la version mobile d'Ebuyer.

Ebuyer desktop (en haut) vs. Ebuyer mobile (en bas)

Notez le texte d’ancrage plus long sur mobile (!). J’ai également remarqué quelque chose de similaire sur le site du New York Times, bien que cela puisse être dû au fait qu’ils testent rapidement différentes variantes de titres.

Quoi qu’il en soit, je ne pense pas que ce soit un gros problème tant que le comportement est intentionnel et que le sujet implicite est largement similaire, ce qui est le cas dans ces cas.

Problèmes courants et solutions

Éléments spécifiques à l’appareil

L’une des causes les plus courantes de disparité est les éléments de navigation qui ne sont disponibles que sur le bureau. L’exemple ci-dessous provient d’Ebuyer et montre un tas de liens que je n’ai trouvé nulle part sur leur page d’accueil mobile.

Liens de bureau uniquement comme on le voit sur Ebuyer.

Ces liens pointent tous vers des URL qui figurent également dans la barre de navigation supérieure, de sorte que l’impact sur le graphique des liens peut ne pas être énorme. Cependant, Google est susceptible de placer des pondérations différentes sur un lien de page d’accueil proéminent comme celui-ci par rapport à un lien enfoui dans une navigation, il y a donc des implications SEO à cette disparité. Le site de bureau d’Ebuyer implique qu’il s’agit de certaines des sous-catégories les plus importantes du site, tandis que leur site mobile leur donne un pied d’égalité avec les autres sous-catégories du méga-menu.

Se produisant sur des millions de sites, c’est le genre de problème qui pourrait avoir un impact sur la qualité des résultats de Google. Ebuyer a vraisemblablement présenté ici les catégories qui sont au cœur de son activité, et si elles se classent légèrement mieux dans ces cas que dans d’autres cas, cela signifie que Google est légèrement plus susceptible de montrer aux gens les résultats d’une entreprise hautement compétente dans ce domaine. Cela, du point de vue de Google, est sûrement une victoire, mais ils la ratent en utilisant exclusivement la version mobile.

Du point de vue d’Ebuyer, le choix de ce qu’il faut mettre en avant dans cet élément est un levier stratégique qui se perd lorsque Google arrête de compter ses liens desktop. La seule vraie solution ici est de développer un équivalent mobile à cet élément, mais on peut être créatif. Il peut s’agir d’un endroit légèrement différent sur la page, par exemple, ou il peut s’agir d’un carrousel sur mobile mais statique sur ordinateur. Alternativement, vous pouvez accepter qu’il s’agisse d’un élément UX spécifique au bureau qui doit être ignoré dans toute considération de référencement, et doit plutôt se justifier par ses avantages pour les taux de conversion.

Liens vers les méga-menus et les sous-catégories

De nombreux sites, en particulier le commerce électronique, gèrent les liens internes en ayant un énorme méga-menu sur le bureau qui s’effondre dans un menu hamburger peut-être quatre couches de profondeur sur mobile. Cela laisse aux utilisateurs de très nombreux clics sur tout ce qu’ils pourraient espérer trouver, et l’ironie est que les navigations supérieures super exhaustives ne sont pas nécessairement optimales non plus du point de vue du référencement. Bien sûr, ils obtiennent beaucoup de pages explorées et transmettent un peu d’équité, mais ils ne font rien pour concentrer la pertinence autour des sous-thèmes, et ils ne vous permettent pas de concentrer votre force là où elle est le plus nécessaire.

Certains sites améliorent cela avec une sous-navigation spécifique à une section, par exemple ces liens sur Amazon qui n’apparaissent que dans la section Épicerie :

Menu de sous-navigation dans la section épicerie Amazon.

C’est une excellente alternative à un méga-menu en général, dans la mesure où il y a moins de liens sur tout le site (ce qui signifie que chaque lien restant sur tout le site est un peu plus fort) et, proportionnellement, plus de liens entre des pages étroitement liées.

Cependant, bien sûr, cet élément n’apparaît pas du tout sur mobile. D’oh.

De même, Amazon a ces sous-catégories en vedette sur le bureau, jouant un rôle similaire :

Sous-catégories sur le bureau Amazon.

Encore une fois, je dirais que c’est une excellente idée du point de vue du référencement, mais ces liens n’existent pas sur mobile.

Zoopla gère le même problème de manière beaucoup plus soignée :

Liens de la barre latérale vers les sous-catégories pertinentes sur Zoopla.

Liens de la barre latérale vers les sous-catégories pertinentes

De même, ils ont des liens de sous-catégorie qui ne figurent que dans la catégorie pertinente, mais ensuite sur mobile, ils les conservent – il suffit de les déplacer vers le bas de la page au lieu d’une barre latérale :

Les liens de la barre latérale ont été déplacés vers le bas de la page sur Zoopla mobile.

Liens de la barre latérale déplacés vers le bas du contenu sur mobile

Ce n’est pas très attrayant, mais cela n’a pas d’importance – peu de gens feront défiler jusqu’à ces profondeurs de toute façon, et la stratégie de référencement de Zoopla est donc robuste pour l’index uniquement mobile. De plus, en raison de l’accent mis sur l’interconnexion uniquement des sous-catégories pertinentes, le volume de liens ici n’est pas extrême.

Copie SEO et contenu caché

Un argument similaire pourrait être avancé pour le traitement par Ebuyer de la copie SEO ici :

Copie SEO sur Ebuyer discutant des cartes graphiques NVIDIA.

C’est juste en bas de la page, donc c’est peut-être une opportunité pour le maillage interne ? En effet, il y a quelques liens à la fin de ce bloc de texte.

Sans trop entrer dans les avantages et les inconvénients de ce type de copie en général, je dirais que c’est un peu excessif pour le bas d’une page de catégorie e-commerce (vous ne pouvez voir qu’une fraction dans la capture d’écran ci-dessus). Au lieu de cela, Ebuyer pourrait faire quelque chose de similaire à ce qu’il a fait avec son pied de page :

Un exemple de contenu réduit ou à onglets sur Ebuyer.

Le contenu réduit ou à onglets peut être un excellent moyen de gérer des structures de liens internes volumineuses sur mobile

Sur le bureau, toutes ces sections de pied de page sont développées par défaut et toutes visibles. Sur mobile, ils sont cachés dans ces sections extensibles. C’est généralement un bon moyen de gérer les éléments SEO sur mobile, comme Google l’a dit à plusieurs reprises à ce stade qu’il n’y a aucun inconvénient à le faire.

Conclusion : des liens sur la page, mais avec goût

J’ai essayé d’explorer ici certains des problèmes courants auxquels les sites sont confrontés lorsqu’ils visent la parité de liaison mobile/ordinateur de bureau.

Pour récapituler rapidement, les principaux problèmes sur lesquels je recommande que les sites se concentrent sont :

  • Éléments de navigation manquants

  • Possibilités de liens profonds sans recourir à des méga-menus

Et mes solutions suggérées sont:

  • Pousser les widgets de liaison vers le bas de la page sur mobile, plutôt que de les supprimer complètement

  • Utiliser des onglets, des carrousels, des sections extensibles et d’autres solutions créatives pour mieux utiliser l’espace à l’écran

J’ai hâte de voir plus d’exemples dans la nature, cependant – comment votre site gère-t-il les liens internes axés sur les mobiles ? Dites-le moi sur Twitter !



(Article traduit de moz.com)

Articles similaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Bouton retour en haut de la page
Index