SSL

SSL/HTTPS設定手順｜無料SSLで常時HTTPS化する

著者: FreeHostBox Web Academy 編集部 公開日: 2026-09-08 最終更新: 2026-09-09

この記事でできること

無料SSLで 発行 → https表示 → 転送 → 混在解消まで完了し、警告なく公開できます。前提はSSL基礎解説記事の理解と、独自ドメイン設定手順記事やDNS解説記事で固めたDNS到達です。本記事では管理画面の操作順、転送設定の考え方、WordPress特有の注意点、失敗時の切り分けに絞って実践的に案内します。私たちでは無料SSLと独自ドメイン持ち込み対応をご用意していますので、ぜひ無料プランでお試しください。

本記事はLet’s Encryptの無料証明書に関する一般解説、サーバー・CMSの一般的なSSL設定手順、IETF RFCのTLS・リダイレクト関連仕様の考え方、MDN Web DocsのHTTPS・混合コンテンツ関連解説を参考にしています。管理画面の表示に従って進めてください。

手順全体像：発行から混在解消までの6段階

常時HTTPS化は次の6段階です。発行だけで終わりにせず、転送と混在解消まで含めて完了とします。

1. コントロールパネルでSSL（無料SSL）項目を開く
2. 対象ドメイン（wwwあり・なしを含む）を選んで発行・有効化する
3. https://あなたのURL/ で開けることを確認する（鍵マークの確認）
4. http:// → https:// への転送（リダイレクト）を有効化する
5. ページ内の http:// 残り（画像・CSS・JS・内部リンク）を https:// へ統一する
6. ブラウザ警告が出ないこと、www統一、主要ページの表示を最終確認する

段階ごとの確認観点を次の表に整理します。

注意: 管理画面の表示に従って進めてください。私たちでは無料SSLをご用意しています。詳しい操作名・上限は公式ページをご覧ください。

作業前のチェックリストを示します。バックアップと確認手段の準備が、失敗時の復旧時間を大きく左右します。

• DNSがサーバーへ向いており nslookup の考え方でIP一致を確認したか
• wwwあり・なしのどちらへ統一するか決めたか
• .htaccessや既存転送設定のバックアップを取ったか
• WordPress利用時はファイル・DBのバックアップを取ったか
• 確認用の複数ブラウザ・別端末の手段があるか
• 作業内容（変更前・変更後・時刻）を記録する用意があるか

ステップ1〜3：発行とhttps確認（対象選びが核心）

コントロールパネルでSSL項目を開き、対象ドメインを選びます。ここで最も重要なのが対象ホスト名の選択です。example.com と www.example.com は技術的には別名であり、両方運用する場合は両方を対象に含めます。片方だけ発行して片方を開くと警告になります。独自ドメイン追加直後はDNS浸透前のため、発行に失敗する場合は時間を置いて再実行します。連続実行より、DNS到達を確認してからの再試行が有効です。失敗時はエラーメッセージの要点（対象不一致か検証失敗か）を控え、次の仮説に活かします。

発行後は https://あなたのドメイン/ と https://www.あなたのドメイン/ の両方を直打ちし、鍵マークが出ること、証明書情報の対象が一致すること、有効期限が期待通りであることを確認します。http:// では見えるが https:// では見えない場合は、発行状態とhttps受け入れ設定を確認します。表示が古い場合は強制再読込・シークレットウィンドウ・別端末でキャッシュを切り分けます。運び方の基礎はHTTP解説記事で復習できます。鍵マークを押して証明書情報を開き、発行先と有効期限が想定通りであることまで確かめると、後の期限管理でも迷いません。

発行時の注意点を表に整理します。

発行から確認までの待ち時間管理も実務上の要点です。DNS変更直後の発行は検証失敗になりやすく、TTL分の待機を挟むと成功率が上がります。発行ボタンの連打は状態の把握を難しくするため、1回実行したら結果メモを取り、DNS到達の再確認を挟んでから次を試します。独自ドメイン追加と同日にSSLまで進める場合は、午前中にDNS・サーバー追加を済ませ、午後に発行・転送へ進む段取りが無理のない配分です。失敗時の切り戻し手順も先に決めておきます。.htaccess編集前には全体を複写して別名保存し、異常時は即座に元のファイルへ戻せる状態にします。WordPressのサイトURL変更前にはファイルとデータベースの両方を保全し、復旧手順（バックアップからの戻し方・URLの戻し方）を確認してから着手します。切り戻しの判断基準は、転送ループの発生、管理画面への接続不能、主要ページの表示崩壊であり、いずれかが起きたら原因究明より先に復旧を優先します。復旧後にメモを見返して原因を特定し、対策を施してから再挑戦する流れが、公開中サイトの事故を最小化します。

転送設定の考え方（.htaccess例の扱いと301統一）

発行後は http:// へのアクセスを https:// へ集約します。常時HTTPSが標準のため、httpへ戻す必要はありません。環境により管理画面のスイッチ一つで有効化できる場合と、手動追記が必要な場合があります。手動の一般例は次の考え方です（環境の案内を優先すること）。

# http → https への恒久転送の一般例（環境の案内を優先すること）
# 注意: 以下は考え方を示す例示であり、値をそのまま使わないこと。
# 既存の転送設定と重複させず、編集前に必ずバックアップを取ること。
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

上記はApache系の一般例であり、すべての環境でそのまま使える完成値ではありません。LiteSpeed・Nginx系や管理画面の自動転送がある環境では別の方法が正解になります。301（恒久的転送）で統一する考え方は共通ですが、転送ループや二重転送がないことを確認します。たとえば管理画面の転送と.htaccess転送を両方有効にするとループし、プラグイン側の転送まで重ねると三重になります。転送設定は1箇所に統一し、変更後は http:// 直打ちで https:// へ一発で飛ぶこと、www統一が保たれることを確認します。確認にはブラウザ直打ちのほか、リダイレクト経路を表示する確認道具の活用も有効です。道具上は転送回数・転送先URL・応答符号が列挙され、多重転送や意図しない飛び先の発見に役立ちます。確認観点は、http版とhttps版の両方、wwwあり・なしの両方、トップと下層ページの代表例であり、全経路が統一先へ集約されることを確かめます。外部に公開した短縮URLや二次元コードの飛び先も、移行後に一通り点検しておくと訪問者の迷子を防げます。編集前には.htaccess全体を複写して保管し、異常時は即座に戻せる状態にします。

転送確認のチェックリストを示します。

• http://example.com が統一先の https:// へ飛ぶか
• http://www.example.com も統一先へ集約されるか
• 転送が1回で終わりループ・多重になっていないか
• 主要ページ・投稿ページでも転送が保たれるか
• 既存の短縮URL・SNS投稿の飛び先に問題がないか

WordPressの注意点：サイトURL・置換・キャッシュ

WordPressでhttps化する場合は、サーバー側の発行・転送に加えてCMS内の3点対応が必要です。詳しい設置手順はWordPress始め方記事と合わせて確認してください。

• 管理画面のサイトURLを https:// へ変更する: 設定のサイトアドレス・WordPressアドレスをhttpsへ統一します。変更前にバックアップを取り、変更後は再ログインして表示を確認します。変更直後に入れなくなる例は、転送重複やURL綴り誤りが原因であることが多く、バックアップからの復旧手順を先に把握しておきます。
• 投稿内・ウィジェット内の http:// を置換する: 画像・内部リンクに残るhttpをhttpsへ置換します。一括置換の前に必ずバックアップを取り、テーマ・ウィジェット・メニュー内の直書きURLも見落とさないようにします。置換範囲は投稿本文だけでなく、カスタマイザー・ウィジェット・メニュー・テーマ設定に及ぶ場合があります。
• キャッシュ系利用時はキャッシュ削除後に再確認する: キャッシュプラグイン・サーバー側キャッシュ・ブラウザキャッシュが古いhttp版を返し続けます。削除後にシークレットウィンドウで鍵マークを確認します。CDN併用時はCDN側のキャッシュ削除とhttps設定も合わせて見直します。

-- WordPress内リンク置換の考え方（一般例・実行前の注意あり）
-- 注意: 以下は考え方を示す例示であり、そのまま実行しないこと。
-- 必ずデータベースのバックアップを取り、対象テーブルの接頭辞や環境の案内に従うこと。
-- 例: wp_posts テーブル内の http://example.com を https://example.com へ置換する発想
-- UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://example.com', 'https://example.com');

上記は発想を示す例示であり、実行用の完成文ではありません。実際には接頭辞・直列化データ・テーマ設定等の考慮が必要なため、プラグインの置換機能や専門手順に従います。置換後はトップ・投稿・固定・問い合わせ・画像一覧の表示と鍵マークを確認し、混在が残る場合は開発者ツールの警告表示で該当URLを特定します。画像が表示されない・レイアウトが崩れる等の症状は、置換漏れかキャッシュ残りであることが多く、該当URLの特定から対処を始めます。

エラーと解決：症状別の切り分け表

症状・確認・対処の早見表を示します。複数箇所の同時変更は避け、1回ずつ確認します。

対処フローは次の順番が効率的です。まずDNS到達（DNS解説記事の診断）を確認し、次に証明書対象を確認し、次に転送の重複を確認し、最後に混在を確認します。最初から混在だけを追うと、根本の対象不一致を見落とします。変更内容は「いつ・何を・何から何へ」のメモを残し、切り戻せる状態を保ちます。メモは作業中の判断材料になるだけでなく、後の振り返りで再発防止策を練る土台になります。同じ失敗を繰り返さないことが、運用技術の着実な向上につながります。小さな記録の積み重ねが財産になります。公開中サイトでの作業は閑散時間帯を選び、関係者への周知とバックアップを済ませてから着手します。作業記録の雛形は、日時・変更箇所・変更前値・変更後値・確認結果の5項目で十分です。記録を残す習慣が、切り分けの速度と復旧の確実さを大きく向上させます。

最終確認のチェックリストで仕上げます。

• https:// で鍵マークが出て警告がないか（複数ページで確認したか）
• http:// が統一先の https:// へ恒久転送されるか
• wwwあり・なしが統一先へ集約されているか
• 画像・CSS・JS・外部読み込みにhttp残りがないか
• 問い合わせ送信・ログイン導線がhttpsで動作するか
• 期限・自動更新の見守り手段を把握しているか

公開後の運用では、証明書の期限見守り、混合コンテンツの再発防止、転送の維持を続けます。テーマ更新・プラグイン追加・記事投稿のたびにhttp残りが混入する可能性があるため、投稿手順にhttps確認を組み込みます。外部サービスの貼り付けコードを更新した際も、鍵マークの再確認を欠かさないでください。サーバー移転やドメイン追加の際は、証明書対象の見直しと転送設定の再確認をセットで行います。年に数回は全主要ページの警告有無を棚卸しし、古いhttp表記（SNS・印刷物・外部登録）の修正漏れがないかも点検します。常時HTTPSは一度設定して終わりではなく、運用で維持するものと心得ておくと警告の再発を防げます。

次に読む記事

• SSLとは — HTTPSとの違いと無料SSLの考え方の基礎固め
• 独自ドメイン設定手順 — DNS到達までの紐付け手順
• WordPress始め方 — サイトURL・内部リンク・キャッシュの実践
• DNSとは — 到達・浸透・TTLの診断の考え方

出典

参考にした資料

• Let’s Encryptの無料証明書に関する一般解説、サーバー・CMSの一般的なSSL設定手順、IETF RFCのTLS・リダイレクト関連仕様の考え方、MDN Web DocsのHTTPS・混合コンテンツ関連解説を参考にしました。私たちでは無料SSL、無料サブドメイン、独自ドメイン持ち込み対応をご用意しています。まずは無料プランで実際に触って確かめてみてください。仕様・画面は公式ページをご覧ください。