ITつれづれなるままに

WordPressサイトを全SSL化したよ♬ IT技術者が実施した手順とポイントと苦労話と将来について ━Stinger対応━

2017/06/02

スポンサーリンク

このサイトではないのですが、サブドメインで展開しているサイトをテストを兼ねて全SSL化しました。全SSL化というのは、お問い合わせページなどの個人情報を入力するページだけSSL化するのではなくて、全ページをhttpsで接続するようにサイトを変更することを指します。

SSL化の手順を説明する前に、SSL化のメリットとデメリットを整理しましょう。

SSL化のメリット
◇URLに鍵マークが表示されサイト訪問者にサイトの信頼性をアピールできる
◇サイトに対するGoogleの評価が上がる(ランキング指標の一つ)
ウェブマスター向け公式ブログ:HTTPS をランキング シグナルに使用します

SSL化のデメリット
◇現時点ではサイトレスポンスが落ちる
◇アフィリエイトサイトには適用できない
◇アドセンス広告の収益が下がる可能性がある
アドセンスヘルプ:SSL対応のAdSense用広告コード

メリット以上にデメリットが多いと感じるかもしれませんが、Googleが公式にランキング指標にすると言っているようにSSL化は時代の流れといっても過言ではありません。何よりサイト訪問者へ安心感を与えられるのが一番大きい利点でしょう。
とはいえ、デメリットに記載した通り現時点ではどんなサイトもSSL化するのは得策とは言えません。
特にアフィリエイトサイトはSSLに対応していないASPがあるので注意しましょう。

SSL化推奨のサイト
◇個人情報などの機密情報を取り扱うサイト
◇アフィリエイトではないECサイト
◇SSLに対応済みのASPを利用しているアフィリエイトサイト
◇企業サイト

Googleは、アドセンスはSSL対応の広告オークションの関係から収益が下がる可能性があると丁寧に解説していますが、広告サイトはアクセスを集めることが前提でサイトの信頼性はアクセスアップのための重要な要素の一つです。

ブログや個人サイトでもマネタイズを意識するのならSSL化したほうがいいと個人的には思います。
主観ですが、広告サイトだからと若干の収益ダウンを嫌ってSSL化を見送るのは本末転倒かと。

Contents

全SSL化の手順

手順概要
1.既存環境のバックアップ
2.SSL証明書の取得
3.内部リンクの修正
4.テーマとプラグインの修正
5.WordPressの設定変更
6..htaccessの設定変更
7.動作確認
8.サイト高速化
9.SSL環境のバックアップ
10.ウェブマスターツール再登録とサイトマップの送信

レンタルサーバーはエックスサーバーとして手順ごとに解説します。
他レンタルサーバーを利用されている方は内容を読み替えるか、不明点ある場合はレンタルサーバー側に問合わせてみてください。
それと個人的にもできる限りの対応はします。
contact@irodorinet.com
ただし回答に関して動作保障はしないし回答日数の制限も設けないので、サイトポリシー を含めてご了承いただける方のみのお問い合わせとさせてください。
なお個人的な絡みも歓迎しますので興味あるかたは是非ツィッターのフォローを♫

バックアップは必ず取りましょう

SQLバックアップとレストア

記事情報やリンク情報、IDやパスワード情報などが保存されています。URLが変わるので事前に保存しておきましょう。

【エックスサーバーでのバックアップ】
サーバーパネルログイン ⇒ データベース ⇒ MySQL設定

mysql1

MySQLバックアップ ⇒ エクスポートの実行

mysql2

 

エックスサーバーのような専用のバックアップの仕組みがない場合は、MySQLのデータをphpMyAdminからバックアップするのが一般的です。

エックスサーバーもインポートはphpMyAdminから行う必要があります。
ここでは全テーブルをまるっとバックアップ・レストアする手順を解説します。

phpMyAdminでのバックアップ

phpMyAdminにログインして左ペインからバックアップしたいDBを選択し、エクスポートタブを選択します。

phpmyadmin1

「簡易」にチェックが入っているのを確認して「実行」ボタンを押してください。

phpmyadmin3

ローカルPCの保存場所を指定して保存します。「データベース名.sql」のファイルが保存されればエクスポートは終了です。

phpMyAdminでのレストア

インポート先のDBにデータが残っているとインポートできないため、まず既存データを削除します。

「構造タブ」を選んで下にスクロール ⇒ 「すべてにチェックする」にチェックを入れ「チェックしたものを」プルダウンで「空にする」を選択して「実行」ボタンを押してください。

注意:プルダウンで間違って「削除」を選択しないようにしてください!

phpmyadmin4

テーブルを空にしたらバックアップしておいたデータをレストアします。
「インポート」⇒ 参照ボタンからバックアップしておいたファイル(拡張子.sql)を指定して最下部にある「実行」を押すとインポートが開始されます。

phpmyadmin5

「インポートが正常に終了しました」が表示されればDBの復元は終了です。

※データベースのバックアップ・レストアは最初に必ずテストDBで試し、手順に不明な点や誤りがなくDBが復元されることを確認してから本番DBで行ってください。

【エックスサーバー以外のレンタルサーバー】
バックアップ方法が不明な場合は、レンタルサーバー会社のサイトヘルプかレンタルサーバー会社に問合わせてください。

WordPressテーマバックアップ

【エックスサーバー】
WordPressテーマも内部ソースのURLを変更する必要があります。事前にバックアップを取っておきましょう。Stingerの場合だと格納フォルダは

/public_html/wp-content/themes/stingerxxx ← (xxxはバージョンや日付)

となります。このフォルダ配下にある拡張子が.phpのファイルをFTP等でローカルバックアップすればいいのですが、ファイル選択が面倒なこととバックアップ漏れを考えるとstingerフォルダごとバックアップしたほうがいいでしょう。

【エックスサーバー以外のレンタルサーバー】
別のテーマを使っていてバックアップフォルダが不明な場合やローカルバックアップの方法が分からない場合は、レンタルサーバー会社のサイトヘルプかレンタルサーバー会社に問合わせてください。

.htaccessバックアップ

.htaccessファイルは必ずローカルバックアップを取ってください。

通常はWordPressがインストールされているフォルダ

/public_html/

配下に.htaccessファイルがあります。WordPressのインストールフォルダが不明な場合は、レンタルサーバー会社のサイトヘルプかレンタルサーバー会社に問合わせてください。

SSL証明書を取得しよう

SSLを実装するためには証明書の取得が必要なのですが、証明書には大きくわけて二つのタイプがあります。

共有SSL
レンタルサーバー会社側で取得した証明書で、文字通り他のユーザーと証明書を共有してSSLを実装する。
◇取得費用も更新費用も無料
◇ドメインが変わってしまう

独自SSL
自分で独自に取得した証明書で、自分の独自ドメインやサブドメインにそのままSSLを実装することができます。
◇取得費用および更新費用が必要
◇ドメインが変わることはない

結論から言うと、

独自SSL

にすることを強くおすすめします。主観ですが、いくら無料とはいえアクセスしたときにURLが変わってしまうと

サイト利用者の信頼を損ねる可能性がある

のが大きなデメリットです。利用者の信頼を得たいがためのSSL化なのにこれじゃ本末転倒、ですよね。

エックスサーバーの場合ですが、証明書の取得方法はサイトヘルプを参照してください。

独自SSLのお申し込み

証明書の取得申請が終わると承認メールが送られてきます。
承認メールをクリックすることでSSL発行元の審査が開始され、審査にパスすることで最終的にSSL証明書の導入が完了します。

審査には数日かかる可能性もある、とレンタルサーバーのサイトには記載されていますが、よっぽど怪しいサイトじゃない限り数時間で導入が完了します。

私の場合は3時間ほどでSSL証明書設定完了のお知らせメールが来ました。

【SSL証明書設定完了メール】

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【Xserver】SSL証明書設定完了のお知らせ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

会員ID : xxx
メールアドレス : xxx

平素は当サービスをご利用いただき誠にありがとうございます。
エックスサーバー カスタマーサポートでございます。
下記SSLの設定作業が完了しましたので、お知らせいたします。
────────────────────
■SSL設定情報

【SSLブランド】 : CoreSSL
【SSLプラン】  : SNI SSL(ネームベース)
【サーバーID】 : xxx
【コモンネーム】: xxx.com
【サイトURL】  : https://xxx.com/
【有効期限日】 : 2017-xx-xx
────────────────────

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▼SSL証明書のご利用について

本ご案内から最大30分程度でご利用可能となります。
https://xxx.com/
への接続をお試しいただき、正常にアクセスが行えることをご確認ください。

メール内に記載されている https://xxx.com/ へアクセスできれば晴れてサーバー側での証明書の導入が完了です。

他のレンタルサーバーにも必ずサイトヘルプがあると思うので、エックスサーバー以外の方はまずはそちらを確認しましょう。

内部リンクをプラグインで一気に修正しよう

内部リンクとは、あなたのサイト内に記述されている画像へのリンクURLや他サイトへの発リンクのことを指します。

httpsサイトではhttpのURLとの混在が許されておらず、サイト内に記載されているURLを全てhttpsにしないとブラウザでエラーとなってしまいます。

なのですが、URLをhttpsで記述する必要はなく、

//xxx.xxx.com

のようにhttpsの記述を省略することができます。
このURLのことを相対パス(相対URL)と言います。

もちろん https:// と絶対パスで記述しても問題ないのですが、Googleはhttpsサイトについて相対パスでの記述を推奨しています。

HTTPSでサイトを保護

相対パスでURLを記述しておけば、仮にURLをhttpに戻す場合でも内部URLを変更する必要はありません。

お気づきの方もいると思いますが、アドセンスコードは相対URLで記述されています。

特に理由のない限り、内部URLは相対パスで記述しましょう。

Velvet Blues Update URLs ーURL一括変換プラグインー

手動で内部URLを書き換えるのは現実的ではないため、プラグインを使って一括変換します。最初はネット検索でヒットした Search Regex で試したのですが、なぜかURLがうまく変換されずブラウザでエラーが出まくりました。

そこで探し当てたのが Velvet Blues Update URLs です。
私のようにSearch Regexでうまくいかなかった方はこちらのプラグインも試してみてください。

【Velvet Blues Update URLs】
1.Velvet Blues Update URLsでプラグイン検索して導入、有効化します。
2.「ツール」⇒「Update URLs」を選択してください。
※プラグイン名のメニューではないため管理画面を探すのに少しとまどいました。
3.図のように設定して最後にUpdate URLsボタンを押してください。チェックボックスのチェック漏れにはご注意を。

setting

修正されたURL総数が表示されます。なお、URLを元に戻す場合はURLの記述を逆にして再度実行すればOKです。

テーマとプラグインの内部URLを一気に修正しよう

私が利用しているテーマはStingerですが、URL変換プラグインではStinger内部に記述されているURLの修正はできません。

加えてWordPressプラグインも修正できないため、プラグインが原因でエラーが出る場合があります。

プラグインの場合は当然ながら修正してしまうとオリジナルではなくなるため、プラグインバージョンアップ時に再度修正する必要があったり、有償プラグインの場合はサポート対象外となる可能性があります。

エラーが出るプラグインは外してしまうのが一番確実なのですが、どうしても必要なプラグインの場合は自己責任となりますが、プラグインのソースを修正することも可能です。

ツールを使ってテーマとプラグインの内部URLを一括修正

ツールといっても私が使ったのは

窓の杜:NotePad++

という高機能テキストエディタです。StingerとプラグインのソースをFTP等でローカルダウンロードし、NotePad++で全ソースファイルの

一括検索 ⇒ 一括修正 ⇒ 一括保存 ⇒ サーバーへ上書きアップロード

という流れになります。

【Stingerの修正】
1.Stingerの導入フォルダから拡張子phpのファイルを全てFTP等でローカルPCに保存
2.NotePad++を起動してローカルPCに保存したphp全ファイルをドラッグ&ドロップでNotePad++へ
3.NotePad++のメニュー「検索(S)」からプルダウンでさらに「検索(F)」をクリック
4.検索文字列に//を入力し「全てのドキュメントを検索」ボタンを押します。
Stinger5の最新バージョンだと7つのファイルで計16箇所のhttp記述があることが分かります。

stingerURL1

5.「検索」タブの隣にある「置換」タブを選択し、検索文字列に「//」置換文字列に「//」を入力し、「すべてのドキュメントを置換」ボタンを押します。

stingerURL2

6.16箇所の「//」記述が「//」へ変換されます。

stingerURL3

7.「ファイル(F)」⇒「すべて上書き保存(E)」を選択すればURL修正は完了です。

stingerURL4

8.拡張子phpファイルを全てサーバー側にFTP等で上書きアップロードしてください。

【プラグインや他のテーマ】
修正方法はStingerと全く同じです。拡張子phpのファイルをサーバー側のフォルダから全てローカルPCにダウンロードし、NotePad++で一括修正後、サーバー側へ上書きアップロードします。
拡張子phpファイルの選択漏れの可能性もあるので、プラグインやテーマをフォルダごとダウンロードして修正、フォルダごとアップロードするのもありかと思います。

WordPressの設定変更は簡単

「設定」⇒「一般設定」でURLをhttpsに変更して「変更を保存」するだけです。
WordPressの管理画面ログインがhttpsで表示されます。

wordpressURL

.htaccessの修正は超慎重に

.htaccessファイルは、Webサイトへのアクセス制限をかけたりリダイレクト(自動転送)をさせたり等、Webサイトの挙動を制御することができるのですが、修正に失敗したりするとWordPress管理コンソールにログインできなくなる可能性もあります。

書き方にも様々な決まりごとがあり、決まりごとにしたがって作成・設置しないとWebサーバーが予期せぬ動きをすることがあるので十分に注意しましょう。

.htaccessファイルの決まりごと
◇ファイル名は .htaccess でtxtなどの拡張子をつけない
◇#で始めるとコメント扱い ※コメント行以外でのコメント混在はおすすめしません
◇文字コードはUTF-8(BOM無し)、ファイルの最終行には空行を入れましょう
◇httpd.confで許可されている命令のみ記述することができます
◇サブドメインなどの階層構造の場合はより深い階層の設定が有効になります

httpからhttpsへのリダイレクトを.htaccessで設定する

.htaccessファイルはテキストエディタで編集するのですが、Windows標準のメモ帳やワードパッドでは上記文字コードなどの制御ができず、.htaccessがうまく機能しない可能性があります。
私はNotePad++という高機能エディタを使用していますが、あなたの使っているテキストエディタが UTF-8(BOM無し) に対応しているか確認しておきましょう、

窓の杜:NotePad++

【2016年3月28日修正】
# BEGIN WordPressと# END WordPressの間にコードを書くと、WordPressが自動的にパーマリンク設定などをしたときに.htaccessを上書きして記述したコードがなくなってしまいます。追記したコードが元に戻っていたのを発見してうっかりに気づきました。大変失礼しました。
なので、下記コードは# BEGIN WordPressと# END WordPressに囲まれている部分以外に記述してください。

サブドメイン設定をしていないサイトでhttpからhttpsへリダイレクトさせるには、メインフォルダ(WordPress導入フォルダ)の.htaccessに以下2行のコードを# BEGIN WordPressから# END WordPressの間以外の場所に追加すればOKです。

ソースコピーは右下のViewかrawをクリックしてから行ってください。

サブドメインをhttps化する場合のURL遷移と.htaccess設定は以下です。

【サブドメインをhttps化した場合の動作】
◇httpsへの301リダイレクト
//yourdomain/
↓ 301リダイレクト
https://yourdomain/

◇httpsおよびサブフォルダの301リダイレクト
//yourdomain/subdomain/
↓ 301リダイレクト
https://yourdomain/subdomain/
↓ 301リダイレクト
https://subdomain.yourdomain/

【メインサイト:yourdomain】

【サブドメイン:subdomain.yourdomain】

繰り返しになりますが、.htaccessの修正は

.htaccessファイルのバックアップ ⇒ 修正 ⇒ 動作確認 ⇒ 動作確認で問題なければ修正した.htaccessファイルもバックアップ

の手順ですすめることを強くおすすめします。

なお、.htaccessの詳細についてはこちらのサイトも是非ご覧ください。

.htaccessの書き方

動作確認は全ページエラーチェックとURLのリダイレクト

動作確認項目
◇従来のhttp://アドレスでアクセスしてhttps://にリダイレクトされるか
◇ページにアクセスしたときにURLバーに緑の鍵マークが表示されるか
◇全ページはもちろんアーカイブやカテゴリからもアクセスして緑の鍵マークの表示を確認

まずは従来のhttp://アドレスでアクセスし、https://にリダイレクトされてサイトが表示されるか確認してください。例えばChromeの場合、内部URL修正がうまくいっているとURLの先頭に緑の鍵マークが表示されます。

https
URLがhttpsなのに緑の鍵マークが表示されない場合は内部URLの修正が不完全です。

httpserr2

ブラウザの種類によってエラー内容の表示のさせ方は異なりますが、エラー内容を確認してURLを修正しましょう。

【Chrome】
右上の横三本の設定ボタンから「その他のツール(L)」⇒「デベロッパーツール(D)」を選択すると、右に別途ウィンドウが表示されます。セキュリティというタブを選択するとエラー内容が表示されます。

下の赤い文字列の上のURLがhttpのままなのが分かると思います。

sslerr2

この場合はファビコンURLの修正漏れですね。
エラーは程度によって赤だったり黄色だったりしますが、おおむねURLの修正漏れだと思います。

各ページにアクセスし、このようなエラーが出ていないかチェックしましょう。

サイト高速化にはいろんな手法があるよ

全SSL化が終わったあとにサイトレスポンスを測ってみました。

PageSpeed Insights

【SSL化後 PC:78点】

beforePC

【SSL化後 モバイル:54点】

beformobile

なんてこったーーいヽ(;▽;)ノ

PCで10点ほど、モバイルにいたっては20点近く点数が落ちて赤くなっています。
なんとかしなければ!というところなんですが、巷で良く言われている
◇画像圧縮
◇キャッシュの利用
◇ソース記述の最適化 などなど
は既に適用済みなんですね。ちなみにエックスサーバーはGoogleが開発したmod_pagespeedというサーバー高速化のための機能をサーバー設定で使うこともできます。

とはいえ何とかせねば、ということで、キャッシュ系や画像圧縮系などのプラグインを追加で入れてみてmod_pagespeedと比較してみたり、プラグインの設定をいじりまくったり、JETPACKを導入してみたりといろいろやってみましたが、1~2点ほどの誤差といえるほどしかサイトレスポンスが改善しません。

途方に暮れていたとき、ふと、STINGERの子テーマを以前利用していたものに戻してみようと思いたちました。

【Stinger-minimum PC:82点】

afterPC

【Stinger-minimum モバイル:66点】

aftermobile

なんということでしょう♦♫♦・*:..。♦♫♦*゚¨゚゚・*:..。♦(ビフォーアフター風に)
子テーマを変えるだけでモバイルにいたっては12点ものアップです。
これには心底びっくりしました。

もちろん画像の多さやSNSプラグインの利用など、サイト構成によってここまでの改善は見られない場合も多々あると思いますが、テンプレートによってここまでの違いが出ることもあるんですね。

※2016年4月28日:テンプレートをAffinger3に変更。サイトスピードは若干の改善♪

私のカスタマイズがアドセンス追加のため、全SSL化によってより顕著にレスポンスへの影響が出たのでしょうか。
両テーマともカスタマイズ内容は全く同じで、アドセンス広告をPC/モバイル問わずどのページにも目いっぱい貼る、というものです。

STINGER5カスタマイズ アドセンス最大数貼ってみた!iPhone6等ワイド画面対応だよ。

話逸れましたが、高速化のためにはテンプレートを入れ替えていろいろとレスポンスを試して見るのもありかなと思いました。

テーマレスポンスに関しては

ブランクテーマって何?

というものもありますので、是非こちらもご覧になってください。

うまくいったらSSL環境もバックアップしておこう

動作確認を全て終えたら、念のためSSL環境もバックアップしておきましょう。バックアップの方法は
バックアップは必ず取りましょう
と同じです。こうすることで、httpとhttps両方の環境をバックアップできます。

ウェブマスターツール(サーチコンソール)を再登録してサイトマップを送信すれば一安心

URLの違いだけとはいえ、httpとhttpsは別サイトとして認識されます。
httpsでの環境が問題ないことを確認できたら、サーチコンソール上でhttpでの登録を削除してhttpsでのサイト再登録、XMLサイトマップの再送信を行いましょう。
インデックスされるまでには時間がかかりますが、徐々に登録URLが増えていくはずです。

全SSL化のポイント

おさえておきたいポイント
1.SNSのカウントがリセットされる
2.レスポンスが落ちる
3.外部リンクは完全に修正できるの?

SNSカウントの引継ぎ方法

プラグイン「SNS Count Cache」を使います。
プラグイン導入の詳細は割愛しますが、プラグイン新規追加→SNS Count Cacheで検索→導入→有効化してください。有効化するとダッシュボードの左サイドバーにSNS Count Casheが追加されます。

SNS Count Cashe ⇒ 設定を選択

SNS

HTTPからHTTPSへのスキーム移行モードを[有効] ⇒ 設定の更新

SNS2

以上です。すぐには反映されませんが、数日経つとカウント数が復活しています。
気長に待ってください♪

レスポンスを意識したテーマを試してみよう

サイト高速化にはいろんな手法があるよ
で高速化のための手法を紹介しましたが、SSL化と同時に思い切ってレスポンスを意識したテーマに変更して試すのもありかもしれません。
ここでは

ブランクWordPressテーマ

をご紹介します。

ブランクテーマって何?

最低限のデザインでカスタマイズが前提のソースデータ容量が軽いテーマです。Stingerのようなテーマカスタマイザーはもちろんなく、CSSやPHPをいじれるスキルが前提となります。

ブランクテーマのメリット
◇ベースのテーマがとにかく軽い=レスポンスが速い
◇最低限のデザインとはいえブログで使うのには十分なテーマも
◇標準でレスポンシブテーマあり
◇CSSやPHPスキルを習得したい人にはおすすめ

ブランクテーマのデメリット
◇テーマによってはカスタマイズ情報が乏しくカスタマイズに時間がかかる
◇自分にとって必要な機能を手早く実装したい人には不向き

なんだかんだとCSSやphpのプログラミングスキルが必要になるために導入のハードルは高いのですが、近い将来JavaScriptが使えないAMPを実装する可能性を考えると個人的にはブランクテーマでスキルアップしておくのもありかなと思います。

おすすめブランクテーマ

素晴らしいサイトがあるのでリンク先を参照ください。
HTML5ベースのブランクWordPress無料テーマ9選

外部リンクはどう対処すればいい?

外部リンクとは、あなたのサイトに外部から貼られているリンクのことを指します。
あなたのサイトURLが http から https に変わるため、貼られているリンクも設定変更しなきゃ、と思われるかもしれませんが、当然ながらあなたのサイトではないので自分で対処することはできません。
それじゃあなたのサイトをhttpsに変更したら外部からhttpで貼られているリンクは大丈夫なの?ということですが、.htaccessの修正は超慎重に で設定したように

httpsへの301リダイレクトが実装できている

ならば、

外部リンクを修正する必要はない

のです。具体的にはリンクが数百本も貼られていたとして、全サイトにリンクの貼りなおしをお願いする手間をかける必要はない、ということですね。

これに関しては素晴らしいサイトがあります。私がとやかく言うレベルではないので詳細はリンク先を参照ください。
HTTPS移行後に外部リンクのURLを https:// に変更する必要はない

全SSL化で苦労したこと

実はHTTPS化によってエラーを出しているプラグインを特定するのにものすごく時間がかかってしまい、その結果としてテーマとプラグインを一気に修正する手順を書くことができたのです。

もう一つは.htaccessの修正。サブディレクトリのサイトをHTTPS化したためにルートの.htaccessの修正と、加えて配下にあるサブディレクトリに.htaccessを設置したのですが、書き方がまずかったのかWordPressにログインできなくなってしまいました。

本当に冷や汗ものです。。

ただ試行錯誤を経てこうして記事を公開できるようになったことは良かったと思っています。

全SSL化の落とし穴

SSLはWebサイトとクライアント間の通信を暗号化することによって第3者からの通信内容の傍受を防ぐことにより通信セキュリティの強度を上げるのですが、実はSSL通信は諸刃の剣になりかねないのです。
SSLのWebサイトが改ざんされたりマルウェアなどに感染すると、悪意を持ったコードも暗号化され、従来のIPS/IDSやWAFなどのセキュリティ対策をすり抜けてしまう可能性があります。

ASCII×TECH:数年後、攻撃トラフィックの半分が暗号化!対抗手段はSSL可視化専用機

Webサーバーを自前で運用している企業であれば通信の復号化チェックができるセキュリティ製品を導入することで対応できますが、私のような個人だと利用しているレンタルサーバー側の対策に頼らざるをえません。

レンタルサーバーによって対策の程度はまちまちですが、まずは自分のサイトが改ざんされたり感染しないように対策を取っておくことをおすすめします。

WordPressサイトを不正アクセスから守る基本ポイント
◇WordPress本体やテーマやプラグインや常に最新の状態に保つことを心がける
◇出どころが不明だったり更新が古いプラグインの利用は避ける
◇ログインパスワードは強度の高いものに
◇ファイルをダウンロードさせる場合はローカルで事前にファイルチェックを
◇サーバーへのアクセスはFTPは避けてFTPSやSSH(SFTP)などの暗号化通信アクセスが望ましい
※ただしレンタルサーバーによっては対応していません
◇WordPressセキュリティプラグインを利用する

この他にもサイト全体にBASIC認証をかけたり管理画面からテーマ編集を出来ないように設定することができますが、wp-config.phpファイルを編集したりします。

おすすめセキュリティプラグイン ーログインURLを変更ー

【Login rebuilder】

login-setting

新しいログインファイルの欄に 任意のファイル名.php を設定して保存してください。

次回からのログインURLが

//ドメイン/任意のファイル名.php

になります。WordPressのログインファイルはwp-login.phpで、単純にサーバーにあるwp-login.phpのファイル名を変更するだけでは動作しないのですが、このプラグインは設定したファイル名でWordPressログインページを表示するように変更してくれます。

ちなみにこのプラグインのデフォルト設定で通常のログインページ(wp-login.php)にアクセスすると、403の権限エラーになります。

403

私はログインページファイル名を20桁のランダムの英数字にしてます。

ワンタイムパスワードや2段階認証などの対策もありますが、これだと設定が大変だったりログイン時の手間が増えるので、このログインURLを変更する対策はおすすめです。

なお、ログインファイル名が分からなくなった場合はサーバー上のWordPress導入フォルダにログインファイルが存在しているので、そこで確認することができます。

Webサイトの今後 -全SSL化と高速化-

現時点では全SSL化のデメリットも多いのですが、数年ほど後?くらいの近い将来は全SSL化+高速化の流れが加速することは間違いありません。なぜそんなことが言えるのか。根拠となるインターネット環境の動向を整理しました。

HTTP/2の実装

HTTP/2は従来のHTTP1.1の後継仕様で、安全性と高速化の両立を目指した仕様となっています。

HTTP2(SPDY)と表記することもありますが、SPDYはGoogleが生み出したプロトコルで、HTTP/2はSPDYをベースにしています。

標準化団体IETF(Internet Engineering Task Force)によって仕様策定が進められ、2015年5月に正式にRFC化されたことによって今後はHTTP/2に統一されます。

GoogleはChromeでのSPDYサポートを2016年までに終了

つまりはWebサイト高速化の流れを見越して仕様を整備しておこうということで、主要ブラウザは全て対応済みです。

SPDY protocol対応状況

あとはサーバー側でHTTP/2に対応させればいいのですが、今後はレンタルサーバー側でも徐々に対応が進むと思われます。

ちなみにGoogleやTwitterFaceBookなどの主要SNSベンダーは既に対応済みです。

アップル社の取り組み -ATS(App Transport Security)-

iOS9では「ATS(App Transport Security)」が実装され、ATSを有効にするとhttpでの接続ができません。

何らかの理由でATSが有効になるとhttpへのアクセスが全てエラーリターンされるため、その場合はATSを完全に無効にするか、特定のドメインに対してATSを無効にすればhttpでのアクセスが可能になります。

例えばですが、そう遠くない将来にATSを標準で有効にしたiOSのバージョンがリリースされることも考えられなくはありません。

そうなると利用者側にATS設定の無効をお願いするのは現実的ではなく、Webサイト側を全SSL化して公開することが必要になります。

Google社の取り組み -AMP(Accelerated Mobile Pages)

モバイル利用の急増やモバイルでのネット環境の不安定さを踏まえ、モバイルからのWebサイトアクセスの速度向上を目的としてGoogle社とTwitter社が共同で策定したプロジェクトです。

AMP HTMLというフレームワークがオープンソースとして公開されていて、Washington PostなどのパブリッシャーやPinterest、LinkedInなどのIT企業30社ほどがパートナーとして参加しています。

AMP仕様に沿ってWebサイトを作成するとGoogle/Twitter側にWebサイトのページがキャッシュされ、クライアントからのリクエストをキャッシュから返すことによって超高速レスポンスを実現します。

デモサイトを見ましたが、鬼の速さです。ローカルより速い感じで瞬時にページが返ってきます。

2016年2月1日現在でAMP対応のためのWordPressプラグインもリリースされていますが、バージョンが0.2のベータ版の扱いで、プラグインにはページとアーカイブはサポートされないことが明記されています。

WebサイトをAMPに対応させるにはJavaScriptを排除したり、HTMLをAMP HTMLに対応させたり(専用タグがあります)、パーマリンクに/amp/もしくは?amp=1を追加したりする必要があります。

英語ですが、AMPプラグインの開発者向けサイトもありますので興味のある方はご覧ください。

WordPress plugin for adding AMP support

AMPの利点として、Google/Twitter側のキャッシュでリクエストを返すことによって自分のサイトがあるWebサーバーの負荷が下がりますが、実ウェブページにはアクセスされないため、例えばブログ運営している場合に実際のアクセス数が反映されないなど、まだ仕様が公開されて日が浅いためにどのようなサイトに適用するかは考慮する必要があるでしょう。

個人的にはアドセンス広告やアフィリエイトのCookieってどうなるんじゃ?って感じです。

Googleも

実装にはまだ早くて2016年2月くらいから本腰入れるかなっと

なんてインタビューに答えていた記憶がありますが、すみません、ソースを見つけることができませんでした。。。
いずれにせよ、今後もGoogle/Twitter社がAMPの普及に力を入れるのは間違いないでしょう。

どうしてSSL化したほうがいいの?-自分的まとめ-

Webサイトをインターネットに公開するからにはアクセスしてもらわないと全く意味がないのですが、不特定多数の人にアクセスしてもらうための要素には大きく下記があると思っています。

◇セキュリティやコンテンツが信頼できる
◇レスポンスが速い
◇コンテンツにオリジナリティがあって有用な情報が掲載されている
◇コンテンツが見やすくかつ分かりやすく整理されている
◇操作性にすぐれている
◇視認性にすぐれている

上記の下3つは広義でサイトデザインによるものと思いますから、平たく言うと

◇安全・安心
◇速い
◇見やすい
◇使いやすい

となります。じゃーこの中で優先順位を決めるとすると、

速い>>>見やすい>使いやすい
-----安全・安心-----

ではないでしょうか。具体的に言うと、

◇安心・安全 ⇒ SSLやサイトセキュリティ対策が施されていて、コンテンツに嘘・偽りや限度を超えた攻撃的な表現がない。サイト運営者がはっきりしていて連絡先が明記されている。

◇速い ⇒ SSLなどのセキュアな環境でも、そしてかつ様々なデバイスでアクセスしてもストレスを感じないレスポンス。

◇見やすい ⇒ 文字の大きさや色使いが見やすく設計され、意図しないリンクや騙しリンク、紛らわしい広告が埋め込まれていない

◇使いやすい ⇒ ボタンなどの大きさや配置が適切で、意図しないサイトが表示されたり意図しないサイトに飛ばされたりしない。

上記のように、Webサイトに求められる要素は全てWebサイトの安全・安心が大前提で成り立つと考えています。
どんなに素晴らしいコンテンツでも安全・安心が担保されないと信頼できるサイトとは言えないかと。

そしてどんなに素晴らしいコンテンツがどんなに素敵なデザインのサイトに掲載されていたとしても、アクセスしてレスポンスが返ってくるのに10秒近くかかるようでは二度とアクセスする気は起きません。

インターネットが普及する以前のホストコンピュータ全盛の時代からシステム設計の最重要指標として、

3秒ルール

というのがあって、実行キーを押してから3秒以内に画面レスポンスが返ってこないとそのシステムは使い物にならないとされたものです。

コンピュータシステムにおいては3秒が人間が待てる時間の限界のようで、なるほどな、と納得したものです。

閑話休題

なので、インターネットインフラが整備されてきた今の時代に全SSL化と高速化が求められるのは必然の流れだと思えるのです。

ブランディングが全て-自分的まとめ-

マネタイズを意識してサイト運営をする場合、サイトの信頼こそが一番重要で、訪問者の信頼なくして継続的なアクセスは見込めないと考えています。言い換えると、

良さそうな製品・サービスだから購入する、から、

信頼できるあなたが紹介する製品・サービスだから購入する

を目指すべきでしょう。

’信頼できるあなた’がブランドにあたり、それは安心・安全なくしては成り立ちません。
世の中の100年と続くブランドは全て安心・安全=信頼の上に成り立っています。

例えばキュレーションサイトや炎上系マーケティングは一時の耳目=アクセスを集められるかもしれませんが、信頼を得られるわけではありません。

常に閉店セールをやっていたり、サクラを集めてたたき売りをやっても、そのうち

’またやってるか’

なんて見向きもされなくなるのと同じでしょう。

ただだからと言って、炎上系マーケティングを否定するわけでもありません。

素晴らしいものを作り続けていればいつかお客様は付いてくれるんだ、なんて商売をする場所も考えず広告費もかけず、そのうち体力が尽きて潰れてしまう、なんてのはよくある話です。

結局は必ず成功する方法なんてあるわけもなく、試行錯誤しながら頑張り続けるしかないのですが、向かう方向は

信頼できるブランド作り

しかないと思っています。そして信頼できるサイトを支える要素の一つがSSL化なのです。

私は理由があって途中からSSL化したために苦労しましたが、最初からSSL化に取り組めるのであればそれに越したことはありません。

この記事が皆様の役に立てることを切に願っています。

スポンサーリンク

-ITつれづれなるままに
-, , , , , , , , , ,

このボタンをクリックすると記事タイトルとURLがコピーされます。
メールやメモ帳などに貼り付けてご利用ください。
TOP