【備忘録】WordPressを早くしたい！そして常時SSL化した♪

陸マイラー活動とは全く関係がないのですが、ちょっと備忘録的に書いておきたくて、陸マイラーのことを一旦脇に置いてみようと思います。
全くもって無関係かというと、そうでもなくて、陸マイラー活動をするにあたって、このブログはわたしにとってはとても大事で、

・何か定期購入したか
・どんな案件に参加済みか
・調べたものの答えはなんだったか

なんかを記載しているので、あの、どれそれ、なんだっけかな？？
と自分の記事を振り返りたくなることがよくあります。

自分の文才のなさにげんなり＆赤面するので、基本過去記事は見返したくないのですが、備忘録なので仕方がない。

だがしかし、だがしかし、このブログ、めっちゃ重い！！

自分の備忘録の為に始めたブログと、お友達紹介なんかもできたらいいな〜なんて軽い気持ちで始めたので、何もこだわりなく、とにかく費用がかからない形でブログを立ち上げることにして、個人サイト御用達の激安サーバーで運営をしてきてたんです。

だけど、めっちゃ重い！
特に管理画面が。。。
記事を書くのにすご〜〜く時間がかかります。

なので思い切ってサーバーの移転をすることにしました。

このことについて、備忘録を書いていきたいと思います。

ツールでページの速度をスコアでチェックしてみよう！

ことの始まりは、ページの表示速度がすこぶる遅いこと。
ブログの持ち主である自分ですら、自分のブログを読むのが億劫になるほどに遅いのです。

1ページ読むのがやっと。
過去の記事を読み返して、リライトしたくても、管理画面から記事を修正して、プレビューして、また修正して、プレビューして、っていう作業を考えるだけでもゾッとするほど、遅いのです。

Googleさんのツール「PageSpeed Insights」でチェックしてみたところ、以下のような結果になりました。

このブログのサーバー移転前サーバー利用時の状況です。

PageSpeed Insights　の結果

Googleさんの「PageSpeed Insights」の結果です。

モバイルのスコアは52、PCは68です。
Googleさんが良いと評価する85とは程遠い数字です(笑)

スコアが低いのはもちろんですが、何よりもサーバー応答時間が0.94秒と約1秒近くかかっています。
PCの方の表示をさせるのを忘れたのですが、大体同じ数値でした。

しかも、この調査をした時間帯は、日本では朝方の比較的レスポンスの早い時間帯にチェックしています。

全体のスコアは、このサーバー応答時間だけにひっぱられるものではなくて、サーバーの応答時間よりもその他の項目の方がスコアに大きく影響をしていますので、サーバーだけが原因でスコアが悪い、というわけではありません。

それでもやはりレスポンスの遅さが気になってしまい、また、nginxにしたい＋php7で動かしたいため、サーバーをお引越しすることにしました。

Pingdom Website Speed Testでもチェックをしてみます。

結果は、スウェーデンストックホルムからのチェックで、サイトのすべての表示にかかる時間が6.82秒となかなかの数字が結果として表示されました。
全体の評価としてはCでした。
ストックフォルムからのアクセスとはいえ、6.82秒て・・・。

こちらもスピードだけで評価Cとなっているわけではなく、その他のJavaScript周りや、もろもろが影響しています。

PageSpeed Insightsのそれぞれのエラーから改善策を検討

Googleさんからのアナウンスによると、表示された結果のカラーによって、対応の重要度が変わるようです。
今回は赤字について、改善しておきたいと思い、赤字部分を潰していくための作業をしました。
Pingdomさんの方でも大方おなじような内容のエラーがスコアを下げていますのより日本語で分かりやすく解説してある「PageSpeed Insights」の結果をもとに修正を進めていきたいと思います。

チェック結果によると、赤字の項目は、PCもモバイルも同じ警告となります。
その細い箇所についてはそれぞれ異なりますが、大項目として、3つの項目が。

スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する

これは、スタイルシートやJavaScriptの読み込みがレンダリング（HTMLの表示)よりも先に読み込まれるため、レンダリングに時間がかかっていると。
特に外部化されているcss、jsについては、かなり影響があるよ。ということでした。

このブログのWordPressには様々なプラグインを導入しており、個々のプラグインが設置するjsファイルやcssファイルの多くがレンダリングをブロックしており、さらには、ブログ村などの外部パーツのjs・cssについても、どげんかせんといけんばい、状態なようです。

このエラーは、サーバーうんぬんというより、Jsファイルをフッターに移動、deferまたはasync属性をscriptタグに設定することで対応するといった、サーバーに頼らず改善できる箇所になります。

ブラウザのキャッシュを活用する

ブログ村などの外部サービスから読み込みが行われているjsやcssや画像等についてはこちらで対処のしようがありませんが、ブラウザにキャッシュさせるべきファイルをきちんとキャッシュさせるように設定しましょうね、ということのようです。

この対応も、.htaccessが利用できるサーバーであればこちら側で設定可能な項目です。

今回、わたしはNginxを利用することにしたので、.htaccessではなく、confファイルで設定をする項目になります。

サーバーの応答時間を短縮する

これに関しては、自分ではどうしようもない箇所ですね。
上記の3つの項目を改善したとしても、サーバーの応答時間が遅ければスコアは伸びませんでした。

なにぶん、WordPressはphpを利用しているので、サーバーサイドで処理を行って貰う必要があり、激安詰め込み型レンタルサーバーではなかなか速度を改善することは難しそうです。

すべてをやり終えた時点で感じたことですが、激安サーバーでもPHP7.1が導入されればページ表示速度はかなり改善されるのではと思います。
無料SSLサービスも徐々に導入されはじめているので、激安サーバーでも速度に悩まされることは無くなっていきそうです。

わたしは月額数百円で構成が決められているものを利用するより、あと数百円捻出するだけで、自分で自由にさわれるサーバーが手に入ることの方が価値が高かったので、今回はVPSを選択して改善をはかることにしました。

最終的にサーバー環境は
サーバー：VPS（Plesk管理)
OS：CentOS7
webサーバー：Nginx
PHP-FPM　バージョン7.1
SSL：Let’s Encrypt
になりました。

その他のコンテンツ側での調整は、めんどくさくてほとんどをプラグインで解決しました^^

WordPress　webサーバーはNginxに

これまで、webサーバーといえばApache（アパッチ）だったわけですが、その代替となるwebサーバーがNginx(エンジンエックス)で、FacebookやWikipedia、クックパッドなんかの、大量アクセスがある企業サイトなんかで利用されています。

Nginxの特徴は、大量アクセスの処理が得意で、リバースプロキシの機能があるので負荷分散できます。

このブログのようなアクセス数で「大量アクセス処理」について気にするなんて、茶がヘソを沸かしちまいそうですが、とにかく表示速度にこだわりたかったのと、ミーハー的思考から、Nginxを選択しました。
ちなみに、このブログのようなアクセス数の少ないサイトでは、Apacheの方がパフォーマンスが高いもしくはほとんど変わらないというレポートが多いのでほぼミーハー的思考が勝っています。

年々Apacheの利用率は減少傾向にあるところ、Nginxの利用率は上昇傾向にあることから、Nginxに触れておきたいという気持ちもあります。

WordPressをNginxで運用する際の最大のネックは、.htaccessが利用できなくなる点にあります。

WordPressの.htaccessではmod_rewriteモジュールが利用されており、URLの書き換え処理が行われていますが、この設定をnginx用に書き換え、Nginxの設定ファイルであるconfに記載する必要があります。

少し難しそうですが、私が実行したPlesk環境ではコピペしちゃえば簡単に設定できます。

PleskのNginxはリバースプロキシとして補助的に使われます。

VPS＋コントロールパネルはPlesk一択で考えた

VPSは仮想専用サーバーです。
やりたいことが自由にできる環境をゲットすることにします。

Pleskは、VPS(仮想専用サーバー)のコントロールパネルです。

VPSはroot権限付きなのでSSHからサーバーを自由に触ることもできますが、VPSにコントロールパネルとしてPleskをつけてもらうことで、コマンドなしで簡単にサーバーの構成を変更したりすることができます。

Pleskはサーバーの高度な設定が直感的に可能で、コントロールパネル的なものに触り慣れていれば特に難しいこともありません。

決して初心者向きではありませんが、WordPressをいじったりできる方であれば、慣れればとても使いやすいコントロールパネルです。

また最初に設定さえしてしまえば、WordPressでサイトを運営する点においてはその後、Plesk側から何かを触るといったことはほとんどないかと思います。

特にWordPressを触れるような方ならなおのこと、Pleskはおすすめです。

このブログのサーバーの選択でVPS及びコントロールパネルがPlesk一択にした理由は下記のとおりです。

常時SSL化が無料で叶う。Let’s EncryptがPleskならワンクリックで簡単に導入でき、証明書は自動更新される

Let’s Encryptとは？
Let’s Encrypt は、認証局（CA）として「SSL/TLSサーバ証明書」を無料で発行するとともに、証明書の発行・インストール・更新のプロセスを自動化することにより、TLS や HTTPS（TLSプロトコルによって提供されるセキュアな接続の上でのHTTP通信）を普及させることを目的としているプロジェクトです。

非営利団体の ISRG (Internet Security Research Group) が運営しており、シスコ（Cisco Systems）、Akamai、電子フロンティア財団（Electronic Frontier Foundation）、モジラ財団（Mozilla Foundation）などの大手企業・団体が、ISRG のスポンサーとして Let’s Encrypt を支援しています。

2015年9月にベータプログラムが開始、380万以上のウェブサイトに対して、170万枚以上の SSL/TLS サーバ証明書が発行され、2016年04月12日より、正式にサービスが開始されました。

Let’s Encrypt 総合ポータル

無料SSLサーバ証明書「Let’s Encrypt」の総合ポータルサイト。導入方法の解説や技術情報の和訳など。

無料SSL証明書として認知され、導入する個人サイトも増えてきたLet’s Encryptは、独自SSL導入可能なサーバーであれば導入できますが、証明書の発行の手間（そんなに大変ではありません）があります。
また、その有効期限が短く、都度更新が必要になり、Let’s Encryptを利用されている方の多くは、自動更新スクリプトを組むなどで対応をしています。

レンタルサーバー屋さんでも、最近は無料SSLを簡単に導入できるサービスが増えてきたので、そういうサーバー会社を利用するのも一つの手だな、と思いつつ、常時SSL化「だけ」が目的ではなかったので今回はVPS＋Pleskにて実現することにしました。

Plesk12.5以上であれば、拡張パッケージとしてLet’s Encryptが利用可能で、ボタン一つで導入ができます。
さらに証明書が自動更新されるので、手間なく、無料で常時SSL化が可能となるんです♪

これまで、個人サイトとSSLを導入するなんて、証明書がいくら年額1,000円代のものが出たと言っても、そこにコストをかけるほどの重要性はないように思っていましたが、Googleの評価のほんの一部として、常時SSL化も加味される時代ですので、無料とあらば、ぜひ導入しておきたいところです。

証明書が期限切れでエラーとなってしまうことほど悲しいことはないので、自動更新されるのはありがたい。

ネックとなるconfファイルの設定が容易

先ほども書きましたが、Wordpressを、ApacheからNginxに変更する際に、最大のネックとなるのが.htaccessが使えなくなる点です。
Wordpressをインストールした後に、htaccessは自動で生成されるので、あまり意識することはありませんが、とても大切な設定がかかれたファイルです。

Nginxでも、同じような命令が記載されたconfファイルを用意する必要があり、一般的には、viコマンドを叩き、confファイルを触る必要があるのですが、Pleskの場合は、コントロールパネルより「nginx 追加ディレクティブ」設定項目にて設定が可能です。

「nginx 追加ディレクティブ」設定項目に記載する内容が、.htaccessに記載されていた命令をnginx用に変更したものになります。

Plesk12.5　以上であればPHP7が利用できる

これまで利用していたサーバーのPHPのバージョンは現在は5(php5.6 / php5.5 / php5.4 / php5.3)です。

2015年にメジャーアップデートされ、5.6に比べて2倍以上のパフォーマンスが向上されたと話題になりました。

WordPressは、WordPress4.7のリリースと共に推奨環境が変わり以下のようになりました。

About » Requirements — WordPress

WordPress4.7 推奨環境

PHP version 7 以上
MySQL version 5.6 以上 OR MariaDB version 10.0 以上
HTTPSのサポート

このことから、PHP7での運用は、Wordpressの推奨環境に沿う形となり、また、セキュリティー的にもPHP7を利用する価値があると判断しました。

ちなみに、PHPセキュリティサポートはすでに5.5までが終了しています。
php5.5に脆弱性が発見されたとしても、アップデートはされません。
5.6は、2018/12/31まで、7.0は2018/12/03まで、7.1は2019/12/01までとなっており、なるべくなら安全が長期的に担保されたものを利用したい思いで、7.1を利用することにしました。

Apache・Nginxの切り替えが可能

Apacheを使うか、Nginxを使うかの選択がいつでも変更可能で、管理画面からすぐに切り替えが行えます。
Nginxで運用してみて、Nginxへの知識が浅いので、何かしらの問題に遭遇した時にApacheにすぐに切り替えられるメリットがあります。

また、PHPの切り替えも容易で、とにかく自由度が高いのです。

値段が安くなっていることに気がついた

少し前まで、VPSは高いものだと思っていましたが、ちらっと金額を調べたらめちゃくちゃ安くなっていることに気がついたんです。
今まで使っていた激安サーバーは月額が500円くらいなので、差はありますが、それよりもブログを快適に更新すること（時間的なコスパが高かった)、自由度が高いことに対する支払い金額としては増額分は妥当だと考えました。

ひと昔前は今とおなじスペックでも数万円していたのに。なんたることか。
嬉しい！

とにかくPleskだと楽

アマゾンのAWSが最近流行っており、コストも安く、好きなサーバー構成で運用できるのでメリットも大きいのでどちらにしようか悩みましたが、今回の目的は
WordPressを高速化＋常時SS化するために、
・迅速にサーバー移転
・お手軽に作業をしたい
だったので、VPS+Pleskにすることにしました。

AWSの場合、必要な構成を自分でインストールしていく必要があるので、一つつまづいたりハマったりすると、それだけで時間を食います。
嫌いな作業ではありませんが、面倒すぎるのでまたの機会にAWSは触りたいと思います。

WordPressがめっちゃ早くなった！

上記の構成に加えて、
・キャッシュの設定
・圧縮の設定
・JavaScript読み込みの非同期（async)・遅延（defer）処理

を設定することでさらに爆速に！
いえーーい！！

async：非同期で読み込み、読み込み終わり次第実行する（レンダリングをブロックせずに実行する)
defer：ページの読み込みが完了してからスクリプトが実行されます。

Plesk搭載VPS提供のレンタルサーバーでよかったのがGMOさん

GMOクラウドのVPSが一番お値段的にもサービス的にも良いなと感じました。

というより、Plesk12.5が導入されていて、ヘルプや、関連資料がわかりやすく豊富で、料金的にも安価なのは、GMOクラウドのVPS以外にないかもしれません。

VPSの値段が
メモリ1GプランであればVPS代が780円
Pleskコントロールパネルをつけて350円
※Plesk 12 Web Admin Edition（10ドメインをホスティングできます）
合計1220円(税込)で利用できます。

初期設定費用がちょっと高いのがイヤですね・・・。
無料になりませんか？GMOクラウドのVPSさん！

1Gプランでは心もとないので、2Gプランにした場合は、月額1,760円(税込)になります。

1年契約をした場合の料金にはなりますが、結構お安いと思います。
わたしは、GMOクラウドのVPSの値段を知る前に、他のサーバーを契約してしまい、2Gプランとほぼ同等で、月額1,944円です。

GMOさんの1Gプランと、現在契約中のVPSの2Gプランと最終的に速度を計測して、決定的な違いがあれば、最終GMOさんに移行しようと企んでおります。
※なのでこの記事はGMOクラウドさんのレスポンスチェック記事でもあります(笑)

GMOクラウドのVPSのいいなぁと思った点は、いつでもプランをアップグレードでき、しかもデータの移行作業がないんです。
ということは、初めは1Gプランでやってみて、足りないなと思ったら、2Gプランにアップグレードできるんです。
このサービスが欲しかった！

VPSなのでグローバルIPアドレス(IPv4)も1つついてくるので、何かと捗ります。

無料期間が14日あるので、Pleskの使い勝手なんかを確かめられるのもかなりポイント高いです。

ただ、IPアドレスを追加すると、月に1IP1,000円かかるのが気になっています。
SEO的にIP分散を気にする時代ではありませんが、極力IPは分けていきたいところです。
現在のサーバーは1IP、月額500円でGMO クラウドさんの半額です。
複数サイトを運営するなら、現在のサーバーの方がランニングコストが高いと言えますが、どちらかというとプロ向けなのか、ドキュメントが劇的に少ないので、悩みどころがたくさんありました。

GMOさんは何かと図解を使って丁寧に説明しているので分かりやすそうです。

今回、このサイトのスタートから使っていたサーバー会社から、現在利用中のサーバー、そして、さらに引越しを検討しているGMOクラウドのVPSさんとの最終的なスコアを比較して、最終利用するサーバーについても考えていこうと思っています。

WordPress高速化　PleskにNginx＋PHP-FPMを導入

osのバージョン

コマンド周りや困りごとが起こった時にまだ（日本語の)ドキュメントが少ないので不安でしたが、centos7を選択しました。

pleskのバージョン

Plesk12.5を、アップデートして「Plesk Onyx」にします

GMO VPSで試してみよう！

現在のサーバーとのサーバー応答時間の比較をしてみたかったので、GMOクラウドのVPS
のVPS　1Gプランを申し込みしてみました。

15日間無料お試しができて、グローバルIPが付いているのでIPアドレスでのチェックができるので現在運営中のこのサイトと同じ環境での比較が可能なのでやってみます。

DNS切り替えしなけりゃ何も問題ないので、このサイトのドメインで申し込みました。

centOS7、テンプレートをPlesk付きにしていざ申し込みスタート！

申し込みからサーバー開設までは10分程度で完了しました。

瞬時にサーバー開設の連絡が来た後、その後、VPSの設置までに多少時間がかかるようで、全体で30分程度でした。
VPSの設置が完了するまでできることはありませんが、GMOのコントロールパネルにはログインができます（Pleskはまだできません)。
GMOクラウド VPS ポータルサイト

VPSの設置が完了するとメールでの連絡とともに、GMOクラウド VPS ポータルサイトからVPSを稼働させることができるようになります。
初期設定では、VPSの設置後は停止状態だそうで、自分で起動する必要があります。

「ONボタン」を押して起動するだけです。

その後、Pleskのライセンス発行を待たねばならず、VPS設置完了から約20分程度で、「【GMOクラウド VPS】Parallels Plesk Panelライセンス発行完了のお知らせ」というタイトルのメールがきます。

このメールに記載されているラインセンス情報を利用してPleskの設定をしていきます。

Pleskの初期設定をしよう！

Pleskにログインします。
ログイン情報はメールで送られてます。
わたしの場合、ドメインのDNSを変更していないので付与されたIPアドレスでアクセスします。

SSl証明書のエラーが出た場合は許可をして表示させます。

ドメイン名
IPアドレスは変更せず。
パスワード入力
Ok

メールできているログイン情報のユーザー名は「root」となっていますが、この設定以降は「admin」になります。
以降のログイン時には「admin」とここで設定したパスワードでログインします。

ライセンスのキーをインストールする。
ライセンスキーは、GMOからメールでダウンロード用URLが送られてくる。
メールに記載のURLをクリックすると、ライセンスキーxmlファイルがダウンロードされるので、ダウンロードしたファイルをアップロード。

ライセンスキーをアップデートすると、Pleskが利用できるようになります。

わたしがテストしているプランのPleskは10ドメイン用のものを利用しています。
最初に登録するサイトの情報を入力します。

FTPのユーザー・PASS等を入力して完了です。

この画面が出たらPleskの初期設定は完了です。
閉じるとコントロールパネルが表示されます。

Plesk　Onixにバージョンアップをしよう！

この作業をした時点では、GMOさんで提供しているPleskのバージョンは、12.5でした。
今後のため、セキュリティのために、Plesk Onixにアップデートしておきます。

メニューの「ツールと設定」から設定画面を開きます。
設定画面の「Plesk」項目の「アップデートとアップグレード」をクリックします。

インストーラーの更新が始まります。待つのみ。

インストーラーの更新完了の表示になっても、ページが自動更新されるまで待ちます。

ページが自動更新されました。
なぜだかGMOさんのは英語になりました(笑)
ここから、Pleskをアップデートします。

一番左のアップデートボタンを押します。

Pleskのバージョンを選択します。といってもこの時点では、12.5からアップデートできるのはOnixだけだったので選択状態でしたが。
Okボタンを押してインストールします。

onixアップデートのダウンロードが始まります。
放置でOK。
ダウンロードが完了したら、自動的にインストールが始まります。

インストールが始まると、こんな画面がしばらく続きます。
1Gプランでは、30分くらいかかりました。
画面が動いていないように見えても、完了するまでひたすら待ちます。

完了した模様です。
Okボタンを押します。

アップデート画面に戻りました。今度はちゃんと日本語です(笑)

これで、Plesk Onixへのアップデートが完了しました。
下部のバージョンのところがちゃんとOnix17.0.17になっていますね。

Nginxを利用できるように、コンポーネントをインストールしよう

今回の目的であるWordPressを爆速にするためにNginx、PHP7の導入と、Let’s Encryptによる常時SSL化を行うためには、Plesk画面から、必要なコンポーネントをインストールする必要があります。

「コンポーネントを追加/削除」をクリックします。

リストが表示されます。
今回追加するのは、
「Web hosting」
「Plesk extensions」
の項目です。

左の＋マークをチェックしてメニューを展開。

PHP interpreter versions＞PHP 7.1にチェック（ついでにPHP 7.0も入れました)。
Web hosting＞Nginx web server and reverse proxy serverにチェック。
Plesk extensions＞Let’s Encrypt

をインストールすることにします。

チェックをしたら「続ける」ボタンを押します。

インストールが開始されます。
待つのみです。

完了しました。

ついでに、アップデートが提供されているコンポーネントを念のためにアップデートしておきます。
特に意味はありませんが、最新の状態にしておきたかったので。

ひとつだけ、更新が提供されていました。
画像は省略していますが、「続ける」を押してアップデートしておきます。

以上で、コンポーネントの追加が完了しました。

Nginxを起動しておきます。

ツールと設定メニューにいきます。

サーバー管理＞サービス管理をクリックします。

動いているサービスなんかが見えるようになっています。
一番下にNginxの項目があります。

停止状態なので、矢印マークを押して起動します。
矢印マークをおしても反応がないような気がしますが、少し待ちます。

しばらくすると、「サービスが起動するまで、しばらくお待ちください」と上部に表示されます。

起動が完了すると、稼働を表すアイコンが表示されます。

以上でNginxの起動も完了しました。

Nginx、PHP7、Let’s Encryptを利用できる環境がこれで整いました(*´∀`*)

WordPress高速化　データを新サーバーに移行

まず、移行には、簡単にデータを移行できる「All-in-One WP Migration」を利用します。

All-in-One WP Migrationで移転前サーバーのデータを取得

使い方は、下記ブログさまに詳しく記載されています。
図解入りで分かりやすく、サイトもおしゃれでカッコイイです。

WordPressのお引っ越しプラグインはAll-in-One WP Migrationが最強

ワードプレスの引っ越し最強プラグインAll-in-One WP Migrationの使い方や使用方法などを説明します。

ホームページ制作・Webサイト制作・Webシステム開発のITS

現在稼働中の（古いサイト)のデータをを、All-in-One WP Migrationプラグインを使ってダウンロードします。

まずは稼働中の管理画面から、All-in-One WP Migrationプラグインをインストールしておきます。

インストール後、上記ブログさまに書かれている手順で移行データをダウンロードしておきます。

新しいサーバーにWordPressをインストールしておく

Pleskを使うとこういうのも便利なのですが、Plesk管理画面からWordPressをボタンひとつでインストールすることができます。
また、通常、WordPressの移転時は、IPアドレスでの動作チェック等が必要になる場合が多いのですが、Pleskの場合は、プレビュー機能があり、ドメインDNS切り替え前に動作の確認ができるのでとても便利です。

DNSを切り替えてから、あちゃ〜〜！サイトが見られない！えらいこっちゃ！！
となりません。

古いサーバーと、新しいサーバー、同じドメインで、DNSが切り替わるまでどちらもアクセスでき、サイトの停止状態がないのが嬉しいです。

それでは、PleskからWordPressをインストールしてみます。

アプリケーションメニューからアプリケーションインストール画面に移動します。

WordPressを簡単にインストールできます。
古いサイトのデータをアップしなくてもいいの？という疑問は無用で、All-in-One WP Migrationプラグインで取得したデータが、PleskからインストールしたWordPressに「ユーザー情報（ログイン情報)」以外、全て旧サーバーの物が上書きされます。

WordPressインストールメニューの「インストール」ボタンをクリックします。

インストールが始まります。
終わるまで待ちます。

完了画面が表示されます。
Pleskによって、ユーザー情報が自動的に登録されますので、自分で覚えやすいものに変更しておきます。
画面上部の「設定変更」ボタンをクリックします。

ユーザー情報の箇所のみ変更します。
その他の箇所は、All-in-One WP Migrationプラグインで取得したデータによって書き換えられるので変更なしでOkです。

「適用」を押して、変更を適用させます。

設定が完了したら、インストールしたWordPressが表示されるかチェックをしてみます。

先ほども触れましたが、Pleskにはプレビュー機能があるので、ドメインのDNSを変更していなくても、サイトのチェックが可能です。
（通常、WordPressは設定したドメイン以外でアクセスしても自動的に転送されてしまいます。）

「ウェブサイトとドメイン」メニューから、ドメインの管理画面に移動し「プレビュー」ボタンをクリックしてみます。

どうでしょうか？
WordPressの初期画面「Hello world!」がでてきました。
インストールは無事完了しました。

プレビュー画面のURLは、
http://割り当てられたIPアドレス/plesk-site-preview/Pleskに設定したドメイン/割り当てられたIPアドレス/
となります。

現時点では、トップページは
http://割り当てIPアドレス
で閲覧できますが、管理画面やその他ページは閲覧することができません。

当然ながら、ドメインでアクセスしても現在稼働中のサイトに行くだけなので、一旦、新サーバーWordPressへIPアドレスからアクセスできるようにするためにサイトURLの設定をプレビュー画面から行います。

http://割り当てIPアドレス/plesk-site-preview/Pleskに設定したドメイン/割り当てIPアドレス/wp-admin/
にアクセスします。

WordPress管理のログイン画面が表示されました。
先ほどPleskで設定したユーザー名、パスワードでログインします。

ログインできました。
まだ何も入っていない真新しいWordPressです。
初々しい。

左の設定メニューから、一般メニューを表示させます。

WordPressアドレス、サイトアドレスのところの、ipアドレス以降を削除して、保存します。
その他の項目や、ディレクトリ構造については、旧サーバーからAll-in-One WP Migrationでエクスポートしたデータを新サーバーにインポートした際に自動的に変わりますので気にしなくて問題ありません。

これで、Ipアドレスから新しいWordPressをチェックすることができるようになります。

一度、
http://割り当てIPアドレス
管理画面は
http://割り当てIPアドレス/wp-admin/
でアクセスをしてみると、無事、IPアドレスでトップページ以外も閲覧できるようになっています。

これで、インストールが完了したので、このWordPressに旧サーバーからAll-in-One WP Migrationでエクスポートしたデータを反映させていきます。

All-in-One WP Migrationプラグインで取得した旧サーバーのデータを新サーバーに適用させるには、新サーバーのWOrdPressにもAll-in-One WP Migrationプラグインを入れる必要があります。

新サーバーにWordPressデータを反映させる

新サーバーのWordPress管理画面のプラグイン新規追加より、「All-in-One WP Migration」で検索をして、インストール、有効化します。

有効化すると、左のメニューに「All-in-One WP Migration」というメニューが表示されるので、マウスオーバー→サブメニューからImportをクリックします。

インポート用の画面が表示されました。
この画面に、旧サーバーからダウンロードしてきたWordPressデータをドラッグ＆ドロップしてアップロードします。

ドラッグ＆ドロップをするとインジゲーターで進行状況が表示されます。
しばし待ちます。

旧サーバーのWordPressデータのアップロードが完了すると、上書きをして良いかの確認画面が表示されます。
新サーバーは新しく追加したWordPressで上書きさせるのが目的ですから、「CONTENUE」ボタンを押して実行します。

インストールが始まります。
しばし待ちます。

完了したようです。
「CLOSE」ボタンを押して完了します。

さぁ！どうでしょう！！
旧サーバーと全く同じ画面が表示されました。
全てのデータがきちんと反映されているようです。

なんと楽なのでしょう！！！！！！！

ヽ(ﾟ▽^*)乂(*^▽ﾟ)ﾉ ﾊﾞﾝｻﾞｰｲ♪
これで、新サーバーへのWordPressを稼働中のものと同じ状況で設置することができました。

ちなみに、このプラグイン、「All-in-One WP Migration」は、インポート作業をしている管理画面のURLを取得し、自動的に全データを変更してくれます。
なので、IPアドレスで接続している状態でインストールをしている現在は、全ての設定（データベースのデータも含め)がIPアドレスに置き換わります。

後述しますが、最終的に新サーバーに向けてDNSを切り替える前には、サイトURLの変更と、データベースのデータ全てを書き換える必要が出てきます。
hostsファイルの設定でドメインで新サーバーを見にいくこともできますが、面倒なので書き換えで対応します。

旧サーバーと、新サーバーのWordPressのデータが同じものになったところで、
新サーバーと旧サーバーでのページ表示速度を測定してみます。

休憩。PHP5.4と、PHP7.1の速度を比較してみよう

せっかくなので、今後の勉強のために、速度の違いがどれくらいあるのかをチェックしてみたいと思います。

速度チェックに利用したのは
・Googleさんのツール「PageSpeed Insights」
・Pingdomさんのツール「Pingdom Website Speed Test」
の2つです。

まずはGoogleさんの「PageSpeed Insights」をみてみます。

PCとスマホ版、別々に結果が出るので、まずPCです。

一番左が、PHP5.4＋PHP-FPM+Apache
真ん中が、PHP7.1＋PHP-FPM+Apache
一番右が、PHP7.1＋PHP-FPM+Nginx
です。

あれれ？
最初の測定よりスコアが下がっております・・・。
(旧サーバーでのモバイルのスコアは52、PCは68でした。)
この理由は、「画像の圧縮」にありまして、もともと利用していた激安サーバーでは、サーバーの設定ファイルhttpd.confによって、あらかじめ画像の圧縮が有効になっていたためエラーに加算されず、GMOクラウドのVPS
については画像の圧縮部分についてはまだ設定していない段階での測定のためスコアが下がっているのです。

ここは旧サーバーとの比較ではなく、PHPのバージョンと、webサーバーの組み合わせによる比較としてみていく必要があります。
旧サーバーとの比較は最終的にやっていきたいと思います。

みてみると、PHP5.4＋PHP-FPM+Apacheの組み合わせで出ていた（Pleskデフォルトの状態です)、「修正が必要」となっている箇所の、サーバー応答時間についてのエラーが、PHP7.1＋Apacheでは「修正を考慮」するに変化しました。
そして、PHP7.1＋Nginxにすると、サーバー応答時間に関するエラーは出なくなりました。

ただ、「PHP7.1＋PHP-FPM+Apache」と「PHP7.1＋PHP-FPM+Nginx」についてはそんなに変わりなく、上記エラーが消えただけで、スコアも全く同じです。

サーバー側ではないコンテンツ側の修正箇所が多く、スコアはそんなに伸びていませんね。

Nginxは本来、たくさんのリクエストへの対応・静的ファイルの扱いが得意といった特徴があるので、同時閲覧のボリュームの大きい企業サイトなんかでないとNginxの恩恵は受けられないかもしれません。弱小ブログで張り切ってしまったようです。

次にスマホの方の結果をみてみます。

スマホの方も大方、PCと同じ結果になりました。
スコアの低さに相変わらず驚きです。

次に、Pingdom Website Speed Testで、ページの表示速度をチェックしてみます。

こちらも、PHP7にすることで1.3秒ほど短縮できたようです。
PageSpeed Insightsの結果と同じように、PHP7の場合は、ApacheでもNginxでもあまり結果は変わりませんでした。

旧サーバーはスコアC74、Load time6.82秒でしたので、旧サーバーと比較すると、2秒近く短縮できたことになります。
スコアに関しては、同じくgzipによる画像圧縮が効いていないので、新サーバーの方が低くなっています。
これは後ほど設定で調整をしていきます。

PleskでのPHPバージョン、ApacheとNginxの切り替え方法

Plesk環境の良いところは、こういったPHPのバージョンや、webサーバーの選択など、コントロール画面から自由に変更できる点にあります。
構成の変更方法は下記の通りです。

「ウェブサイトとドメイン」からホスティング設定をクリックして設定画面を開きます。

PHPサポート（PHPバージョン)の項目と、PHPの実行タイプの2箇所を変更するのみです。

PHPサポート（PHPバージョン)を7.1に、PHPの実行タイプを、FPMアプリケーション＋Nginxがわたしの環境の場合一番早かった設定です。

ただし、Nginxにした場合、この時点ではトップページ以外は404エラーとなり、表示されません。

トップページ以外を正しく動作させるには、Apacehの設定ファイルである.htaccessへの記述の代わりとなるものを、Nginxの場合はconfに設定する必要があります。
Pleskの場合は、「追加ディレクティブ」の設定欄から簡単に追加できます。

WordPressをNginxで動かせるようにする

ウェブサイトとドメインの設定から、「ApacheとNginxの設定」にいきます。

「nginx 追加ディレクティブ」欄に下記コードを、コピペして、適用を押します。


# Source: https://www.websavers.org/how-to-speed-up-wordpress/
rewrite !\.(js|ico|gif|jpg|png|css|pdf|mov|mp3|eot|svg|ttf|woff|otf|txt|swf)$ /index.php break;
rewrite /wp-admin/$ /wp-admin/index.php break;
rewrite /$ /index.php break;

location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# .から始まるファイルへのアクセス拒否
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}
# wp-configへのアクセス拒否
location ~* /wp-config.php {
deny all;
}

※最低限の設定しかしていません。
※https://www.websavers.org/how-to-speed-up-wordpress/を参考にしています。

この設定をするとwebサーバーにNginxを選択しても
http://割り当てIPアドレス/ページスラッグ
でアクセスができるようになります。

これで、Nginx選択時でも、下層ページも閲覧できるようになりました。

これで、普通にはサイトが運営できるようになりました。

「スピードチェックで出ていたエラーをなんとかして、スコアをあげておきたい」という気持ちがなければ、ここで完了です。
DNSの切り替えをすれば、新サーバーでサイトが運営できます。

DNSを切り替える前に、サーバーのサイトURLの設定をIPアドレスから、運営するドメインに変更しておく必要があります。

これについては備忘録の最後の方に記載しています。

・WordPress高速化
・常時SSL化
の作業が残っていますので、進めていきます。

WordPress高速化　各種設定をする

まずは課題の整理です。
先ほどのスピードテストをもう一度みてみます。
修正が必要な箇所として表示されているところを課題として解決していきたいと思います。

PCの課題は、

• 圧縮を有効にする
• ブラウザのキャッシュを活用する
• スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する

の3つです。

モバイルの課題は、

• スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する
• ブラウザのキャッシュを活用する
• 圧縮を有効にする
• 表示可能コンテンツの優先順位を決定する

の4つです。

モバイルの「表示可能コンテンツの優先順位を決定する」以外は、同じ問題点が指摘されています。

まずは、この3つから解決していきます。

圧縮を有効にする

gzip や deflate を使用してリソースを圧縮することで、ネットワークで送信されるバイト数を減らすことができます。

とありますので、gzipで圧縮をしてみます。

Nginxの場合は、先ほども出てきた、Plesk画面のNginxの追加ディレクティブにて対応します。

ウェブサイトとドメインの設定から、「ApacheとNginxの設定」にいきます。

「nginx 追加ディレクティブ」欄に下記コードを、コピペします。

# gzip設定
gzip on;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 4 32k;
gzip_types
text/plain
text/html
text/xml
text/css
application/xml
application/xhtml+xml
application/rss+xml
application/atom_xml
application/javascript
application/x-javascript
application/x-httpd-php;
gzip_disable "MSIE [1-6].(?!.*SV1)";
gzip_vary on;

次に、ブラウザのキャッシュを活用するための設定を行います。

ブラウザのキャッシュを活用する

ブラウザのキャッシュを活用するための設定も、Nginxの追加ディレクティブから行います。

追加ディレクティブ欄に下記コードをコピペします。
# キャッシュ設定
location ~* ^/(.*\.(js|css|png|jpg|jpeg|gif|ico))$ {
expires 2w;
log_not_found off;
}

※2週間に設定しています。
※割愛していますが拡張子ごとに期間を変更することもできます。

上記でキャッシュをするように設定したjs|css|png|jpg|jpeg|gif|icoについては、Nginxでの静的処理をしてしまうとキャッシュされません。
追加ディレクティブ上の「静的ファイルを nginx で直接処理」から該当の拡張子を削除します。

「適用」ボタンを押して保存します。

no-cashになっていないかチェック

キャッシュを有効にしたのに、スピードチェックでエラーが改善されないことがあります。

そんな時は、WordPressの何かしらのプラグインから、no-cashヘッダーが繰り出されていないかチェックをします。

わたしの場合は「redirection」というプラグインがno-cashを履いていたので、使っていないし、とプラグインを停止して対応しました。

このあたり利用しているプラグインによっては、運用上、停止できない場合もあるかもしれないですね。

スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する

PageSpeed Insightsのエラー説明は下記のとおりです。

このページには、レンダリングをブロックするスクリプト リソース が 13 個、CSS リソースが 14 個あります。これが原因で、ページのレンダリングに遅延が発生しています。
以下のリソースの読み込みが終わるまで、このページでスクロールせずに見えるコンテンツを何もレンダリングできませんでした。レンダリングをブロックするリソースの読み込みを遅延させるか、非同期に読み込むか、これらのリソースの重要部分を HTML 内に直接インライン化してください。

この対応策として、

1. JavaScriptは</body>タグ付近で読み込むようにする
2. JavaScriptはの読み込みタグの<script>にdefer(遅延)またはasync(非同期)属性を付ける

Autoptimizeでcss、html、jsの最適化

このあたりにはもうめんどくさくなってきたので、プラグインですべてことを済ませようと、Autoptimizeで対応をすることにしました。
Autoptimizeは、PageSpeed Insightsで出ているエラーの代替を回避してくれます。

<参考サイトさま>Autoptimizeの設定方法と使い方｜HTML、CSS、JavaScriptを縮小して高速化できるWordPressプラグイン

利用しているプラグインや、テーマによっては崩れが生じることもあるようです。

また、キャッシュが溜まっていくので、定期的キャッシュのクリアをした方が良いようです。

JavaScriptはの読み込みタグの<script>にdefer(遅延)またはasync(非同期)属性を付ける

これは、テンプレートファイルのfunctions.phpに設定を追加します。

下記サイトさまを参考に実施しました。
WordPressのscript_loader_tagを使ってscriptタグをすっきりする

わたしは挙動がおかしくなったので、一部ファイルには何もせず、その他ファイルについては、「defer」設定をすることで対応しました。

function replace_script_tag ( $tag ) {
if(preg_match('/jquery\.min\.js/',$tag)){//jqueryはasync
return str_replace( "type='text/javascript'", 'async', $tag );
}else{
return str_replace( "type='text/javascript'", 'defer', $tag );
}
}
add_filter( 'script_loader_tag', 'replace_script_tag' );


上記コードを、テンプレートのfunctions.phpの一番下に追加したのみです。

Pleskの場合、このへんの編集も、Plesk画面からできるのがとても楽です。

この一連の作業で、FTPを一切使っていないというのがめんどくさがりには楽でいいです。

ブログ村のPVランキング参加タグが邪魔をする・・・

ブログ村のPVランキングを表示させるためのタグを、ウィジェットに追加して利用していたのですが、スピードチェックではネックとなってしまいました。

ウィジェットのScriptタグにdeferやasyncを付与すると正しく動作しなかったので、別の方法を採用することにしました。

上記「Autoptimize」プラグインは、ウィジェットにかかれたスクリプトタグ等には反応しませんので、圧縮もされません。
面倒ですが、テンプレートのfunctions.phpを再度触ってブログ村スクリプトへの対応をします。

下記コードを追加。
if (!is_admin()) {
function blogmura_script(){
wp_register_script('blogmura', '//blogparts.blogmura.com/pts/js/parts_view.js', array(), '' );
}
function blogmura_add_script() {
blogmura_script();
wp_enqueue_script('blogmura');
}
add_action('wp_enqueue_scripts', 'blogmura_add_script');
}

そして、先ほどのコード

function replace_script_tag ( $tag ) {
if(preg_match('/jquery\.min\.js/',$tag)){//jqueryはasync
return str_replace( "type='text/javascript'", 'async', $tag );
}else{
return str_replace( "type='text/javascript'", 'defer', $tag );
}
}
add_filter( 'script_loader_tag', 'replace_script_tag' );

を

function replace_script_tag ( $tag ) {
if(preg_match('/jquery\.min\.js|blogmura/',$tag)){//jquery・ブログ村はasync
return str_replace( "type='text/javascript'", 'async', $tag );
}else{
return str_replace( "type='text/javascript'", 'defer', $tag );
}
}
add_filter( 'script_loader_tag', 'replace_script_tag' );

に書き換えて保存します。

「jquery.min.js」、「blogmura」にマッチするファイルに関してはasync(非同期通信)でファイルを読み込む形にしました。

ウィジェットに記載してあった、
<script type=’text/javascript’ src=’//blogparts.blogmura.com/pts/js/parts_view.js’ charset=’UTF-8′></script>
については上記のようにテンプレートから読み込むことにしたので、削除しました。

画像の圧縮には、EWWW Image Optimizer

いつからか、画像の圧縮ができておらず、スピードチェックでエラーが出ていました。
EWWW Image Optimizerを利用して、圧縮されていない画像を一括で最適化して解決しました。

これで、SSL化以外のところは、一旦設定ができたこととして（完全ではないのですが、PCのスコアが85を越えたらそれでいいと思っていたので）、ある程度のスコアが出たところで切り上げました(笑)

その他、導入したプラグイン

今回、Nginxを利用することにしましたので、サーバー側にもキャッシュが残り、記事を更新したのに変わらない！なんてことが起こります。
Nginxのキャッシュを削除するプラグイン「Nginx Cache」を導入しました。

ヘッダーにキャッシュを削除するメニューが出てくるので、必要に応じてキャッシュを削除しつつ運用していきたいと思います。

Word Press高速化 最終的なスコアを比較・確認しておきます

「PageSpeed Insights」での測定結果

まずは、PageSpeed Insightsでのモバイルのスコアです。

最終、GMOさんのサーバーの場合は、72までスコアが改善されました。

はじめはモバイルのスコアは52でしたので、その他の改善も含めて最終的には20スコアが改善されたことになります。
ブラボーです。

サーバーの速度が激安サーバーとVPSサーバーとで大きく違うのは、PHPのバージョンによるものかと思います。

3倍以上の速度です！
体感としては、もっとも〜〜〜〜っと速くなった感じがします。
かなり嬉しい！！サクサクサクサク動く♪

続いてPCです。

改善前のPCのスコアは68でした。
改善後は、89と、21スコアを伸ばすことができました。

100まであと少しというところですが、外部のリソース等もあるので、ここらで断念しました。

PCのGMOでの結果は、サーバー応答速度が0.2秒以下と、大変素晴らしい結果となりました。
サーバーの応答時間の差でいうと5倍以上！

かなり嬉しいです(*´∀`*)

といっても、まだテストの段階で、GMOさんにDNSを切り替えていないので、現在のスコアは、真ん中の使えるネットさんのものになります(笑)
夜中にしたかったので、今晩にでもやってみようと思います。

「Pingdom Website Speed Test」での測定結果

Pingdom結果も、概ねPageSpeed Insightsと同様です。
サーバーの速度は、ストックホルムからのアクセスの場合、という数値なので、Load timeが長いのですが、激安サーバー、現在利用中のVPSサーバー、GMOのVPSサーバーの順番で速くなっていっています。

こちらのLoad timeの数値は最初の測定時は、「6.82秒」でした。
最終的に3.25秒になったので、半分以下になったことになります＼(^o^)／ﾔｯﾀｰ!

体感速度としては、もっともっと早く感じます。特に管理画面が全然違うので、とても嬉しいです。

現在のサーバー使えるネットさんと、GMOさんの無料期間で試した数値ですが、GMOさんの数値が良くて、GMOさんにまたお引っ越ししようか悩み中です。

1秒半くらい違うので、こりゃ、GMOクラウドのVPSにやっぱり変えようかな(笑)

使えるネットの方は、CPU 2.4Ghz2コア・メモリが2G・OSがCentOS6で、
GMOクラウドのVPSの方は、CPU（QEMU Virtual CPU version (cpu64-rhel6)） クロック数記載なし、2コア、メモリが1G、CentOS7です。

CPUが比較できないのでなんともあれですが、GMOクラウドのVPSの方がメモリは少なく1Gしかありません。

VPSについてはどちらもNginx＋PHP7での比較です。

GMOクラウドの2Gプランも試してみたいところですが、1Gで止めておきます(笑)

上記の結果から、GMOクラウドのVPSにしようかと思っています。

WordPressを快適に動かせるよ！とWordPressに特化したレンタルサーバーもたくさんありました。
しかも、大抵が無料SSLが付与されるので、他のサーバーも速度的な面で比較してみたいと調べてみたのですが、わたしのやりたいことが一番安価で叶えられるのが、使えるネットさんかGMOさんだったので、二つを比べた場合速度的な面でGMOさんにまたお引っ越しをする予定です。

他のサーバーは、複数ドメインにしようと思うと2契約必要だったり、VPSと言っていってもWordPress１つしか設置できなかったりと、自由度が低いことが多くて悩みました。
SSD採用のサーバーもすごく気になったのですが、上記理由から今回は見送りました。

自由にはばたきたいので、現在のサーバーか、GMOのVPSのどちらかがわたしには良さそうです。

幸い、この比較テストのために環境作ったのであとはDNS切り替えるだけなので、無料期間いっぱい悩んでみたいと思います(笑)

サイトURLの変更・DNS切り替え

サーバーが決まったら、DNSの切り替えを行わなくてはいけません。
DNSの切り替え前に、まず、新サーバーへ設置したWordPressのURLを変更しておく必要があります。

サイトのURL変更は、「Search & Replace」というプラグインで実施しました。
プラグインの新規追加から、「Search & Replace」を検索して、インストール、有効化をします。

「Replace Domain URL」タブを表示させ、Replace with:に運用ドメインを入力します。
わたしの場合は、SSL化をし、https://oka-miler.info/で運用予定なので、そのように入力しました。

その他の項目はわたしの場合変更不要でしたので、「Do Replace Domain/Url」を押して完了です。

サーバーを移転する場合は、動作確認をしてDNSを切り替えておく

ドメインのコントロールパネルから（muumuuドメインとか、お名前.comとか？）DNSの変更を行います。

PleskへのDNSテンプレートの登録方法や、外部ドメイン（ムームードメインが例となっています）のDNS設定変更方法等、下記サイト様がとてもわかりやすいです。

Plesk12の初期設定からDNSの設定まで-趣味を活かしたアフィリエイト実践記

DNSが新サーバーに向いたら、常時SSL化を進めます。

Plesk 無料SSL証明書「Let’s Encrypt」による「常時SSL化」

Pleskによる「Let’s Encrypt」の導入は、ボタンを押すだけの簡単設定です。
※Plesk12.5以上

この記事のPlesk設定部分で記載しましたが、コンポーネントの追加から「Let’s Encrypt」を導入する必要があります。

「Let’s Encrypt」を導入

※テストの段階では「Let’s Encrypt」は導入できません。DNSの切り替えが完了してからでないとエラーになります。

コンポーネントを追加すると、ウェブサイトとドメインメニュー内に、Let’s Encryptの項目が表示されます。
クリックをして、導入画面を表示させます。

メールアドレスを入力して、「インストール」ボタンを押します。
「www. を代替ドメイン名として含めます。 」の箇所は、どちらでもお好きな方で良いかと思います。

インストールが完了したら、もうこれで、SSL通信ができるようになります(*´∀`*)
なんと簡単な。

そうそう、これがやりたかったんだよ(笑)

試しに、https://をつけてアクセスしてみます。

きちんとSSL化されているようです。
いいですね〜。

SSLの導入は完了しましたが、「常時」SSL化をしなくてはいけません。

現在の状態は、「SSLでもアクセスできる」状態なので、いつ、だれがアクセスしても、「SSL」通信でサイトを閲覧してもらう必要があります。

今回はWordPressも絡んでいるので、設定変更も含めて、常時SSL化をしていきます。

といっても、WordPress側の設定は「Search & Replace」プラグインで全て書き換えたので問題ありません。

Plesk側から、http://でアクセスがあった場合、https://に転送をさせる設定をするだけです。

常時SSL化 Pleskからリダイレクト設定をする

「常時」SSL通信するには、非SSL通信でアクセスがあった場合は、SSL通信でアクセスしていただけるように、https://にリダイレクトをさせる必要があります。

通常、Apacheの場合は.htaccessで、Nginxの場合はconfファイルで転送設定をしますが、Pleskの場合はドメインの設定から簡単に設定できます。

Pleskのウェブサイトとドメインメニューから、「ホスティング設定」をクリックして設定画面を開きます。

セキュリティの設定項目の、「SEO に対応する HTTP から HTTPS への恒久的 301 リダイレクト」にチェックを入れます。

SSL/TLS サポートにチェックが入っているか、
SSL証明書にLet’s Encryptが選択されているか、
も確認して適用するのみです。

試しに、非SSL通信でサイトにアクセスしてみます。https://にリダイレクトされれば成功です(*´∀`*)

まぁ、簡単！！

これで、サイト自体の常時SSL化は完了しました。

常時SSL化するにあたって、細かい周りの設定を行っておく必要があります。

・GRC
・アナリティクス
・Google Search Console
・アドセンス
・SNSボタンの数値引き継ぎ（SNS Count Cacheプラグインの設定変更）
・非SSL通信アクセスの画像・js・css等の編集（外部サイトのバナー等)
などなど。

このあたりは、下記ブログさまに手順も含めて非常に詳しく記載されています。

<参考サイトさま>
WordPressをhttpからhttpsにSSL化した全手順まとめ（エックスサーバー環境）

特に、「非SSL通信アクセスの画像・js・css等の編集」は、環境によっては面倒かもしれません。

わたしの場合は、ポイントサイトのバナー画像のURL変更のみで終わりました。
ハピタスさんと、ポイントタウンさんのバナーを掲載しているのですが、画像部分のURLをhttp://からhttps://に変更したのみで楽でした。

これで、常時SSL化が完了しました。
運営しながら、何かおかしな点を見つけたら少しずつ修正していきたいと思います。

たぶん、やったことは全部書けたはず・・・。
備忘録ってすごく時間がかかりますね。
もう嫌だ^^