SEOと使いやすさのためのHTTPSベストプラクティス
http://example.comページについて考えてみましょう。このページは、公開されているときと、ユーザーが認証されたときに表示できます。ここで、ユーザーがWebサイトにログインするときにすべてのページでHTTPSを有効にしますが、ログインしている場合のみです。ページ、http://example.comはすべてのログインユーザーに対してhttps://example.comになります。ログインしたユーザーがあなたのページを気に入って、ブログ投稿やソーシャルメディアWebサイトからリンクすることに決めた場合、HTTPSバージョンのURLを使用する可能性が高くなります。
SEOの観点から、2つのURL間の重複コンテンツの問題を回避するための戦略は何ですか？
ユーザーがHTTPS URLにアクセスしたが、ログインしていないか、アカウントを持っていない場合はどうなりますか？ HTTPバージョンへのリダイレクトが必要ですか？もしそうなら、どのようにそれを処理しますか？
私の本能は、一般公開とログイン中の両方で表示できるすべてのページについて、ユーザーがログインしているかどうかを最初に検出する必要があることです。ログインすると、HTTPSのままになるか、HTTPバージョンからHTTPSへの302リダイレクトを使用します。ユーザーがログインしておらず、HTTPSバージョンのURLに到着した場合、HTTPバージョンへの301リダイレクトを使用します。ただし、よりエレガントで効果的なソリューションを歓迎します。
編集：ユーザーがログインする場合、すべてのURLはHTTPS（または少なくともオプションである必要があります）であると想定していましたが、もう少し調査して、おそらく仮定が間違っていた。私がそれを実装している人々を見ているのは、ログイン、ショッピングカートのチェックアウト、ユーザープロファイル管理などの機密データを送受信するページに対してのみHTTPSを有効にしているということです。
どうやら、Google Mailは、ユーザーのプロファイルの設定を通じて、すべてのページでHTTPSを使用するかどうかのオプションをユーザーに提供します。これは確かにオプションですが、すべての認証状態で公開されているページの動作に対処する必要があります。
私は他の人が使用するコンテンツ管理システムを構築しているので、それが正しいことを確認する必要があります。サイトの所有者が利用できる設定は何ですか？この時点で、各ページ（SSLで保護されているかどうか）を細かく制御し、さらにサイト全体を制御することを考えています。ただし、人々がすべての問題を理解しておらず、最終的にセキュリティの問題を引き起こす可能性がある場合、そのレベルの制御を与えることは間違いかもしれません。それがおそらく最初の問題です。適切な制御レベルとは何ですか？インテリジェントなデフォルトとは何ですか？ 2番目は、ユーザーに対するページの動作です。 SEOの観点からは、上記で説明したプロセスまたはrel="canonical"（jmbが推奨するような）を使用することは機能すると思いますが、安全でシームレスなページの動作を特定することも不可欠です。
<link rel="canonical" />を調べることもできます。 http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html を参照してください。 Googleからのコメントでは、http/httpsの問題に使用できると述べています。
警告：Google、Yahoo、Bing以外の検索エンジンで<link rel="canonical" />がサポートされているかどうか、またどの程度までサポートされているかわかりません。他のエンジンがサイトにとって重要な場合は、それらのFAQを確認してください。
ユーザーの観点から：ログインしているユーザーをhttpからhttpsにリダイレクトすることは安全ではありません（シームレスなプロセスを作成したいと正しく理解している場合）。 （リダイレクトの前に）サイトに到着した時点で、彼はhttpを介してセッションCookieを転送し、セッションハイジャックに対して脆弱になりました。このようなユーザーは、httpsページから再度ログインする必要があります。
ユーザーがhttps経由で到着し、ログインしていない場合：状況（サイトのサイズ、予想されるトラフィック量、予想される回数）に応じて、単純にユーザーをhttpsのままにしておくことができます。また、 サイト全体のHTTPS および https://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https も参照してください。 https上のサイト（一部はあなたの場合）。
更新：
適切な制御レベルとは何ですか？インテリジェントなデフォルトとは何ですか？
適切なレベルの制御：
- セキュア（httpsがオンになり、ログインページとそこからすべてを含む）
そして
- 安全でない（httpsなし）。
「正しく」したいのであれば、妥協点はありません。 http://paulmakowski.wordpress.com/2009/07/20/http-post-https-bad-idea/ および https://stackoverflow.com/questions/ 274274/is-it-secure-to-submit-from-a-http-form-to-https
デフォルト：顧客が誰であるかによって異なります。
SSLページにはSEO戦略はありません。キャッシングの定義の一部は次のとおりです。
If the request is authenticated or secure (i.e., HTTPS), it won’t be cached.
参照： キャッシングチュートリアル
したがって、ランキングを損なう可能性のある非SSLページとの重複を防ぐために、SSLに敏感なページを完全に異なるURLに配置することです。
皮肉なことに、私は検索エンジンが実際にHTTPS URLを含むリンクを保存して保持しているのを見てきました。これは通常起こるべきこととは逆ですが、ページがログイン領域である場合、ホームページである場合、またはキャッシュを許可するためにキャッシュプラグマが書き換えられている場合に発生します。ページは通常PageRankでドロップするため、可能であればこれを避けることをお勧めします。
302リダイレクトは検索ランキングを転送しません。したがって、サイトをまとめて検索すると、検索ランキングが失われる可能性があります。
301はブックマークの定義を変更できます。ユーザーの周りを常に301にしたくはありません。
また、httpバージョンにログインフォームが含まれていることを確認して、ユーザーがhttpsバージョンにすばやく戻ることができるようにします。
ここで大きな疑問は-データがhttpで表示できる場合、なぜhttpsバージョンがあるのですか？まだ公開されていないhttps暗号化でどのデータを隠していますか？
Httpsメンバーエリアを作成するか、httpページからhttps URLにフォームを投稿するか、httpとhttpsの両方にサイト全体を含めることを含まない他の多くのオプションを使用できます。
それ以外は、あなたのアイデアは実行可能に見えます-しかし、私はGoogleや他のウェブサイトがどのように動作するかについての内部情報を持っていません。 Googleがアルゴリズムを更新するたびに大幅に変更されます）。