Le 30 janvier 2017
Nombre de webmasters ont eu des tas de questions sur ce changement, en particulier en ce qui concerne le classement et l’indexation des sites qui affichent actuellement différentes versions du même contenu, pour le bureau, une pour le mobile.
Google a d’abord annoncé le changement à venir le mois dernier, mais avec cette nouvelle annonce de Doantam Phan, Google Product Manager, il est désormais en phase de test dans les résultats de recherche mobile. Et nous avons maintenant beaucoup plus de détails sur ce changement.
J’ai également contacté Google pour clarifier certains des points indiqués dans leur article.
Google veut s’assurer qu’ils offrent la meilleure qualité aux internautes dans les résultats de recherche. Et avec plus de 50% des recherches effectuées sur les appareils mobiles, le fait que Google classe les pages en fonction de la version desktop commençait à devenir un problème.
Ceci est dû au fait que certains sites web affichent des contenus différents pour les mobinautes, généralement une version raccourcie ou abrégée du contenu, tout en fournissant une version plus détaillée aux internautes Desktop. Google se base sur la version Desktop pour classer les pages. Cela signifie que certains mobinautes peuvent choisir un résultat de recherche qui semble contenir ce qu’ils recherchent mais ils ne le trouvent pas une fois sur la page car le contenu est disponible uniquement pour la version Desktop.
Ce n’est pas une surprise, comme Gary Illyes de Google a mentionné plusieurs fois que Google travaillait sur un seul index mobile.
Alors que tous les sites verront leur contenu classé via la version mobile, il existe deux domaines spécifiques où les propriétaires de site devront probablement apporter des modifications. Le premier concerne les sites qui diffusent des contenus différents pour les mobinautes par rapport aux utilisateurs Desktop. Le second est les sites qui ont supprimé les balises de données structurées de leurs pages mobiles.
Autrement, pour les sites qui fournissent un contenu identique, par exemple pour les sites responsive et à diffusion dynamique, il n’est pas nécessaire d’apporter des modifications.
Les sites qui utilisent actuellement des configurations m.example.com, où le mobile et le Desktop sont sur des pages complètement différentes et parfois même des sites différents, seront ceux qui seront le plus affecté par l’index mobile first. La plupart des sites m.example.com ont un contenu différent. Si la version mobile de chaque page a moins de contenu, ces pages pourraient perdre leur positionnement pour les mots clés de longue traine dont le contenu apparaît uniquement sur la version desktop de la page et non mobile.
Les sites aux contenus différents devront tenir compte de l’impact que cela aura sur leur site, d’autant qu’il pourrait entraîner une perte de trafic si le contenu manquant du site mobile est le contenu qui est bien classé dans Google.
Il est important de noter que si vous utilisez moins de contenu sur la version mobile d’une page, une fois que Google fonctionnera avec l’index mobile first, vous ne pourrez classer que le contenu affiché sur la page mobile. Si le contenu existe sur la version desktop de la page mais pas sur la version mobile correspondante, le site risque de perdre le classement et le trafic de recherche lié au contenu manquant.
Gary Illyes a également confirmé qu’ils n’utiliseront pas le contenu plus long sur desktop lorsqu’une version tronquée du contenu apparaitra sur le mobile. Google indexera uniquement le contenu sur le site mobile.
@denstopa @krystianszastok well yeah, if the content is not on the page, it’s pretty hard to rank it
— Gary Illyes ?( ? )? (@methode) 5 novembre 2016
Si votre site mobile est configuré sur un sous-domaine, tel que m.example.com ou sur un autre domaine, tel que examplemobilesite.com, assurez-vous de vérifier le site dans Google Search Console. Cela signifie que vous serez informé de tout problème sur votre site mobile, tel que le blocage des erreurs de crawl ou d’exploration, ou des problèmes plus graves telles que des actions manuelles ayant une incidence sur le site mobile.
Il est important de noter que Google considère example.com et m.example.com comme deux propriétés différentes (www.example.com serait encore une autre propriété, comme les URLs avec et sans HTTPS), vous devez donc vérifier les deux afin d’obtenir les données complètes.
Pour ceux qui ont encore des questions sur l’article de Google, Gary Illyes a confirmé que les sites responsive n’ont pas besoin de revérifier leurs sites pour l’index mobile first.
Google dit que les balises canonicals n’auront pas besoin d’être changées. Est-ce que les propriétaires de site devraient toutefois commencer à changer les canonicals sur les nouvelles pages pour refléter que la page mobile est celle indexée ? Selon Phan, non.
Phan dit: «Les sites n’ont pas besoin d’apporter des modifications à leurs liens canoniques. Nous continuerons à utiliser ces liens comme guides pour fournir les résultats appropriés à un internaute recherchant sur un ordinateur de bureau ou un mobile. »
Il s’agit d’une excellente nouvelle pour les sites avec un grand nombre de canonicals en place, à la fois pour l’adaptation des pages mobiles et desktop et aussi pour les pages correspondantes qui autrement seraient « marquées » comme dupliquées pour montrer quelle page doit être idéalement indexée.
Il semble donc que Google sera capable de comprendre les canonicals entre une version mobile d’une page et la version desktop, même si le desktop est considéré comme l’URL canonique principale.
Il est également intéressant de noter que la propre documentation de Google pour les canonicals pour les sites mobiles montre encore l’utilisation de la version desktop comme canonical.
Google pourrait changer cela comme leurs premiers tests sur l’index mobile first évoluent.
Gary Illyes a déclaré qu’ils ne demandent pas aux propriétaires de site de changer les canonicals pour montrer le desktop comme primaire car si ils le faisaient, cela prendrait un temps fou et ils souhaitent rendre la chose plus facile pour les propriétaires de sites. Et, bien sûr, cela profite également aux propriétaires de sites qui ne sont peut-être pas au courant de ce changement, si Google l’avait exigé.
@gfiorelli1 @aleyda asking people to switch these would take decades, so we’re trying to be a bit smarty about them
— Gary Illyes ?( ? )? (@methode) 5 novembre 2016
Si vous avez supprimé le marquage des pages mobiles afin d’accélérer le temps de chargement, vous devrez le rajouter à la page mobile, sinon vous risquez de perdre vos extraits enrichis une fois que Google aura évolué sur l’index mobile first. Et cela devrait être fait plus tôt que plus tard car il est probable que les internautes qui verront l’index mobile first actif dans les résultats de recherche ne voient pas les données structurées du site si elles n’étaient pas sur le site mobile.
Google recommande de réduire la quantité de données structurées sur les pages.
Lorsque vous ajoutez des données structurées à un site mobile, évitez d’ajouter de grandes quantités de marquage qui ne sont pas pertinentes pour le contenu de chaque document.
Souvent, les pages sont automatiquement marquées avec un schéma supplémentaire qui n’est pas utilisé par Google dans les résultats de recherche, habituellement suite à l’utilisation d’un plugin, il est donc utile de regarder de plus près ce schéma afin de préserver les temps de chargement.
Vous pouvez également utiliser l’outil de test de données structurées de Google pour vous assurer que le bon marquage est affiché.
C’est un domaine qui semble être plus qu’un travail en cours. Google a dit précédemment que les webmasters ont tendance à ne faire autant de liens externes sur mobile que sur desktop. Puisque les liens pèsent lourdement dans l’algorithme de recherche comme l’un des deux principaux facteurs de classement, cela peut avoir un effet sur le classement des pages pour l’index mobile first.
Gary Illyes a confirmé qu’ils ne communiquent pas trop sur les liens en ce moment, car ils en sont au début seulement des tests.
Je m’attends à ce qu’une partie des tests sera de voir si les gens déplacent l’intégralité de leur contenu vers les pages mobiles, s’il y a une grande différence dans les liens entre le desktop et le mobile. Comme cela évolue, nous devrions obtenir plus de précisions de Google sur la façon dont les choses seront d’un point de vue linking.
Une autre grande préoccupation est la façon dont Google va gérer le contenu caché derrière les onglets et les accordéons. Après tout, sur desktop, Google dévalue le contenu dans les onglets mais c’est généralement pour des raisons autres que celles utilisées pour le mobile.
Sur mobile, ces types de fonctionnalités sont habituellement utilisés pour faciliter l’accès à l’information, sans avoir à scroller sans fin. Cela est souvent utilisé sur les sites mobiles lorsqu’ils utilisent le même contenu sur desktop et sur le mobile mais qui veulent montrer aux internautes un résultat moins encombré.
Gary Illyes a confirmé que ces types d’implémentations UX n’entraîneraient pas la dévaluation du contenu sur mobile.
L’exemple le plus populaire d’un site utilisant des onglets / accordéons est effectivement Wikipedia.
J’ai demandé à Google si ces modifications auraient un impact sur les pages mobiles qui ont également des versions AMP. « Rien ne change en ce qui concerne l’AMP », a confirmé Phan au SEM Post.
Cela signifie également que pour les sites m.example.com, l’utilisation d’AMP ne serait pas une solution pour le contenu manquant. Si la version mobile de la page a une quantité réduite de contenu alors que la version AMP a le contenu complet, alors Google ne classera pas le contenu basé sur la page AMP. Google classera toujours les résultats en fonction de la page mobile.
La seule exception à cela serait si le site en question n’a que des pages AMP comme pages mobiles … alors Google classerait les pages en AMP. De la même façon, Google continuera d’appliquer le critère mobile friendly aux pages AMP quand il n’y a pas de page mobile ordinaire mais seulement une version desktop.
Il y a encore quelques sites Web sans version mobile, ce qui est bien. Google va encore indexer la version desktop de ces pages mais ils utiliseront le Googlebot mobile à la place.
Si vous n’avez qu’un site desktop, prenez le temps d’explorer et afficher comme Googlebot mobile afin de vous assurer que, même si le rendu n’est pas correct pour les mobinautes, le contenu réel est entièrement accessible.
Ils suggèrent également aux propriétaires de sites qui développent actuellement une stratégie de site mobile qu’il est préférable de continuer à utiliser un site desktop plutôt que de mettre en œuvre un site mobile non terminé.
Si vous construisez une version mobile de votre site, gardez à l’esprit qu’un site fonctionnel orienté desktop peut être mieux qu’une version mobile du site cassée ou incomplète. Il est préférable pour vous de construire votre site mobile et de le lancer quand il est prêt.
Gary Illyes a également confirmé cela sur Twitter, pour les propriétaires de sites Web qui sont toujours concernés.
Mobile-first: with ONLY a desktop site you’ll still be in the results & be findable. Recall how mobilegeddon didn’t send anyone to oblivion?
— Gary Illyes ?( ? )? (@methode) 6 novembre 2016
Il est également utile de rappeler les propriétaires de sites sans un site mobile friendly ne recevront pas le boost de classement associé au critère mobile friendly.
Si vous n’avez pas utilisé l’outil Explorer comme Google dans Search Console, c’est un outil qui récupère une URL et l’affiche, ce qui permet aux propriétaires de site de voir leurs pages exactement comme Googlebot.
Google affiche toujours le desktop comme choix par défaut, bien que, espérons-le, cela change à l’avenir. Mobile: Smartphone est la version mobile correcte à utiliser.
Les sites, en particulier ceux qui utilisent une stratégie d’URL distincte pour le mobile, voudront vérifier ce que Google voit, et faire les ajustements nécessaires pour éviter la perte de classement, ou au moins être au courant de la perte potentielle.
Cela montrera également s’il y a d’autres problèmes, comme la page qui n’est pas affichée correctement ou si Googlebot est bloqué par inadvertance.
Vous pouvez également l’utiliser pour comparer les versions desktop et mobile, si vous n’êtes pas certain qu’il y ait des différences. Il n’est pas nécessaire de soumettre ces pages lorsque vous les affichez, sauf si vous apportez des modifications importantes … vous êtes limités à 500 soumissions par mois.
Google recommande également de vérifier votre site mobile avec son outil de test robots.txt afin de vous assurer que vous ne bloquez pas Googlebot. Et encore, si vous avez un site m.example.com sur un autre domaine ou sous-domaine, vous devrez d’abord vérifier cette propriété dans Google Search Console.
Lorsque les SEOs créent des pages desktop, ils ont tendance à prêter une attention particulière à leurs balises title (même si Google les réécrit souvent), mais aussi à des choses comme leurs H1. Mais quand il s’agit de pages mobiles, Gary Illyes note que ces éléments sont souvent créés pour l’utilisateur et non pour les moteurs de recherche, comme ce qui se passe pour desktop.
Donc, cela signifie que certains propriétaires de sites devront optimiser ces pages mobiles pour que Google commence à les utiliser pour l’indexation et le classement – quelque chose que beaucoup de propriétaires de sites ne font pas du tout.
@kleinja 2/2 For search you might need to optimise differently on mobile than on desktop. Less real estate to work with
— Gary Illyes ?( ? )? (@methode) 5 novembre 2016
Une autre chose importante à considérer est le fait de repenser les balises title utilisées sur mobile. Les title ont des longueurs différentes selon qu’elles sont affichées sur un téléphone mobile ou sur un ordinateur de bureau, ce qui complique davantage le problème pour les propriétaires de sites qui tentent de déterminer la longueur des titres qu’ils doivent utiliser.
Dans l’ensemble, les balises title mobile sont d’environ 8 caractères de plus par rapport aux ordinateurs de bureau. Mais en optimisant ces balises title pour mobile, si vous passez au-delà de 70 caractères, le title sur le bureau sera soit réécrit par Google, soit sera affiché sous une forme tronquée, coupant la fin de la balise.
La vitesse de la page a été un facteur pour les résultats de recherche pendant un certain temps, bien qu’elle visait principalement les sites excessivement lents, pas ceux qui étaient excessivement rapide. Mais il y a souvent des écarts énormes entre les temps de chargement sur le mobile par rapport au bureau, d’autant plus que certains propriétaires de sites optimisaient seulement la vitesse sur desktop pour s’assurer de ne pas être touchés par l’algorithme.
Ainsi, la vitesse de la page jouera-t-elle un rôle lorsque Google passera à l’index mobile first ? Cela semble être quelque chose sur lequel Google travaille encore.
Rien ne change en ce qui concerne le boost du critère mobile friendly. À l’heure actuelle, ce critère vérifie uniquement si la page est mobile ou non. Si ce n’est pas le cas, aucun boost n’est accordé, mais si c’est le cas, les pages obtiennent un boost dans le classement.
Il n’y aura qu’un seul index de recherche Google et il sera entièrement basé sur ce que le Googlebot mobile voit quand il crawle les sites. Il n’y aura PAS d’index desktop différent pour les recherches effectuées sur desktop. Il n’y aura pas d’index desktop différent pour les sites qui ne disposent que d’une version desktop.
Paul Haahr a dit qu’ils pourraient faire quelques expériences avec deux indices. Il est également clair quand il dit que nous ne devrions pas s’attendre à avoir deux index, et a confirmé qu’il n’y aura pas d’indice mobile de pages mobiles pour les mobinautes et d’indice desktop de pages desktop pour les internautes.
Certaines personnes sont très claires sur le fait de vouloir un index desktop mais il semble plutôt clair que ça n’arrivera pas.
Lorsque Google a commencé à parler de l’index mobile forst, ils ont parlé de deux index distincts, et confirmé l’index mobile first avec la première annonce officielle le mois dernier. Le fait d’avoir deux index se produit simplement quand Google teste l’index mobile first puisque certains utilisateurs voient les nouveaux tests mobiles d’abord, tandis que d’autres voient toujours des classements mobiles basés sur le contenu desktop.
Google semble pousser les propriétaires de site à s’assurer qu’ils ont le même contenu sur desktop et sur mobile. Du point de vue du propriétaire du site, il est également logique de s’assurer que le contenu correspond sur les deux versions afin de tirer pleinement parti des classements Google et du trafic de recherche.
Cet article est la traduction de l’article publié sur The SemPost.
Partagez