2017/4/24サイト全体https（常時SSL）化が完了しました！ブラウザのアドレスバーに、今までなかった「鍵マーク」が表示されていると思います。
今回は、WordPress初心者の私が、ブログの常時SSL化を行った手順と、注意点について紹介したいと思います。
長文となっておりますので、手順だけ確認したい方は、項番4.からお読みください！
目次
前回のおさらい：サイト全体https化とは
https通信とは、情報のやり取りを暗号化することで、入力した内容を第三者に読み取られたとしても内容がわからないようにすることです。
以前までは、クレジットカード情報や会員情報を入力する時だけhttpsのページに移行するサイトが多かったのですが、最近では、サイトのどのページに移動してもhttps通信となる「サイト全体https化（常時SSL化）」が中心となってきています。
対応の目的や事前に検証したことについては、前回記事をご参照ください。
当記事で紹介したい常時SSL化の手順について
今回のサイト全体https化の手順は、WordPressブログ運営でいつも参考にしている“寝ログ”さんのこちらの記事を参考にさせていただきました。
WordPressをhttpからhttpsにSSL化した全手順まとめ（エックスサーバー環境）
非常にわかりやすく全手順が網羅されています。
こちらの記事の通りに作業行うことでSSL化を完了させることができるため、当ブログでは、以下のポイントに焦点を当てて紹介したいと思います。
- WordPress初心者で初めてのSSL化である
- 作業前に確認しておきたいこと・注意点
- ファーストサーバ Zenlogic環境である
- 実際にSSL化した後に発生した問題
Zenlogicについてはたまたま私が使用しているだけで、多くのレンタルサーバーにおいてサーバー証明書取得などの手順は共通です。Zenlogic利用の方にはより参考になるかと思います。
https(常時SSL)化にあたっての注意点
① ソーシャルのシェアカウントリセット
別サイトとして扱われるため、Facebook、はてなブックマークなどのソーシャルシェアカウントはリセットとなります。
プラグインを用いることで対応する方法もあるようですが、当ブログは設立も浅くソーシャルでのシェアもごく少数のため、割り切って0からのスタートとすることにしました。
② 今回使用したWordPressプラグイン
https化を行う上で使用したプラグインは以下です。
- バックアップ：BackWPup
- http→httpsへの文字列置換：Search Regex
結構プラグインを使ったイメージがありましたがこれだけでした。どのように利用したかについては後の項目で紹介します。
③ 作業時のアクセス度合い
作業時は、わずかながら接続断が発生する可能性があるため、できるだけアクセスの少ない時間帯を狙って行いましょう。
次に紹介する、バックアップやサーバー証明書の申し込みなどの事前準備が滞りなく進んでいれば、実際にSSL化する部分は1時間程度で対応できます。
あとは、問題が発生した場合には都度対応が必要となりますので、その期間も見込んでの移行となります。
④ メンタルの問題
次の項目で詳しく紹介しますが、移行に失敗した場合に前の状態に”切り戻し”ができる手段をシミュレートしておくことが大切です。
切り戻しについて検討することは、システム移行時は鉄則となります。
余裕を持って作業することでミスする可能性を減らすことができます。
WordPress歴半年の私がサイト全体https化を行った手順
① サーバー証明書の申し込み
ファーストサーバの場合は、カスタマーポータルにログインして、「会員/契約管理 > サービスお申し込み」から、SSL証明書の申し込みを行います。
標準独自SSLのお申込み｜Zenlogicサポートサイト［ファーストサーバ］
証明書は、その信頼度によって価格が変わってきますが、今回使用するのはシマンテック社提供の「標準独自SSL（無料）」です。
申し込みから証明書が届くまで、1,2週間はかかるのかと思っていましたが、数分で設定完了のメールが来て証明書が利用可能となりました。
手続きにかかる時間は、サーバーによって異なるため、前もって準備しておくことをお勧めします。なお、証明書の有効期限は、申し込みからちょうど１年後となっていました。
期限が切れる前に、何らかの対応が必要になりますので、それはまた記事にしたいと思います。
② バックアップの取得
まずはこれが一番大切です。失敗したり、SSL化によって思わぬ問題が発生することもあるかもしれません。絶対に事前のバックアップを取得しましょう。
今回は、BackWPupを用いてデータベースのバックアップと、標準のエクスポート機能を用いてのxmlバックアップ、念には念を入れてwp-contentフォルダごとのバックアップも取得しました。
BackWupでのバックアップとxmlエクスポートはすぐに終わりましたが、wp-contentフォルダをFTPでダウンロードするのは数十分かかりました。
そこまでしなくても大丈夫だと思いますが、念のため取得してます。バックアップ方法は過去記事にも記載しておりますのでよろしければこちらも参考に
また、バックアップの取得だけではなく、バックアップからデータを復旧させる（リストア）手順まで確認しましょう。
バックアップの手段を考える際は、取得したバックアップデータでのリストア作業をイメージできるか？を考えて手段を選ぶことをお勧めします。
「駄目だったとしても元に戻せる」安心感を持って作業することで、落ち着いて作業を行うことができます。
③ サーバー証明書の適用
バックアップの取得後、手順①で取得したサーバー証明書を適用してみます。以下の手順にてサーバーコントロールパネルから行います。
この時点で、「https://」で始まるアクセスURLを使ってアクセスできるようになりますが、以前の「http://」のアクセスURLでももちろんアクセスできます。
証明書の適用直後は、サイト内に「http」と「https」のリンクが混ざった状態（混在コンテンツ）となっているため、「https」部分に鍵マークは出ない状態です。
せっかくhttpsアクセスしても、この表示だと残念な感じ…
完全に保護された状態にする方法については後の項目で紹介します。
まずは、httpアクセスで普通にアクセスできる状態を保ちつつ、バックグラウンドでhttps環境を構築していく方式で常時SSL化を行いました。
④ Serach Regexプラグインを使用しての文字列置換
これが、私が今回のhttps化対応で一番心配だった部分です。
サイト内にある「http」のリンク、当ブログでは「http://simple-lifelog.com/」となっている部分を、全て「https://simple-lifelog.com/」に置き換える必要があります。
画像ファイルを呼び出すためのURLも、全てhttps://simple-lifelog.com/から画像を呼び出すように変更しなくてはいけません。
そうしないと、混在コンテンツとなり、「保護された通信」の表示は一向に出てこないままです。
画像を呼び出している回数も相当な数を予想していましたが、置換対象は全体で1800ほどでした。
Search Regexを用いた置換方法
まずは必要な部分を入力します。
- 「Source」「Limit to」「Order By」 ・・・デフォルトから変更なし
- Search pattern ・・・置換前の文字列（例 http://simple-lifelog.com/）
- Replace pattern ・・・置換後の文字列（例 https://simple-lifelog.com/）
- Regex ・・・すべてチェックなし
「Search」をクリックすると、検索結果の置換対象文字列が出てきます。
その後、「Replace」をクリックすると、置換後の結果が表示されます。この時点ではまだ文字列は置換されません。
検索文字列と、置換後の文字列に間違いがないか、この時点で十分に確認しましょう。
チェックして問題ないようであれば、「Replace&Save」をクリックすることで、置換が実行されます。
数千とある文字列の置換のため、時間がかかることを想定していましたが一瞬で終わり拍子抜けでした。
これで、httpから始まるほとんどのページ内リンクは、httpsに置き換えられます。
⑤ ウィジェットエリアのhttp部分をhttps化
プロフィール欄にあるimgタグのsrc属性や、ページ内リンクの呼び出し部分を変更するだけです。
Twitterボタンは、httpsでのリンク、画像呼び出しとなっているため対応は不要です。
Feedlyボタンはhttpが使われているので対応が必要です。
Feedlyボタンはあったほうがいい…
しかし、https化後なぜかFeedlyボタンを押すと「Feed not found」となってしまうため、現在はFeedyボタンは未設置としています。（要因切り分け中。フィードの出力自体はできている）
混在コンテンツのチェックについて
混在コンテンツのチェックは、Google Chromeの開発者ツールを使うことで、確認することができます。
WindowsではF12キーで開発者ツールを呼び出すことができます。Macの場合はショートカットがわからなかったので「ブラウザ上で右クリック > 検証をクリック」することで開発者ツールを表示できます。
混在コンテンツは赤文字で表示され、対象URLも確認できる
根気がいる作業ですが、コツコツと対応しましょう。
⑥ アフィリエイトリンクのhttp部分への対応
現在、カエレバ・ヨメレバはSSLに対応しています。今回引っかかったのは、カエレバで楽天の画像を取得している部分がhttpだったため、混在コンテンツとなりました。
こちらもSerchRegexを利用することで全て置換できます。
楽天アフィリエイトの画像取得用URLをhttpsに置換すれば解決
また、Amazonアソシエイトのテキストのみの広告もhttp通信であったため、今回は取り外しました。
最終的に混在コンテンツとして残り続けたのは、PzリンクカードのCSS呼び出し部分のHTMLタグのみとなりましたが、次のWordPressサイトアドレスの変更によってこちらも改善しました！
ここまでの対応ができて、アドレスバーのURLに「保護された通信」と出るように。よかった！
⑦ WordPressサイトアドレスの変更
サイトアドレスを変更します。手順はWordPressダッシュボードの「設定 > 一般」から
「WordPressアドレス」と「サイトアドレス」を、https付きのアドレスに変更します。
最初のhttp部分をhttpsに変更するだけです。サイトによっては、WordPressアドレスとサイトアドレスが異なる場合もあるため注意しましょう。
なお、変更後も、以前のhttp://simple-lifelog.com/へは普通にアクセスできました。
⑧ 301リダイレクト設定
以前の「http」からアクセスした人も、新しい「https」へ転送されるように、リダイレクト（転送）の設定を行います。
プラグインを使用してもリダイレクト設定を行うことはできますが、今回参考にしているサイトから、以下のコードを.htaccessへ追記してリダイレクト設定しました。
<ifModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</ifModule>
【！】.htaccessを編集するときは、必ず編集前にファイルをコピーしてバックアップしておきましょう。サイトにアクセスできなくなることがあります。
これで、以前のURLをブックマークしてくれている人がアクセスしても、httpsのページに飛ぶことができるようになります。
サイト全体SSL化後の対応
各SNSでの登録URL変更
Facebook、Twitter、Google＋、instagramなどでブログのURLを紹介している場合は、登録しているURLをhttpsへ変更しましょう。
私は「にほんブログ村」にもブログを登録していたのですが、httpsのURLに変えても同じブログとして扱われ、ランキング順位なども全く影響はありませんでした。
また、Googleアナリティクス、SearchConsoleで登録しているサイトURLも、変更を済ませておきましょう。
発生した問題
https化後、Feedlyの一覧画面を見ると、ブログの画像だけが全くフィード一覧に表示されていませんでした。
アイキャッチ画像がない！
混在コンテンツなども疑いましたが、こちらのサイトを参考に、RSSフィードに画像の表示を加える処理をfunctions.phpへ記述することで改善しました。
● WordPress RSS フィードにアイキャッチ画像を表示する方法
先ほど挙げたFeedlyボタンが使えない件はまだ解決していませんが、また解決したら報告します！
SSL化後のアクセス状況
まだSSL化してから3日しか経っていないのでサンプル数が少なすぎますが、アクセス数はhttps化する前から増えることも減ることもない状態であるため、少なくとも「悪い方向には転ばなかった」と言うことができます。
これからのアクセスの伸び率は、httpsかどうかではなく記事の内容によってくるとは思いますが、「httpだからサイトが伸びないのか…」という言い訳要素を一つ排除してのサイト運営となるため、気合を入れて更新したいところです。
アクセス状況や表示速度については後日
https化後のアクセス状況については、1ヶ月ほどのサンプル期間を設けて報告したいと思います。
また、表示速度については今のところ何もわかりませんが、開発者ツールを使って測定した結果を紹介できればと思います。（そもそも高速化にはHTTP/2対応など条件があったような気がする）
まとめ：WordPress構築を検討の方は最初からhttpsで
いかがでしたか？httpで運営しているサイトのhttps化は結構面倒だと思っていたのですが、意外と簡単にできました。
SSL化自体はサーバ証明書を取得してサーバーに適用すれば可能なのですが、既存のhttpリンクが存在することによる「混在コンテンツ」への対応が最も面倒です。
せっかくhttpsプロトコルでアクセスしているのに、完全に保護された通信とならないのは、ユーザーからの信頼度も低下してしまいます。
これからサイトやブログを立ち上げるに当たってhttpかhttpsかで迷っている方は初めからhttpsで運用することをお勧めします。
無料ブログなどでは、自分の意志でSSL化などに対応することはできません。せっかくWordPressでブログを運用するのであれば、WordPressの自由度を生かして少しでも優位に立てるようにしましょう！
追加の情報などあれば、記載していく予定です。
それでは、新URLとなった「どこでもシンプルライフ！」をこれからもよろしくお願いいたします^^
コメントを残す