サイトがHTTPSになっていないときの直し方｜証明書・転送・表示を順に確認

• サイトがHTTPSになっていないときは、まずhttps://で警告なしに開ける状態にし、それを確かめてからhttp://をhttps://へ転送します
• SiteKensaの診断に出る「HTTPSに転送されていません」は、http://で開くとhttps://へ移らず、http://のページが表示される状態です
• https://で開けないサイトで先に転送を入れると訪問者に警告画面やエラーが表示されます
• 「http:// では開けません (https:// では開けます)」は参考の表示です。http://で始まるリンクやブックマークから来る人を受けなくてよいなら、直さなくてかまいません

出てくる用語

すでにご存じの語は読み飛ばしてください。

http:// と https:// の違い、https:// にする理由

Webページは、HTTPという決まりに沿って、訪問者のブラウザとサイトのサーバーのあいだでやり取りされます。アドレスの先頭の http:// と https:// は、このやり取りを中身を守った接続で行うかどうかを表しています。

https:// の接続では、接続先のサーバーがそのドメイン名の持ち主に代わって応答しているものかが確かめられます。やり取りの全体は途中で読まれないように守られ、書き換えられたら分かるようになっています。HTTPの仕様である RFC 9110 セクション4.2.2 は、これを「the server has been authenticated as acting on behalf of the identified authority and all HTTP communication with that server has confidentiality and integrity protection」と定めています。接続先が本物のサーバーかの確認には証明書の検証が使われ、途中に入った攻撃者がサーバーになりすますのを防ぎます。RFC 9110 セクション4.3.4 の原文は「Certificate verification is used to prevent server impersonation」です。http:// を定めた RFC 9110 セクション4.2.1 には、サーバーの確認と中身を守ることの条件がありません。

http:// と https:// の両方がある理由

HTTPは、はじめ暗号化せずに使われていました。その後、大事な情報のやり取りにHTTPが使われることが増え、TLSという通信を守る仕組みの上でHTTPを使うやり方がまとめられました。そのアドレスの先頭が https:// です。http:// も使える方式として残っているので、http:// でも開けるサイトでは、http:// で来た人を https:// へ移す転送を入れます。

このやり方をまとめた RFC 2818 は、セクション1でこの経緯を「originally used in the clear on the Internet. However, increased use of HTTP for sensitive applications has required security measures.」と書き、RFC 2818 セクション2.4 で https:// のアドレスを http:// と区別すると定めています。

サイトを https:// にする理由

Chromeのヘルプは、アドレス欄に「情報、または保護されていない通信」のアイコンが出るサイトについて「サイトはプライベート接続を使用していません。このサイトとの間で送受信される情報は、何者かに見られる、または変更される可能性があります。」と説明し、解決するには「サイト所有者が HTTPS を使用してサイトとお客様のデータを保護する必要があります」と書いています（Chrome ヘルプ）。同じヘルプによると、Chromeで「常に安全な接続を使用する」をオンにしている人がHTTPSに対応していないサイトを開くと、「接続は安全ではありません」という警告が出ます。

フォームに入力された内容やページの中身を途中で見られたり書き換えられたりしないようにするのが、https:// にする目的です。

ここからは、サイトを実際に https:// にする手順です。まず https:// で警告なしに開けるようにし、次に http:// を開いた訪問者を https:// へ移す転送を入れます。最後に、ページの中に http:// のまま残った画像やスクリプトがあるとブラウザが読み込みを止めることがあるので、それを確かめます。

「HTTPSに転送されていません」と出たら、証明書の項目を見てください

SiteKensaの診断でドメインを調べ、http://からhttps://へ転送する設定が無いと、次のように「HTTPSに転送されていません」と出ます。

診断の結果には、Webサイトの項目と並んで証明書の項目が出ます。証明書の項目は、http://のアドレスから転送をたどって最後に着いたホスト名にhttps://で接続したときの結果です。下の表を上から順に見て、最初に当てはまる行へ進んでください。

診断を使わずにこの記事へ来た方は、https://で開けるかの確かめ方から始めてください。

Webサイトの項目に「http:// では開けません (https:// では開けます)」と出ているときは、この表ではなく「http:// では開けません」と出たときの節を読んでください。

ステップ 1/3：https:// で開けるようにしてください

同じドメイン名でも、http://とhttps://は別々に扱われます。http://の既定は80番、https://の既定は443番のポートで、https://で出すページはhttp://のページと同じものとはみなされません。RFC 9110 セクション4.2.1、セクション4.2.2 はこれを「They are distinct origins with separate namespaces」(別々の発信元で、名前の範囲も別々) と書いています。http://で表示できているサイトでも、https://で開けるとは限りません。

macOSかLinuxのターミナルで次を実行するとhttps://で開いたときの応答の番号が出ます。example.com を自分のドメイン名に置き換えてください。

$ curl -sS -o /dev/null --connect-timeout 10 -w "%{http_code}\n" https://example.com/
200

200 が出れば、https://での接続はできています。https://の側で既に別のアドレスへ転送しているサイトでは、301 などの3で始まる番号が出ます。証明書に問題があると次のように curl: (60) で始まるエラーが出て、番号は 000 になります。

$ curl -sS -o /dev/null -w "%{http_code}\n" https://self-signed.badssl.com/
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html
...
000

https://の接続 (443番) を受け付けていないサーバーでは curl: (7) Failed to connect to で始まるエラーが、10秒待っても接続できないときは curl: (28) Failed to connect to で始まるエラーが出ます。番号はどちらも 000 です。どの出力も2026年10月4日にmacOSのcurl 8.7.1で実行したものです。Windowsをお使いなら、このコマンドの代わりに診断の証明書の項目と下のブラウザでの確かめで判断してください。

コマンドで 200 などが出たとき、またはコマンドを使わないときは、ブラウザでhttps://で始まるアドレスを開いてください。警告画面が出ずにいつものページが表示されれば、転送の作業へ進めます。

警告画面が出たときは curl: (60) と同じ扱いです。ページが開けないと出たときは、https:// で開けないときへ進んでください。

WordPressを使っていて、警告は出ないのに表示が崩れているときは、転送の作業へ進んでください。転送の節のWordPressの手順とステップ3の読み込みの確かめ方で直します。転送の前に、読み込みの確かめ方でボタンやフォームが動くかも見ておけば、訪問者を崩れたページへ送らずに済みます。

名刺やほかのサイトからのリンクに、wwwあり・wwwなしの両方のアドレスが使われているなら、両方のアドレスで確かめます。

https:// で開けないとき

curl: (7) か curl: (28) が出るとき、または診断に「このサイトはHTTPSで応答しませんでした」と出るときは、https://での接続ができていません。サーバーでSSL証明書が有効になっているかを確かめてください。443番への通信が通っているかは、サーバーの管理会社か契約先に問い合わせて確かめてください。証明書を有効にする場所は、使っているサーバーやサービスの種類で決まります。

• レンタルサーバーなら、管理画面で証明書を申し込めるかを契約先の案内で確かめてください
• 自分で管理しているサーバーなら認証局の手順で証明書を取得してサーバーに設定してください
• CDNを通しているならCDNの側でも証明書の設定が要ることがあります。CDNの案内で確かめてください

申し込みや設定のあとは、契約先の案内にある反映までの時間の目安を待ってから、https://で開けるかの確かめ方と診断でもう一度確かめてください。200 が出てブラウザで警告なしに開ければ、転送の作業へ進めます。目安の時間が過ぎても開けないままなら、コマンドの出力と診断の結果を添えて契約先に問い合わせてください。

curl: (60) や警告画面が出るとき

curl: (60) が出るときやブラウザに警告画面が出るときは、サーバーに証明書は入っているものの、ブラウザがその証明書を信頼していない状態です。自分で証明書を申し込んだ覚えがないなら、上の申し込みから始めてください。診断の証明書の項目に「有効期限が切れています」と出ていればSSL証明書の期限切れの対処、それ以外の表示ならSSL証明書の名前不一致・信頼エラーの直し方で直します。直したら、ステップ1の確かめ方に戻ってください。

ステップ 2/3：http:// を https:// へ転送してください

https://で警告なしに開けることを確かめてから、http://を開いた訪問者をhttps://へ移す設定を入れます。順序を逆にすると訪問者のブラウザに警告画面やエラーが表示されます。

Googleの検索セントラルは、HTTPからHTTPSへのURLの変更をサイト移転の1つに挙げ、可能であれば301や308のような恒久的な転送を使うことを勧めています（URL の変更を伴うサイト移転）。この記事のApacheとnginxの設定例は301を返します。

転送を入れる場所は、契約しているサーバーの管理画面に転送の設定があるかどうかとサーバーで動いているソフトで決まります。分からないときは、契約先の案内かサイトを作った会社に確かめてください。どの方法でも、書き換える前に今の設定を控えてください。

WordPressを使っているときは、上のどれかで転送を入れたうえでWordPressの管理画面にあるアドレスの設定も変えます。

変える前に今の設定を控えてください

作業のあとで問題が起きたときにすぐ戻せるよう、次のものを控えておきます。

• .htaccessやnginxの設定ファイルを書き換えるなら、今のファイルを別の名前 (.htaccess.bak など) で保存しておきます
• 管理画面の設定を変えるなら、変える前の画面を撮っておきます
• WordPressを使っているなら、管理画面の「設定」の「一般」にある「WordPress アドレス (URL)」と「サイトアドレス (URL)」の今の値を控えておきます

管理画面に転送の設定があるとき

レンタルサーバーには、管理画面で転送を入れられるものがあります。例としてエックスサーバーの公式マニュアルは、独自SSLを設定しただけではhttps://へ転送されないと書き、転送の入れ方として.htaccessに書く方法とドメインの設定で「HTTPSに転送する」を選ぶ方法を挙げています（エックスサーバー マニュアル）。ほかのレンタルサーバーでは、契約先の案内で転送の設定があるかを確かめてください。管理画面に転送の設定があればそれを使い、設定が見当たらなければ.htaccess に書くときへ進んでください。管理画面の転送は301とは限りません。さくらのレンタルサーバーのサポート情報は、HTTPS転送設定を含む転送をすべて302で行うと書いています（ドメインリダイレクトを設定したい）。302は一時的な移転を示す番号で、RFC 9110 セクション15.4.3 は、「the target resource resides temporarily under a different URI」と定めています。301にしたいなら、.htaccessで301を返せるかを契約先の案内で確かめてください。

.htaccess に書くとき (Apache)

.htaccessを使えるか、ファイルがどこにあり何で編集するかは、先に契約先の案内で確かめてください。そのうえでファイルの先頭に次の3行を足します。既にある設定は、WordPressが書いた RewriteEngine On を含む記述も消さずに残し、足す3行の1行目の RewriteEngine On もそのまま入れてかまいません。WordPressが書く記述の上にこの3行を足した.htaccessで301が返ることをApache 2.4.69で確かめました（2026年10月4日）。

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

この設定は、http://で受けた接続をホスト名もその後ろの部分 (/blog/?p=1 など) も同じままのhttps://のアドレスへ301で移します。Apache 2.4.69 で実行し、後ろの部分が残ることを確かめました（2026年10月4日）。次の出力は筆者の手元で確かめたときの記録で、読者が打つコマンドとは違います。自分のサイトでは、後の転送が入ったかを確かめてくださいのコマンドを使います。

$ curl -sS -o /dev/null -D - -H "Host: example.jp" "http://127.0.0.1:18080/blog/?p=1" | grep -i -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
Location: https://example.jp/blog/?p=1

nginx に書くとき

nginxでは、設定ファイルの中で listen 80; と書かれた server { } のまとまりに return を書きます。example.jp と www.example.jp は自分のホスト名に置き換えてください。

server {
    listen 80;
    server_name example.jp www.example.jp;
    return 301 https://$host$request_uri;
}

return は301や308などの番号と転送先のURLを指定できます（nginx の return）。nginx 1.30.5 で実行し、上のApacheと同じ 301 と Location: https://example.jp/blog/?p=1 が返ることを確かめました（2026年10月4日）。

CDNや負荷分散装置がhttps://を受けているとき

TLS終端がCDNや負荷分散装置にあり、そこからサーバーへはhttp://で届く構成では、上の.htaccessの条件はサーバーに届いた接続がhttp://かどうかだけを見ます。サーバーに届いた接続がhttp://である限り301を返すので、訪問者がhttps://で開いても転送を繰り返すことがあります。手前の装置が「訪問者はhttps://で来た」という情報 (X-Forwarded-Proto: https) を付けて送ってもこの3行は301を返すことをApacheで確かめました。この構成では、CDNや負荷分散装置の側にある転送の設定を使ってください。

WordPressを使っているとき

WordPressの管理画面には、サイトのアドレスを設定する項目があります。転送を入れたら、管理画面の「設定」の「一般」にある「WordPress アドレス (URL)」と「サイトアドレス (URL)」をhttps://で始まる形に変えてください。保存する前に、http を https に変えた以外に文字が変わっていないかを見てください。上のエックスサーバーのマニュアルも、WordPressではこの変更を手順に入れています。

転送が入ったかを確かめてください

ターミナルで次のコマンドを実行し、http://で開いたときの応答を見ます。example.com を自分のドメイン名に置き換えてください。転送が無いときは3で始まらない番号が返り、Location は出ません。下は転送が無い example.com の例で、200 が返っています。

$ curl -sS -o /dev/null -D - http://example.com/ | grep -i -E "^(HTTP|location)"
HTTP/1.1 200 OK

転送が入っていれば 301 や 308 などの3で始まる番号 (管理画面の転送では 302 のこともあります) とhttps://で始まる Location が返ります。次は本サイトで実行した出力です。

$ curl -sS -o /dev/null -D - "http://sitekensa.com/blog/?a=1" | grep -i -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
Location: https://sitekensa.com/blog/?a=1

どちらも2026年10月4日に実行しました。Location がhttps://で始まり、開いたアドレスのドメイン名より後ろの部分 (/blog/?a=1) が残っていれば、1回目の転送は入っています。転送の先まで正しく着くかは、-L を付けて最後に着いたアドレスと番号を見ます。

$ curl -sS -o /dev/null -L -w "%{http_code} %{url_effective}\n" "http://sitekensa.com/blog/?a=1"
200 https://sitekensa.com/blog/?a=1

最後が 200 で、着いたアドレスがhttps://で始まり、意図したホスト名になっていれば合格です (2026年10月4日に実行)。ブラウザは前に受け取った転送を覚えていて、サーバーの今の設定と違う動きをすることがあります。確かめるときはcurlか診断を使ってください。

ステップ 3/3：https:// のページで読み込みが止まっていないか確かめてください

https://で開いたページが、画像やスクリプト (ページの中で動くJavaScriptなどのプログラム) をhttp://で読み込もうとしているとブラウザはそれを止めることがあります。スクリプトは利用者が許可しない限り読み込まれません。画像はブラウザがhttps://に切り替えて読み込むことがあり、そうでなければ止められます（W3C の Mixed Content の Key Concepts and Terminology の節。2023年2月23日の勧告候補の草案）。ページが崩れていないか、ボタンやフォームが動くかをhttps://で開いて確かめてください。

Chromeでは開発者ツールのコンソールで確かめられます。コンソールは、macOSでは Command+Option+J、WindowsではCtrl+Shift+Jで開きます（Chrome DevTools を開く）。コンソールを開けないときは、上のページの崩れとボタンやフォームの動きの確かめで代えてください。Chromeのもとになっているブラウザの Chromium 151 でhttp://のスクリプトと画像を持つページを開くとコンソールに Mixed Content: で始まる次の表示が出ました（2026年10月4日）。

Mixed Content: The page at 'https://localhost:18443/' was loaded over HTTPS, but requested an insecure script 'http://example.com/app.js'. This request has been blocked; the content must be served over HTTPS.
Mixed Content: The page at 'https://localhost:18443/' was loaded over HTTPS, but requested an insecure element 'http://example.com/logo.png'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html

表示に出たアドレスを読み込んでいる箇所を探し、https://に書き換えてください。WordPressなら投稿の本文やテーマ・プラグインの設定、それ以外ならページのHTMLファイルが探す先になります。どこで読み込んでいるか分からないときは、コンソールの表示を添えて、サイトの制作を任せた会社かテーマやプラグインの提供元に確かめてください。読み込み先がhttps://に対応していないときは、その部品を別のものに替えるか外すことになります。

トップページ以外も確かめてください

トップページで合格してもほかのページが同じとは限りません。よく見られるページ、フォームのあるページ、画像の多いページをいくつか選び、それぞれのページで、ステップ2の転送を確かめるcurlとブラウザのコンソールを確かめてください。

あわせて、検索エンジンに伝えるアドレスもhttps://に揃えます。Googleのサイト移転の文書は、新しいサイトの内部リンクを新しいURLに変えること、移転先の各URLに自身を参照する rel="canonical" を置くこと、新しいURLを含むサイトマップを用意することを挙げています（URL の変更を伴うサイト移転）。ページの中のリンク、canonical、サイトマップにhttp://のアドレスが残っていないかも見てください。Search Consoleを使っているなら同じ文書の手順でサイトマップを送信してください。

診断をもう一度実行してください

SiteKensaの診断で同じドメインを調べ、「HTTPSに転送されていません」が消えたことを確かめてください。

転送が入ると、診断はhttps://のページについて、サーバーがページと一緒にブラウザへ送るセキュリティの指示 (ヘッダー) も見るようになります。そのため「HSTS (Strict-Transport-Security) が設定されていません」などの項目が新しく出ることがあります。これはHTTPS化がうまくいかなかったという意味ではありません。設定するかどうかは、診断のその項目の説明を読んで決めてください。

うまくいかないときの戻し方

転送を入れたあとに次のことが起きたら、転送の設定を外して元に戻してください。

• https://のページで警告画面が出る
• 転送が何度も繰り返されて、ページが開かない
• 表示が崩れたり、フォームが動かなくなったりして、その場で直す方法が分からない

外したあとも、一度301を受け取ったブラウザは、しばらくhttps://へ移り続けることがあります。ブラウザが前の転送を覚えておくことがあるためで、RFC 9110 セクション15.4.2 はこれを「A 301 response is heuristically cacheable」と書いています。戻せたかどうかはcurlで見てください。原因を直したら、改めてhttps://で開けるかを確かめるところから進めます。

「http:// では開けません (https:// では開けます)」と出たとき

診断のWebサイトの項目にこの表示が出たときは、http://では接続できず、https://では開ける状態です。この場合も、診断はhttps://のページについてほかの項目を調べています。参考の表示なので、直すかどうかはhttp://のアドレスから来る人を受け付けたいかで決めてください。

http://の80番を閉じてhttps://だけで公開する構成は、ブラウザにhttps://だけで開くよう登録する一覧 (HSTSのプリロード一覧) の登録条件でも想定されています。この条件は、http://からhttps://への転送を「80番で受けている場合」に求めています（hstspreload.org の「Redirect from HTTP to HTTPS on the same host, if you are listening on port 80」）。

ブラウザがhttp://のリンクをhttps://に切り替えて開くことはあります。Chromeは、http://のリンクを自動でhttps://に切り替える変更を2023年にChrome 115で試験し、全員へ広げる予定だと告知していました（Chromium Blog）。どのブラウザでもそうなるとは限らないので、http://のアドレスから来る人を受け付けたいなら、これに頼らずに転送を入れてください。

http://のアドレスから来る人も受け付けたいなら、まずhttp://で接続できるようにし、そのうえでhttp://をhttps://へ転送する設定を入れてください。http://の接続は、80番を受けるサーバーの設定か通信を制限する設定 (ファイアウォールやクラウドの通信の許可設定) で止まっていることがあります。サーバーを管理している会社か契約先に、http://の接続 (80番) を受け付けているかを問い合わせてください。