先日、ロリポップからmixhostへの乗り換えを行いました。乗り換え先のmixhostでは無料でサイトをSSL対応にすることができます。
今回はmixhostでサイトをSSL対応したのですが、これが意外と大変でした。笑
今回はmixhostのサーバでSSL対応する時の設定手順と、発生したエラーおよび対処についてまとめました。また、SSL対応したことで意外なメリットもあったのであわせてご紹介します。参考になれば幸いです。
実施したこと
私がmixhostのサイトをSSL対応するために実施したことは以下の作業です。1個1個細かく、ご説明したいと思います。
- mixhostのSSL設定
- wordpressの設定変更
- リダイレクトの設定
- コンテンツの内部リンク見直し(serch Regex)
mixhostのSSL設定
まずはmixhostのSSL設定です。ただし、mixhostではwordpressの設定が完了すれば、何もしなくてもSSLが使えるようになっています。私のように別のサーバから移行した場合はWordPressのデータ移行後にDNS設定を変更し、あとはひたすら待つだけです。
なお、データの移行前にはhostsファイルを使って動作確認をしておいてください。これを怠ると、DNSの設定変更後にエラーとなってしまうため、サイトの評価に影響してしまうかもしれません。hostsファイルを使った動作確認は以下の記事を参考にしてください。

WordPressの設定変更を行う
続いて、WordPressの設定変更を行います。
WordPressの管理者メニューの「設定」>「一般設定」から以下2つを設定してください。
- WordPress アドレス (URL)・・・WordPressをインストールした場所
- サイトアドレス (URL)・・・・・管理者メニューにログインするためのアドレス
これも非常に簡単であまり迷うポイントはないと思います。
httpsへのリダイレクト設定を行う
続いてhttpのURLにアクセスしてきたユーザを自動でhttpsのURLに飛ばすリダイレクトの設定を行います。
httpsへのリダイレクト設定は「.htaccess」ファイルを編集します。「.htaccess」ファイルはWordPressをインストールしたフォルダの直下にあります。「.htaccess」ファイルは隠しファイルであるため、「.htaccess」ファイルが見当たらないという方はFTPソフトの設定などで隠しファイルを表示するように設定変更してください。
htaccessファイルのリダイレクト設定内容
「.htaccessファイル」に記載する内容は以下の通りです。これにより、httpでアクセスしたユーザはhttpsのページにリダイレクトされます。
<IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{HTTPS} !=on [NC] RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] </IfModule>
リダイレクトの動作確認方法
上記の設定により、リダイレクトが有効になっているかについては、以下のサイトのリダイレクトツールを使って確認してください。

このように、httpにアクセスしたが、httpsにリダイレクトされたことが確認できればOKです。
コンテンツの内部リンク見直し(Search Regex)
最後に、本文内のコンテンツの内部リンクの見直しを行います。私の場合はSearch Regexというプラグインを用いて一括置換しました。
私はSearch Regexに詳しいこちらのサイトやSimplicity本家のわいひらさんのサイトを参考に実施しました。
なお、コンテンツの内部リンク見直し設定についてはSearch Regexを使用する以外にもいくつか別の手段があります。
Simplicityの設定機能を使う
Simplicityの設定機能を使えば、簡単に内部リンクの見直しを行うことができます。

私もこの方法にするか迷ったのですが、
- 毎回表示前に毎回PHPで置換してするので多少の処理時間がかかる
- 全ての非SSL URLに対応しているわけではない
という2点が気になったのと、実際に全てのデータを修正した方が安全かなと思い、やめました。
Really Simple SSLを導入する
Really Simple SSLはmixhostの公式サポートでも導入が推奨されているプラグインです。このプラグインを利用した場合、SSL対応のために常にこのプラグインを有効化しておく必要があります。
私は極力余計なプラグインを入れない方が良いと思っています。プラグインによるサイトの負荷増加やプラグイン同士の相性問題などもあるためです。というわけでこのプラグインも導入はやめました。
SSL対応してみて発生したエラー
上記の流れで実施すれば、基本的にはうまくいくと思います。ただ、私の場合はいくつかエラーが出てしまいました。
エラーの内容と対処方法についてご紹介します。
- ログインできなくなった(404エラー)
- リンクエラーが出まくった(cssの取り消し線を表示はなくした)
ログインできなくなった(404エラー)
SSLの設定変更後、管理画面からログインしようとすると404エラーが発生しました。正しいIDとパスワードを入力しているにも関わらず、ログインボタンを押下後にログインエラーとなりました。
色々と調べた結果、SiteGuardのプラグインが何か悪さをしていることがわかりました。
FTPソフトを使ってSiteGuardのプラグインを削除
SiteGuardが原因であることまではわかったのですが、管理画面にログインできないため、サイトからプラグインの設定変更を行うことはできません。
そこで以下2つを実施しました。
- .htaccessファイルからSiteGuardの記載を削除
- FTPソフトを使って、プラグインフォルダにあるSiteGuardを削除
すると、無事ログインすることができました。ログイン後に改めてSiteGuardをインストールし、管理ページアクセス制限も有効にしたところ、問題なく動作しました。
SearchRegex実施後にリンクエラーが続出
SearchRegexを実施した後、リンクチェッカーというリンク切れを確認するプラグインでリンクエラーが続出しました。
ただ、該当のリンクを表示しても普通に表示できました。リンクチェッカーで再確認してもうまく表示できたため、たまたま一時的なエラーが出てしまったのかなと考えました。
結果的にはプラグインの誤認でしたが、今後も発生するかもしれません。そのため、リンク切れのように見えてしまうように、リンクチェッカーの設定画面から「リンク切れ時に取り消し線を付与する」という設定は解除しておきました。
SSL対応したことによる効果
Googleが公表していた通りにSSL対応しましたが、正直、順位が上がりやすくなったのかはよく分かりません。
ただ、SSL対応したことでHTTP2.0に対応されたため、若干速度が改善されたと思います。改善というか速度が安定しました。また、鍵マークが緑色になったこともあり、サイトの信頼度が上がったせいか、離脱率が下がったり、ページ平均滞在時間が長くなりました。
全てがSSL対応したことによって得られた効果かは分かりませんが、多少なりともSSL対応が良い影響を及ぼしていると思います。
まとめ
SSL対応は思っていたよりも面倒でした。笑
ここに書き切れませんでしたが、実は他にも色々と設定変更しました。(これらが地味に面倒でした。。。)
- Googleアナリティクスの設定変更
- SearchConsoleの設定変更
- SNSボタンのコード再取得
- サイドバーに表示しているウィジット等、ソースの直接編集箇所の変更
色々と面倒なことが多かったのですが、得られたメリットもそれなりにあったと思っています。まだ躊躇している方もこの記事を参考にしていただき、SSL対応にチャレンジしてみてください。
コメント