Depuis l’annonce de Gary Illyes concernant l’index « mobile first » à Pubcon, il y a eu de nombreuses théories, conjectures, spéculations et paniques sur ce que ça veut dire vraiment. Les utilisateurs PC auront-ils un site mobile ? Les sites qui n’ont pas un design mobile friendly seront-ils affectés ? Avons-nous besoin de changer toutes vos balises canonicales ?
Google a déclaré qu’ils étaient toujours en train d’essayer de trouver une façon de gérer certains problèmes, mais ce n’est probablement pas réconfortant pour les entreprises qui s’appuient sur le trafic Google pour payer leurs factures.
D’abord, essayons de comprendre ce qu’est l’indexation
– Crawling (« navigation » en français) est le processus par lequel Google suit des liens sur le web pour découvrir les pages. C’est là qu’ils sont susceptibles de découvrir votre contenu et où ils peuvent également appliquer des règles de fichier nofollow.
– Indexing (« indexation » en français) est le processus qui rend votre page web plus utilisable. Google fait une copie de votre page dans un format plus utilisable pour l’algorithme de classement.
– Retrieval (« extraction » en français) est la première partie de la requête de recherche. Cela arrive avant le classement, mais il y a de fortes chances que l’algorithme actuel fasse l’extraction et le classement en même temps. L’extraction est le moment où le moteur dit « donne-moi tout ce qui est pertinent à cette requête ».
– Ranking (« classement » en français) est la partie qui nous obsède le plus. C’est quand Google ordonne les résultats selon une multitude de facteurs que nous sommes en train de débattre aujourd’hui.
Ce classement est principalement défini pendant la phase d’extraction. Toutefois il est susceptible que certains facteurs (comme les pénalités et la vitesse ou encore le mobile friendly) aient une influence après l’extraction.
Qu’est donc l’index mobile first ?
Actuellement, Google a seulement un index qui est basé sur le site PC. Il crée des signaux basés sur Googlebot avec l’agent utilisateur (user-agent) PC. Google explore ensuite avec son Googlebot mobile pour rassembler des signes mobile friendly et autres signes mais ils ne créent pas un nouvel index basé sur le site mobile.
Actuellement, quand un utilisateur effectue une recherche Google (sur PC ou mobile) la partie d’extraction de l’algorithme regarde l’index PC créé par le crawler Googlebot PC. Il trouve des résultats pertinents basés sur l’index PC, puis les classe en fonction de l’index PC et montre même aux utilisateurs les snippets selon l’index PC. Le « Ranker » regarde ensuite les signes mobile collectés par le crawler mobile et ajuste le classement en fonction.
Cela a causé quelques problèmes. En effet, il existe de nombreux cas où l’utilisateur voit quelque chose qui l’intéresse dans un snippet, clique sur les résultats, est redirigé sur la page d’accueil mobile du site et puis réalise que le contenu qu’il a vu dans le snippet n’est plus disponible sur la version rudimentaire du site mobile. Cela entraîne une mauvaise expérience utilisateur mais on le voit sur de nombreux sites.
Avec ce nouveau changement, Google cherche à arrêter cela. La théorie générale est la suivante : si le contenu n’est pas suffisamment important pour être sur votre site mobile, peut être que vous n’êtes pas le résultat le plus pertinent pour ce contenu.
OK…Qu’est que cela signifie ?
Il est vrai que l’indexation peut affecter le classement mais ça ne devrait pas être la préoccupation première. Nous devrions faire un pas en arrière et regarder l’indexation si nous voulons vraiment être préparés à ce changement.
Quant à l’indexation, il y a seulement quelques situations potentielles qui peuvent se produire pour votre site. Ignorons le concept de mobile friendly car cela offre seulement une amélioration minime dans votre classement.
Il est important de distinguer « mobile friendy » pour le classement et « mobile index » pour la pertinence. Le poids du « mobile friendly » peut changer mais ce n’est pas le même concept que l’index mobile. Un site peut être dans l’index mobile sans être mobile friendly.
Quant à l’index mobile first, il y a seulement trois cas possibles : un site internet est soit responsive, ou bien a un site mobile séparé, ou n’a pas de site mobile du tout. Regardons ce que cela signifie pour ces trois scénarios.
Sites responsive
La bonne nouvelle : quasiment rien n’a changé en ce qui concerne l’indexation. (Presque) Le même contenu est vu par Googlebot mobile et Googlebot PC. Il y a encore quelques problèmes que Google a besoin d’analyser mais les sites responsive ne devraient pas être trop affectés. Ces problèmes incluent notamment le poids du contenu par onglet ou les menus déroulants qui ont probablement moins de valeur que sur PC mais ne devraient pas (en théorie) être dévalués sur mobile.
Sites mobile et PC séparés
Pour ce cas-ci, ça devient plus délicat. Si un site a des redirections pour les appareils OU des balises rel=alternate et balises canonical, le crawler mobile verra seulement le site mobile, et pas le site PC. Cela signifie donc que si du contenu est disponible uniquement sur le site PC, le Googlebot mobile ne le verra pas et ne sera donc pas sur l’index mobile first. C’est le problème que Google est en train d’essayer de résoudre, mais c’est également un problème pour beaucoup d’éditeurs.
Pas de site mobile
La dernière catégorie correspond aux pages qui n’ont pas de site mobile. Il y a encore beaucoup de sites dans ce cas. Mais il y a une bonne nouvelle : le Googlebot mobile verra toujours ces pages ! Le crawler mobile ne parcourt pas seulement les pages mobile friendly mais tout le contenu du site. Ces pages seront donc toujours vues, elles n’obtiendront simplement pas la désignation « mobile friendly » mais ça n’a pas d’importance puisque ça n’a rien à voir avec l’indexation mobile first. Bien sûr, ils ne vous classeront pas aussi bien que des sites mobile friendly mais ils ne vous classent déjà pas comme les sites mobile friendly. Ça ne changera pas après l’indexation mobile first.
Qu’est-ce qui sera donc affecté ?
En réalité, les seules pages affectées seront celles qui ont une version mobile qui n’inclut pas le même contenu que la version PC. Il est encore important de noter le « niveau de page » ici. Par exemple, si un site avait une version mobile qui n’incluait pas tout le contenu que la page PC contenait, il souffrirait de ce changement. Si, par contre, le site avait SEULEMENT des pages PC, il serait quand même classé ! Ça serait juste pas attractif visuellement sur un téléphone mobile. C’est une distinction importante.
Bien, assez de théorie. Que faire ?
FAITES UN SITE RESPONSIVE !
Mais qu’en est-il lorsque mes utilisateurs mobiles sont des personnes différentes de mes utilisateurs PC ? Et si je veux personnaliser mon site mobile du fait qu’ils recherchent différemment ?
Faites-le ! Mais faites-le intelligemment. Pensez à votre site. S’il manque beaucoup de contenu sur votre page d’accueil pour la version mobile, peut-être que ce contenu appartient alors à une sous-page au lieu de la page d’accueil ? Il y aura besoin d’une bonne architecture d’informations, d’une stratégie de contenu et d’une équipe dédiée à l’UX (User Experience) mais il est totalement possible de créer une expérience mobile différente sans perdre le contenu. Ça demande juste de l’anticipation.
Et si je ne suis pas responsive ? Puis-je fais des petites choses ?
Pour les débutants, débarrassez-vous de toutes ces redirections de type d’appareil des sous-pages vers la page d’accueil mobile. Personne ne les aime. Si vous n’avez pas d’équivalent mobile de la page, proposez simplement la page PC aux utilisateurs mobile. C’est une meilleure expérience d’obtenir le contenu qu’ils veulent dans un format peu attractif plutôt qu’une jolie page qui n’est pas en relation avec ce qu’ils sont en train de chercher. Mieux encore, créez une version mobile de la page.
Qu’en est-il des rel=alternate et canoniques ? Ai-je besoin de les changer ?
Probablement pas. Google a indiqué que c’est susceptible qu’ils soient suffisamment intelligents pour les gérer eux-mêmes.
Source : Search Engine Journal – Ryan Jones