HTTPS avec WWW vs Non WWW : lequel choisir ?

Mis à jours 11 mars 2018 La saisie de www n’est plus à la mode avec la montée en puissance de la navigation sur le Web mobile, de sorte que de nombreux propriétaires de sites ont choisi de la laisser tomber. Mais, est-ce bon pour le référencement ? Et qu’en est-il du suivi des cookies dans les sous-domaines ?

Allons découvrir si la saisie de www ou non est la meilleure solution pour votre site et comment vous assurer que Google connaît vos préférences, et comment ne pas confondre votre référencement, en particulier avec HTTPS.

Jargon

Pour vous aider à mieux comprendre l’ensemble du concept de domaine et de lien, allons-nous voir plus clair le jargon technique en langage non geek.

Domaines

tophebergeur est un nom de domaine racine.

tophebergeur.com est un nom de domaine racine avec une extension de domaine de premier niveau (la partie .com). Les autres extensions de niveau supérieur incluent .net, .org, .biz et .info.

WWW est considéré comme un sous-domaine.

Ainsi, www.tophebergeur.com est considéré comme un domaine de deuxième niveau parce que tophebergeur.com est un sous-domaine de www.

Lorsque nous ajoutons un autre sous-domaine, tel que www.webblog.tophebergeur.com, il est considéré comme un domaine de troisième niveau, alors que webblog.tophebergeur.com est considéré comme un deuxième niveau.

Lorsqu’un domaine n’a pas de sous-domaine, y compris www, il s’appelle un domaine nu.

Liens canoniques

Dans WordPress, allez dans Paramètres, puis dans Général.

Les deux URL répertoriées ici doivent être identiques et constituent l’URL canonique de votre site.

Ils seront soit http ou https avec www ou non.

Chaque nouveau lien que vous créez sera dérivé de cette canonique.

Les nouveaux liens incluent :

Donc, si vous changez soudainement la canonique dans ces paramètres, tous les nouveaux liens vont la correspondre.

Mais, cela ne convertit pas vos liens existants au nouveau canonique.

Cela n’a d’impact que sur les liens nouvellement créés.

Les anciens liens canoniques sont toujours dans votre base de données et ils sont simplement redirigés vers le nouveau chemin d’URL.

On va apprendre plus sur les redirections dans un instant.

Informations sur l’en-tête masqué

Lorsqu’un visiteur demande un lien vers votre site, une infobulle d’informations cachées est envoyée à son navigateur avec les informations de la page/publication du site qui seront affichées sur leur écran.

Les informations d’en-tête masquées contiennent :

Exemple d’en-tête

Disons que votre canonique est http et www.

Lorsqu’un visiteur tape dans cette canonique, les informations d’en-tête ressemblent à ceci :

Il a un statut de 200 ok et le reste de l’information d’en-tête cachée.

Redirections WWW

WordPress gère en interne le www ou les non-redirections.

Donc, si votre canonique est www et qu’un utilisateur mobile n’a pas saisi cette partie, alors WordPress redirige en interne vers la canonique et l’en-tête ressemble à ceci :

Maintenant, vous avez une redirection 301 avant d’arriver sur la destination finale de 200 ok.

HTTPS et WWW

Comme indiqué précédemment, www est un sous-domaine, également appelé nom d’hôte, et WordPress gère en interne la redirection.

HTTPS est un protocole.

Il détermine si le visiteur se connecte à votre site via un port sécurisé ou non sécurisé sur le serveur hôte.

Le port 80 n’est pas sécurisé et utilise http.

Le port 443 est crypté et utilise https.

Le serveur hôte détermine comment les requêtes entrantes sont acheminées vers ces deux ports.

HTTPS et redirections

Le moyen gratuit de changer votre site en HTTPS nécessite de changer le canonique en https et en forçant tous les liens à utiliser le port HTTPS pour se connecter.

Et si vous changez simplement votre canonique dans les paramètres sur WordPress à non www, vous avez soudainement un tas de différents types de liens dans votre base de données.

Et cela signifie que vous avez un tas de redirections différentes.

Quel désordre !

En fait, la conversion des liens de la base de données vers la nouvelle version canonique élimine tout ce chaos.

Tous les anciens et futurs liens seront vraiment changés correspondant aux nouveaux canoniques.

Redirections forcées

Pour info, il est recommandé de forcer toutes les requêtes entrantes à utiliser HTTPS si votre site a été déjà converti.

Vous pouvez également forcer www ou non, mais la plupart des gens ne le font pas, car cela est déjà géré par WordPress.

Anciens liens inaccessibles dans le monde

Peu importe comment vous avez changé en HTTPS ou www ou non, vos liens précédemment partagés sont inaccessibles dans le monde, mais une certaine forme de redirection sera impliquée pour les forcer à se conformer à la nouvelle canonique.

Voici un exemple :

Disons que vous êtes un blogueur sur la gastronomie et vos publications sont persistantes.

Cela signifie que vous avez probablement des milliers de liens http-www partagés partout sur le Web, sur les médias sociaux et d’autres sites.

Lorsque vous convertissez en « https et non www », tous ces liens précédemment partagés seront redirigés soit par le serveur hôte et/ou WordPress pour se conformer à la nouvelle canonique. Et c’est ce qui s’affichera dans la barre d’URL lors du chargement de la page.

Exemple de redirection

Alors, disons que votre nouvelle canonique est https et www.

Lorsqu’un visiteur du site entre le http non canonique et non www, votre chaîne de redirection d’en-tête ressemble à ceci :

Le serveur hôte a forcé une redirection vers le port https crypté.

Et WordPress a forcé une redirection interne à www.

Donc, vous avez une chaîne de redirection de 301, 301, 200.

Il y a beaucoup de redirection !

Dans ce cas, vous voulez faire tout ce que vous pouvez pour minimiser les chaînes de redirection.

Redirections et SEO

Chaque fois qu’un lien doit passer par une redirection, il peut perdre un peu du “jus de Google”.

Alors, vous voulez éviter toutes les redirections autant que vous pouvez.

Vous ne pouvez rien faire concernant les liens que vous avez déjà partagés sur les réseaux sociaux par le passé.

Mais, vous pouvez partager les nouveaux liens canoniques à partir du moment où vous faites le changement et aller de l’avant.

Vous pouvez également mettre à jour tous les URL de votre site dans vos profils de médias sociaux.

Au fil du temps, les anciens liens ne seront tout simplement plus cliqués car ils ne seront pas vus.

Google Analytics et la Search Console

Il est facile de modifier vos paramètres de propriété Google Analytics avec votre nouvelle version canonique.

Cela ne changera rien dans le suivi, et aucune de vos anciennes données de suivi ne sera perdue.

Par contre, Google Search Console est une histoire différente.

Vous devez vérifier la propriété du site pour chaque version de l’URL de votre site.

Cela signifie donc vérifier votre domaine nu avec :

Assurez-vous de soumettre votre sitemap XML à la version canonique.

Si vous envisagez d’apporter une modification à votre canonique, assurez-vous d’avoir un sitemap XML envoyé à la version de la propriété telle qu’elle se présente actuellement.

Recréez ensuite votre sitemap XML après la modification, vérifiez cette propriété dans GSC et soumettez le nouveau sitemap XML.

Fondamentalement, Google a dit qu’il préfère que vous donniez juste toutes les informations et qu’il réglera tout.

Données et messages de Search Console

Jusqu’à ce que Google récupère les modifications canoniques apportées à votre site, en particulier si vous ne leur avez pas imposé les redirections, les robots de Google peuvent toujours afficher les liens et les explorations sur vos versions de propriété précédentes.

C’est une bonne idée de tout nettoyer après avoir effectué le changement.

Les données de Google comprennent :

Une fois que vous avez tout nettoyé, vous pouvez faire une recherche comme Google pour lancer une nouvelle exploration.

Si vous avez forcé les redirections, ces robots exploreront les nouveaux liens canoniques.

Google finira par comprendre que vous avez effectué un changement de lien majeur. Il peut s’écouler entre 3 et 6 mois avant que toutes les informations relatives à votre propriété s’affichent dans la Search Console.

Pas de perte de SEO sur les liens entrants

Les backlinks sont au cœur du référencement SEO.

Si vous avez des liens entrants vers votre ancien canonique, ils compteront toujours dans le classement de votre domaine nu même après que vous ayez passé à un nouveau canonique.

Gardez à l’esprit que ce que Google vous montre sur chacune des différentes propriétés de la version de Search Console est différent de la façon dont Google agrège toutes ces données et les regroupe dans leur algorithme de classement.

Donc, même si cela peut vous paraître comme un tas d’informations différentes, c’est une grande chose pour Google.

Même les jus des sous-domaines et des sous-répertoires flottent vers le domaine racine, bien qu’il y ait toujours un fervent débat sur lequel l’un d’entre eux flotte le plus vers le domaine racine.

Pour conclure, changer votre canonique n’a pas d’impact négatif sur votre référencement sur les liens entrants.

De plus, Google donne un coup de pouce dans les classements en ce moment pour tous les sites qui sont HTTPS, de sorte que vous allez profiter de cet avantage pour aussi longtemps que cela dure.

Si vous avez le temps, vous pouvez demander aux sites de haute qualité de vous donner un backlink pour mettre à jour votre nouveau canonique. Cela ne vous donne pas un coup de pouce dans le classement, mais il supprime une chaîne de redirection de plus.

Pourquoi garder WWW ?

Il n’y a que deux bonnes raisons de conserver le sous-domaine www.

1 ère Raison

WWW rend l’ajout des enregistrements DNS plus flexible, en ajoutant spécifiquement des enregistrements pour plusieurs sous-domaines ou sous-répertoires sur un hébergement cloud redondant.

Par exemple, si vous avez un site au niveau de l’entreprise (pensez à la taille d’Amazon) et que les fichiers de votre site sont distribués à travers les services cloud, vous avez besoin du DNS pour avoir un enregistrement CNAME. Vous ne pouvez pas faire cela avec un domaine nu (sans www).

2ème Raison

Si vous avez un site énorme et que vous diffusez du contenu statique d’une autre source pour accélérer le chargement de la page, vous devez vous assurer que les informations de cookie de l’en-tête de votre site ne sont pas transmises au sous-domaine. Cela devient un énorme problème de vitesse et détruit toute la raison pour laquelle vous fournissez du contenu statique à partir d’une source secondaire. Si vous n’utilisez pas www, le seul moyen de contourner ce problème consiste à acheter un autre domaine pour le contenu statique.

Les blogueurs n’ont pas besoin de WWW

Il est évident de voir que la plupart des blogueurs, peu importe leur taille, n’ont pas les deux raisons ci-dessus pour garder www dans leur URL.

Ce qu’ils ont, ce sont plus de visiteurs mobiles que jamais, et ces visiteurs détestent taper plus qu’ils ne le doivent.

S’ils cliquent simplement sur un lien partagé qu’ils ont vu sur Facebook, c’est le nouveau canonique, donc pas de soucis.

C’est pourquoi tant de blogueurs abandonnent www maintenant.

Nombre de partages

La seule autre chose à laquelle vous devez vous préoccuper lorsque vous modifiez les liens pour HTTPS et WWW est le nombre de vos partages, si vous les affichez.

Ils devront être récupérés et il n’y a que deux plugins de partage qui peuvent le faire.

De plus, toutes les plateformes de médias sociaux ne participent pas à la fourniture de comptes ou à cette récupération.

Pinterest est l’un des rares qui vous permette de récupérer un nombre de partages assez précis, et cela ne restera peut-être pas éternellement non plus.