Hormis pour des raisons historiques, existe-t-il une raison d'avoir «www» dans une URL?
Devrais-je créer une redirection permanente de www.xyz.com
vers xyz.com
ou de xyz.com
vers www.xyz.com
? Lequel suggérez-vous et pourquoi?
Hormis pour des raisons historiques, existe-t-il une raison d'avoir «www» dans une URL?
Devrais-je créer une redirection permanente de www.xyz.com
vers xyz.com
ou de xyz.com
vers www.xyz.com
? Lequel suggérez-vous et pourquoi?
Réponses:
L'une des raisons pour lesquelles vous avez besoin de www
ou d'un autre sous-domaine est liée à une bizarrerie de DNS et à l'enregistrement CNAME.
Supposons, aux fins de cet exemple, que vous exécutez un grand site et que vous sous-traitez l'hébergement à un CDN (réseau de distribution de contenu) tel qu'Akamai. En général, vous configurez l’enregistrement DNS de votre site en tant que CNAME à une akamai.com
adresse. Cela permet au CDN de fournir une adresse IP proche du navigateur (en termes géographiques ou de réseau). Si vous utilisiez un enregistrement A sur votre site, vous ne pourriez pas offrir cette flexibilité.
Le hasard du DNS est que si vous avez un enregistrement CNAME pour un nom d’hôte, vous ne pouvez avoir aucun autre enregistrement pour ce même hôte. Cependant, votre domaine de premier niveau example.com
doit généralement avoir un enregistrement NS et SOA. Par conséquent, vous ne pouvez pas également ajouter un enregistrement CNAME pour example.com
.
L'utilisation de www.example.com
vous permet d'utiliser un CNAME www
qui pointe vers votre CDN tout en laissant les enregistrements NS et SOA requis example.com
. L' example.com
enregistrement aura généralement aussi un enregistrement A pour désigner un hôte sur lequel www.example.com
une redirection HTTP sera redirigée.
ALIAS
(ou les ANAME
disques) dans ce genre de sujet? Ne donne-t-il pas les mêmes résultats que le CNAME sur le domaine nu (sauf en ce qui concerne le problème des cookies ...)?
Remarque: à compter de la ratification et de la mise en œuvre (par tous les navigateurs actuels, à l'exception éventuellement de MSIE 11 , voir les commentaires) de la RFC 6265 en 2011, les informations suivantes ne sont plus exactes, car les cookies ne sont jamais définis par défaut sur plusieurs sous-domaines.
Historiquement , une bonne raison technique de rendre www.example.com
canonique était que les cookies d'un domaine principal (c'est-à-dire example.com
) étaient envoyés à tous les sous-domaines.
Donc, si votre site utilisait des cookies, ils seraient envoyés à tous ses sous-domaines.
Cela a du sens, mais cela a un effet négatif si vous souhaitez uniquement télécharger des ressources statiques, car cela ne fait que gaspiller de la bande passante. Prenez en compte toutes les feuilles de style et les images de votre site Web: en règle générale, il n’ya aucune raison d’envoyer des cookies au serveur lorsque vous demandez une ressource image.
Une bonne solution consiste donc à utiliser un sous-domaine pour les ressources statiques, par exemple static.example.com
, pour économiser la bande passante en n'envoyant pas de cookies. Toutes les images et autres téléchargements statiques peuvent être téléchargés à partir de là. Si vous utilisez maintenant www.example.com
le contenu dynamique, cela signifie que les cookies ne doivent être envoyés qu'à www.example.com
, pas à static.example.com
.
Si, toutefois, example.com
est votre site principal, des cookies seront envoyés à tous les sous-domaines, y compris static.example.com
.
À présent, cela n’est pas pertinent pour la plupart des sites, mais changer votre URL canonique plus tard n’est pas une bonne idée. Une fois que vous avez choisi votre example.com
place www.*
, vous vous en tenez à cela.
Une alternative consiste à utiliser une URL totalement différente pour les ressources statiques. Stack Overflow, par exemple utilise sstatic.net
, utilise YouTube, ytimg.com
etc.…
www.x
l'URL canonique. Personnellement, j'utiliserais probablement une URL différente pour les ressources statiques si je devais concevoir un grand site.
domain=example.com
cookie sur le domaine apex et sur les sous - domaines . Pour éviter cela, évitez d'utiliser le domaine apex pour HTTP. Bien que convenu, une autre solution serait simplement de ne pas spécifier domain
lors de l’installation du cookie. Je me demande si cela a changé depuis que j'ai écrit ma réponse (ce qui est antérieur à la RFC 6265 en question !), Mais je ne me dérangerai pas de la regarder maintenant.
www
est un sous-domaine généralement utilisé pour le serveur Web sur un domaine avec d'autres à des fins telles que, mail
etc. Aujourd'hui, le paradigme de sous-domaine est inutile; Si vous vous connectez à un site Web dans un navigateur, vous obtiendrez le site Web, ou l'envoi de courrier au serveur utilisera son service de messagerie.
Utiliser www
ou non est une question de préférence personnelle. Les points de vue opposés peuvent être trouvés sur http://no-www.org/ et http://www.yes-www.org/ - cependant, je pense que cela www
est inutile et ajoute simplement plus cruellement à l'URI.
La plupart des serveurs envoient le même site de toute façon, mais ne redirigez pas. Pour les besoins du référencement, choisissez l’un puis faites rediriger l’autre. Par exemple, un code PHP pour faire ceci:
if (preg_match('/www/', $_SERVER['SERVER_NAME'])) {
header("Location: http://azabani.com{$_SERVER['REQUEST_URI']}");
exit;
}
Cependant, certaines raisons encourageant l'utilisation d'un www
sous - domaine par d'autres répondeurs sont également utiles , telles que le fait de ne pas envoyer de cookies à des serveurs statiques (crédit Konrad Rudolph ).
C'est assez historique. Il était une fois, auparavant, www.example.com, ftp.example.com, images.example.com, uk.example.com, etc., ce qui semblait être une chose logique à faire et une méthode simple pour répartir la charge entre les serveurs.
Ces jours-ci, je voudrais simplement aller à example.com pour le site principal et rediriger la version www vers celui-ci.
Les outils Google Webmaster vous permettent de spécifier votre domaine préféré . Assurez-vous de les utiliser également.
Voir aussi:
https://stackoverflow.com/questions/1109356/www-or-not-www-what-to-choose-as-primary-site-name
https://stackoverflow.com/questions/1884157/to- www ou pas à www
Si vous allez avoir des sous-domaines à d'autres fins (blog par exemple), vous souhaiterez peut-être différencier les sites et avoir un www
préfixe pour le site standard. Autre que cela, la seule chose importante est de choisir l'un des deux et s'y tenir (pour des raisons de référencement).
www.example.com
partir de example.com
ou vice versa sans quelque chose comme JSONP.
Je ferais le premier. La www
convention vient des débuts de HTTP, où www.cmu.edu et cmu.edu étaient très probablement des machines différentes.
Voici une autre perspective mineure.
En l'absence de www, il existe un inconvénient mineur en ce qui concerne les supports textuels, qu'ils soient imprimés ou en ligne, et c'est de les faire reconnaître comme une adresse Web. En version imprimée, il est généralement assez évident que example.com est une adresse Web, et vous pouvez ajouter des touches de style pour la mettre en valeur. Mais un texte en ligne? Pas si facile. Il est probable que si vous envoyez un message en texte brut - qu’il s’agisse d’un courrier électronique, d’un tweet, d’une publication Facebook, d’un SMS ou autre chose -, il reconnaîtra une URL commençant par http: // ou www. mais ne reconnaîtra personne sans l’un ou l’autre. Donc, pour que l'URL devienne un lien cliquable, vous devez soit mettre www. ou http: // sur le devant, et des deux, www. est plus courte, moins encombrante à regarder et plus facile à lire.
http://example.com/
est pleinement qualifié alors que www.example.com
non. Je préfère l'approche pleinement qualifiée car elle est toujours reconnaissable en tant qu'URL, que ce https://example.uk/
soit https://blog.example.eu/
ou non. Cela est compatible avec la spécification du protocole d'un site sécurisé en tant que HTTPS; www.example.com
est juste un domaine et ne dit rien sur le protocole à utiliser pour y accéder.