Devrais-je inclure «www» dans les URL de mon site Web? Quels sont les avantages et inconvénients?

Quels sont les avantages et les inconvénients d'avoir http://www.example.com/vs http://example.com/?

Par exemple, un problème que je connais est que si j'utilise un domaine sans, wwwje ne peux pas définir de cookie pour le sous-domaine actuel uniquement (car il n'y a pas de sous-domaine), et les cookies que je définis sont envoyés à tous les sous-domaines.

N'oubliez pas que l'utilisation de ce www.example.combouton vous permet de définir des cookies uniquement sur le site principal . L'utilisation example.comne vous permettra que de définir des cookies *.example.comqui incluent static.example.com. Ainsi, chaque demande pour n'importe quel sous-domaine inclura les cookies, ce qui ralentira un peu le transfert. L'utilisation www.example.comvous permettra de décider pour quelle partie vous souhaitez créer des cookies.

Si vous allez utiliser www.example.com, vous devriez faire example.comune réorientation permanente vers www.example.com.

Dans wwwcertains cas, le sous-domaine est en fait un serveur complètement différent de celui du TLD parent. Bien que la plupart des moteurs de recherche soient assez intelligents pour le comprendre, il est toujours bon de placer le renvoi.

Je suis l'inverse complet de cela, www.example.comest une redirection permanente vers example.com, parce que je préfère utiliser l'URL canonique plus courte. Il est également logique pour moi que je puisse espérer qu'une requête HTTP example.comgénérera une page Web ou une redirection vers tout sous-domaine traitant de requêtes HTTP.

De plus, vous souhaitez que les personnes qui pointent sur votre site utilisent l'URL canonique, celle qu'elles sélectionnent dans la barre d'outils de leur navigateur. La redirection sur celle qui N'EST PAS votre URL canonique permet d'assurer la cohérence à cet égard.

Y compris le wwwsous - domaine semble se résumer à deux conditions:

1. Cookies - La définition de cookies *.example.comrisque de causer du chagrin (davantage de trafic), car les cookies seront envoyés à chaque demande, quel que soit le sous-domaine. Dans ce cas, je choisirais d'utiliser le, wwwcar cela me donne le choix de définir des cookies à savoir *.example.comsi j'en ai besoin (par exemple, un cookie d'utilisateur authentifié), ou www.example.comde réduire le trafic sur mes autres sous-domaines.

2. Esthétique - Est-ce que je me soucie beaucoup de l'apparence du domaine? Si je déteste vraiment le wwwtrafic mais que je suis inquiet à propos du trafic de cookies, je pourrais atténuer le problème en hébergeant mon contenu statique sur un tout nouveau domaine tel que celui static-example.comqui resterait sans cookie.

Ceci est une considération mineure mais pertinente pour les sites commerciaux. Les utilisateurs non techniques s'attendent à ce qu'un site Web commence avec www, par conséquent, lorsqu'ils ne voient pas qu'ils pourraient ne pas penser à un domaine en tant que site Web.

Bien que cela puisse sembler ridicule à ceux d'entre nous qui savent comment fonctionnent les choses, j'ai souvent rencontré cette attitude avec leur famille, leurs amis et leurs collègues non techniques, et ces personnes sont susceptibles de représenter la grande majorité de vos clients.

En outre, de nombreux logiciels tels que la messagerie électronique, les processeurs mondiaux, les clients de réseaux sociaux & co reconnaîtront automatiquement un nom de domaine commençant par wwwun lien hypertexte et le rendront actif - avec un domaine nu ou un non-wwwdomaine que vous devrez ajouter http://pour le logiciel. pour le rendre actif. Le fait de pouvoir cliquer sur un lien au lieu de copier-coller dans un navigateur peut faire la différence entre un client visitant votre site ou se rendant chez votre concurrent.

Il ne semble pas y avoir de raison concrète d’utiliser l’une sur l’autre en ce qui concerne les résultats de recherche ou d’autres résultats souhaités. Ma préférence personnelle est no-wwwdue à la longueur.

Le plus important est de vous assurer que vous redirigez vos travaux vers votre domaine préféré et de définir votre domaine préféré dans la console de recherche Google (Google Webmaster Tools).

Sans répéter les réponses valables ci-dessus concernant les cookies, l'esthétique, les utilisateurs non techniques attendant le wwwsous - domaine, etc.

Une autre raison pour laquelle j'ai tendance à privilégier l' www.approche de sous - domaine pour le site principal est le développement local. J'utilise local.pour mon serveur de test local. Je m'attends toujours à ce que le site soit accessible via un sous-domaine et puisse facilement faire la distinction entre les sites de test et les sites en direct, si nécessaire. Les cookies peuvent être conservés séparément des sites locaux et réels.

• www.example.com Site en direct
• local.example.com Serveur de test local

L'utilisation d'un sous-domaine pour le serveur de test facilite également les tests à partir d'un appareil mobile, car le sous-domaine peut être défini dans le DNS public qui pointe vers un serveur de test local (IP local). Ce n'est que lorsque le périphérique mobile est sur le réseau WiFi local qu'il pourra accéder au serveur de test local. (Assurez-vous que les optimisations de navigateur mobile sont désactivées lors de la connexion locale, sinon le serveur d'optimisation distant tentera également d'accéder à votre serveur local et échouera.)

Oui, utilisez toujours à la wwwplace d'un domaine nu. Bien que Heroku soit quelque peu spécialisé, le type de structure de routage qu’il a créé va probablement devenir plus courant à mesure que les utilisateurs déploient des sites Web sur des grappes d’ordinateurs. Les domaines nus sont beaucoup moins flexibles que www, car ils nécessitent un enregistrement A au lieu d'un enregistrement CNAME. Voir https://devcenter.heroku.com/articles/avoiding-naked-domains-dns-arecords .

Bien que vous ne le pensiez peut-être pas aujourd'hui, tous les sites Web devraient et, espérons-le bientôt, utiliseront tout le temps le protocole SSL. En effet, la sécurité vaut toujours mieux que pas de sécurité et les coûts liés à SSL ne représentent déjà qu'environ 1% de CPU supplémentaire (voir http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html ). Vous devriez également obtenir votre certificat SSL pour www.

Mes gens du référencement me disent que Google n'aime pas les domaines nus. Un symptôme de ceci est que si vous essayez de rediriger votre myblog.blogspot.comblog vers example.com/blog, vous obtiendrez une erreur indiquant que les blogs ne peuvent pas être hébergés sur des domaines nus .