web-dev-qa-db-fra.com

Stratégie d'URL mobile

Je vais utiliser jQuery Mobile pour créer une version mobile de mon site.

Ma question concerne les meilleures pratiques concernant l'emplacement du site mobile, en particulier l'URL. Je cherche deux options:

  1. Il suffit de détecter si l'utilisateur est mobile et de lui servir un modèle de mobile, sans avoir besoin d'une URL distincte pour le site mobile. Par exemple, mysite.com/foo/bar aurait une version mobile et une version de bureau de la page. Mon site utilise le cache HTTP et cela compliquerait les choses ...

  2. Avoir une URL mobile (m.mysite.com). Je préfère cette méthode car je la vois dans beaucoup d’endroits (c.-à-d. M.facebook.com). Mon hésitation est avec le référencement, la duplication de contenu n'est-elle pas mauvaise?

Des idées, des pensées, des commentaires sur mon dilemme? Y a-t-il une stratégie qui me manque?

4
Kevin

La plupart des sites choisissent l'option n ° 2. Si vous le faites, cela ne nuira pas à votre référencement, car Google sait qu'il existe des versions mobiles de sites Web. C'est pourquoi Google a deux robots: Googlebot et Googlebot-Mobile. Googlebot analyse le type de pages Web et de contenu intégré dans le navigateur du bureau, et Googlebot-Mobile analyse le contenu mobile.

référencement Google mobile récemment couvert . Si vous êtes intéressé par le référencement mobile, cela vaut la peine d'être lu.

Une question très courante que nous voyons est la suivante: est-il important que les différents types de contenu soient servis à partir de la même URL ou d'URL différentes? Par exemple, certains sites Web ont www.example.com comme les navigateurs d'URL de bureau sont destinés à accéder à m.example.com ou à wap.example.com et à les avoir pour les différents appareils mobiles. D'autres sites Web servent tous les types de contenu à partir d'une seule structure d'URL telle que www.example.com.

Pour Googlebot et Googlebot-Mobile, la structure de l'URL n'a pas d'importance tant qu'elle renvoie exactement ce que voit l'utilisateur. Par exemple, si vous redirigez les utilisateurs mobiles de www.example.com vers m.example.com, ils seront reconnus par Googlebot-Mobile et les deux sites Web seront analysés et ajoutés au bon index. Dans ce cas, utilisez une redirection 301 pour les utilisateurs et Googlebot-Mobile.

Si vous diffusez tous les types de contenu à partir de www.example.com, c’est-à-dire du contenu optimisé pour les postes de travail ou optimisé pour les mobiles à partir de la même URL, en fonction de l’agent utilisateur, cela conduira également à une analyse correcte par Googlebot et Googlebot-Mobile. Ceci n'est pas considéré comme une dissimulation par Google.

Il convient de répéter que, quelle que soit la structure de l'URL, vous devez détecter correctement l'agent utilisateur tel que défini par vos utilisateurs et Googlebot-Mobile, et servir le même contenu. N'oubliez pas de conserver le contenu par défaut, le contenu optimisé pour le poste de travail, lorsqu'un utilisateur-agent inconnu le demande.

3
John Conde

Vous devriez également envisager de créer votre site Web pour répondre en fonction de la taille de l'écran.

Ethan Mercotte a publié un article décrivant cela. C'est la technique de tendance actuelle pour traiter avec le mobile de sites Web:

http://www.alistapart.com/articles/responsive-web-design/

À mon avis, il s'agit de la meilleure stratégie mobile et simplifie également le processus de référencement.

2
chrisjlee

Kevin, la réponse à votre question à proprement parler est: cela dépend.

Plusieurs facteurs doivent être pris en compte lors de la sélection d’une des options que vous avez décrites, et aucune n’est "fausse" en soi. Cela dépend simplement de votre objectif et des circonstances.

Cela étant dit, la portée et l’évolutivité de votre site/application sont les principales préoccupations.

J'ai fait pas mal de recherches sur ce sujet pendant 6 mois. - 1 an maintenant (pour mon travail sur CURE.org , où nous avons déjà implémenté l'une de ces options pour cure.org/blog ), et en fait l'a revisité discussion encore cette semaine pour mon site personnel, joelglovier.com .

Donc, quand je dis que "l'évolutivité" est un problème, vous devez vous rappeler que si votre site doit mettre à jour en permanence le contenu, vous devez le gérer aux deux endroits si vous avez votre scénario de m.site.com configuration. Si votre site est basé sur une base de données et/ou utilise un bon CMS, cela n’est pas nécessairement trop difficile à configurer.

Néanmoins, selon la fréquence à laquelle vous créez du nouveau contenu, des pages de destination ou des campagnes sur votre site, il peut s'avérer fastidieux de devoir créer ce contenu deux fois à chaque fois.

Et si vous vous référez à un simple site de portefeuille pour vous-même ou pour un client, il peut être fastidieux de réutiliser du contenu (sans aucun type de base de données ou d’infrastructure CMS).

Par contre, lorsque vous avez un site comme Facebook, par exemple, où l’évolutivité de votre site/contenu est essentielle à ce que vous faites dans son ensemble, un sous-domaine est vraiment très approprié. En partie parce qu'au niveau de l'application Web, vous aurez très certainement un CMS ou un environnement dynamique qui soutiendra assez facilement votre publication de contenu en cours sur le site mobile et l'environnement de bureau (après le développement initial bien sûr).

Le site mobile séparé vous permet en réalité de ne donner aux utilisateurs que le balisage et le contenu que vous souhaitez qu'ils contiennent, plutôt que de tout servir et de cacher une grande partie de ceux-ci via la méthode @ media-queries ou une méthode jQuery.

Personnellement, pour mon propre site de portefeuille simple, j'ai plus ou moins décidé de ne pas avoir de site mobile séparé, car je ne construis rien de vraiment au niveau de l'application. Je vais donc avec les requêtes de médias CSS3 et jQuery fallback pour les utilisateurs IE.

Voici quelques-unes des ressources récentes que j'ai parcourues:

http://trentwalton.com/2011/05/10/fit-to-scale/

http://unstoppablerobotninja.com/entry/responsive-images/

http://css-tricks.com/6206-resolution-specific-stylesheets/

http://www.alistapart.com/articles/responsive-web-design/

http://www.zeldman.com/category/responsive-web-design/

http://thinkvitamin.com/design/getting-started-and-gotchas-of-css-media-queries/

2
Joel Glovier