WebサイトのURLを見ると、先頭が、
http://
になっているものと、
https://
になっているものがあります。
現在では多くのWebサイトがHTTPSを利用していますが、
「HTTPとHTTPSは何が違う?」
「HTTPSなら絶対に安全?」
「HTTPSとSSL・TLSは同じもの?」
「httpからhttpsへ変えるとURLも変わる?」
「HTTPSにするとSEOに有利?」
「HTTP/2やHTTP/3とHTTPSは何が違う?」
と迷うことがあります。
結論からいうと、「HTTP」はWebブラウザとWebサーバーなどが情報をやり取りするための通信プロトコルで、「HTTPS」はそのHTTP通信をTLSなどによって安全に保護したものです。
一言で覚えるなら、
HTTP=「Web上で情報をやり取りするためのルール」
HTTPS=「そのHTTP通信を安全に保護したもの」
です。
IETFのRFC 9110では、HTTPを分散型・協調型のハイパーテキスト情報システムのためのステートレスなアプリケーション層プロトコルと定義しています。
同じRFCでは「http」と「https」という2つのURIスキームを定めており、httpsではサーバー認証に加えて、通信の機密性と完全性を確保することが求められています。
現在のHTTPSでは、古いSSLではなく、基本的にTLSが利用されます。
この記事では、「HTTP」と「HTTPS」の違いから、SSL/TLS、暗号化、証明書、URL、ポート番号、HTTP/2・HTTP/3、SEO、HTTPS移行時の注意点まで詳しく解説します。
- 「HTTP」と「HTTPS」の違い【結論】
- 「HTTP」とは?
- HTTP通信の基本は「リクエスト」と「レスポンス」
- HTTPは「ステートレス」
- HTTPの何が問題なの?
- 「HTTPS」とは?
- HTTPとHTTPSの最大の違いは「S」?
- HTTPとHTTPSではURLも別物?
- 「http://」と「https://」は何と呼ぶ?
- HTTPとHTTPSでポート番号は違う?
- HTTPSとSSL・TLSの違い
- HTTPSではどのように暗号化する?
- HTTPSではWebページ全部を公開鍵で暗号化する?
- 「証明書」は何のためにある?
- HTTPSならパスワードを安全に送れる?
- HTTPSならWebサイトそのものも安全?
- 「鍵マーク」があれば安全?
- HTTP/1.1・HTTP/2・HTTP/3とHTTPSの違い
- HTTP/2とは?
- HTTP/3とは?
- HTTPからHTTPSにするとSEOに有利?
- HTTPからHTTPSへ変更するときのSEO上の注意点
- HTTPからHTTPSへのリダイレクトは必要?
- 「Mixed Content」とは?
- 「Secure Context」とHTTPSの関係
- 「HSTS」とは?
- HTTPのサイトを見るだけでも危険?
- 「HTTP・HTTPS」で迷ったときの3秒判定
- 「HTTP」を使った例文
- 「HTTPS」を使った例文
- 具体例で比較:ログインページ
- 具体例で比較:普通の記事ページ
- よくある間違い1:「HTTPSはHTTPとは別のWebプロトコル」と思う
- よくある間違い2:「HTTPSならサイトの運営者も必ず信用できる」と思う
- よくある間違い3:「HTTPSではSSLを使っている」と思う
- よくある間違い4:「httpとhttpsは同じURL」と思う
- よくある間違い5:「HTTPSならパスワードは絶対に盗まれない」と思う
- よくある間違い6:「HTTP/3とHTTPSはどちらかを選ぶ」と思う
- よくある間違い7:「HTTPSに変更すればSEO順位が必ず上がる」と思う
- 「HTTP」と「HTTPS」に関するよくある質問
- まとめ
- 参考リンク・出典
「HTTP」と「HTTPS」の違い【結論】
| 比較項目 | HTTP | HTTPS |
|---|---|---|
| 正式名称 | Hypertext Transfer Protocol | Hypertext Transfer Protocol Secure |
| 主な役割 | Web上の情報を送受信する | HTTP通信を安全に保護して送受信する |
| 通信の暗号化 | 通常は暗号化されない | TLSによって保護される |
| サーバー認証 | HTTP自体にはHTTPSのような証明書認証がない | 証明書等を利用して接続先を確認 |
| 改ざん検知 | HTTP単体では通信保護を提供しない | TLSによって完全性を保護 |
| URL | http:// | https:// |
| 既定ポートの代表例 | 80 | 443 |
| 現在のWebサイト | 積極的に利用する理由は少ない | 基本的に利用すべき |
3秒で判断するなら、
「通信を保護せずHTTPとして送る?」 → HTTP
「TLSで保護されたHTTP通信?」 → HTTPS
と考えると分かりやすいでしょう。
「HTTP」とは?
ブラウザとサーバーが情報をやり取りするための通信ルール
HTTPは、
Hypertext Transfer Protocol
の略です。
Web上で、ブラウザなどのクライアントとWebサーバーが、
- HTML
- 画像
- CSS
- JavaScript
- JSON
- 動画などの各種データ
をやり取りするための基本的なプロトコルです。
MDNはHTTPについて、HTMLなどのハイパーメディア文書を転送するためのアプリケーション層プロトコルであり、WebブラウザとWebサーバーだけでなく、API通信などにも利用されると説明しています。
HTTP通信の基本は「リクエスト」と「レスポンス」
Webページを表示するとき、ブラウザはサーバーへ、
HTTPリクエスト
を送ります。
サーバーはそれに対して、
HTTPレスポンス
を返します。
たとえば、
- 利用者がWebサイトのURLを開く
- ブラウザがサーバーへHTTPリクエストを送る
- サーバーがHTMLをHTTPレスポンスとして返す
- ブラウザがHTMLを解析する
- 画像・CSS・JavaScriptなどを追加でリクエストする
というやり取りが行われます。
HTTPとHTTPSのどちらでも、基本となる「リクエストとレスポンス」という考え方は共通です。
HTTPは「ステートレス」
HTTPの重要な特徴の一つが、
ステートレス
であることです。
HTTP自体は、前のリクエストと次のリクエストを自動的に同じ利用者の連続した操作として記憶する仕組みを持ちません。
そこで実際のWebサービスでは、
- Cookie
- セッション
- 認証トークン
などを組み合わせて、ログイン状態やショッピングカートなどを維持します。
HTTPの何が問題なの?
HTTPそのものには、HTTPSで利用されるTLSのような通信経路の暗号化・認証・完全性保護がありません。
そのため、HTTP通信を信頼できないネットワーク上でそのまま利用すると、通信経路上の第三者に、
- 通信内容を盗み見される
- 送受信内容を書き換えられる
- 偽の情報を差し込まれる
などのリスクがあります。
ログイン情報や個人情報だけでなく、一般的なWebページでも、通信内容が改ざんされれば利用者へ悪意ある情報を表示される可能性があります。
そこで現在のWebではHTTPSが基本となっています。
「HTTPS」とは?
HTTP通信をTLSで保護したもの
HTTPSは、
Hypertext Transfer Protocol Secure
の略です。
MDNはHTTPSについて、HTTPの暗号化されたバージョンであり、TLSを利用してクライアントとサーバー間の通信を保護すると説明しています。
簡単に表すと、
HTTP+TLS=HTTPS
と考えることができます。
HTTPSではTLSによって、主に次の3つを保護します。
| 機能 | 意味 |
|---|---|
| 機密性 | 通信内容を第三者に読まれにくくする |
| 完全性 | 通信中のデータを勝手に変更されにくくする |
| 認証 | 接続先が正しいサーバーか確認する |
HTTPとHTTPSの最大の違いは「S」?
見た目では、
http
と、
https
の最後に「s」が付くかどうかの違いです。
しかし、この「S」は単なる文字の違いではありません。
HTTPSではHTTP通信を暗号学的に保護し、サーバーの認証や通信内容の完全性確認などを行います。
つまり技術的には大きな違いがあります。
HTTPとHTTPSではURLも別物?
はい。厳密には別のURL・別のオリジンです。
たとえば、
http://example.com/
と、
https://example.com/
は、ホスト名が同じでもURIスキームが異なります。
RFC 9110では、オリジンを、
- scheme
- host
- port
の組み合わせとして定義しています。
そのため、httpとhttpsは別のオリジンになります。
HTTPからHTTPSへ移行するときにリダイレクトやcanonicalの設定が重要になるのは、この違いがあるためです。
「http://」と「https://」は何と呼ぶ?
URLの先頭にある、
http
や、
https
は、
スキーム(scheme)
と呼ばれます。
RFC 9110では、
http URI scheme
https URI scheme
がそれぞれ定義されています。
「プロトコル部分」と説明されることもありますが、URL・URIの構造としては「スキーム」という用語がより正確です。
HTTPとHTTPSでポート番号は違う?
代表的な既定ポート番号は異なります。
| 通信 | 代表的な既定ポート |
|---|---|
| HTTP | 80 |
| HTTPS | 443 |
RFC 9110では、http URIの既定ポートを80、https URIの既定ポートを443としています。
ただしWebサーバーが必ずそのポートしか利用できないという意味ではありません。
URLに明示的なポート番号を指定したり、別の仕組みで通信したりすることも可能です。
HTTPSとSSL・TLSの違い
HTTPSを理解するときに特に混同しやすいのが、
SSL
と、
TLS
です。
現在のWeb通信では、
HTTPS=HTTPをTLSで保護した通信
と理解するのが基本です。
SSLはTLSより前に使われていた旧世代の技術で、現在は使用すべきではありません。
ただしWeb業界では現在も慣用的に、
- SSL化
- SSL証明書
- 常時SSL
という表現が使われています。
HTTPSではどのように暗号化する?
HTTPS接続を開始すると、クライアントとサーバーの間でTLSによる通信確立処理が行われます。
簡略化すると、
- ブラウザがHTTPSサイトへ接続する
- サーバーが証明書などを提示する
- ブラウザが証明書を確認する
- 鍵交換等を行う
- 安全な通信に利用する鍵を確立する
- HTTPの内容を暗号化して送受信する
という流れになります。
実際のTLSでは、公開鍵暗号、デジタル署名、鍵交換、共通鍵暗号など複数の暗号技術が組み合わされています。
HTTPSではWebページ全部を公開鍵で暗号化する?
いいえ。
公開鍵暗号はサーバー認証や鍵交換などで重要な役割を持ちますが、大量の通信データをすべて公開鍵暗号だけで処理するわけではありません。
実際の通信では、TLSハンドシェイク等によって安全に確立した共通鍵を利用して、効率よく大量のデータを暗号化します。
つまり、
HTTPS=公開鍵暗号だけで通信している
という理解は正確ではありません。
「証明書」は何のためにある?
HTTPSでは、サーバーが、
公開鍵証明書
を提示します。
Webサイト用の証明書には一般に、
- 対象となるドメイン名
- 公開鍵
- 証明書を発行した認証局
- 有効期間
- デジタル署名
などの情報が含まれます。
ブラウザは証明書チェーンやドメイン名などを確認し、
「接続しているサーバーが、そのドメインを正当に扱うサーバーか」
を検証します。
HTTPSならパスワードを安全に送れる?
HTTPSを正しく利用すれば、パスワードなどの通信内容はTLSによって暗号化され、通信経路上で単純に盗み見されるリスクを大きく減らせます。
しかし、
HTTPS=パスワードが絶対に盗まれない
という意味ではありません。
たとえば、
- 偽のフィッシングサイトへ自分で入力する
- 端末がマルウェアに感染する
- サービス側から情報が漏えいする
- 弱いパスワードを使い回す
といった別のリスクは残ります。
HTTPSならWebサイトそのものも安全?
必ずしもそうではありません。
HTTPSが主に保証するのは、
- 通信経路の暗号化
- 通信内容の完全性
- 接続先サーバーの認証
です。
悪意のある運営者でも、自分が管理するドメインについて有効な証明書を取得し、HTTPSを利用できます。
そのため、
「鍵マークがあるから、この通販サイトは必ず信用できる」
と判断するのは危険です。
サイトの運営者、会社情報、URL、取引条件なども確認する必要があります。
「鍵マーク」があれば安全?
ブラウザの表示は時代とともに変化しており、必ずしも従来の鍵マークだけが表示されるとは限りません。
重要なのは、アドレスバーの表示だけを見るのではなく、
正しいドメインへHTTPSで接続しているか
を確認することです。
HTTPSは「接続中のドメインとの通信が保護されている」ことを示すための仕組みであり、「そのドメインを運営する人物が信頼できる」という評価とは別です。
HTTP/1.1・HTTP/2・HTTP/3とHTTPSの違い
HTTPには複数のバージョンがあります。
代表的なのが、
- HTTP/1.1
- HTTP/2
- HTTP/3
です。
ここで重要なのは、
HTTP/2やHTTP/3とHTTPSは別の分類
という点です。
HTTP/2・HTTP/3は、HTTP通信をどのように効率よく実現するかというプロトコルの世代・方式です。
HTTPSは、HTTP通信を安全に保護するという意味です。
HTTP/2とは?
HTTP/2はHTTP/1.1より効率的な通信を実現するため、
- バイナリフレーミング
- 複数リクエストの多重化
- ヘッダー圧縮
などを導入しています。
RFC 9113では、HTTP/2について、HTTPの意味を変えることなく、ネットワークリソースをより効率よく利用し、遅延を減らすことを目的とした方式として説明しています。
HTTP/3とは?
HTTP/3は、
QUIC
というトランスポートプロトコル上でHTTPを利用する方式です。
RFC 9114では、HTTP/3をHTTP semanticsのQUIC上へのマッピングとして定義しています。
QUICにはTLS 1.3による暗号機能が組み込まれており、HTTP/3通信では機密性・完全性・相手の認証などが提供されます。
つまり、
HTTP/3=HTTPの新しい通信方式
HTTPS=安全に保護されたHTTP通信
であり、単純な対義語ではありません。
HTTPからHTTPSにするとSEOに有利?
Googleは、ユーザーとWebサイトの安全性を高めるため、HTTPではなくHTTPSを利用することを推奨しています。
またGoogle Search Centralは、HTTP版とHTTPS版に同等のページが存在する場合、原則としてHTTPSをcanonicalとして優先することを説明しています。
ただし、
「HTTPSにしただけで検索順位が必ず大幅に上がる」
と考えるのは適切ではありません。
Googleは現在、ページエクスペリエンスを単一の「HTTPSランキング要因」だけで評価しているわけではなく、コンテンツ品質や多くの要素を総合して検索結果を決定しています。
HTTPSはSEOの小手先の施策というより、
現在のWebサイトに必要な基本的なセキュリティ要件
と考えるほうがよいでしょう。
HTTPからHTTPSへ変更するときのSEO上の注意点
HTTPからHTTPSへ移行すると、URLが変わります。
そのため適切な移行設定が重要です。
Google Search Centralでは、HTTPからHTTPSへの移行もURL変更を伴うサイト移転として扱っています。
代表的な対応には、
- HTTP URLから対応するHTTPS URLへリダイレクトする
- canonicalをHTTPSへ統一する
- XMLサイトマップをHTTPS URLへ更新する
- 内部リンクをHTTPSへ更新する
- robots.txtやnoindex設定を確認する
- HTTPSページが正常にクロールできることを確認する
などがあります。
HTTPからHTTPSへのリダイレクトは必要?
通常は必要です。
たとえば、
http://example.com/page
へアクセスした人を、
https://example.com/page
へリダイレクトします。
これによって利用者や検索エンジンをHTTPS版へ誘導できます。
Googleも、HTTP版からHTTPS版へのリダイレクトを、HTTPS版をcanonicalとして認識させるための強いシグナルの一つとしています。
「Mixed Content」とは?
HTTPSページへ移行したときに注意したいのが、
Mixed Content(混在コンテンツ)
です。
Webページ本体はHTTPSなのに、ページ内の、
- 画像
- JavaScript
- CSS
- iframe
などをHTTPで読み込もうとする状態です。
特にスクリプトなどの危険性が高いHTTPリソースは、ブラウザによってブロックされることがあります。
HTTPS化するときは、ページ本体だけでなく、サイト内の各リソースもHTTPSへ統一することが重要です。
「Secure Context」とHTTPSの関係
現在のWebブラウザでは、一部の高度なWeb APIを、
Secure Context
でなければ利用できないようにしています。
MDNも、HTTPSで提供されたページはSecure Contextとして扱われ、多くの強力なWeb機能が安全なコンテキストでのみ利用可能になると説明しています。
そのためHTTPSは単なる暗号化だけでなく、現代のWeb機能を利用するための基盤にもなっています。
「HSTS」とは?
HTTPS運用で登場する仕組みに、
HSTS
があります。
HSTSは、
HTTP Strict Transport Security
の略です。
Webサイトがブラウザに対して、
「今後、このサイトへはHTTPSでのみ接続してください」
と指示する仕組みです。
HTTPS運用が安定したサイトでは、HTTPへの意図しない接続を防止する対策として利用できます。
ただし設定を誤るとサイトへアクセスできなくなる場合があるため、導入時には十分な確認が必要です。
HTTPのサイトを見るだけでも危険?
HTTPサイトへアクセスしただけで、必ず被害が発生するわけではありません。
しかし信頼できないネットワーク上では、通信内容を盗聴・改ざんされる余地がHTTPSより大きくなります。
特に、
- パスワード
- クレジットカード情報
- 個人情報
- 問い合わせ内容
などをHTTPページから送信することは避けるべきです。
現在のWebサイトでは、情報入力ページだけでなくサイト全体をHTTPS化することが基本です。
「HTTP・HTTPS」で迷ったときの3秒判定
| こんな場合 | 答え |
|---|---|
| Web上でデータをやり取りする基本プロトコル | HTTP |
| HTTP通信をTLSで保護する | HTTPS |
| URLがhttp://で始まる | HTTP |
| URLがhttps://で始まる | HTTPS |
| 既定ポート80 | HTTP |
| 既定ポート443 | HTTPS |
| 通信内容を暗号化して保護 | HTTPS |
| Webサイトで現在基本的に選ぶ | HTTPS |
最も簡単に覚えるなら、
HTTP=「Web通信のルール」
HTTPS=「安全に保護されたHTTP」
です。
「HTTP」を使った例文
- ブラウザがサーバーへHTTPリクエストを送る。
- HTTPレスポンスとしてHTMLが返ってくる。
- HTTPはステートレスなプロトコルである。
- 古いHTTP URLからHTTPSへリダイレクトする。
- Web APIがHTTPの仕組みを利用してデータを送受信する。
「HTTPS」を使った例文
- Webサイト全体をHTTPSで配信する。
- HTTPSによって通信内容を保護する。
- フォームから個人情報をHTTPSで送信する。
- HTTP版からHTTPS版へリダイレクトする。
- 証明書を設定してHTTPS接続を有効にする。
具体例で比較:ログインページ
利用者がログイン画面へ、
- メールアドレス
- パスワード
を入力するとします。
HTTPのまま送信すると、通信経路上で情報が保護されません。
HTTPSであればTLSによって通信が暗号化され、単純な盗聴からパスワードなどを保護できます。
このような認証情報を扱うページでは、HTTPSが必須と考えるべきです。
具体例で比較:普通の記事ページ
「入力フォームがないブログ記事ならHTTPでもよいのでは?」と思うかもしれません。
しかしHTTP通信は、受信するWebページ自体を第三者に改ざんされる可能性があります。
たとえば通信途中で、
- 広告を追加する
- リンクを書き換える
- 悪意あるスクリプトを挿入する
といった攻撃を受ける余地があります。
そのため、入力フォームがないページも含めてサイト全体をHTTPS化することが基本です。
よくある間違い1:「HTTPSはHTTPとは別のWebプロトコル」と思う
HTTPSはHTTPと無関係な別物ではありません。
HTTPによる通信をTLSで安全に保護したものです。
よくある間違い2:「HTTPSならサイトの運営者も必ず信用できる」と思う
HTTPSは通信経路を保護しますが、サイト運営者の信頼性や商品内容まで保証するものではありません。
よくある間違い3:「HTTPSではSSLを使っている」と思う
現在のHTTPSで利用されるのは基本的にTLSです。
SSLという名称は「SSL証明書」「SSL化」などの慣用表現として残っています。
よくある間違い4:「httpとhttpsは同じURL」と思う
スキームが違うため、厳密には別URL・別オリジンです。
HTTPS移行時にはリダイレクトやcanonical設定などが重要になります。
よくある間違い5:「HTTPSならパスワードは絶対に盗まれない」と思う
HTTPSは通信経路を保護しますが、フィッシング、マルウェア、サービス側の漏えいなどは別の問題です。
よくある間違い6:「HTTP/3とHTTPSはどちらかを選ぶ」と思う
HTTP/3はHTTPの通信方式・世代で、HTTPSはHTTP通信が安全に保護されていることを示します。
HTTP/3ではQUICにTLS 1.3の機能が組み込まれ、安全な通信が提供されます。
よくある間違い7:「HTTPSに変更すればSEO順位が必ず上がる」と思う
HTTPSはGoogleも推奨するWebの基本的なセキュリティ要件ですが、検索順位はHTTPSだけで決まるわけではありません。
HTTPS化ではSEO目的だけでなく、利用者とWebサイトの安全性を高めることを第一に考えることが重要です。
「HTTP」と「HTTPS」に関するよくある質問
Q1. 「HTTP」と「HTTPS」の一番簡単な違いは?
HTTPはWeb上で情報を送受信するためのプロトコル、HTTPSはそのHTTP通信をTLSで安全に保護したものです。
Q2. HTTPSの「S」は何ですか?
一般に「Secure」を表します。
HTTPSはHypertext Transfer Protocol Secureの略です。
Q3. HTTPSではSSLとTLSのどちらを使いますか?
現在はTLSを利用します。
SSLはTLSの前身となった旧規格で、安全な現在のWeb通信には使用しません。
Q4. HTTPとHTTPSではポート番号が違いますか?
代表的な既定ポートは、HTTPが80、HTTPSが443です。
Q5. HTTPSなら通信内容は誰にも読まれませんか?
通信経路上の第三者が内容を読み取ることを大幅に難しくできます。
ただし通信の端点である利用者の端末やWebサービス側では、処理のためにデータを扱う必要があります。
HTTPSがすべての情報漏えいリスクをなくすわけではありません。
Q6. HTTPSなら詐欺サイトではありませんか?
いいえ。
詐欺目的のサイトでもHTTPSを利用できます。
HTTPSは通信の安全性を高めるもので、サイト運営者そのものの信用を保証するものではありません。
Q7. HTTPからHTTPSにするとURLは変わりますか?
はい。
http://とhttps://ではスキームが異なるため、別URLとして扱われます。
移行時にはHTTPからHTTPSへのリダイレクトなどを適切に設定します。
Q8. HTTPSはSEOに必要ですか?
GoogleはHTTPSの利用を推奨し、同等のHTTP版・HTTPS版が存在する場合は原則としてHTTPSをcanonicalとして優先します。
ただしHTTPSだけで検索順位が決まるわけではありません。
Q9. HTTP/2やHTTP/3ならHTTPSは不要ですか?
いいえ。
HTTPのバージョンと、通信が安全に保護されているかは別の観点です。
現在のブラウザ環境ではHTTP/2はHTTPSと組み合わせて利用されることが一般的で、HTTP/3ではQUICにTLS 1.3の暗号機能が組み込まれています。
Q10. Webサイトを新しく作るならHTTPとHTTPSのどちら?
基本的にHTTPSです。
GoogleやMDNも、現在のWebサイトではHTTPSを利用することを推奨しています。
まとめ
「HTTP」と「HTTPS」は、どちらもWeb上のデータ通信に関係しますが、最大の違いは通信を安全に保護する仕組みの有無です。
| HTTP | HTTPS |
|---|---|
| Hypertext Transfer Protocol | Hypertext Transfer Protocol Secure |
| Web通信の基本プロトコル | 安全に保護されたHTTP通信 |
| 通常はTLSによる保護なし | TLSで暗号化・完全性・認証を提供 |
| http:// | https:// |
| 既定ポート80 | 既定ポート443 |
| 現在の一般サイトでは推奨されない | 現在のWebでは基本 |
最も簡単な覚え方は、
HTTP=「Webでデータをやり取りするためのルール」
HTTPS=「その通信をTLSで安全にしたもの」
です。
HTTPSではTLSによって、
- 通信内容の暗号化
- 通信内容の完全性保護
- 接続先サーバーの認証
を実現します。
そのため、ログイン情報や個人情報を入力するページだけでなく、現在はWebサイト全体をHTTPSで提供することが基本です。
ただし、
HTTPS=Webサイトの内容そのものが安全
HTTPS=詐欺サイトではない
HTTPS=パスワードが絶対に盗まれない
という意味ではありません。
HTTPSが保護する中心は、
ブラウザとサーバーの間の通信
です。
また、HTTPからHTTPSへ変更すると、http://とhttps://ではURL・オリジンが異なるため、Webサイト運営では、
- HTTPからHTTPSへのリダイレクト
- canonicalの統一
- 内部リンクの更新
- サイトマップの更新
- Mixed Contentの解消
なども重要になります。
「HTTP」「HTTPS」「TLS」を混同しないためには、
HTTP=Web通信そのもの
TLS=通信を安全にする技術
HTTPS=TLSで保護されたHTTP
と整理すると理解しやすいでしょう。
参考リンク・出典
-
IETF / RFC Editor「RFC 9110: HTTP Semantics」
― HTTPをステートレスなアプリケーション層プロトコルとして定義し、http・https URI scheme、既定ポート80・443、httpsにおけるサーバー認証・機密性・完全性などを規定 -
MDN Web Docs「HTTP」
― HTTPの基本、httpスキーム、ステートレスという性質、ブラウザ・サーバー間やAPIでの利用について解説 -
MDN Web Docs「HTTPS」
― HTTPSをHTTPの暗号化されたバージョンとして説明し、TLSによってクライアント・サーバー間の通信を保護する仕組みを解説 -
MDN Web Docs「トランスポート層セキュリティ(TLS)」
― TLSによる暗号化・完全性・認証、HTTPS、TLSハンドシェイク、Mixed Content等を解説 -
IETF / RFC Editor「RFC 9113: HTTP/2」
― HTTP/2のバイナリフレーミング、多重化、ヘッダー圧縮など、HTTP/1.1より効率的な通信方式を規定 -
IETF / RFC Editor「RFC 9114: HTTP/3」
― HTTP/3をQUIC上でHTTP semanticsを利用する方式として規定。QUICにTLS 1.3が組み込まれ、通信の機密性・完全性等が提供されることを説明 -
Google 検索セントラル「サイト運用 SEO メンテナンス ガイド」
― ユーザーとサイトのセキュリティ向上のため、HTTPではなくHTTPSを利用することを推奨 -
Google Search Central「How to specify a canonical with rel="canonical" and other methods」
― HTTP版とHTTPS版が存在する場合のcanonical処理について、Googleが原則としてHTTPSを優先することを説明 -
Google Search Central「Site Moves and Migrations」
― HTTPからHTTPSへの変更を含むURL移行時のリダイレクト、サイトマップ、robots.txt、クロールエラー等の注意点を解説
※本記事では一般ユーザー・Webサイト運営者向けに、「HTTP=Web通信の基本プロトコル」「HTTPS=TLSによって安全に保護されたHTTP」と整理しています。
※HTTPSは通信経路を保護する仕組みであり、Webサイト運営者の信用、掲載情報の正確性、商品の安全性、マルウェアの不存在などを保証するものではありません。
※http://とhttps://はスキームが異なるため、厳密には別のURL・オリジンです。WebサイトをHTTPからHTTPSへ移行する場合は、リダイレクト・canonical・内部リンク・サイトマップ等を適切に更新してください。
※HTTP/1.1・HTTP/2・HTTP/3はHTTPの通信方式・世代を表す言葉であり、「HTTPかHTTPSか」とは別の観点です。特にHTTP/3はQUIC上で動作し、QUICにTLS 1.3の暗号機能が統合されています。
※HTTP・HTTPS・TLS・ブラウザのセキュリティ仕様は更新される場合があります。実際のサーバー設定やHTTPS移行では、IETF、MDN、Google Search Central、利用するサーバー事業者等の最新情報を確認してください。
