Quelle est la politique de Google concernant le contenu séparé sur les mêmes URL dans les versions mobile et de bureau?
Je développe actuellement une version mobile de mon site dans laquelle les appareils des utilisateurs sont automatiquement identifiés, puis affichés en mode mobile ou sur ordinateur de la même adresse URL.
Pour des raisons de convivialité, je souhaite afficher des informations différentes sur certaines URL du mobile que du bureau. Par exemple, je préférerais que le contenu soit directement sur la première page du mobile, alors que le domaine racine de mon ordinateur est une page de destination.
- Comment un tel arrangement affectera-t-il l'opinion de Google sur mon site?
- Est-ce blessant pour mon classement?
- Ou Google sépare-t-il les résultats des ordinateurs de bureau et des appareils mobiles?
Il semble que vous craignez que le fait de servir un contenu différent à des utilisateurs mobiles plutôt qu'à des utilisateurs de bureau avec la même URL, à l'aide de la détection d'agent utilisateur, puisse être considéré comme une forme de masquage , et donc pénalisé par Google.
Selon le Google Webmaster Central Blog , ce n'est pas le cas, fourni que vous faites la détection du navigateur mobile correctement. En gros, le détail important à comprendre est que les robots d'exploration de Google utilisent différentes chaînes d'utilisateur-agent selon qu'ils attendent du contenu pour ordinateur ou mobile. Par exemple, une chaîne d'agent utilisateur typique pour les demandes Googlebot normales serait:
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
alors que pour les requêtes du robot mobile, vous verrez quelque chose comme:
SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1
UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1;
+http://www.google.com/bot.html)
ou (pour les demandes de smartphone):
Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26
(KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible;
Googlebot/2.1; +http://www.google.com/bot.html)
Tant que vous vous assurez que vous avez correctement détecté le dernier type de demandes Googlebot (et non le premier) comme mobile et que vous leur transmettez du contenu mobile, tout devrait bien se passer. En gros, l’important est que les requêtes Googlebot normales nécessitent de recevoir du contenu de bureau, tandis que les requêtes Googlebot mobiles doivent recevoir du contenu pour mobile.
Voici un joli diagramme illustrant ceci, tiré du article du blog Google Webmaster Central que j'ai lié à ce qui précède:
En outre, de laisser le robot d'exploration de Google sait qu'il ya peut être différent du contenu disponible pour les navigateurs mobiles, vous souhaitez configurer votre serveur Web à envoyer le Vary: User-Agent en-tête HTTP pour toutes les pages que vous utilisez la détection de l'agent utilisateur pour . Vous voudrez également vous assurer de éviter les pièges courants lors de la détection des agents utilisateur .
Le meilleur plan d'action consiste à tiliser des URL canoniques . Cela évite une situation dans laquelle vous êtes pénalisé pour un contenu en double.
En ce qui concerne les sites Web de bureau par rapport aux sites Web mobiles, la plupart des sites ont ce type de contenu sur leur site Web mobile:
Exemple pour: http://m.mywebsite.com/page.html
<link rel="canonical" href="http://mywebsite.com/page.html" />
La balise canonique indique en gros à Google que le même contenu est accessible via plusieurs URL.
Les utilisateurs Desktop/Mobile sont détectés par le serveur et redirigés vers la version appropriée (cela se produit sur Blogger, qui appartient à Google).
Avec cette méthode, Google ne séparera pas les résultats (vous ne le souhaitez pas). Cela signifie également que les liens entrants vers les pages mobiles redonneront du poids/"lien de jus" à la page d'origine. Dans ce cas, les liens vers http://m.mywebsite.com/page.html affecteront http://mywebsite.com/page.html
D'après mon expérience, les visiteurs mobiles veulent le même contenu que vos visiteurs de bureau. J'ai travaillé pour un site Web de voyage avec beaucoup d'informations sur les hôtels et les restaurants. Le site est généralement connu pour les hôtels, mais nous pensions que les utilisateurs mobiles seraient beaucoup plus intéressés par le contenu des restaurants car ils recherchaient quelque chose quand ils étaient sortis. Cette hypothèse n'était pas correcte, les utilisateurs mobiles recherchaient le contenu de l'hôtel autant que les utilisateurs d'ordinateurs de bureau.
J'ai également entendu l'argument selon lequel la réduction du contenu peut améliorer l'expérience mobile, car les pages se chargent plus rapidement. J'ai constaté qu'il est rare que le contenu ralentisse le chargement des pages sur le mobile.
- La latence est un problème plus important que la vitesse de téléchargement sur mobile. Les grandes pages ne sont pas le problème, mais chaque demande peut prendre quelques secondes à faire. Il est souvent judicieux de placer plus de contenu sur la page et de laisser l'utilisateur y accéder, plutôt que de le faire cliquer sur plus de pages.
- Le poids du contenu est souvent minimisé par le poids du balisage, des CSS et de JavaScript. Commencez par les éléments que l'utilisateur ne peut pas voir lorsqu'il tente de supprimer des octets de la page.
Les utilisateurs ont tendance à être frustrés lorsqu'ils ne peuvent pas utiliser le site mobile de la même façon qu'ils utilisent le site de bureau. Google utilise la satisfaction des utilisateurs comme un signal majeur dans leurs algorithmes de classement. Je doute que Google pénalise totalement votre site pour avoir fourni un contenu différent à des utilisateurs mobiles. Toutefois, lorsque les utilisateurs trouvent que votre site est moins utilisable qu’ils ne l’espéraient, votre classement chute.
Vous pouvez afficher une version mobile à l'aide de balises alternatives canoniques et rel, la version de bureau affichant la balise alternative et la version mobile affichant la balise canonique. Lorsque vous utilisez du code HTML dynamique sur la même URL, vous devez utiliser l’en-tête HTTP.
Google explique cela en détail:
https://developers.google.com/webmasters/smartphone-sites/details
Google est suffisamment intelligent pour détecter les sites mobiles par rapport aux sites non mobiles. Et ajoute que cela n’est pas considéré comme du spam.
La considération la plus importante est de marquer votre URL préférée comme canonique.
De WMT de Google:
Dupliquer le contenu fait généralement référence à des blocs substantiels de contenu dans ou entre des domaines qui correspondent complètement à un autre contenu ou qui sont sensiblement similaires. Généralement, cela n’est pas trompeur à l’origine. Des exemples de contenu dupliqué non malveillant peuvent inclure:
Discussion forums that can generate both regular and stripped-down pages targeted at mobile devices Store items shown or linked via multiple distinct URLs Printer-only versions of web pages
Cela a été bien documenté depuis 2010.
Voir l'article du SEL sur:
ne vous pénalisez pas: les sites mobiles ne font pas double emploi avec le conten
Plus récemment, Matt Cut de Google a dit de ne pas trop s’inquiéter du contenu en double. La question est davantage de savoir quelle page vous souhaitez classer dans les SERP.
Comment fonctionne le contenu en double requis (termes et conditions, etc.)
Enfin, consultez la rubrique des outils pour les webmasters de Google sur:
SEOMOz propose également un excellent article sur le sujet:
Paroles de Google: Lorsqu'un site Web est configuré pour servir des navigateurs de bureau et mobiles à l'aide d'URL différentes, les webmasters peuvent souhaiter rediriger automatiquement les utilisateurs vers l'URL qui les sert le mieux. Si votre site Web utilise la redirection automatique, veillez à traiter tous les Googlebots comme tout autre agent utilisateur et à les rediriger de manière appropriée.
Google reconnaît trois configurations différentes pour la création de sites mobiles.
Google ne privilégie aucun format d'URL particulier tant que la ou les pages et tous les actifs de la page sont accessibles à tous les agents utilisateurs de Googlebot.