ssl化する際にhttpsが表示されない原因をまとめておきます。簡単にいうと保護された通信にならないのはhttpのリンクが残っている、この1点につきると思います。実体験に基づき、問題になった箇所を網羅しました。
目次
- 1 https化(ssl化)で保護された通信にならない人も、Wordpressの管理画面は保護された通信になる
- 2 保護された通信にするための基本作業
- 3 保護された通信が出ない原因となるメニューのカスタムリンク
- 4 Search Regexでhttpsに変更できないウィジェット
- 5 httpからhttpsに書き換える必要があるphpファイル
- 6 保護された通信が出ない原因となるロゴの設定
- 7 保護された通信が表示されない原因となるプラグイン
- 8 保護された通信が表示されない原因となる1ピクセルのインプレッション画像
- 9 外部サイトが「この接続ではプライバシーが保護されません」
- 10 httpが残っていないかチェックする方法
- 11 httpsの変更はヒートマップツールにも影響を及ぼす
- 12 ssl化に伴いgoogle search consoleが機能せず、google analyticsの検索クエリがゼロになる
- 13 ssl化に伴いgoogle analyticsの設定変更
- 14 facebookのいいねがゼロになる
https化(ssl化)で保護された通信にならない人も、Wordpressの管理画面は保護された通信になる
まずWordPressの管理画面が保護された通信になっているのかを確認しましょう。そこだけはすぐなります。管理画面が保護された通信になっていないと他に原因があるかもしれません。
テクニカルな調査をする際、ブラウザはchrome(クローム)とfirefoxの両方を使っている人が多いです。firefoxなら原因なる画像などがわかります。
保護された通信にするための基本作業
念のため基本作業も簡単に書いておきます。
バックアップを取ります。ついでにバックアップの仕組みを見直してもいいかもしれません。個人的にはUpdraftPlusを使っています。
- スターサーバーやエックスサーバーなどレンタルしているレンタルサーバーの管理画面でsslの設定をします(次の見出し)
- 設定 > 一般 「WordPress アドレス (URL)」と「サイトアドレス (URL)」でアドレスをhttpからhttpsにします。
- Search Regexでhttpからhttpsに内部リンクを置換します。
- .htaccessにリダイレクト用のコードを追記します。スターサーバーはpublic_htmlの直下にあります。他のレンタルサーバーも似た感じです。
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>このコードは元からあるコードの上に追記してください。下に追記してもリダイレクトされません。
BOMなしで保存します。普通に保存すればBOMなしになります。
この作業をするとhttpのアドレスにアクセスしてもhttpsに転送するようになります。書き換えた後、念のため確認してみましょう。
ただ、リダイレクトなどはせずとも保護する通信にはなります。保護された通信にするにはhttpのリンクさえなくなればOKです。
スターサーバー（旧ファイアバード、ミニバード）のsslの設定
ファイアバード、ミニバード、スターサーバーのsslの設定は下記のとおりです。
スターサーバー管理ツール > サーバー管理ツール > ドメインの「SSL設定」> 対象ドメインを「選択」> 「無料独自SSL追加」のタブ > 独自 SSL 設定を追加する（確定）
設定追加後、下記のメッセージが表示されます。
※処理には数分程度かかる場合があります。
※独自SSLは追加後、サーバーに設定が反映されるまで最大1時間程度かかります。
「独自 SSL 設定を追加する（確定）」をする際に、「CSR情報(SSL証明書申請情報)を入力する」のオプションがありますが、このチェックは入れなくてokのようです。企業が別の有料SSLプランを利用する際に必要なもののようです。
エックスサーバーのhtaccessがない。transmitでhtaccessを表示する方法
エックスサーバーの管理画面からもhtaccessを編集できますが、直接いじるのではなくバックアップが取りたかったのでFTPソフトを使うことにしました。
しかし、ftpソフトではhtaccessファイルがありません。すぐに隠しファイルになっているだけとわかったため表示しました。
transmitというftpソフトを使っています。
表示 > 不可視項目の表示
で、htaccessファイルが表示されます。
表示するとメニューが反転するため非表示にもできます。
表示 > 不可視項目を隠す
さくらインターネット
サブドメインの場合は少しわかりにくいです。
ドメイン/SSL > ドメイン/SSL > 設定(独自ドメインはSSLという項目がある) > [共有SSLを利用する]にチェック > 保存
保護された通信が出ない原因となるメニューのカスタムリンク
メニューのカスタムリンクはhttpからhttpsの書き換えが必要です。数が多いとすごく面倒です。。
外観 > メニュー
Search Regexでhttpsに変更できないウィジェット
Search Regexの置換範囲はあくまでコンテンツであり、ウィジェットのアドレスまで置換してくれません。
テキストウィジェットにurlが入っていないか確認しましょう。このような手動リンクを作っているとダメですね。
httpからhttpsに書き換える必要があるphpファイル
functions.php、header.phpやfooter.phpやsingle.phpなどのファイルはすべてチェックが必要です。子テーマを利用している場合、直書きも少なくないでしょう。
こちらの方法もfunction.phpにアドセンス以外の画像を設定している場合は修正が必要です。
保護された通信が出ない原因となるロゴの設定
有料テーマなどでロゴを指定するものがあります。
httpのアドレスになっていると全ページ保護された通信になりません。全ページ表示されているので。。
ssl化した際に画像は生成されているため、httpをhttpsにするだけでokです。
保護された通信が表示されない原因となるプラグイン
Simple Local Avatars
Simple Local Avatarsは原因になっていました。このプラグインに限らずプロフィール画像や著者情報を記事下にのっけている人は注意してください。
解決方法は画像をもう1回設定しなおすことです。
Recent Comments Widget Plusなどアバター画像でコメントを表示するプラグインも間接的に影響があります。元のアバター画像を設定しなおすと全部なおります。
WP Responsive Menu
WP Responsive Menuも原因になりました。スマホのメニューですが、PCも非表示時もソース上にあるためです。解決方法はロゴの画像をhttpsにします。
このプラグインに限らずスマホの上部固定のプラグインを使っている人は注意してください。
Dynamic To Top
トップに戻るプラグインですが、画像が使われているようで、そのアドレスを書き換えなければなりません。直接コードをいじらないとダメなようです。
個人的にはこの機会に別プラグインを採用しました。
このようにssl化に対応していないプラグインはたくさんありそうですね。
Link Manager
Link Managerのurlも書き換える必要があります。
その他プラグイン
urlが入りそうなプラグインはすべてチェックしてください。
保護された通信が表示されない原因となる1ピクセルのインプレッション画像
アフィリエイトリンクで1ピクセルのインプレッション画像がhttpsではなくhttpになっている場合があります。最近はほとんどのaspが対応しているので、リンクの張り替えが必要です。aタグもhttpsになっていないともちろんダメですがインプレッション画像がhttpsになっていない場合が多いです。
ひたすら面倒です。。seo的に順位がさがるなどの悪い効果がなければ放置してもいいかもしれません。Google的にはhttpかhttpsかが評価のポイントであり、アドレスの混在コンテンツエラーは関係ないはず。
外部サイトが「この接続ではプライバシーが保護されません」
リンク先が「この接続ではプライバシーが保護されません」になると鍵マークになりませんね。そのリンクは外してあげる必要があります。この作業は必須じゃないと書かれているサイトもあるため、気になるなら修正しましょう、ぐらいですかね。
外部リンクはSearch Regexで内部リンクを置換後、http://で検索するとhttpの外部リンクのみ抽出できます。
httpが残っていないかチェックする方法
firefoxでチェックする方法もありますが、ソースを表示して直接検索してもOKです。
FireFoxのチェック方法は次のとおりです。
urlの左隣の警告のアイコン > >マーク > ウィンドウ下の「詳細を表示」 > 「メディア」のタブ
Googleさんによると2017年10月から「Not secure（保護されていません）」を表示されるみたいですね。
httpsの変更はヒートマップツールにも影響を及ぼす
少ししたのち、気づいたのですが、ヒートマップツールがurlを指定して使うものの場合、ヒートマップのデータが取れなくなる可能性があります。というか実際にそうなりました。。
httpのアドレスはhttpsに全部修正しなければなりません。ヒートマップツールによっては自動対応しているものもありそうですけどね。この機会に乗り換えを検討する人は、ヒートマップツールはこちらにまとめたのでよかったらみてください。
ssl化に伴いgoogle search consoleが機能せず、google analyticsの検索クエリがゼロになる
google search consoleのキーワードが取得できない状態になり、google analyticsの検索クエリが移行に伴いゼロになります。httpのアドレスが指定してあるからです。httpsのアドレスを追加してあげます。移行期間があるため、httpのアドレスもすぐ消さない方がいいみたいです。
プロパティを追加 > urlを入れる > 追加 > 確認
新しいサーチコンソールの場合、
画面左上の▼ > urlを入れる > 続行 >
所有権を自動確認しました
確認状態を維持するために、サイトのホームページからメタタグを削除しないでください。 確認状態を維持するために、設定 > 所有権の確認 で複数の確認方法を追加することをおすすめします。
と表示されたら完了。
トラッキングコードは以前埋め込んだなら、再度埋め込む必要はありません。サイトマップの送信は必ずしも必要ありませんけど気になるならした方がよいでしょう。
google analyticsとgoogle search consoleの連携については、詳しくはこちらです。
「Search Consoleを調整」もhttpのアドレスではなくhttpsのアドレスを指定します。google analyticsとgoogle search console の記事をみてください。この作業をしないとgoogle search consoleでキーワードが表示されても、google analyticsの検索クエリ側でキーワードが表示されません。ゼロのままになります。
SSL化後、「Search Consoleを調整」を再び行う場合は削除して追加する
なお、それまで蓄積したhttpの検索クエリは見えなくなります。もしもどうしても見たいときはgoogle search consoleにログインします。そのため、google search consoleのデータは残しておいてもいいかもしれません。
ssl化に伴いgoogle analyticsの設定変更
こちらはとくに設定を変更しなくてもトラフィックなどに影響はなくデータは取れるようです。さすがにそこはGoogleさんも問題ないようにしているのでしょう。なので、後日やってもOKです。
左下の歯車アイコン(以前はアナリティクス設定だったけど変わった) > プロパティ設定 > デフォルトのURL httpからhttpsに変更
その下のデフォルトビュー > すべてのウェブサイトのデータを選択。選択されていないと保存できません。
保存で終了です。
もうひとつあります。
左下の歯車アイコン > ビュー設定 > ウェブサイトのURL httpからhttpsに変更
facebookのいいねがゼロになる
facebookのいいねがゼロになります。。sns count cacheというプラグインや他の方法で回避します。
下記の方法で無事いいねを取り戻せました。
簡単ではありますが自分が書き換えたところを覚書がてらまとめてみました。いろいろとカスタマイズしている人は結構、重たい作業ですね。。参考になれば幸いです。
コメント