URL d'un site mobile distinct
J'ai parcouru ce site et découvert plusieurs questions similaires mais aucune ne répond à mes besoins actuels.
Normalement, je crée des sites réactifs, mais parfois, je crée un site "de bureau" et un "site mobile".
Ces sites utilisent le même contenu de la même base de données, mais celui-ci est servi différemment en HTML.
J'utilise la détection de navigateur pour déterminer le code HTML utilisé. Je me rends compte qu'il est discutable de savoir si ces deux sites constituent des "sites" distincts, mais c'est le terme que j'utiliserai pour cette question.
Ma préférence actuelle est de garder l'URL exactement identique entre les deux sites. Pas de préfixe ou suffixe comme m. ou .mobi
Hormis les cookies de domaine/session, je ne sais pas quoi d'autre pourrait être affecté par cela. Étant donné que de nombreux sites utilisent, par exemple, m., je suppose qu’il ya un avantage. Quelqu'un peut-il s'il vous plaît éclaircir un peu pourquoi cela pourrait être?
Si j'avais un contenu séparé, je penserais probablement que m. était approprié, mais comme il s'agit exactement du même contenu et de la même hiérarchie, je ne vois pas le but.
De plus, l’URL unique permet un partage facile entre appareils (de mobile à ordinateur de bureau).
Quels sont les avantages, le cas échéant, de l'utilisation d'une URL distincte pour un site mobile où la version mobile et la version de bureau partagent le même contenu?
Pour être clair, il existe un moyen de visualiser le site de bureau sur un mobile en utilisant un lien. De plus, je peux le faire fonctionner de manière à ce que l’ajout de /mobile/ ou le préfixe m. renvoie la version mobile, mais l’ajout ne persiste pas sur le site.
EDIT
J'aurais dû le préciser avant. J'utilise un CMS avec un réécriteur d'URL intégré (en fait, il est toujours utilisé, quel que soit le nombre de sites que vous avez, pour créer des URL conviviales). En raison de la nature des sites que je crée, les cookies sont inévitables.
Personnellement, je suis un partisan de l’approche d’un domaine comme vous le faites, mais je pensais pouvoir ajouter quelques considérations supplémentaires à ajouter aux bons conseils déjà donnés par d’autres ici.
- Le référencement est une raison majeure pour utiliser deux domaines OU un. Deux domaines = deux sites commercialisables distincts et un site peut être affiché sur les marchés des applications. D'autre part, vous séparez votre contenu et votre classement de liens et vous vous exposez à d'éventuels problèmes de contenu en double. Comme l'a dit un utilisateur à propos du contenu dupliqué, il est facile de lutter contre les balises canoniques et les liens de page vers la version mobile/desktop. Les balises canoniques sont une invention de Google et je ne sais pas combien d'autres moteurs de recherche (le cas échéant) l'ont adopté.
- Googlebot n'utilise pas de cookies/sessions pour explorer votre site. Et les chaînes d'agent utilisateur sont inutiles dans de nombreuses situations. C’est là que les liens sur les liens page/version mobile sont utiles.
- détection mobile peut être difficile et volumineux et doit être mis à jour. Deuxièmement, lorsqu'un nouvel appareil sort demain, vous devez modifier votre code de détection. Un secondaire m. ou le domaine .mobi ne le fait pas car il a été construit pour cela.
- Certains webmasters veulent que Google indexe leur domaine mobile séparément dans Google Mobile Search. Ils veulent spécifiquement classer un site ou une section de leur site différemment.
- certains webmasters souhaitent commercialiser deux sites de manière différente et desservir différents AD. Ajoutant également un inventaire supplémentaire pour les acheteurs de médias.
- L’optimisation des performances Web peut être plus facile à réaliser pour une application Web distincte que pour une application réactive ou qui charge une conception différente.
- certains webmasters veulent mettre leur site/application mobile sur un marché d'applications mobiles (oui, même s'il ne s'agit que d'un site HTML et non d'une application, les gens le font de toute façon.). Vous ne pouvez pas vraiment faire cela à moins d’avoir (m. Ou .mobi ou/mobile).
- Pour certains marchés, et la masse de visiteurs qui les visitent, sont plus à l'aise et comprennent mieux une URL de site mobile.
GO TO http://mobile.bluewidget.com Today!qui peut avoir un sens pour une personne non avertie telle queOH I didn't know I can visit this site on my iPhone too!et sont plus susceptibles de l'essayer maintenant sur leur téléphone ou leur tablette. - Google a sitemap.xml spécifique au mobile
- Les moteurs de recherche, comme Google, peuvent traiter les sites mobiles différemment . C'est également une différence majeure, le fait que votre site fonctionne en 320 pixels ne signifie pas qu'il s'agit d'un site Web mobile ou qu'il fonctionnera sur tous les appareils mobiles. C'est formidable pour les smartphones modernes, mais comme l'explique ce document, il existe encore des téléphones pouvant tirer parti de la création de sites distincts utilisant la technologie mobile (plus ancienne) normalisée.
Outre le référencement, l'un des problèmes est de savoir à quoi ressemble l'URL lorsque les gens l'utilisent/l'impriment/l'envoie. Si vous allez rediriger les personnes vers m lorsqu'elles accèdent à www, si elles se trouvent sur un appareil mobile, et si vous redirigez les personnes vers www de m lorsqu'elles ne le sont pas, qu'avez-vous réalisé en utilisant des domaines distincts?
Autant que je sache, il n'y a pas d'avantages. Mais la raison pour laquelle les gens ont décidé d'utiliser m. et www. domaines dans le passé est parce que soit:
- Ils n'utilisent pas uniquement les requêtes multimédia css pour changer la version de leur ordinateur en leur version mobile.
- Leur plate-forme de serveur ne peut pas envoyer de balisage différent au mobile que les appareils non mobiles.
Si vous pouvez utiliser l'une ou l'autre des méthodes ci-dessus, je vois non un avantage à utiliser des domaines distincts.
Question interessante.
Google peut lire votre site quelle que soit la détection. Lequel de ces fichiers est-il indexé? La version mobile ou desktop? Et comment vous assurez-vous qu'il n'apparaît pas comme du spam!?
Si vous avez 2 URL et que la page est rendue assez différemment (et que le contenu est affiché différemment), vous ne devriez pas être vu comme un spam de la nouvelle URL (par exemple, m.domain.com) ... le sous-domaine plus toute métadonnée supplémentaire ne devrait être suffisant pour informer le moteur de recherche que c'est pour un navigateur mobile.
Si vous utilisez un site et une détection de "plateforme", transmettez-le à une session/à un cookie, puis affichez le contenu en conséquence, je pense.
1) la maintenance est difficile et
2) Que se passe-t-il si le navigateur ne supporte pas les cookies? Je crois que les sessions utilisent des cookies uniquement pour garder une trace du visiteur (bien que tout le contenu soit enregistré sur le serveur). Vous aurez besoin d'un moyen de les laisser choisir la version "allégée" de votre site (la version mobile).
De plus, que se passe-t-il si je souhaite afficher la version pour ordinateur ou la version mobile comme vous le demandez - le fait de dépendre des cookies peut gêner l'utilisateur (si l'utilisateur les a désactivés ou doit cliquer sur un lien pour obtenir ce qui devrait être être le choix par défaut pour la plate-forme) et votre débogage fastidieux.
Donc, pour répondre à votre question, vous pouvez l'avoir comme vous le souhaitez! Préfixe avec un m. ou utilisez le dossier/mobile/ou l’annexe, ou même tout ce qui précède.
Si c’était moi, j’utiliserais le domaine 2 (www. Et mobile.)
En plus des autres réponses, il y a quelques obstacles sur le chemin:
Problèmes
Les moteurs de recherche n'aiment pas quand vous avez du contenu en double sur le même domaine. Si le même message apparaît à deux endroits différents de votre domaine, le classement de votre recherche en souffre.
Comment détectez-vous la plate-forme? Scripts basés sur UserAgent? non fiable . Biscuits? Illégal, sans consentement (selon les lois de l'UE).
Solutions
Un simple tag canonique à votre version de bureau devrait faire l'affaire.
Selon votre serveur, il pourrait être très facile de faire une réécriture d’URL. Cela dit, je suggère fortement le design réactif.
La technique est bien supportée, mais mon aspect préféré est que la plupart des navigateurs modernes ne récupèrent pas les ressources DOM pour les éléments qu’ils ne rendent pas. Par exemple, j'ai intégré une vidéo YouTube (iframe) à mon site. mon bureau css dit "display: block" alors que mobile css dit "display: none". Les navigateurs utilisant le css mobile ne cingleront pas youtube.com car ils ne figurent pas dans le DOM actif, car l’iframe est affiché sous forme de texte arbitraire sur une plate-forme mobile.
Est-ce que ça vaut le coup?
Personnellement, je trouve qu'il est beaucoup moins fastidieux de répondre à une requête multimédia en fonction de la taille de l'écran.
Les réécritures d'URL peuvent être réussies, mais tout se résume à détecter la plateforme en premier lieu. Je suis sûr que vous pourriez écrire du javascript pour détecter certaines fonctionnalités du navigateur, puis rediriger vos résultats en fonction des résultats, mais comment transmettriez-vous ces informations? Le fait est que vous pouvez parcourir toutes ces étapes pour créer un site distinct. Peut-être que les quelques Kb de bande passante enregistrée en valent la peine, mais votre temps serait mieux utilisé ailleurs.
vous devrez donner à Google annotations pour indiquer que le m.yoursite.com/page est la version mobile de www.yoursite.com/page
vous devez lire ce message sur le blog de Google Webmasters à propos de comment configurer un site Web qui diffuse un contenu différent sur différents appareils