httpをhttpsへ301リダイレクトする.htaccessの書き方
この記事の要点
- httpからhttpsへの転送は、元に戻す予定のない恒久移行なので301(恒久リダイレクト)を使う。恒久的な移動という意図を正確に伝えられるのが301
- Apacheなら.htaccessに3行書くだけ。ただし編集前のバックアップとSSL証明書の有効化が前提
- リダイレクトループ・500エラー・混合コンテンツが3大トラブル。原因と回避手順を具体的に解説
SSL証明書は入れたのに、http://で始まる古いURLでアクセスされてしまう。検索結果にはhttpのページが残ったまま。こんな状態でお困りではありませんか。
この記事では、httpからhttpsへ確実に転送するための.htaccessの書き方を、コピペで使えるコードとあわせて解説します。基本の3行から、wwwありなしの統一、リダイレクトループが起きたときの直し方まで、実際に手を動かして完了できるレベルでお伝えします。サーバーの専門知識がなくても、順番どおりに進めれば設定できる内容です。
Contents / 目次
結論。httpからhttpsは「301」で1回だけ転送する

ここで押さえておきたいのが「301」と「302」の違いです。301とは、そのURLが恒久的に移動したことを検索エンジンに伝えるステータスコードです。302は「一時的な移動」を意味します。httpsへの切り替えは元に戻す予定のない恒久移行です。恒久的な移動という意図を正確に伝えられるのは301なので、httpsへの切り替えでは301を選びます。
取り組むべきことを整理すると、次の3つに集約されます。
- SSL証明書を先に有効化する:証明書が入っていない状態でリダイレクトすると、サイトが表示できなくなります。転送設定の前に必ずhttpsで正常表示されることを確認します。
- .htaccessで301リダイレクトを1回だけ書く:httpで来たアクセスを、同じURLのhttps版へまとめて転送します。
- 転送後の後片付けをする:内部リンク・canonicalタグ・サイトマップをhttpsに更新し、混合コンテンツ(後述)を潰します。
この記事では、この3つを順番に、具体的なコードと確認手順まで落とし込んで解説していきます。まずは301と302、そして関連する用語の違いを表で整理しておきましょう。
| 用語 | 意味 | httpsへの移行での扱い |
|---|---|---|
| 301リダイレクト | 恒久的な移動を伝えるコード | これを使う(正解) |
| 302リダイレクト | 一時的な移動を伝えるコード | 恒久移行では使わない |
| HSTS | 次回以降ブラウザに常にhttpsで接続させる仕組み | 301と併用すると安全性が上がる |
| 混合コンテンツ | httpsページ内でhttpの画像やスクリプトを読む状態 | 鍵マークが出ない原因。要修正 |
| リダイレクトループ | 転送が無限に繰り返される不具合 | 設定ミスで発生。回避法は後述 |
常時SSL化そのものの必要性や費用感については常時SSL化の費用とは|B2Bサイトに不可欠な対策【2026年版】でも整理しています。
.htaccessでhttpをhttpsへリダイレクトする手順
ここからが本題です。実際の設定を、準備から順番に進めていきます。特別なツールは不要で、サーバーのファイル管理画面かFTPソフトがあれば完了できます。

ステップ1。SSL証明書が有効か確認し、.htaccessをバックアップする
最初にやるべきは、リダイレクトの前提を整えることです。まず、ブラウザのアドレスバーに手打ちで「https://あなたのドメイン」と入力し、エラーなく表示されるかを確認します。ここで証明書エラーが出るなら、リダイレクト設定はまだ入れてはいけません。先に証明書を有効化します。多くのレンタルサーバーでは、管理画面から無料SSL証明書を発行できます。発行できる証明書の種類や具体的な操作手順はサーバー会社ごとに異なるため、契約中のサーバー会社の公式マニュアルを確認してください。
ポイント。.htaccessは先頭がドットで始まる「隠しファイル」です。サーバーのファイル管理画面(cPanelなど)で見当たらないときは、設定で「隠しファイルを表示する」をオンにすると出てきます。ファイルがなければ、ルートディレクトリ(public_htmlなど、サイトの一番上の階層)に新規作成して構いません。
ステップ2。基本の3行をコピペで書き込む
準備ができたら、.htaccessの先頭に次の3行を追加します。これがhttpからhttpsへ転送する、もっとも基本的なコードです。WordPressを使っている場合は、必ず「# BEGIN WordPress」と書かれた行より上に貼り付けてください。
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
それぞれの行が何をしているかを、かんたんに説明します。
- 1行目 RewriteEngine On:「これから転送ルールを使いますよ」という宣言です。
- 2行目 RewriteCond %{HTTPS} off:「接続がhttpsではないとき」という条件を意味します。
- 3行目 RewriteRule …:実際の転送です。アクセスされたホスト名(%{HTTP_HOST})とページのパス(%{REQUEST_URI})をそのまま引き継いで、https版へ飛ばします。末尾の[R=301,L]の「R=301」が301リダイレクトの指定、「L」はここでルールを打ち切るという意味です。
このコードはドメイン名を直接書いていないので、どのサイトにもそのまま使えるのが利点です。書き込んで保存したら、いったんブラウザのキャッシュを消すか、シークレットモード(プライベートウィンドウ)で「http://あなたのドメイン」にアクセスしてみてください。自動でhttpsに切り替われば成功です。
ステップ3。wwwのありなしも統一したい場合
「www.example.com」と「example.com」の両方で同じサイトが開ける状態は、訪問者にとってもURLが2種類あるように見え、紛らわしくなります。httpsへの転送と同時に、wwwのありなしも1つに寄せておくのがおすすめです。ここで大事なのは、httpsとwwwを別々の行で2段階に転送すると、リダイレクトが2回連続する「チェーン」になってしまう点です。これを避けるため、1回で両方を満たすコードにします。
wwwありに統一したい場合(https://www.example.com に集約)は次のように書きます。example.comの部分は自分のドメインに置き換えてください。
# www.example.com の部分は自分のドメインに書き換える
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]
逆に、wwwなし(https://example.com)に統一したい場合は、条件の向きを変えます。
# example.com の部分は自分のドメインに書き換える
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]
[OR]は「どちらかの条件に当てはまれば」という意味です。「httpsでない、または、wwwのありなしが希望と違う」ときに、一発で正しいURLへ飛ばします。こうしておけば、どんな入り口から来ても最短1回の転送で目的地に着きます。
ステップ4。HSTSと混合コンテンツ対策を追加する(任意)
より強固にしたい場合は、HSTS(HTTP Strict Transport Security)を追加します。HSTSとは、一度アクセスしたブラウザに対して「次からは最初から必ずhttpsで来なさい」と指示する仕組みです。これがあると、そもそもhttpでの通信が発生しなくなり、リダイレクトの往復すら省けます。
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>
HSTSは一度ブラウザに記憶されると、指定した期間(上の例では約1年)はhttpに戻せなくなります。サイト全体が確実にhttpsで動くことを確認してから入れてください。サブドメインもすべてhttps化できている確信がない限り、安易にincludeSubDomainsやpreloadは付けないのが安全です。
あわせて、混合コンテンツを一括で無害化するヘッダーも足しておくと安心です。混合コンテンツとは、httpsのページの中で画像やCSSをhttpのまま読み込んでいる状態のことです。これがあると鍵マークが表示されません。次の1行は、ページ内のhttp読み込みをhttpsへ読み替えるよう指示するContent-Security-Policyのヘッダーです。ブラウザ側の対応状況によって挙動が変わるため、導入後は実際の表示を確認してください。
<IfModule mod_headers.c>
Header always set Content-Security-Policy "upgrade-insecure-requests"
</IfModule>
なお、ロードバランサーやCDN(アクセスを分散させる中継サーバー)をApacheの手前に置いている構成では、%{HTTPS} offがうまく効かないことがあります。その場合は、条件行を「RewriteCond %{HTTP:X-Forwarded-Proto} !https」に差し替える方法があります。構成によって挙動が変わるため、採用する前に契約中のサーバー会社の公式マニュアルで.htaccessの推奨記述を確認してください。
リダイレクト後にやると効果が定着する後片付け
リダイレクトを入れて終わり、ではありません。転送を設定した直後にきちんと後片付けをするかどうかで、検索評価の引き継ぎスピードと安定度が大きく変わります。

やることは主に4つです。
- 記事本文やメニューに残っているhttpの内部リンクをhttpsに書き換える
- 各ページのcanonicalタグ(正規URLを示すタグ)をhttpsに更新する
- sitemap.xml(サイトの構成を示すファイル)をhttps版に作り直す
- Google Search ConsoleにhttpsのURLを登録して、新しいサイトマップを送信する
特にSearch Consoleへの登録は、httpsへの移行をGoogleに素早く認識させるために効果的です。登録のやり方はSearch Consoleの登録手順|所有権確認とサイトマップ送信で手順を追って解説しているので、あわせて進めてください。httpとhttpsは別サイト扱いになるため、httpsのプロパティを新たに追加するのがポイントです。
成果として何が期待できるかというと、まず訪問者に「安全ではありません」という警告が出なくなります。これは離脱を防ぐうえで実利があります。加えて、301で評価をまとめることで、それまでhttpとhttpsに分散していた評価が1本に集約され、検索での見え方が安定します。
WordPressサイトなら、管理画面の設定でサイトアドレスをhttpsに変える方法もあります。常時SSL化を補助する専用プラグインも公開されているので、.htaccessの編集に不安がある場合は、利用するプラグインの公式ドキュメントで対応内容を確認したうえで選ぶとよいでしょう。表示速度の測り方は表示速度は自分で測って直せる|Core Web Vitals改善の3手で解説しています。
よくある失敗と回避法
.htaccessのリダイレクトは、うまくいかないときの症状がいくつかのパターンに分かれます。現場でよく見かける失敗を、原因と直し方をセットで挙げていきます。

失敗1。リダイレクトループ(ERR_TOO_MANY_REDIRECTS)が出る
転送が無限に繰り返され、ブラウザに「リダイレクトが多すぎます」というエラーが出るケースです。これは、転送ルールが二重に効いているときに起きます。よくある状況は、サーバー管理画面の「HTTPS強制」機能と.htaccessの記述が両方オンになっている、あるいはWordPressのプラグインと.htaccessが競合している、というものです。
回避法はシンプルで、転送ルールを1か所だけに絞ることです。次のどちらか一方に統一します。
- 管理画面のHTTPS強制を使うなら、.htaccessの3行は消す
- .htaccessで書くなら、管理画面の強制は切る
- CDNを使っている構成では、前述のX-Forwarded-Protoを使う書き方に変えると解決することが多い
テストするときは必ずブラウザのキャッシュを消すか、シークレットモードで確認してください。古い転送が記憶されていて、直したのに直っていないように見えることがあります。
失敗2。500 Internal Server Errorでサイトが真っ白になる
設定を保存した瞬間にサイト全体が表示されなくなるケースです。原因のほとんどは.htaccessの構文ミス、つまりスペルミスや余計な記号です。全角スペースが紛れ込んでいたり、コピペのときに行が途中で切れていたりすると起きます。
この失敗への備えこそが、ステップ1でお伝えしたバックアップです。500エラーが出たら、迷わず控えておいた元の.htaccessに戻してサイトを復旧させ、それから追加したコードを1文字ずつ見直します。この記事のコードをそのままコピーし直すのも確実な手です。焦って別の行をいじると傷口が広がるので、まず復旧、次に原因確認という順番を守ってください。
失敗3。そもそもリダイレクトが効かない
エラーは出ないのに、httpのままアクセスできてしまうケースです。考えられる原因は3つあります。
- サーバーでmod_rewrite(転送を担うApacheの機能)が無効になっている
- .htaccessを置く場所を間違えている
- SSL証明書がまだ正しく機能していない
確認の順番としては、まず「https://あなたのドメイン」が単体で開けるかをチェックします。ここでつまずくなら証明書の問題です。次に、.htaccessがサイトのルートディレクトリ(public_htmlなど一番上の階層)に置かれているかを確認します。サブフォルダに置いてもサイト全体には効きません。それでも動かない場合は、mod_rewriteが有効かどうかをサーバー会社に問い合わせるのが早いです。
失敗4。鍵マークが出ない(混合コンテンツ)
リダイレクトは効いているのに、アドレスバーに鍵マークが表示されず「保護されていない通信」と出るケースです。これは、ページ内の画像やCSS、JavaScriptの一部がhttpのまま読み込まれている混合コンテンツが原因です。ブラウザの検証機能(F12キーで開くコンソール)を見ると、どのファイルがhttpで読まれているか警告が出ています。
回避法は、本文やテンプレートにベタ書きされたhttpのURLをhttpsに書き換えることです。数が多くて手作業がつらいときは、ステップ4で紹介した「upgrade-insecure-requests」のヘッダーを入れると、まとめて読み替えられます。それでも警告が残る要素は、外部サービスの埋め込みなど自分で直せないものが多いので、その提供元がhttpsに対応しているかを確認します。
現場で見えた落とし穴と、任せどころの判断
ここまで手順を書いてきましたが、正直にお伝えすると、.htaccessのリダイレクトは「コードを貼れば終わり」で済まない場面があります。教科書には載りにくい、現場での妥協点と注意点をお話しします。
まず、レンタルサーバーによって作法が違います。大きく分けると次のような違いがあります。
- 共有サーバーでは、.htaccessでの記述が推奨されていることが多い
- ルート権限のあるサーバーでは、バーチャルホスト設定(サーバー本体の設定ファイル)で転送するほうが速い場合がある
ネットで見つけたコードをそのまま貼って動かないとき、実は自社の環境が想定と違っていた、というのはよくある話です。だからこそ、契約中のサーバー会社の公式マニュアルを一次情報として確認する習慣が大事になります。
次に、判断が要るのは「自分でやるか、任せるか」の線引きです。目安を整理しておきます。
- 自分でやってよい範囲:1ドメインの単純な常時SSL化。この記事の基本3行で完了するケースがほとんどです。
- 慎重に進めたい範囲:wwwの統一やHSTSを併用する場合。ループや戻せない設定のリスクがあるため、テスト環境で試してから本番に入れるのが理想です。
- プロに任せたほうが早い範囲:複数ドメイン・多言語・サブドメイン運用、旧URLから新URLへの1対1の個別リダイレクトが大量にある移行。ここは1つのミスが検索評価の大きな損失につながります。
コストの見落としもよくあります。証明書の更新期限を放置してサイトが止まる事故は、規模を問わず起きます。SSLやドメインの期限管理についてはドメイン・SSL期限切れでサイト停止を防ぐ中小企業の更新管理で具体的な体制づくりを解説しているので、設定が終わったら次はここを固めておくと安心です。
もう一つ、AIツールを使う場合の注意も添えておきます。最近はChatGPTやClaudeに「httpsへのリダイレクトの.htaccessを書いて」と頼めば、それらしいコードがすぐ返ってきます。ただし、AIが出すコードは自社のサーバー構成やwwwの方針を知らないまま書かれています。そのまま本番に貼る前に、必ずバックアップを取り、テスト環境やシークレットモードで挙動を確かめること。これはAIに任せていい部分(コードのたたき台づくり)と、人が必ずやるべき部分(自社環境での検証と最終判断)の線引きそのものです。
よくある質問
301と302、結局どっちを使えばいいですか
httpsへの切り替えは301を使ってください。301は「恒久的な移動」を意味し、そのURLが恒久的にhttpsへ移ったことを検索エンジンに伝えられます。302は「一時的な移動」を伝えるコードなので、元に戻す予定のない恒久移行では301が適切です。迷ったら301と覚えておけば問題ありません。
.htaccessを触るのが怖いです。プラグインでもいいですか
WordPressには常時SSL化を補助する専用プラグインもあり、.htaccessの編集に不安がある場合の選択肢になります。導入する際は、そのプラグインの公式ドキュメントで対応内容を確認してから選んでください。ただし表示速度を重視するなら.htaccessでの転送が軽量です。どちらの場合も、作業前のバックアップは必ず取っておきましょう。
設定したのにhttpのままアクセスできてしまいます
まずブラウザのキャッシュを消すか、シークレットモードで試してください。古い状態が記憶されているだけのことが多いです。それでも直らなければ、SSL証明書が有効か、.htaccessがサイトの一番上の階層に置かれているか、mod_rewriteが有効かの3点を順に確認します。
リダイレクトを入れたら鍵マークが出なくなりました
ページ内の画像やCSSがhttpのまま読み込まれる「混合コンテンツ」が原因です。ブラウザの検証機能(F12キーで開くコンソール)を見ると、どのファイルがhttpで読まれているか警告が出ています。ベタ書きされたhttpのURLをhttpsに書き換えるのが基本ですが、数が多い場合は.htaccessにupgrade-insecure-requestsのヘッダーを足すとまとめて読み替えられます。
まとめと、設定に不安があるときの相談先
httpからhttpsへの転送は、301リダイレクトを1回だけ、バックアップを取ってから.htaccessに書くのが基本です。あわせて内部リンクとサイトマップの更新まで済ませれば、検索評価を落とさず安全に常時SSL化を完了できます。
ここまで読んで、複数ドメインが絡む移行や、ループが直らずに時間だけが溶けていく状況に心当たりがある方は、無理に一人で抱えなくて大丈夫です。コレットラボのAILP・サイト制作の伴走支援では、こうしたサーバー設定の詰まりどころを一緒に整理し、自社で運用できる形まで並走します。現状を見せてもらうだけでも構いません。AI業務システム化の詳細はこちらから、気軽にお話を聞かせてください。
30分の無料相談
現状をお聞きし、優先順位を一緒に整理します。
予約する →