Quelle est la politique de Google concernant le contenu séparé sur les mêmes URL dans les versions mobile et de bureau?

Je suis en train de développer une version mobile de mon site où les appareils des utilisateurs sont automatiquement identifiés, puis ils affichent une vue mobile ou de bureau de la même URL.

Pour des raisons de convivialité, je souhaite afficher des informations différentes sur certaines URL sur mobile que sur ordinateur. Par exemple, je préférerais que le contenu soit directement sur la première page sur mobile, alors que mon domaine racine de bureau est une page de destination.

• Comment un tel arrangement affectera-t-il les opinions de Google sur mon site?
• Est-ce blessant pour mon classement?
• Ou Google sépare-t-il les résultats de bureau et mobiles?

Il semble que vous craigniez que la diffusion d'un contenu différent aux utilisateurs mobiles et aux utilisateurs de bureau sur la même URL, à l'aide de la détection d'agent utilisateur, puisse être considérée comme une forme de dissimulation , et donc pénalisée par Google.

Selon le blog Google Webmaster Central , ce n'est pas le cas, à condition que vous effectuiez correctement la détection du navigateur mobile. Essentiellement, le détail important à réaliser est que les robots d'exploration de Google utilisent différentes chaînes d'agent utilisateur selon qu'ils attendent du contenu de bureau 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)

tandis que pour les demandes du robot d'exploration 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 détectez correctement ce dernier type de demandes Googlebot (et non l'ancien) comme mobile et que vous leur fournissez du contenu mobile, tout devrait bien se passer. Fondamentalement, l'important est que les requêtes Googlebot normales doivent recevoir du contenu de bureau, tandis que les requêtes Googlebot mobiles doivent recevoir du contenu mobile.

Voici un joli diagramme illustrant cela, à partir de l' article du blog Google Webmaster Central auquel j'ai lié ci-dessus:

De plus, pour faire savoir au robot d'exploration de Google qu'il peut y avoir différents contenus disponibles pour les navigateurs mobiles, vous devrez configurer votre serveur Web pour envoyer l' Vary: User-Agenten-tête HTTP pour toutes les pages pour lesquelles vous utilisez la détection d'agent utilisateur . Vous devez également vous assurer d' éviter les pièges courants lors de la détection des agents utilisateurs .

La meilleure solution consiste à utiliser des URL canoniques . Cela évite une situation où vous êtes pénalisé pour du contenu en double.

En ce qui concerne les sites Web de bureau et mobiles, la plupart des sites auront quelque chose comme ça 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 essentiellement à Google que le même contenu est accessible via plusieurs URL.

Les utilisateurs de postes de travail / mobiles 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 des pages mobiles redonneront du poids / "jus de lien" à la page d'origine. Dans ce cas, les liens vers http://m.mywebsite.com/page.htmlaffecteronthttp://mywebsite.com/page.html

D'après mon expérience, les visiteurs mobiles veulent le même contenu que vos visiteurs sur ordinateur. J'ai travaillé pour un site Web de voyage contenant de nombreuses 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 recherchent quelque chose lorsqu'ils sont sortis. Cette hypothèse n'était pas correcte, les utilisateurs mobiles recherchaient le contenu de l'hôtel tout autant que les utilisateurs de bureau.

J'ai également entendu l'argument selon lequel la réduction du contenu peut aider l'expérience mobile car les pages se chargent plus rapidement. J'ai constaté que c'est rarement du contenu qui provoque un chargement lent des pages sur 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. Il est souvent judicieux de mettre plus de contenu sur la page et de laisser l'utilisateur y faire défiler plutôt que de le faire cliquer sur plus de pages.
• Le poids du contenu est souvent éclipsé par le poids du balisage, du CSS et du JavaScript. Commencez par les choses que l'utilisateur ne peut pas voir lorsqu'il essaie 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 manière 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énaliserait carrément votre site pour avoir diffusé différents contenus aux utilisateurs mobiles. Cependant, 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, une version de bureau affichant la balise alternative et une version mobile montrant la balise canonique. Lorsque vous diffusez du HTML dynamique sur la même URL, vous devez utiliser l'en-tête HTTP variant.

Google explique cela en détail:

https://developers.google.com/webmasters/smartphone-sites/details

Google est suffisamment intelligent pour détecter les sites mobiles et non mobiles. Et commente spécifiquement 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.

Depuis le WMT de Google:

Le contenu en double fait généralement référence à des blocs de contenu substantiels à l'intérieur ou à travers des domaines qui correspondent complètement à d'autres contenus ou sont sensiblement similaires. Surtout, ce n'est pas trompeur d'origine. Des exemples de contenu en double non malveillant pourraient 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 est bien documenté depuis 2010.

Voir l'article SEL sur:

Ne vous pénalisez pas: les sites mobiles ne sont pas du contenu en double

Plus récemment, Matt Cut de Google a dit de ne pas trop s'inquiéter du contenu en double. Le problème est plutôt de savoir quelle page vous souhaitez classer dans les SERPs.

Comment le contenu en double requis (termes et conditions, etc.)

Enfin, consultez le sujet des outils pour les webmasters de Google sur:

Contenu en double

SEOMOz a également un excellent article sur le sujet:

Qu'est-ce qu'un contenu en double

Les mots de Google: Lorsqu'un site Web est configuré pour servir des navigateurs de bureau et mobiles utilisant différentes URL, les webmasters peuvent vouloir rediriger automatiquement les utilisateurs vers l'URL qui les sert le mieux. Si votre site Web utilise la redirection automatique, assurez-vous de traiter tous les Googlebots comme tout autre agent utilisateur et de 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 éléments de la page sont accessibles à tous les agents utilisateurs de Googlebot.