Meilleures pratiques HTTPS pour le référencement et la convivialité
Considérons une page, http://example.com, qui peut être visualisée publiquement et lorsqu'un utilisateur s'authentifie. Supposons maintenant que vous activiez le protocole HTTPS pour chaque page lorsqu'un utilisateur se connecte à votre site Web, mais uniquement lorsqu'il est connecté. Votre page, http://example.com devient désormais https://example.com pour tous les utilisateurs connectés. Si cet utilisateur connecté aime votre page et décide de créer un lien vers celle-ci via un blog ou un site Web de réseau social, il y a de fortes chances pour qu'il utilise la version HTTPS de l'URL.
Du point de vue du référencement, quelle est votre stratégie pour éviter les problèmes de contenu en double entre les deux URL?
Que devrait-il se passer si un utilisateur arrive à l'URL HTTPS mais ne s'est pas connecté ou n'a pas de compte? Devrait-il y avoir une redirection vers la version HTTP? Si oui, comment vous y prendriez-vous?
Mon instinct est que, pour toutes les pages pouvant être visualisées publiquement et lors de la connexion, la page doit d'abord détecter si l'utilisateur est connecté. Si connecté, il reste HTTPS ou utilise une redirection 302 de la version HTTP vers HTTPS. Si l'utilisateur n'est pas connecté et qu'il arrive à la version HTTPS de l'URL, il utilise une redirection 301 vers la version HTTP. Cependant, je souhaiterais une solution plus élégante ou efficace.
Edit: Je supposais que si un utilisateur était connecté, chaque URL devrait être HTTPS (ou du moins, cela devrait être une option), mais comme je l'ai fait un peu plus de recherches, peut-être que hypothèse était fausse. La façon dont je vois les personnes qui l’implémentent est qu’elles n’activent le HTTPS que pour les pages qui envoient et reçoivent des données sensibles: connexion, validation du panier d’achat, gestion du profil utilisateur, etc. J'essaie de déterminer quel modèle est le meilleur.
Apparemment, Google Mail donne aux utilisateurs la possibilité d'utiliser ou non le protocole HTTPS sur chaque page via un paramètre du profil de l'utilisateur. C'est certainement une option, mais je devrais tout de même aborder le comportement des pages accessibles au public pour tous les états d'authentification.
Étant donné que je construis un système de gestion de contenu qui sera utilisé par d'autres personnes, je dois m'assurer de bien faire les choses. Quels paramètres doivent être disponibles pour le propriétaire du site? À ce stade, je pense au contrôle granulaire de chaque page (sécurisée ou non avec SSL), puis de l’ensemble du site. Cependant, donner ce niveau de contrôle peut être une erreur si les gens ne comprennent pas tous les problèmes et risquent de causer des problèmes de sécurité. C'est peut-être le premier problème. Quels sont les niveaux de contrôle appropriés et quels sont les paramètres par défaut intelligents? La seconde est la manière dont les pages doivent se comporter pour l'utilisateur. Du point de vue du référencement, je pense que le processus que j'ai décrit ci-dessus ou l'utilisation de rel="canonical" (comme suggéré par jmb) fonctionnerait, mais il est également essentiel de bien définir le comportement de la page afin qu'elle soit sécurisée et transparente.
Vous voudrez peut-être examiner <link rel="canonical" />. Voir http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html . En bas dans les commentaires, quelqu'un de Google dit qu'il peut être utilisé pour les problèmes http/https.
Avertissement: je ne sais pas si et dans quelle mesure <link rel="canonical" /> est pris en charge par des moteurs de recherche autres que Google, Yahoo et Bing. Si d'autres moteurs sont importants pour votre site, vous devriez consulter leurs FAQ.
Du point de vue de l'utilisateur: la redirection d'un utilisateur connecté de http à https n'est pas sécurisée (si je comprends bien, vous souhaitez créer un processus transparent). Au moment où il arrive sur le site (avant la redirection), il transfère son cookie de session via http, ce qui le rend vulnérable au détournement de session. Un tel utilisateur doit se reconnecter à partir d'une page https.
Si un utilisateur arrive via https sans être connecté: en fonction des circonstances (taille du site, volume de trafic attendu, nombre de fois attendu), vous pourrez peut-être simplement le garder sur https. Voir également HTTPS pour l'ensemble du site et https://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https pour des discussions sur l'exécution un site sur https (en partie dans votre cas).
Mise à jour:
Quels sont les niveaux de contrôle appropriés et quels sont les paramètres par défaut intelligents?
Niveaux de contrôle appropriés:
- Sécurisé (https activé, y compris la page de connexion et tout à partir de là)
et
- Non sécurisé (pas de https).
Il n'y a pas de moyen terme si vous voulez "bien faire les choses". Voir aussi http://paulmakowski.wordpress.com/2009/07/20/http-post-https-bad-idea/ et https://stackoverflow.com/questions/ 274274/is-it-it-secure-to-submit-from-a-http-form-to-https
Par défaut: dépend de qui sont vos clients.
Il n'y a pas de stratégie de référencement pour les pages SSL. Une partie de la définition de la mise en cache est la suivante:
If the request is authenticated or secure (i.e., HTTPS), it won’t be cached.
voir: tutoriel de mise en cache
Par conséquent, afin d'éviter tout chevauchement avec des pages non SSL qui risqueraient de nuire au classement, vous devez placer vos pages sensibles au SSL sur des URL complètement différentes.
Ironiquement, j'ai vu des moteurs de recherche stocker et conserver des liens avec l'URL HTTPS qu'ils contiennent. Ceci est contraire à ce qui devrait normalement se produire, mais cela se produit dans les cas où la page est une zone de connexion, la page d’accueil, ou sinon, le pragma de cache est réécrit pour permettre la mise en cache. Je dirais que cela doit être évité si possible, car votre page tombera normalement dans PageRank.
La redirection 302 ne transfère pas le classement de recherche - vous risquez donc de perdre le classement de recherche si vous massez 302 votre site.
301 peut changer les définitions des signets, je ne voudrais pas constamment 301 mes utilisateurs circuler.
Assurez-vous également que la version http inclut un formulaire de connexion afin que l'utilisateur puisse revenir rapidement à la version https.
Maintenant, la grande question est la suivante: si les données sont visualisables sur http, pourquoi avez-vous une version https? Quelles données cachez-vous avec le cryptage https qui n'est pas déjà disponible?
Vous pouvez créer une zone membre https, ou publier des formulaires dans l'URL https à partir de la page http ou de nombreuses autres options qui n'incluent pas la présence de l'intégralité du site sur http et https.
En dehors de cela, votre idée semble réalisable - mais je n'ai aucune information interne sur la manière dont Google et les autres sites Web fonctionnent, et vous ne pouvez vraiment pas savoir en quoi cela affectera votre classement (et son cas Edge bien changer radicalement chaque fois que Google met à jour l'algorithme).