[対象: 上級]

気付いている人もいるかと思いますが、このブログ全体をHTTPSにしました。

この記事では、備忘録を兼ねて、完全HTTPSへの移行を検討しているサイトの参考になるように僕が実行してきたプロセスをまとめます。

実行した主な作業は次のとおりです。

  1. サーバー証明書の取得
  2. HTTPSへのリダイレクト
  3. 内部リンクの修正
  4. 各種ツール・パーツのHTTPS動作確認
  5. すべてのコンテンツがHTTPSでダウンロードされているかを確認
  6. WordPressの設定変更
  7. rel=”canonical”の更新
  8. ウェブマスターツールへの登録
  9. サイトマップの更新
  10. ソーシャルシェアの引き継ぎ
  11. HSTSの設定
  12. 外部リンクの更新
  13. 高速化

順に説明します。

1. サーバー証明書の取得

サーバー証明書をまず取得します。

手順は利用しているサーバー会社によって変わってきます。
詳しくはお使いのサーバー会社のヘルプを参照したりサポートに問い合わせたりしてください。

僕のブログはエックスサーバーで運用しています。
マニュアルはこちらで確認できます。

なおHTTPSを評価するGoogleのアルゴリズムにおいてはサーバー証明書の種類は今のところ問われません。
たとえば通常の証明書とEV (Extended Validation) SSL証明書に優劣はありません。
また証明書の鍵長の推奨は 2048 bit ですが、必須条件にはしていません。

どこの証明機関のどんな種類のサーバー証明書を取得するかは内容と費用で考えてください。
僕はとりあえずいちばんお安いのを選びました。(笑)

ところで、僕は取得申請の段階で最初の失敗がありました。

僕の場合「コモンネーム」には、www.suzukikenichi.com を指定しなければなりません。
ところが何を思ったか、suzukikenichi.com で申請してしまいました。
これだとwwwありのドメイン名では、有効なサーバー証明書として使えません。
つまりムダに取得してしまいました。
もう一度取り直しです。

マニュアルではきちんと説明されているので、間違えた僕が間抜けなだけです。
同じポカを犯さないようにご注意ください。

なお自前のサーバーで運用していてサーバー証明書を自分でインストールできるなら、テスト用の無料証明書を使うといいでしょう(期間が短いこと以外は、HTTPSの仕組み・機能は本番用とまったく同じ)。

サーバー証明書を販売している証明機関は、通常、テスト用の証明書を無料で提供しています。
有効期限は一般的に1〜2週間です。
この期間のなかでHTTPSを正常に導入できるかどうかを検証できます。

2. HTTPSへのリダイレクト

http:// のURLから https:// へのURLへとリダイレクトします。
301リダイレクトを使います。

.htaccessに次のように記述しました。

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$ [OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.suzukikenichi.com/$1 [R=301,L]

1行目の RewriteEngine on はすでに記述されていれば繰り返す必要はありません。

2行目はなくてもかまいません。
3行目と同じことを通常は意味しています。

追加のリダイレクト設定

僕のブログは、「blog」ディレクトリ配下にWordPressで運用しています。
WordPressがblogディレクトリに.htaccessを自動で作成していました。

これが理由で、blogディレクトリ(つまりブログ)のなかのURLに対してリダイレクトが機能しませんでした。
blogディレクトリ内の.htaccessがルートディレクトリにある.htaccessの命令を引き継がずに上書きしてしまっていたのだと思われます。

そこで、blogディレクトリ内の.htaccessに次の記述を追加しました。

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$ [OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.suzukikenichi.com/blog/$1 [R=301,L]

これでブログのURLもHTTPSに正しく301リダイレクトできるようになりました。

リダイレクトのチェック

設定が終わったら、http:// から https:// へ正常にリダイレクトされているかどうかを確かめます。

ブラウザでの目視とFetch as Googleでチェックします。

Fetch as GoogleでHTTPSへのリダイレクトを検証

【追記】
はてなブックマークで次のようなコメントをいただきました。

あえてツッコミを入れるなら、301リダイレクトはhttpsでの確認を一通り終えたあと、一番最後にやるべき。先にやってしまうと、不注意でループを招くことがある。

まったくそのとおりです。

僕も実際には、すぐには301リダイレクトを設定しませんでした。
HTTPとHTTPSの両方でアクセスできる状態にしておき、HTTPSで表示の不具合がないかどうかをチェックしました。

万全を期すなら、「5」まではリダイレクトしなくてもいいかもしれません。
もっともビジネス用途のクリティカルなサーバーは、テスト用サーバーで十分に検証してから本番で実行すべきです。

3. 内部リンクの修正

http:// になっている内部リンクや画像の参照元(srcの値)を修正します。

相対URL(相対パス)で記述しているならこの作業不要です。
僕は基本的に内部リンクであっても http:// から始まるURLで記事中では記述していたので必要な作業になりました。
301リダイレクトを設定していればそのままでも見た目の不具合は起きませんが、スピードの低下(とPageRankの喪失?)を防ぐならリダイレクトしないに越したことはありません。

しかし2,600以上の記事があるので手作業での修正は困難です。
そこでSearch RegexというWordPressのプラグインを使って置き換えました。
使い方は説明を読むかGoogleで検索して調べてください。

念のために事前にDBをバックアップしておきます。
少しドキドキしましたが、何のトラブルもなく一瞬で完了しました。

プロトコル相対URLに僕は置き換えました。

http://www.suzukikenichi.com/blog/...//www.suzukikenichi.com/blog/...

HTTPSへの移行がうまくいかずHTTPでの運用を続けるかもしれなかったし、将来再びHTTPに戻す可能性がゼロとは言えないからです。
プロトコル相対URLは、そのページが http:// であれば http:// が、https:// であれば https:// が補完されます。

相対URLに置き換えることも当然できました。
実際、内部リソースには相対URLを使うようにHTTPS利用のガイドラインでGoogleは勧めています。

  • 同じ安全なドメイン上にあるリソースには相対 URL を使用します
    たとえば、サイト example.com 上のページを参照するには、<a href="https://example.com/about/ourCompany.php"> ではなく、<a href="/about/ourCompany.php"> を使用します。このように指定すると、リンクやリソースに常に HTTPS が使用されます。さらに、ローカルでの開発では、画像、ページ、またはその他のリソースが、本番環境ではなくローカル開発環境から読み込まれるので、誤りが起こりにくくなるという副次的な利点もあります。

4. 各種ツール・パーツのHTTPSでの動作確認

アクセス解析ツールやソーシャルボタン、広告、プラグインなどがHTTPSでも動作するかどうかを確認します。

僕の場合は次が対象になりました。

Googleアナリティクス

標準でHTTPSに対応しているので修正は発生しません。
そのままです。

ソーシャルボタン

僕が設置しているソーシャルボタンは以下です。

  • Twitter
  • はてなブックマーク
  • Facebook
  • Google+

どれも最新のコードはHTTPSに対応しています。
古いコードは新しいコードに置き換えました。

AdSense

新しいコードはHTTPSに対応しています。
僕のは古かったので貼り替えました(既存のコードに含まれる http://// に変えるだけでもよい)。

僕は設置していませんが、アフィリエイト広告もHTTPSに対応している必要があります。
未対応のASPがあるようなので、アフィリエイトをやっている人はASPに確認してください。

プラグイン

僕が利用しているWordPressのプラグインは1つだけ対応していませんでした。
正確には、対応していないというよりは外部JavaScriptをHTTPで読み込んでいました(後述)。
自分で修正できたように思いますが、なくても困らないプラグインなのでオフにしました。

サイト内検索

サイト内検索にGoogleカスタム検索エンジンを僕は使っています。
古いコードはHTTPSに対応しておらず、検索すると警告が出ました。
新しいコードに交換しました。

5. すべてのコンテンツがHTTPSでダウンロードされているかを確認

HTTPSのページで、HTTPで読み込むコンテンツがあるとたいていのブラウザでは警告が出ます。

たとえばChromeの場合は、緑色の鍵マークにならずに黄色い三角の警告マークが付きます。
マークをクリックすると理由が示されます。

安全ではないリソースのChromeによる警告

この原因の特定に僕は非常に手こずりました。
内部リンクと画像はすべて正しく記述しています。
HTMLのソースを見てもダウンロード先を http:// で指定している箇所はありません。

最終的に、Chromeのデベロッパーツールで原因を突き止められました。
Consoleメニューに問題点がレポートされます。

Chromeのデベロッパーツールに出てきたHTTP Over HTTPSのエラー

緑色の枠のなかのメッセージを日本語に訳すとこうなります。

混在したコンテンツ: https://www.suzukikenichi.com/blog/ のページはHTTPSで読み込まれました。しかし、安全ではない http://platform.twitter.com/widgets.js のスクリプトをリクエストしました。このコンテンツはブロックされました。HTTPSで取得されなければなりません。

Twitterのスクリプトが http:// でダウンロードされています。
ですが、僕が貼ったコードは https:// で読み込む設定なっていました。
このキャプチャには出ていませんが、同じスクリプトがHTTPとHTTPSの両方で二重にダウンロードされていることに気付きました。

結局、プラグインの仕業でした。
矢印がTwitterのスクリプトを http:// で読み込んでいるスクリプトです。
プラグインの名称までは出ていませんが、スクリプトのファイル名をみてピンときました。

原因になっているプラグインをオフにして万事解決です。

なおChromeでは外部サイトに送信するフォームがHTTPであっても警告が出ます。
FirefoxとSarafiは出ませんでした。

6. WordPressの設定変更

WordPressのURL出力の設定をHTTPSのアドレスに変更します。

一般設定から行います。
WordPressの一般設定でURLを変更

WP以外のCMSでも同様の設定箇所があるはずです。

7. rel=”canonical”の更新

rel=”canonical”をHTTPSのURLに向けます。

もしrel=”canonical”がHTTPのままだと、301リダイレクトしてもいずれHTTPに正規化されてしまいます。
そんなトラブルをつい最近記事にしましたね。

WordPressであれば、上で紹介したURL設定の修正で同時に置き換わります。

しかし僕はWPとrel=”canonical”のURLを数日間HTTPのままにしておきました。
HTTPSでの運用に問題がないと判断するまでは、HTTPのインデックスに保っておきたかったからです。

8. ウェブマスターツールへの登録

URLが変わるので、HTTPSに移行したサイトは別サイト扱いになります。
https:// で始まるアドレスのサイトを新たに登録しました。

インデックスの移行状況を把握するために以前のHTTPのサイトは残します。
wwwありなしも含めて、1つのサイトなのに6つ登録しています(ブログだけの状況を知りたいので別に登録している)。

  • suzukikenichi.com
  • www.suzukikenichi.com
  • www.suzukikenichi.com/blog
  • https://suzukikenichi.com
  • https://www.suzukikenichi.com
  • https://www.suzukikenichi.com/blog

強調表示した下の2サイトが現在のインデックス対象のサイトです。

[UPDATE] 否認ファイルの再アップロード

リンクの否認ファイルをアップロードしていた場合は、HTTPSで登録したサイト側で再アップロードが必要です。
移行前のHTTPサイトのリンクの否認は、移行後のHTTPSサイトには引き継がれません。
詳細はこちらの記事を参照してください。

9. サイトマップの更新

https:// のURLを記述したサイトマップを送信します。
ここでいうサイトマップは、検索エンジン用のXMLサイトマップです。

http:// ではもうインデックスさせないのでHTTPのときのサイトマップは削除します。

これもHTTPSでの運用に問題がないと判断してから実行しました。

およそ2,600のURLを送信しており、10日ほどで約85%の2,200ほどがインデックスされています。

インデックスステタース」レポートにはデータの更新が1週間に1回程度なので反映は遅めです。
グラフにようやく出始めました。

HTTPSサイトのインデックスステータス

HTTPからHTTPSへの移行にはアドレス変更ツールは利用できないので、HTTPSのURLに完全に移行するまで気長に待つしかないです。

10. ソーシャルシェアの引き継ぎ

結果からいうと、これは断念しました。

URLが変わるので、ソーシャルシェアのカウントはゼロからのスタートになります。

以前のシェア数を表示させることはできるのですが、http://https:// のそれぞれについたカウントを合算させることはできません。
また、HTTPS移行前の記事のURLを http:// のままにする一方で、HTTPS移行後の記事のURLを https:// で表示させられればいいのですが、それも僕には無理です。

そういうわけで、ソーシャルのシェアは新規にスタートになりました。
はてブでホットエントリした記事もゼロに戻っています(+1は、何らかの条件を満たしたものは引き継がれている)。

もったいない気がしないわけではないですが、仕方ありません。
上手な対処法があれば教えてください。

11. HSTSの設定

HSTS (HTTP Strict Transport Security) を設定します。

HSTSは、2回目移行のアクセスはたとえHTTPのURLをブラウザに打ち込んでも、HTTPSでアクセスさせる仕組みです。

.htaccessに次のように記述しました。

Header set Strict-Transport-Security "max-age=31536000;"

正しくHTTPヘッダーで返されているかどうかを確認します。

HTTPヘッダーでHSTSが返されている。

Preload HSTS

HSTSをさらに確実にするために、Google ChromeのPreload HSTS(プリロードHSTS)のサイトリストに登録申請することもできます。

Preload HSTSを利用するときはたとえば次のような記述になります。

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

HSTSとPreload HSTSについてはWeb担当者Forumで説明したことがあります。
詳細はそちらの解説を参照してください。

12. 外部リンクの更新

外部サイトからのリンクも https:// のURLに修正します。

でも自分が管理するサイトはともかくとして、管理外のサイトは依頼する必要があって面倒ですよね。
なので僕はソーシャルネットワークのプロフィールくらいしかまだ更新してません。
とはいっても僕を真似せずに、あなたは可能な限り更新しましょう。

僕のブログにリンクしてくれている方は、HTTPSに修正してください。

【UPDATE】
外部リンクの更新は特に重要ではありません。
簡単に変更できるものだけで十分です。
HTTPS移行後に外部リンクのURLを https:// に変更する必要はない

13. 高速化

HTTPS化への移行には直接関係しませんが、表示速度の高速化のためにいくつか施策しました。
HTTPSは暗号・復号の処理が必要になる分だけスピードが遅くなりがちだからです。

今回実行したのは次です。

  • 不必要な(たいして役立てていない)JavaScriptの削除
  • 設置していることにさほど意味がないサイドバーのパーツの撤去
  • 記事コンテンツのレンダリングに必要がないJavaScriptの遅延読み込み

やろうと思えばもっといろいろできますが、モバイル対応化に向けて準備中なのでリニューアルのタイミングで込み入ったことをやるつもりです。

僕が利用しているエックスサーバーは、mod_pagespeedを有効にできます。
これも手伝ってか、少なくともPCからのアクセスに限って言えば遅さは感じないはずです。

以上です。

固有の状態で、ともすると不具合が見られるページがあるかもしれません。
もし発見したら教えてください。

正直に言うと、完全HTTPS化したいちばんの理由は、GoogleがHTTPSをランキング要因にしたことです。
そして日本のGoogleのサーチクオリティチームの方たちが押していたことです。

そこで気になるのはHTTPS化がSEOに与える影響です。
アクセスが少ない年始に移行したこと、移行が完全に完了からまだ1週間ほどしか経過していないこと、すべてのHTTPSページがまだインデックスされていないことなど、影響を判断するにはまだ早すぎます。
今後気付いたことがあればお伝えします。

どんな結果が出るかはわからないとして、SEOだけが目的ならHTTPS化は割に合わなそうというのが実際に移行してみた僕の率直な感想です。
実行ステップの1つ1つは難しいことはないのですが、いざやってみると思いどおりに行かないことがあって苦労しました。

HTTPで長年運用してきてページ数が多いサイトではどこかどこかで問題が出てくるに違いありません。
どのくらい効果があるかわからない順位上昇だけを理由にHTTPSに移行するというなら、僕なら勧めません。

しかし、そもそもHTTPSはSEOを目的に導入するものではありません。
ユーザーに安全に利用してほしいという狙いがあるならHTTPS化はおおいに意味があります。
また新規サイトであれば最初からHTTPSを組み込むことを前向きに検討すべきです。

多くの苦労があったとしても、ムダなことをしたとは僕はまったく思っていません。
非常に良い経験になりました。
それにHTTPSの導入を勧める場面では自分のサイトもHTTPSにしておいたほうが説得力がありますしね。

機密性が高い情報を僕のブログは扱っているわけではありませんが、それでも安全な通信を今はあなたに提供できます。
クレジットカード情報を問い合わせフォームから送信しても第三者に盗み見られることはないので安心してください(本当に送らないように)。w

HTTPSへの移行に際しては、Web担当者Forumの安田編集長と友人の木村將さん、同僚の矢萩クンに行き詰まった場面で手助けしていただきました。
最後になりますが、この場を借りてお礼します。
ありがとうございました :)

このエントリーが役に立ったらシェアしてください

[Ads & Featured Contrents]

海外SEO情報ブログTOPSEM・SEO全般 › ブログの完全HTTPS化を完了、HTTPからHTTPSへの移行プロセスを共有

Comments

  1. By くりくり on

    いつもお世話になっております。

    これはすごい!!
    httpsに移行する方に参考になるでしょう。

    自分も去年の8月に移行しましたが、
    この記事読んでいたらもっとスムーズに移行できたろうな・・・。
    トラブルと修正で盆休みが終っちゃいました・・・。

    *** Reply from Suzuki Kenichi ***
    コメントありがとうございます。

    それでも最終的にはうまく移行できたのですよね。
    早い段階でHTTPS化に挑んだのはすごいことだと思います。

    僕は正月休みが移行作業で終わっちゃいました(笑)

  2. By flirt on

    こんにちは、いつも拝見させて頂いています。

    ソーシャルカウントの件ですが、こんなアイデアはどうでしょうか?

    1.functions.phpで関数を作って、single.phpなど表示される箇所で各ソーシャルサービスのAPIを叩いてソーシャルカウントを取得する。
    2.プラグイン実行前に分岐をして、ソーシャルカウントのある場合はhttp://のURLを渡す。そうでないならhttps://の(つまりpermalink)を渡す。

    古い記事にhttps://でカウントされたらリセットする、よいう条件を加えたいのであれば、更に分岐すれば良いかと。

    各ソーシャルのAPI叩くコード等はメール頂ければお渡しいたします。

    *** Reply from Suzuki Kenichi ***
    ご提案ありがとうございます。
    そんな方法が考えられるのですね。
    すごいと思いました。
    でも僕のスキルでは作れません(汗

  3. By 山田 on

    初めまして、
    山田と申します。
    一つ、
    質問があります。

    自分の管理しているサイトの問合せフォームのみを
    httpのものからセキュリティを考えて、
    httpsに変更しようと考えています。
    これに際して、
    独自SSLの会社と契約をしようと考えています。
    素人ながら、
    該当のページのURLだけ変わるのかなと思っていましたが、
    内容を見てみると、
    ドメイン単位でhttpsのドメインがサイト全体に
    自動で生成されるみたいで、
    問い合わせのページ以外はこれまで通り
    httpでいこうと思っていますが、
    その作業をSEO的に不利にならないように制作会社側に相談したところ、
    canonical設定で問い合わせのページ以外に
    これまでのhttpを指定すれば得に問題がないと
    言われています。
    どうでしょうか。
    きちんと上記の処理を行えば問題なさそうでしょうか?
    ずっと育ててきたサイトですので慎重に行いたいので、
    専門家に聞いておこうと思いました。

    制作側では無く、自社のサイトを管理している者です。
    的外れかも知れませんが困っています。
    お忙しいかと存じますが、
    宜しくお願い致します。

       山田

    *** Reply from Suzuki Kenichi ***
    問い合わせフォームのみHTTPSにするのであれば、問い合わせフォームはHTTPSへ301リダイレクト、その他のページはHTTPへ301リダイレクトが良いかと思います。
    rel=”canonical”でもいいですが、HTTPSページにもアクセス可能なので、何かの拍子でHTTPSにアクセスしたユーザーのブラウザで状況によってはセキュリティ警告が出ることがあるかもしれません。
    またrel=”canonical”は命令ではなくヒントなので、HTTPSページが検索結果に出てくる可能性がゼロとはいえません(実際にrel=”canonical”を無視してHTTPSページが出ているケースを確認しています)。

    問い合わせフォームだけなら独自サーバー証明書を取得せずに、レンタルサーバーが提供している共有SSLを使うという手段もあります。
    たいていのレンタルサーバー会社は共有SSLを提供しているはずです。
    追加費用もかかりませんがこちらがお手軽では?

  4. By 山田 on

    山田です。
    早速返事を頂き、
    大変ありがたく思います。
    ありがとうございます。

    ①まず、鈴木さんの仰られように、
    canonical設定だけでは危なっかしいので、
    加えて、
    HTTPSへ301リダイレクト、その他のページはHTTPへ301リダイレクト
    をしておけば仰られるようなエラーや検索結果下落に対する懸念に対しては
    問題なさそうということでしょうか。

    ②サーバー側に確認したところ、
    問い合わせページのみを暗号化するにしても
    独自SSLと同様に、
    ドメイン全体で証明を発行するため、
    サイト全体にhttpsのページが生成されてしまうようです。
    ですので、
    料金の面は有利かも知れませんが、
    懸念点は同じかなと思います。
    いかがでしょうか。
    そうであれば、今後、サーバー移転する可能性があるのであれば
    サーバー固有のアドレスが入ってしまう
    共有SSLは避けたいなと思っています。

    素人ながらいっしょうけんめい10年ほど運営して
    やっとアクセスが増えてきた段階です。
    よろしくお願いします。

    対応、回答、
    感謝します。
    どこにもすっきりする答えが見つからなかったので、
    心から感謝致します。

      山田

    *** Reply from Suzuki Kenichi ***

    HTTPSへ301リダイレクト、その他のページはHTTPへ301リダイレクト
    をしておけば仰られるようなエラーや検索結果下落に対する懸念に対しては
    問題なさそうということでしょうか。

    2つのURLがインデックスされる問題はなくなります。

    rel=”canonical”については以下の点にご注意ください。
    HTTPSのページ(問い合わせページ)はHTTPSに向けます。
    それ以外のHTTPのページはHTTPに向けます。

    費用を気にしないのであればもちろん独自SSLが好ましいです。
    ユーザーによっては問い合わせページだけドメイン名が異なるのを気にするでしょう。

    以上、ご参考になれば幸いです。

    追加の質問はGoogleの公式ヘルプフォーラムで尋ねることをおすすめします。
    多くの上級ユーザーが手助けしてくれます。

  5. By はるか on

    こんにちは。
    冗談半分で3年7200円の証明書を買ってしまって
    インストールしてみたら、もの凄く大変で
    このページをバイブルにして頑張ってます^^;

    それで、ちょっと見つけたのですが
    http://www.suzukikenichi.com/http://www.suzukikenichi.com/
    となります。
    また、同じリダイレクションだと思いますが
    http://suzukikenichi.com/http://www.suzukikenichi.com/
    となります。
    ついでに、当該サイトのブログリンクなど、殆どにhttpsが付いていません。

    メルマガが機能しなくなるので、最後の以外は意図的にやっているようにもみえましたが
    念のため連絡します。

    いや、鈴木謙一さんなら
    http://www.suzukikenichi.com/https://www.suzukikenichi.com/
    http://suzukikenichi.com/https://www.suzukikenichi.com/
    にリダイレクトしていると思って見てしましたw

    <余談>
    さくらはポート80で動くし、httpsの環境変数は吐かないし、
    なんか大変です(T_T)

    *** Reply from Suzuki Kenichi ***
    はるかさん、こんにちは。

    .htaccessをいじったときに、HTTPS化する前の古いものを使ってしまっていました(汗
    今は大丈夫なはずです(Fetch as Googleでも正常でした)。

    気付いてくれてありがとうございます。

    当該サイトのブログリンクなど、殆どにhttpsが付いていません。

    「当該サイトのブログリンク」とは何を指していますか?

    HTTPSにすると気持ちが良いので(笑)、最後までがんばってください!

  6. By はるか on

    >「当該サイトのブログリンク」とは何を指していますか?
    海外SEO情報ブログ
    ↑のブログリンクです。
    httpになってたと思いましたが、今httpsを確認しました。

    G+フォローしているのに、海外出張中だと気付いたのは
    コメントした後でした。出先からすいませんでした(>_<)

    「検索順位を上げることより経験値」と
    おっしゃっていますのが、まさにその通りだと思いました。
    お客様に対して安全を提供するための施策の一つなので
    経験があって損はないとおもいました。

    頑張って(凄く大変そうです)全https化を目指してみたいと
    思います。

    *** Reply from Suzuki Kenichi ***

    G+フォローしているのに、海外出張中だと気付いたのは
    コメントした後でした。出先からすいませんでした(>_<

    いえいえ、大事な設定だったので指摘していただいて助かりました。
    言われなかったら放置していた気がします。

    HTTPS化の早成功をお祈りします。

  7. By はるか on

    https://www.haluka.org/blog/2278/
    にてさくらのダメダメを回避する方法と
    このサイトを紹介させてもらいました。
    ほんとうにありがとうございました^^

    ついでにモバイル対応お疲れ様でした。
    まだまだ調整はありそうですが、読者の要望を最大限取り入れる姿勢は
    Googleの検索エンジンと同じアルゴリズムwだと思いました。
    とっても見習いたいとおもった一件でした。

    *** Reply from Suzuki Kenichi ***
    記事での紹介ありがとうございます。
    さくらはかなり面倒ですね。
    HTTPS化に挑戦するさくらユーザーにはとても役立ちそうです。
    記事執筆、お疲れさまでした。

    1点補足を。
    HTTPSの目的は3つあります(あえて2つにしたのかもしれませんが念のため)
    1. 盗み見防止
    2. 改ざん防止
    3. なりすまし防止
    http://goo.gl/Rq5Y29

  8. By 佐々木常広 on

    ここまで詳しく解説されているサイトはないのでとても助かりました。

    ありがとうございます。

    .htaccessについてなのですが

    11. HSTSの設定

    Header set Strict-Transport-Security “max-age=31536000;”

    これは1行だけ追記すればいいのでしょうか?

    のように挟むタグはないのでしょうか?

    また

    Preload HSTSを使う場合に

    Header set Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”

    を追記するのですが

    Header set Strict-Transport-Security “max-age=31536000;”

    と置き換わるのでしょうか?両方記載する必要がありますか?

    初歩的なことばかりかもしれませんが教えてもらえると助かります。自分なりに調べたのですがだったりサイトに寄ってまちまちだったので混乱するばかりでした。

    最後に

    HSTS Preload Listへの登録はhttp://の方、https://の方、どちらを登録するのでしょうか?

    *** Reply from Suzuki Kenichi ***
    タグで囲む必要はありません。
    Preload HSTSを使うのであれば、includeSubDomains; preload を追加した方を記述します。
    2つを記述しません。

    HTTPSで接続させるための仕組みですから、リストへの登録は当然HTTPSの方です。
    HTTPでは条件を満たしません。

    以上、疑問が解決していれば幸いです。

  9. By 佐々木常広 on

    Suzuki Kenichiさま

    ご教授ありがとうございます。
    おかげさまで疑問が解決致しました。

    こんなに早くお返事を頂けてビックリです。感謝致しますm(__)m

    佐々木

    *** Reply from Suzuki Kenichi ***
    お役に立てていれば幸いです。
    HTTPS移行、頑張ってください!

  10. By a on

    > http://platform.twitter.com/widget.jp
    早速の修正ありがとうございます。何度もすいません、本質的な違いはないですが、さらによく見ると http://platform.twitter.com/widgets.jp でした。

    *** Reply from Suzuki Kenichi ***
    いえいえ、僕が気付くべきところなのに、何度もご指摘いただいて恐縮です。
    これが最後ですかね?(笑)

    【追記】
    問い合わせフォームからのご指摘も直しました。
    重ね重ね、ありがとうございます。

  11. By Shin on

    こんにちは。

    少し教えてください。
    suzukikenichi.com とwww.suzukikenichi.com
    の両方をサーチコンソールに登録されているのは、
    それぞれのsitemap.xmlを作成されているのでしょうか?

    よろしくお願いします。

    *** Reply from Suzuki Kenichi ***
    いいえ、サイトマップはインデックスさせるURL(検索結果に出すURL)が対象なので、https://www.suzukikenichi.com/blog だけのサイトマップを送信しています。
    suzukikenichi.com とwww.suzukikenichi.com の両方を登録するのは、何かあった時に診断しやすくするためと、優先するドメインをSearch Consoleで設定するためです。
    両方の登録は推奨ですが必須ではありません。

  12. By Shin on

    鈴木様

    ご返信ありがとうございます。
    Search Consoleで優先するドメインを設定しておく方が良いのですね。
    今まで、.htaccessにて301リダイレクトさせているだけで、
    Search Consoleは優先するドメインを設定しないままでした。

    いろいろ勉強になります。
    ありがとうございます。

    *** Reply from Suzuki Kenichi ***
    301リダイレクトで正規化しているなら未設定でもまったく問題ないですよ。
    SCの設定はオマケみたいなものですね。(笑)

  13. By hikari on

    HTTPSにリダイレクトするさい
    「Options +FollowSymLinks」シンボリックリンクは、必要ないのでしょうか?

    他の記事(www統一、301リダイレクト)等では、
    「Options +FollowSymLinks」の記載がありますが、

    「Options +FollowSymLinks」は、
    あっても、無くても、いいものなのでしょうか?

    *** Reply from Suzuki Kenichi ***
    あったほうがいいです(1回書けばOK)。
    完全HTTPS化するような人は、すでに.htaccessを使ってるはずでたいていは書いてあるだろうし、わざわざ言わなくてもわかっているだろうという思い込みにも似た前提で説明していました。
    失礼しました。

  14. By yt on

    いまは307でリダイレクトさせているのでしょうか?

    *** Reply from Suzuki Kenichi ***
    今でも301リダイレクトです。
    HSTSをサポートしているブラウザでは307が内部的に返されます。 ⇒ http://goo.gl/IXyOVN

  15. By tam on

    大変有意義な情報ありがとうございます。
    プリロードHSTSに登録する際、下記の設定だと「Error: HTTP redirects to www first」とエラーになってしまいます。
    RewriteEngine on
    RewriteCond %{SERVER_PORT} !^443$ [OR]
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://www.sample.com/$1 [R=301,L]

    RewriteRule ^(.*)$ https://sample.com/$1 [R=301,L]
    だと登録できるのですが、wwwを付けた場合でプリロードHSTSに登録するにはどのようにしたら宜しいでしょうか。

    *** Reply from Suzuki Kenichi ***
    「wwwあり」で運用しているのですよね?
    プリロードHSTSのリストに登録するときに、一時的に「wwwあり」へのリダイレクトによる正規化を無効にしてみてください。
    僕はそうやって登録したように記憶しています。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA


▲ページの一番上に戻る