アドレスバーを見ると分かる通り、このサイトも時代の流れを受けて（実際はGoogleさんのご意向を受けて）
サイトのSSL(TLS)化対応を行いました。(httpからhttpsになった！)
その際の要点や、ハマりそうになった際の注意点を備忘録的に残しておきます。（多分自分がこの情報を使うことはもうない気がするので割りと書き殴りかも・・すみません）
実施環境としては、VPS、CentOS 6、Wordpress、Apacheです。
SSL対応手順：Let’s Encryptで認証する場合
WordPressでVPSなどで自前でサーバーソフト立ててる人の主流はLet’s Encryptだと思います。
当サイトも同じですので、基本の設定手順は他のサイトに山ほど書いてあるので要点だけ載せます。
- certbot-autoコマンドのダウンロードと権限変更
- certbot-autoコマンドを実行 対話式なので必要項目答えればOK。EMail入力は必須。Read TermsはAgree。EFF共有はNo。
これだけです。ちょーー簡単でした。
ご親切にhttpからのリダイレクト設定もオプションでしてくれますし、設定ファイルも明示されるので、設定ファイルを見れば具体的設定内容もわかります。
設定ファイルは /etc/httpd/conf.d/vhost-le-ssl.conf にSSl対応のVirtualHost設定があります。また既存の vhost.conf にSSL側へのリダイレクト設定が追記されました。
リダイレクト対応が入っているので、これだけで、ほぼすべてのページが問題なく表示されました。個別記事へのリンク等も特に問題なく機能します。
参考サイト
certbot公式:CentOS 6 Apache版
Let’s Encrypt の使い方
ネコでもわかる！さくらのVPS講座 ～第六回「無料SSL証明書 Let’s Encryptを導入しよう」
SSL化後のアドレス変更に対して必要な対応
ここまでで、SSL化対応そのものは終わっていますが、問題はここから。サイトアドレスが
http://hogehoge.com → https://hogehoge.com
に変わったことへの対応です。順に見ていきます。
WordPressの設定を変更
WordPressのダッシュボード → 設定メニュー
にサイトアドレスの設定があるので変更します。
多分Wordpress内のテンプレートタグなどの関数群などで参照されるんだと思います。忘れずに変えておきましょう。
内部リンク先の変更
サイト内の記事やメディアへのリンクアドレス（いわゆる<a>や<img>など）の対応が最も物量が多いですね。
ということでWordpressの場合、Search Regexプラグインでやるのが最も簡単です。
http://hogehoge.com を https://hogehoge/.com へ置換
という処理をするだけです。使い方は特に難しくないので、入れればおおよそわかると思います。
プラグイン嫌悪な人も、一旦入れて利用して無効にするなどして上手に利用するといいと思います。
ちゃんと検索結果を一旦表示してから置換ができるので、安心して処理できます。
これで8割程度のhttp参照はつぶせますが、このプラグインでは、各記事などのコンテンツ単位のものしか変更できません。そのため、headerに記載してるlink(CSSなど)やschemaなど、フレームワークで利用しているは、変換できませんので、そちらは別途手動で対応します。
ちなみに、このサイトはschemaの部分はまだ、放置中です。なので、混在サイト扱い。そのうち調べてやります。
利用している外部SNSやメディアの対応
TwitterやYoutube、ブログランキング等必要なサイトのアドレスを変更しましょう。
リダイレクトされるので特に飛べなくなっているわけではないですが、httpサイトとhttpsサイトは別物扱いなので、被リンクが減ったように見られると思います。
SEO等気にするのであれば、忘れずに変えましょう。
Google Analyticsの設定変更
Google Analyticsを使っている場合、左下の管理メニュー → プロパティ、からプルダウンで変更可能なのでサクッと変更しておきましょう。
また、その管理画面のビュー設定にも、アドレス設定があるので変更しておきましょう。
Google Search Consoleの設定変更とクロール要求
Google Search Console(サーチコンソール)は、設定が少しだけ面倒です。
https用のプロパティを新規に追加する必要があります。追加すれば、認証はこれまでと同様であればすぐできるはずです。
サーチコンソールへの登録が終わったら、Fetch as GoogleにてサイトをGoogleさんにクロールしてもらい、新しいアドレスを認識してもらいます。ルートのアドレスから、リンク先も含めたリクエストをしておけば問題ないと思います。
Sitemapを設定している場合、作り直してアップロードして置くと良いと思います。
それから細かい設定で、
- Google Analyticsと連携している場合、その連携設定
- ターゲット地域の設定
等を行います。
新規プロパティ登録すると、Search Consoleから、検索結果最適化のメールがきて「wwwあり・なしのサイト両方で登録を～」、なんてきますが、自分でServerAliasでどちらかをつぶしているなら、これは特に必要ないと思います（多分）。僕はやってません。
ここまでで、一般的な環境としては設定終了だと思います。以下少し特殊な環境の話。
VimRepressを使っている場合の対応と注意
VimRepressを使っている場合、.vimpressrcの書き換えを行います。
上で、内部リンク等のhttpからhttpsへの置き換えを、WordpressプラグインSearch Regexで行いましたが、VimRepressの場合ここで注意。
VimRepressでMarkdown記述の場合、Markdownの本文はメタ情報に文章があるので、Search Regexを使ったときに
「Source」を「Post meta value」に対しても行う必要があります。
というか、メタデータに対応してくれていてありがとうございます！！！
これでかなり助かりました。はじめは、Search Regexでやるにしても、Markdown側の記述どうしようって・・結構悩みました。あまり期待せずに、ひとまずプラグイン入れてどんな感じか見てみたら、meta valueにも対応していて感動いたしました。
Polylangを使っている場合の注意点
多言語化対応で、Polylangを使っている場合、
ダッシュボード → 言語 → 設定 → ブラウザーの言語の検出
が有効になっていることがあります。（デフォルト有効かな？）
この影響で、改めてSearch Consoleに登録し直して、ルートからクロール要求(Fetch as Google)したリクエストが、英語サイトにリダイレクトされているという結果が返ってきました。
これは困ります、英語サイト側からでは、日本語のコンテンツまでクロールしてくれるかかなり怪しいです。そもそも、リダイレクトされているという結果が出ること自体気持ち悪すぎます。
ということで、きっとPolylangの影響ということで、上記設定をオフにして、リクエストすると、正しく日本語サイトのルートで認識されました。
その後に気づいたのですが、そのタイミングで、Search Consoleのターゲット地域の設定をしていなかった影響もあるかもしれません。ターゲット地域を日本にしていればそもそも問題も起きなかった可能性もあります。
残りのTODO
ということで、なんやかんや様々な対応をして、移行自体はうまくいっています。
が、残りの対応もあります。
- 混在コンテンツの解消
- cronでSSL認証の自動更新
混在コンテンツは、実際には現状SEOに影響しないらしいので、急ぐ必要が無いので現状放置しています。とはいえ、ないにこしたことはないので、schemaなど放置したものをいずれ対応していきます。
SSL認証は、Let’s Encryptは無料な分3ヶ月程度で認証が切れてしまうため、3ヶ月後くらいに再度更新する必要があります。毎回手でやっていられませんし、忘れてはいけないので、自動化します。自分がcronを使ったことがないため、これから改めて設定予定です。
以上、ホントに書き殴りになりましたが、SSL化対応についてでしたっ。
コメント