Depuis des années, une petite guerre de pédantisme fait rage dans nos bars d'adresses. Dans un coin se trouvent des marques comme Google, Instagramet une Facebook. Ce groupe a choisi de rediriger example.com à www.example.com. Dans le coin opposé : GitHub, DuckDuckGoet une Discorde. Ce groupe a choisi de faire l'inverse et de rediriger www.example.com à example.com.
« WWW » appartient-il à une URL ? Certains développeurs ont des opinions bien arrêtées sur le sujet. Nous explorerons les arguments pour et contre après un peu d'histoire.
C'est quoi les W ?
Les trois W signifient "Internet", une invention de la fin des années 1980 qui a fait découvrir au monde les navigateurs et les sites Web. La pratique consistant à utiliser « WWW » découle d'une tradition consistant à nommer les sous-domaines d'après le type de service qu'ils fournissent :
- un serveur Web à www.example.com
- un serveur FTP sur ftp.exemple.com
- un serveur IRC à irc.exemple.com
Problème de domaine sans WWW 1 : fuite de cookies vers des sous-domaines
Les détracteurs des domaines "sans WWW" ont souligné que dans certaines situations, subdomain.example.com serait en mesure de lire les cookies mis en place par example.com. Cela peut être indésirable si, par exemple, vous êtes un fournisseur d'hébergement Web qui permet aux clients d'exploiter des sous-domaines sur votre domaine. Bien que le problème soit valable, le comportement était spécifique à Internet Explorer.
RFC 6265 standardise la façon dont les navigateurs traitent les cookies et signale explicitement ce comportement comme incorrect.
Une autre source potentielle de fuites est la Domain Plus-value de tous les cookies installés par example.com. Si l' Domain la valeur est explicitement définie sur example.com, les cookies seront également exposés à ses sous-domaines.
| Valeur des cookies | Exposé à example.com | Exposé à subdomain.example.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
En conclusion, tant que vous ne définissez pas explicitement un Domain et que vos utilisateurs n'utilisent pas Internet Explorer, aucune fuite de cookie ne devrait se produire.
Problème de domaine sans WWW 2 : maux de tête DNS
Parfois, un domaine « sans WWW » peut compliquer la configuration de votre système de noms de domaine (DNS).
Lorsqu'un utilisateur tape example.com dans la barre d'adresse de leur navigateur, le navigateur doit connaître l'adresse IP (Internet Protocol) du serveur Web qu'ils essaient de visiter. Le navigateur demande cette adresse IP aux serveurs de noms de votre domaine, généralement indirectement via les serveurs DNS du fournisseur d'accès Internet (FAI) de l'utilisateur. Si vos serveurs de noms sont configurés pour répondre avec un Un enregistrement contenant l'adresse IP, un domaine « sans WWW » fonctionnera correctement.
Dans certains cas, vous voudrez peut-être utiliser à la place un Nom canonique (CNAME) enregistrer pour votre site Web. Un tel enregistrement peut déclarer que www.example.com est un alias de exemple123.somecdnprovider.com, qui indique au navigateur de l'utilisateur de rechercher à la place l'adresse IP de exemple123.somecdnprovider.com et y envoyer la requête HTTP.
Notez que l'exemple ci-dessus utilise un sous-domaine WWW. Il n'est pas possible de définir un enregistrement CNAME pour example.com. Selon RFC 1912, les enregistrements CNAME ne peuvent pas coexister avec d'autres enregistrements. Si vous avez essayé de définir un enregistrement CNAME pour example.com, le serveur de noms (NS) enregistre pour example.com contenant les adresses IP des serveurs de noms de domaine ne seraient pas autorisés à exister. Par conséquent, les navigateurs ne seraient pas en mesure de déterminer où se trouvent vos serveurs de noms.
Certains fournisseurs DNS vous permettront de contourner cette limitation. Cloudflare appelle leur solution Aplatissement CNAME. Avec cette technique, les administrateurs de domaine configurent un enregistrement CNAME, mais leurs serveurs de noms exposeront un enregistrement A.
Par exemple, si l'administrateur configure un enregistrement CNAME pour example.com pointant vers exemple123.somecdnprovider.com, et un enregistrement A pour exemple123.somecdnprovider.com existe pointant vers 1.2.3.4, alors Cloudflare exposerait un enregistrement A pour example.com pointant vers 1.2.3.4.
En conclusion, si le souci est valable pour les propriétaires de domaines qui souhaitent utiliser des enregistrements CNAME, certains fournisseurs de DNS proposent désormais une solution de contournement adaptée.
Avantages sans WWW
La plupart des arguments contre WWW sont pratiques ou cosmétiques. Les partisans du "No-WWW" ont fait valoir qu'il est plus facile de dire et de taper example.com que www.example.com (ce qui peut être moins déroutant pour les utilisateurs moins avertis).
Les opposants au sous-domaine WWW ont également souligné que son abandon s'accompagne d'un modeste avantage en termes de performances. Les propriétaires de sites Web pourraient ainsi supprimer 4 octets de chaque requête HTTP. Bien que ces économies puissent s'additionner pour les sites Web à fort trafic comme Facebook, la bande passante n'est généralement pas une ressource rare.
Avantages du Web
Un argument pratique en faveur du WWW est dans les situations avec des domaines de premier niveau plus récents. Par exemple, www.exemple.miami est immédiatement reconnaissable en tant qu'adresse Web lorsque exemple.miami n'est pas. Ceci est moins préoccupant pour les sites qui ont des domaines de premier niveau reconnaissables comme .com.
Impact sur votre classement dans les moteurs de recherche
Le consensus actuel est que votre choix n'influence pas les performances de votre moteur de recherche. Si vous souhaitez migrer de l'un vers l'autre, vous devrez configurer des redirections permanentes (HTTP 301) au lieu de temporaires (HTTP 302). Les redirections permanentes garantissent que la valeur SEO de vos anciennes URL est transférée aux nouvelles.
Conseils pour soutenir les deux
Les sites choisissent généralement soit example.com or www.example.com comme site officiel et configurez les redirections HTTP 301 pour l'autre. En théorie, il est possible de supporter les deux www.example.com ainsi que example.com. En pratique, les coûts peuvent l'emporter sur les avantages.
D'un point de vue technique, vous voudrez vérifier que votre pile technologique peut le gérer. Votre système de gestion de contenu (CMS) ou votre site généré statiquement devrait produire des liens internes sous forme d'URL relatives pour préserver le nom d'hôte préféré du visiteur. Vos outils d'analyse peuvent enregistrer le trafic vers les deux noms d'hôte séparément, sauf si vous pouvez configurer les noms d'hôte en tant qu'alias.
Enfin, vous devrez franchir une étape supplémentaire pour protéger les performances de votre moteur de recherche. Google considérera les versions "WWW" et "non WWW" d'une URL comme étant duplicate content. Pour dédupliquer le contenu dans son index de recherche, Google affichera celui des deux qu'il pense que l'utilisateur préférera - pour le meilleur ou pour le pire.
Pour conserver le contrôle sur la façon dont vous apparaissez dans Google, il est recommandé d'insérer des balises de lien canoniques. Tout d'abord, décidez quel nom d'hôte sera le nom d'hôte officiel (canonique).
Par exemple, si vous choisissez www.example.com, vous devrez insérer l'extrait de code suivant dans le tag sur https://example.com/my-article:
Cet extrait indique à Google que la variante "WWW-less" représente le même contenu. En général, Google préférera la version que vous avez marquée comme canonique dans les résultats de recherche, qui serait la variante "WWW" dans cet exemple.
Conclusion
Malgré d'intenses campagnes de part et d'autre, les deux approches restent valables tant que vous êtes conscient des avantages et des limites. Pour couvrir toutes vos bases, assurez-vous de mettre en place des redirections permanentes de l'une à l'autre et le tour est joué.
