HTTPS は、ブラウザとサーバー間の通信を攻撃者による傍受や改ざんから保護します。これにより、今日のWWWトラフィックの大部分に機密性、整合性、および認証が提供されます。
アドレスバーに鍵のアイコンが表示されているWebサイトはHTTPSを使用しています。
この記事では、次のことを学びます。
- HTTPとHTTPSの基本
- TLS証明書のしくみ
- HTTPSがSEOにどのように役立つか
- HTTPSの設定方法
- 潜在的なHTTPS移行の間違いを確認する方法
まず、間に攻撃者がいる場合のクライアント(ブラウザ)とサーバー間の通信を簡略化して説明します。
ご覧のとおり、攻撃者はログインや支払いの詳細などの機密データを入手したり、リクエストされたリソースに悪意のあるコードを挿入したりできます。
潜在的なネットワーク攻撃は、信頼できないルーターまたはISPを使用している場所であればどこでも発生する可能性があります。したがって、どの公衆WiFiネットワークもそのような攻撃に対して脆弱です。幸い、一般の人々はこの事実に気づいているようです(VPNの使用が増加しています)。
ただし、全員のブラウジングエクスペリエンスを安全にする負担は、ウェブマスターにあります。
そこでHTTPSの採用が始まります。
HTTPSはHTTPリクエストとレスポンスを暗号化するため、傍受した攻撃者は、たとえばクレジットカードの詳細ではなくランダムな文字のみを見ることができます。
HTTPSの動作の類似点は、貴重品を破壊できないロックされたコンビネーションボックスで送信することです。送信側と受信側だけがその組み合わせを知っており、攻撃者がそれを手に入れても、中には入りません。
現在、HTTPS接続が形成されると、多くのことが起こります。主に、HTTPSはTLS(Transfer Layer Security)暗号化に依存して接続を保護します。
WebサイトでHTTPSを有効にする唯一の方法は、TLS証明書を取得してサーバーにインストールすることです。SSLまたはSSL / TLS証明書としても表示されますが、心配する必要はありません。すべて同じです。技術的には後継者のTLSを使用していますが、SSLは依然として広く使用されている用語です。
TLS証明書は認証局(CA)によって発行されます。CAの役割は、クライアントとサーバーの関係において信頼できるサードパーティになることです。基本的に、誰でもTLS証明書を発行できますが、ブラウザがサポートするのは、公に信頼されているCAのみです。
ブラウザのアドレスバーにある鍵のアイコンをクリックすると、すべてのWebサイトのTLS証明書と発行元のCAを確認できます。
証明書をクリックすると、詳細を確認できます。ここで重要なのは「Issued to:」の行です。これは、TLS証明書のさまざまな種類の検証標準に入るときであり、主に無料と有料の証明書を区別するものです。
DV、OV、およびEV:それは何を意味し、どれを選択すべきですか?
ホスティングおよびCDN プランに付属する無料のTLS証明書は、ドメイン検証(DV)のみを実行します。これにより、証明書の所有者が特定のドメイン名を制御していることが検証されます。このような基本的な検証手法は、機密情報を処理しないブログやWebサイトには十分ですが、そうしたブログには適していません。
DV TLS証明書を使用しているWebサイトは安全に見えますが、ロックアイコンをクリックしたときに[発行先]行が表示されません。
最も一般的なDV TLS証明書は、Let’s Encryptと呼ばれる非営利のCAからのものです。これは、無料の自動更新可能なTLS証明書を提供するほとんどの企業が使用するものです。
DVのみの証明書には何の問題もありません。結局、それは、自動的に大規模に発行できる唯一のタイプのTLS証明書です。ただし、HTTPSは、通信しているサーバーを認証する基本的な証明書と同じくらい強力です。
Webサイトでログインまたは支払いが許可されている場合は、組織の検証(OV)または拡張された検証(EV)を提供するTLS証明書に投資する必要があります。これら2つのタイプは検証プロセスが異なり、EVはより厳密です。
1つだけを購入する場合は、EV TLS証明書を直接購入することをお勧めします。これは最も信頼できるものであり、OVよりはるかにコストがかかりません。
ワイルドカードとSAN TLS証明書
検証標準を残して、TLS証明書の別のカテゴリに移りましょう。
ワイルドカードとSAN証明書は、複数の(サブ)ドメインを一度に保護するために使用されます。example.comの標準EV TLS証明書を購入した場合、blog.example.comには別の証明書が必要です。
ワイルドカード証明書は無制限のサブドメイン(example.com、blog.example.com、docs.example.com)を保護できますが、SAN証明書には他のドメイン(example.com、blog.example.com、different.org)も保護するオプションがあります)。
これらのタイプは検証タイプと組み合わされているため、CAが提供するオプションを参照すると、あらゆる種類の組み合わせが表示されます。また、検証プロセスについても説明します。
HTTPSのほとんどすべての利点はSEOに結びついています。
- 軽量ランキング信号
- セキュリティとプライバシーの向上
- 紹介データを保持する
- セキュリティとサイト速度を強化する最新のプロトコルの使用を可能にします
軽量ランキング信号
Google は、 2014年にHTTPSが軽量のランキングファクターであると発表 しました。他のランキングファクター変数が変更されていない場合にランキングを急上昇させるものというよりは、タイブレーカーのようなものです。
これは基本的に、世界中でのHTTPSの採用を促進するためのGoogleの貢献です。
セキュリティとプライバシーの向上
これについてはすでに話しました。しかし、これはどのようにSEOに関係していますか?
安全でないWebサイトにアクセスすると、次のようなものが表示されます。
それは本当に信頼を築くものではありませんよね?私は自分の専門的な偏見を認識していますが、個人的にはこれに注意を払い、どのWebサイトでもそれを目にするとすぐに悪い第一印象を形成します。
私の推測では、HTTPSに 移行することで滞留時間 を改善し、pogoの付着を防ぐことができます。これらは理論上の(確認されていない)ランキング要素にすぎませんが、ユーザーがWebサイトにアクセスしたときに「固定」することは、SEOに関係なく必要なことです。
紹介データを保持する
WebサイトがまだHTTP上にあり、Google AnalyticsなどのWeb分析サービスを使用している場合、悪いニュースがあります。HTTPSからHTTPページに参照データが渡されません。
最近のほとんどのWebはHTTPSで実行されているため、ほとんどの参照トラフィック(他のWebサイトからのリンクのクリック)のソースには、ほとんどの分析ソフトウェアで直接のラベルが付けられます。
これの1つの欠点は、データが乱雑になり、ゆがんでしまうことです。もう1つは、最適な参照ソースを確認できないことです。これは、無駄な リンク構築の機会です。
一般的なGoogle Analyticsのトラッキングの間違いに興味がある場合は、この投稿を確認してください。
セキュリティとサイト速度を強化する最新のプロトコルの使用を可能にします
紙の上では、セキュリティ機能が追加されているため、HTTPSはHTTPよりも低速です。ただし、最新のセキュリティおよびWebパフォーマンステクノロジーを使用するには、HTTPSが必要です。
つまり、セキュリティに加えて、TLS 1.3 やHTTP / 2などの プロトコルを使用すると、HTTPSによってWebサイトのページ速度が向上します。また、ユーザーエクスペリエンスの向上とは別に、Googleはページ速度をHTTPSに似た軽量のランキング要素と見なしています。
Jose Rivolta@jocherivoltaReplying to @pedrodiasA strong comment, but: Site speed not being important? Really?
Gary 鯨理/경리 Illyes✔@methode
Ranking wise it’s a teeny tiny factor, very similar to https ranking boost. That particular one is not surprising. You do that primarily to enable users to convert.
25
· Zurich, SwitzerlandTwitter Ads info and privacy
これはシナリオによって異なります。
1.新しいウェブサイトを立ち上げる
宝くじに当選しました。一緒に行くHTTPS初めから、あなたは今まで心配する必要はありませんHTTPおよび移行に関連したエラー。
必要なのは、プロセスをガイドし、最新のHTTPおよびTLSプロトコルバージョンをサポートする優れたホスティングプロバイダーを用意することだけです。結局のところ、稼働中の場合 は、セキュリティを保護するための最後のステップとしてHSTSを実装します。
2. HTTPSが有効なWebサイトがすでにある
この記事を読んでいるという事実は、おそらく正しくセットアップされていないことを示しています。次のセクションのアドバイスに従って、 一般的なエラーを確認してください。
3. HTTPで実行中のウェブサイトがまだある
すべてを準備して完了するには、しばらく時間がかかります。移行の複雑さは次の要素に依存します。
- ウェブサイトのサイズと複雑さ
- 使用するCMSの種類
- あなたのホスティング/ CDNプロバイダー
- あなたの技術的能力
人気のあるCMSと堅固なホスティングで実行されている小さなWebサイトの所有者が自分で移行を実行できると私は信じていますが、さまざまな要素が関係しています。
CMS / server / hosting / CDNのドキュメントを確認し、それに応じて続行することをお勧めします。実行する必要のある手順は非常に多いため、移行チェックリスト を作成または実行し、他のアクティビティに適合させないでください。
これらすべてが技術的に難しすぎる場合は、専門家を雇ってください。それはあなたの時間を節約し、あなたの神経を救い、そして将来を見据えた実装を確実にします。
HTTPS移行チェックリスト全体をチェックしたとしても、いくつかの問題が発生する可能性があります。
実際、2016年に戻って、10,000の上位のドメインを分析して、さまざまなHTTPSの間違いがないかを調べたところ、次のことがわかりました。
- ドメインの90.9%で、HTTPSの実装が最適ではなかった
- HTTPSが ドメインの65.39%で正しく機能していなかった
- ドメインの23.01%が永続的な301ではなく一時的な302リダイレクトを使用していた
それ以来、多くの点が変更および改善されていますが、以下の5つの一般的なHTTPS移行の間違いを確認することをお勧めします。それは長くはかからず、それらのほとんどは修正するのが難しくありません。
間違い1:残りのHTTPページ
まず第一に、サイトのすべてのページがすでにHTTPS上にあることを確認する必要があります。
Webサイトを完全にクロールすることで、残りのHTTPページを見つけることができます。HTTPS移行チェックリストに固執している場合、これは新しいものではありません。クローラーが必要なURLソースをすべて備えていることを確認してください。これにより、ページが残されません。
Ahrefsのサイト監査を使用している場合は、次の設定をお勧めします。
完了したら、最新のクロールを開き、ページエクスプローラーに移動して、次のフィルターを適用します。
HTTP URL のリストをエクスポートし、それらをリダイレクトして移行を完了します。
サイトマップ内になく、 それらを指すリンクがゼロのページは、クロールによって発見することは不可能です。これは、専用のPPCランディングページでよく発生します。これらを見つける1つの方法は、Google広告やFB Business Manager などの広告マネージャーからURLリストをエクスポートすることです。
そこから、孤立したページが適切に移行されたことを確認します。また、キャンペーンダッシュボードでそれらを新しいHTTPS形式に更新することを忘れないでください。
間違い2:HTTPコンテンツを含むHTTPSページ
このエラーは、HTTPSを使用して最初のHTMLファイルが読み込まれたが、そのリソースファイル(画像、CSS、JavaScript)がまだHTTPSに更新されていない場合に発生します。
これがウェブサイトの問題である場合は、クロールの概要と内部ページレポートの両方に表示されます。Site Auditのすべてのエラー、警告、および通知には、問題の説明と修正方法に関するアドバイスが含まれています。
間違い3:HTTPSに更新されていない内部リンク
内部リンク をHTTPSに更新しないと、不要なリダイレクトが発生します。これは明らかにHTTPページに到達するよりも優れていますが、この間違いはすでに済んでいます。これらのリンクを見つけて修正するのは簡単です。
この問題は、サイト監査のリンクレポートの下にあります。
URLをhttps://に書き換えれば完了です。これは、間違い#1のアドバイスを使用してHTTPページが残っていないことを確認している場合にのみ当てはまります。
間違い4:タグがHTTPSに更新されない
URLをHTTPSに更新する必要があるWebサイトで使用する可能性のあるタグには、正規タグとオープングラフタグの2種類があります。
正規タグ は、類似したページまたは重複したページの束から、最も信頼できるページであるとGoogleに通知します。これをHTTPバージョンに指定すると、間違いなくGoogleに悪いシグナルが送信される可能性があり、ほとんど無視されます。
Open Graphタグ を使用してソーシャルメディアの投稿を最適化する場合、Facebook では URLタグが必要です。これらは正規URLと同じである必要があります。
HTTP正規タグとOGタグを含むページを見つけるには、ページエクスプローラーでこのカスタムフィルターを設定します。
繰り返しになりますが、残っているのは、完全に移行が完了した場合、それらをhttps://に書き換えることです。
間違い5:失敗したリダイレクト
リダイレクトは注意が必要です。壊れたリダイレクトからリダイレクトチェーンやループまで、問題が発生する可能性はかなりあります。
さいわい、サイト監査でこれらのエラーを見つけるのは簡単です。リダイレクトレポートを確認して、すべての問題を確認してください。
[影響を受けるURLを表示]ボタンをクリックすると、次のようなレポートが表示されますが、デフォルトの列と指標が追加されています。
ここで一番良いのは、影響を受けるすべてのURL(リダイレクトされたURL、リダイレクトチェーン内のURL、リダイレクトされたURLにリンクしているURL)が実際に表示されることです。
ここでは、2つのことを行う必要があります。
1つ目はリダイレクトを分割することで、この場合は次のようになります。
https://blog.example.com/123/>-> 301リダイレクト->> https://example.com/blog/987/
これにより、https://blog.example.com/123/とhttps://example.com/blog/123/の両方を指すすべてのバックリンクが1回だけリダイレクトされるようになります。リンク編集リクエストでウェブマスターに連絡することは非常に非効率的で、非常に煩わしいので、外部バックリンクにとってそれは問題ありません。
内部的にはもっと上手くできます。
リダイレクトの数を最小限に抑えるよう努力する必要があります。そのとき、インリンク列の数が役立ちます。
インリンクは、リダイレクトチェーンの影響を受けるURLにリンクするURLです。これらのページのリンクを、200 HTTPステータスコードを返すURLに交換する必要があります。インリンクの数をクリックすると、それらすべてが表示されます。

Ahrefsのサイト監査でのInlinksレポートの例。ここでは、これら4つのページすべてに移動して、リンクをhttps://blog.example.com/123/からhttps://example.com/blog/987/に変更する必要があります。
もちろん、次のステップはリダイレクトチェーン内のURLのインリンクをチェックすることです。ただし、リダイレクトチェーンは既に切断されているため、優先度は低くなります。これらは、次のクロール時に3XXリダイレクトレポートで標準の301リダイレクトとしてタグ付けされます。
最終的な考え
私は一緒に、World Wide Webをより速く、より安全にブラウジングできることを願っています。
w3techs.comによると、調査サンプルの59.4%のWebサイトはデフォルトでHTTPSを使用しています。対照的に、Googleでは 、Chromeの閲覧時間の88〜99%がHTTPSウェブサイトで費やされていると報告しています。
このデータから私が得たことは、トラフィックの多い人気のあるWebサイトの大部分がすでにHTTPSに移行していることです。これら2つのデータポイントの大きな違いについて疑問に思っているのであれば、Googleのデータに含まれていない中国のWebサイトに原因があると思います。
ただし 、TLSサポートの品質に関しては、まだ多くのことが望まれています。ここで学んだように、HTTPSセットアップは移行プロセスで終わりません。Webのパフォーマンスとセキュリティのトレンドに対応し、最新の機能を実装することは、関係者全員にメリットがあります。
Leave a Reply