サイトを完全SSL化する前に気をつけたいリダイレクトの話
Webサイトの信頼性、SEO対策！という流れで、「SSL化」するサイトが増えていますね。以前書いた記事
Pleskでhttpをhttpsにリダイレクトして完全SSL化する方法（nginx）｜ぷれつく
でも紹介したように、プレスクを使えば難しい設定なく簡単にSSL化できるので、初心者も安心です。さて、今回の記事では主流になりつつあるサイトのSSL導入に伴う注意点とリスクを紹介したいと思います。僕が陥った経験もあわせてどうぞ
nginx を使ったリダイレクトの種類301と302を使い分ける
前回の記事では、nginx でサイトの完全SSL化するには、下記のコードを追加ディレクティブに記述すると紹介しました。
if ($server_port = 80)
{ rewrite ^ https://$host$request_uri permanent;
}
確かにこの記述だけでもサイト全体、http（80番ポート）にアクセスしたら自動的に https（443ポート） にリダイレクトしてくれるので間違いではありません。では、この記述は一時的なリダイレクト302なのか、それとも恒久的なリダイレクト301なのか知っていますか？。
※301と302の違いが分からないひとは下記のサイトを熟読してください。
301、302リダイレクト違いとGoogleの見解
Googleは、http と https は2つのサイトとして見なし重複コンテンツとしてペナルティの対象としています。ですので、httpのページと、httpsのページがあった場合、httpのページに301リダイレクトをすることで、httpsが正規のページだと認識します。（他にもcanonical属性タグを使う方法もあります。）
nginx のリダイレクトの記述の違いは、先ほど記述したこちらが 301リダイレクト（恒久的）
302リダイレクト（一時的）の場合は、
どちらもリダイレクトに変わりはありませんが、302は一時的なので重複コンテンツとしてGoogleに認識されるまで一定の時間がかかるわけです。次にこの301が及ぼす影響を説明します。
サイトのSSL化でポイントなのはキャッシュ時間
常時SSL化すると大変なのがHSTSです。
Googleは、http と https 双方に同一のコンテンツを持つページが存在した場合に、どちらが原文（=オリジナル=検索結果に表示すべきページ）であるかを判断する術がありません。サイト運営者がHSTSを利用してSSL通信するように応答するようサーバを設定することで、Googleもhttps://～の方をインデックスして検索結果に表示すれば良いという判断をすることが可能になります。
Webサイトを常時SSL化(https）する時に知っておきたいSEOチェックリスト ::SEM R (#SEMR)
というわけで、キャッシュ時限を決めずに301の恒久的なリダイレクトを行うと、HSTSの罠にはまって301を記述を削除してもキャッシュがクリアされない現象に陥ります。要はPleskの追加ディレクティブに、
を書いて、再起動後、やっぱりhttps へのリダイレクトをやめたいので記述を消してもリダイレクトが残ってしまう現象です。（これは海外のスレッドでも話題にあがっていますね）
Chrome で 301 リダイレクトが解除できないときの対処方法 | gotohayato
