Mueller dit qu’il reçoit parfois des questions sur la façon d’utiliser les attributs rel-alternative et rel-canonical sur les liens des sites avec des URL mobiles distinctes.
Cette information peut être connue de vous, mais John Mueller a estimé qu’elle est assez importante pour créer un fil Twitter entier là-dessus.
Index Mobile-First et URL canoniques
John Mueller explique que rien n’a changé avec l’indexation mobile first en ce qui concerne les sites avec des URL mobiles séparées utilisant rel=canonical.
« Gardez les mêmes annotations. Aucun changement n’est nécessaire », déclare-t-il dans un Tweet.
Mueller a même créé un diagramme (voir le Tweet intégré ci-dessous) pour montrer comment rien ne doit changer avant et après l’indexation mobile first.
Il poursuit en disant ce qui a été dit depuis le début sur l’indexation mobile-first, à savoir que les versions mobiles d’un site sont indexées par défaut.
Dans le cas des sites avec des URLs mobiles distinctes, cela signifie que la version m-dot est utilisée pour l’indexation.
Lisez la discussion complète autour de ce sujet en lisant le thread Tweet ci-dessous:
I occasionally get questions about this, so just to be clear: if you have separate mobile URLs (with rel-alternate / rel-canonical links), with mobile first indexing you *don't* need to change anything. Keep the same annotations. No changes needed. pic.twitter.com/nGPucxPXWn
— 🍌 John 🍌 (@JohnMu) January 18, 2021
Je reçois parfois des questions à ce sujet, donc juste pour être clair : si vous avez des URL mobiles distinctes (avec des rel-alternative / des liens rel-canonical), avec l’index mobile-first, vous * n’avez pas * besoin de changer quoi que ce soit. Gardez les mêmes annotations. Aucun changement n’est nécessaire.
The change with mobile first indexing is that we'll use the mobile version (m-dot) as the version for indexing, instead of the www (desktop) version. For most sites, this change has already happened. If your site is already indexed with mobile, nothing will change.
— 🍌 John 🍌 (@JohnMu) January 18, 2021
Le changement avec l’indexation mobile-first est que nous allons utiliser la version mobile (m-dot) comme étant la version pour l’indexation, au lieu de la version www (bureau).
Pour la plupart des sites, ce changement s’est déjà produit. Si votre site est déjà indexé sur mobile, rien ne changera.
Technically, we'll use the mobile URL as canonical even if the rel-canonical points to desktop. That's fine. In the sitemap file, you can list either of these, or even both. We'll crawl, find the annotations, and do what's needed. There is no special mobile markup for sitemaps.
— 🍌 John 🍌 (@JohnMu) January 18, 2021
Techniquement, nous utiliserons l’URL mobile comme URL canonique même si le rel-canonical pointe vers le bureau. C’est pas grave.
Dans le fichier sitemap, vous pouvez énumérer l’un ou l’autre d’entre eux, ou même les deux. On va explorer, trouver les annotations et faire ce qu’il faut. Il n’y a pas de balisage mobile spécial pour les sitemaps.
Ideally you'd also redirect users by device type: if a desktop user accesses the mobile version, redirect to the desktop URL. If a mobile user accesses the desktop version, redirect to the mobile version.
— 🍌 John 🍌 (@JohnMu) January 18, 2021
Idéalement, vous redirigeriez également les utilisateurs par type d’appareil: si un utilisateur de bureau accède à la version mobile, redirigez vers l’URL de bureau. Si un utilisateur mobile accède à la version de bureau, redirigez vers la version mobile.
If you use m-dot URLs + hreflang, the hreflang annotations should be by device type. Desktop hreflangs point to desktop URLs, mobile hreflangs point to mobile URLs. M-dot + hreflang is hard & confusing. Another reason to move to a responsive setup with the next site revamp :-).
— 🍌 John 🍌 (@JohnMu) January 18, 2021
Si vous utilisez des URL m-dot + hreflang, les annotations hreflang doivent être par type d’appareil. Les hreflangs de bureau pointent vers les URL de bureau, les hreflangs mobiles pointent vers les URL mobiles. M-dot + hreflang est difficile et déroutant. Une autre raison de passer à une configuration réactive (responsive) avec la prochaine refonte du site :-).
