Meilleures pratiques HTTPS pour le référencement et la convivialité


8

Considérez une page, http://example.comqui peut être consultée publiquement et lorsqu'un utilisateur s'authentifie. Supposons maintenant que vous activez HTTPS pour chaque page lorsqu'un utilisateur se connecte à votre site Web, mais uniquement lorsqu'il est connecté. Votre page http://example.comdevient désormais accessible https://example.comà tous les utilisateurs connectés. Si cet utilisateur connecté aime votre page et décide de s'y connecter via un article de blog ou un site Web de médias sociaux, il y a de fortes chances 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 doit-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 le géreriez-vous?

Mon instinct est que pour toutes les pages qui peuvent être consultées à la fois publiquement et lorsque vous êtes connecté, la page doit d'abord détecter si l'utilisateur est connecté. S'il est connecté, il reste HTTPS ou utilise une redirection 302 de la version HTTP vers HTTPS. Si l'utilisateur n'est pas connecté et 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 est connecté, chaque URL devrait être HTTPS (ou au moins, cela devrait être une option), mais comme j'ai fait un peu plus de recherche, cette hypothèse était peut-être erronée. La façon dont je vois les gens l'implémenter, c'est qu'ils n'activent le HTTPS que pour les pages qui envoient et reçoivent des données sensibles: connexion, paiement du panier, 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 HTTPS sur chaque page via un paramètre dans le profil de l'utilisateur. C'est certainement une option, mais je devrais encore aborder le comportement des pages accessibles au public pour tous les états d'authentification.

Parce 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 à un contrôle granulaire sur chaque page (qu'elle soit sécurisée ou non par SSL), puis sur 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 peuvent finir par causer des problèmes de sécurité. C'est peut-être là 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 façon 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 en utilisant lerel="canonical" (comme jmb l'a suggéré) fonctionnerait, mais il est également essentiel de définir le comportement de la page afin qu'elle soit sécurisée et transparente.

Réponses:


6

Vous voudrez peut-être examiner <link rel="canonical" />. Voir http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html . Dans les commentaires, quelqu'un de Google dit qu'il peut être utilisé pour des problèmes http / https.

Avertissement: je ne sais pas si et dans quelle mesure <link rel="canonical" />est pris en charge par les moteurs de recherche autres que Google, Yahoo et Bing. Si d'autres moteurs sont importants pour votre site, vous devriez consulter leur FAQ.

Du point de vue de l'utilisateur: rediriger un utilisateur connecté de http vers https n'est pas sûr (si je comprends bien que 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, le rendant vulnérable au détournement de session. Un tel utilisateur doit se reconnecter à partir d'une page https.

Dans le cas où un utilisateur arrive via https et n'est pas connecté: selon les circonstances (taille du site, volume de trafic attendu, nombre de fois prévu), vous pourrez peut-être simplement le garder sur https. Voir également HTTPS pour l'ensemble du site et /programming/174348/will-web-browsers-cache-content-over-https pour des discussions sur la gestion d'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

  • Insécurité (pas de https).

Il n'y a pas de compromis si vous voulez "bien faire les choses". Voir également http://paulmakowski.wordpress.com/2009/07/20/http-post-https-bad-idea/ et /programming/274274/is-it-secure-to-submit -de-un-http-formulaire-à-https

Par défaut: dépend de qui sont vos clients.


Je pensais aussi à cela comme une option. La raison pour laquelle je n'étais pas sûr à ce sujet est que, bien qu'il traite du problème de référencement, il ne traite pas du comportement de la page pour un utilisateur. Des pensées?
Virtuosi Media

Bon point, j'ai mis à jour ma réponse.
jmb

La régénération de la session à chaque chargement de page résoudrait-elle le problème de détournement de session?
Virtuosi Media

Merci. Une autre question: comment pensez-vous que les gens verraient un CMS nécessitant un certificat SSL s'ils acceptent l'enregistrement des utilisateurs?
Virtuosi Media

Je pense que cela dépend beaucoup du public cible. Les banques y verraient une exigence, même dans des domaines non essentiels n'impliquant pas d'informations financières. Un organisme sans but lucratif doté d'un budget froncera probablement les sourcils sur le coût et la complexité supplémentaire.
jmb

2

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

Donc, afin d'éviter le chevauchement avec des pages non SSL où cela peut nuire au classement, il faut avoir vos pages sensibles à 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. Cela 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 une réécriture du pragma de cache pour permettre la mise en cache. Je dirais d'éviter cela si possible, car votre page tombera généralement dans le PageRank.


1
Merci, Talvi, mais je pense que vous avez peut-être mal compris ma question, qui ne concernait pas la mise en cache du navigateur. Étant donné que les moteurs de recherche explorent et indexent les pages https, cela signifie que vous êtes confronté à des problèmes de contenu en double si quelqu'un établit un lien vers la version https. Changer l'URL n'aide pas car http et https sont déjà deux URL différentes aux yeux du moteur de recherche. Avec différentes URL, vous divisez efficacement votre PageRank. Le cœur de ma question était de savoir comment développer une stratégie pour éviter le problème de contenu en double. Malheureusement, je ne pense pas que le lien de mise en cache aide à résoudre ce problème.
Virtuosi Media

Je suis d'accord avec Virtuosi Media - Les moteurs de recherche n'ont généralement pas de problème avec https: // - URL.
John Mueller

1
@virtuosi Tu m'as eu là. Peut-être matraquer le moteur de recherche avec un objet contondant?
Talvi Watia

2

La redirection 302 ne transfère pas le classement de recherche - vous risquez donc de perdre le classement de recherche si vous massifiez votre site.

301 peut changer les définitions de signets, je ne voudrais pas constamment mes utilisateurs.

Assurez-vous également que la version http comprend un formulaire de connexion afin que l'utilisateur puisse rapidement revenir à la version https.

Maintenant, les grandes questions sont - si les données sont visibles 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 d'avoir le site entier sur http et https.

En dehors de cela, votre idée semble réalisable - mais je n'ai aucune information privilégiée sur le fonctionnement de Google et des autres sites Web et vous ne pouvez vraiment pas être sûr de la façon dont cela affectera votre classement (et c'est un cas si particulier qu'il peut bien changer radicalement chaque fois que Google met à jour l'algorithme).


Je suppose que je supposais que si un utilisateur est connecté, chaque URL devrait être https, mais comme j'ai fait un peu plus de recherche, cette hypothèse était peut-être erronée. La façon dont je vois les gens l'implémenter, c'est qu'ils n'activent https que pour les pages qui envoient et reçoivent des données sensibles: connexion, paiement du panier, gestion du profil utilisateur, etc. J'essaie de déterminer quel modèle est le meilleur. Parce 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.
Virtuosi Media
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.