常時SSL化の費用｜無料と有料の違い・選び方と失敗しない移行手順

常時SSL化の費用は、証明書そのものより移行作業の量で決まります。多くのレンタルサーバーが無料で提供している証明書（Let’s Encryptなど）でも、通信を暗号化する強さは有料の証明書と変わりません。有料を選ぶのは、取引先や入札の条件で「組織の実在まで確認した証明書」を求められる場合です。

自社サイトがまだhttpのままで、自社で移行するか制作会社に依頼するかを決めたい方に向けた記事です。読み終わる頃には、無料と有料のどちらにするかを決め、9つの手順で移行を進められる状態を目指します。見積もりを取るときに制作会社へ確認する質問文も載せています。

そもそもSSL化が必要かどうかから確かめたい方は、先にSSL化しないとどうなるか｜無料で対応する手順と失敗回避をご覧ください。この記事では、SSL化すると決めたあとの費用・選び方・移行手順を扱います。

Contents / 目次

1. 常時SSL化の費用の内訳と、無料と有料の違い
2. 失敗しない常時SSL化の移行手順9ステップ
3. 常時SSL化でつまずきやすい6つの失敗と戻し方
4. 常時SSL化で変わること、変わらないこと
5. 見積書に出ない費用と、制作会社への確認事項
6. 常時SSL化の費用と移行についてのよくある質問
7. 常時SSL化の移行作業のご相談

常時SSL化の費用の内訳と、無料と有料の違い

常時SSL化の費用は「証明書の代金」と「移行作業の手間」の2つに分かれ、中小企業のサイトで差が大きいのは後者です。証明書の代金は、無料SSLなら0円です。一方、サイト内のURLの書き換えや外部サービスの設定変更は、無料でも有料でも同じだけ発生します。

有料SSLの代金は、販売会社・認証局・契約年数で変わります。同じ認証局の証明書でも販売会社ごとに価格が違うため、この記事では金額を載せていません。有料を検討する場合は、認証局や販売会社の公式サイトの価格ページで、DV・OV・EVそれぞれの年額を同じ契約年数どうしで比べてください。

常時SSL化とは、サイトのすべてのページを「https://」で表示し、「http://」で開かれても自動でhttpsへ転送する状態にすることです。お問い合わせフォームのページだけをhttpsにする昔のやり方と区別するために、「常時」と付けて呼びます。

DV・OV・EVは、認証局（証明書を発行する機関）がどこまで確かめたかを表す区分です。DVはドメイン認証、OVは企業認証、EVはより厳しい審査を経た企業認証を指します。

無料と有料の違いは、次の表のとおりです。

項目	無料SSL（DV）	有料SSL（DV）	有料SSL（OV・EV）
暗号化の強さ	同じ	同じ	同じ
認証局が確かめること	ドメインを管理していること	ドメインを管理していること	ドメインに加えて、組織が実在すること（EVはさらに厳しい審査）
証明書の代金	0円	年額の費用がかかる	DVより高い
1枚の有効期間	Let’s Encryptは90日	最大200日	最大200日
更新のしかた	サーバーが自動で更新する形が一般的	自動更新に対応した商品と、手作業で入れ替える商品がある	自動更新に対応した商品と、手作業で入れ替える商品がある
証明書に載る会社名	載らない	載らない	載る（証明書の詳細を開くと確認できる）
向いている会社	取引先から証明書の種類を指定されていない会社	使っているサーバーで無料SSLが使えない会社	取引先や入札の条件でOV以上を求められる会社

有効期間は2026年9月26日時点の情報です。Let’s Encryptは、標準の証明書の有効期間を2027年2月10日から64日、2028年2月16日から45日に短くする予定を公表しています（Let’s Encryptの告知「Decreasing Certificate Lifetimes to 45 Days」）。最新の値はLet’s EncryptのFAQで確認してください。

移行作業も含めた作業ごとの費用の内訳は、SSL化の費用は何で変わるか｜内訳と制作会社に任せる作業で解説しています。

見積もりを比べるときは、1年間にかかる費用を次の2つに分けて足し合わせます。

1. 証明書の代金：販売会社の価格ページで、年額と、契約期間中の再発行が追加料金なしでできるかを確認する
2. 入れ替えの作業費：制作会社に依頼する1回あたりの作業費 × 1年間の入れ替え回数（自動更新なら0回、手作業なら後述の有効期間の表の回数以上）

無料SSLを自動更新で使うなら、この2つはどちらも0円です。移行作業そのものの費用は、この章の後半にある「5つの数」で作業の量が決まります。

無料SSLで足りる会社、有料SSLを選ぶ会社

次の条件がすべてそろうなら、無料SSLで足ります。

• サーバー：レンタルサーバーの管理画面から無料SSLを有効にできる
• ドメイン：ドメインが、そのサーバーを向いている（手順1で確かめ方を説明します）
• 取引先の条件：取引先や入札の仕様書で、証明書の種類を指定されていない

反対に、次のどれかに当てはまる場合は有料の証明書を検討します。

• 種類の指定：セキュリティチェックシートや入札の仕様書に「OV以上」「EV」と書かれている
• サーバーの制約：使っているサーバーやホームページ作成サービスで、無料SSLが提供されていない
• ワイルドカード：「*.example.com」のように、サブドメインをまとめて1枚で守る証明書が必要で、サーバーの無料SSLが対応していない

チェックシートに「SSL対応」とだけ書かれている場合は、HTTPSで通信できれば足りる意味のことがあります。有料を買う前に、取引先の担当者へ「HTTPS対応であればよいか、証明書の種類の指定があるか」を確認してください。

使っているサーバーで無料SSLが使えない場合、有料証明書を毎年買うより、無料SSLに対応したサーバーへ移転したほうが、年間の費用と入れ替えの手間を抑えられることがあります。移転の進め方はWordPressのサーバー引っ越し手順｜DB移行と無停止切替で解説しています。

2026年3月15日から、証明書の有効期間は最大200日

2026年3月15日以降に発行されるSSL/TLS証明書は、有効期間が最大200日になりました。認証局とブラウザの開発元でつくる業界団体CA/Browser Forumの決議（Ballot SC-081v3）により、次の表のとおり段階的に短くなります。

適用が始まる日	1枚の最大有効期間	1年間に必要な入れ替え（最低）
2026年3月15日	200日	2回
2027年3月15日	100日	4回
2029年3月15日	47日	8回

表の回数は、365日を最大有効期間で割って切り上げたものです。実際には期限ぎりぎりで入れ替えることはないので、これより多くなります。

この変更で、有料証明書の選び方が変わりました。「1年契約」「複数年契約」の商品でも、証明書そのものは契約期間の中で再発行と再設置が必要です。手作業で入れ替える商品を選ぶと、2027年3月以降は年4回以上の作業が発生します。いまは証明書の代金より、自動で更新できるかどうかで選ぶほうが費用を抑えられます。

見積もりの前に数える5つの数

移行作業の手間は、次の5つの数で決まります。制作会社に見積もりを依頼する前に書き出しておくと、見積もりの抜けに気づけます。

1. ドメインとサブドメインの数（wwwあり・なし、shop.、recruit. など、httpsで開く名前をすべて）
2. 主要なページで見つかる「http://」の箇所の数（手順6のコードで数えられます）
3. URLを登録している外部サービスの数（Search Console、GA4、Googleビジネスプロフィール、SNS、広告、予約・決済サービスなど）
4. 自社で動かしているプログラムの数（問い合わせフォーム、カート、会員ログインなど）
5. 1年間に証明書を入れ替える回数（自動更新なら0回、手作業なら上の表の回数以上）

作業ごとの費用の内訳と、制作会社に任せる作業の分け方は、SSL化の費用は何で変わるか｜内訳と制作会社に任せる作業で詳しく解説しています。

サーバーやドメインの契約者が社内で分からない場合や、前の制作会社と連絡が取れない場合は、社内だけで移行を進めるのは難しくなります。サイトのリニューアルも検討しているなら、ホームページ制作・LP制作のページで、制作の流れと、公開後の任意の月額保守（サーバー・ドメイン・SSLの管理を含む）を紹介しています。

この章の結論。取引先から種類を指定されていなければ無料SSLで足ります。費用を左右するのは証明書の代金ではなく、5つの数で決まる移行作業と、年に何回入れ替えるかです。

失敗しない常時SSL化の移行手順9ステップ

常時SSL化は、証明書を入れる → https://で表示を確かめる → サイト内のURLを書き換える → httpからhttpsへ転送する → 外部サービスの登録URLを変える → 証明書の期限を確かめる、の順で進めます。転送を先に入れると、https側で表示が崩れていたときに全ページが崩れた状態で公開されます。

ここではレンタルサーバーで動いているWordPressサイトを例にします。WordPressを使っていないサイトは、手順4と手順5を「HTMLファイルの中のhttp://自社ドメインを一括で検索し、https://に書き換える」作業に置き換えてください。

ステップ1。サーバーとドメインの契約先、DNSの向き先を確かめる

最初に、次の3つを確かめます。

• サーバーの管理画面に入れるか
• ドメインをどの会社で管理しているか
• ドメインがどのサーバーを向いているか

サーバーの管理画面から有効にする無料SSLは、一般的には、ドメインがそのサーバーを向いていないと発行も更新もできません。DNSのレコードを使う認証方式などで、ネームサーバーを切り替える前に設定できるサーバーもあります。認証方式の種類はLet’s Encryptの認証方式の説明で確認できます。

DNSとは、ドメイン名とサーバーの住所（IPアドレス）を結びつける仕組みです。住所録の登録先が前の制作会社のサーバーのままだと、新しいサーバーで証明書を申し込んでも、認証局は確認に失敗します。Macのターミナル、またはWindowsのコマンドプロンプトで次を実行すると、向き先を確かめられます。

# ドメインがどのIPアドレスを向いているかを確かめる（example.com を自社ドメインに変更）
nslookup example.com
nslookup www.example.com

# DNSをどの会社のネームサーバーで管理しているかを確かめる
nslookup -type=NS example.com

# 表示されたIPアドレスが、レンタルサーバーの管理画面に書かれたIPアドレスと同じか比べる
# 違う場合は、CDN（Cloudflareなど）か、前のサーバーを向いている可能性がある

あわせて、URLを登録している外部サービスを書き出しておきます。手順8でそのまま使います。

外部サービス	ログインできる人	登録しているURL	変更した日
Google Search Console	［担当者名］	http://example.com/
GA4	［担当者名］	http://example.com/
Googleビジネスプロフィール	［担当者名］	http://example.com/
予約・決済・フォームの外部サービス	［担当者名］	［戻り先URLなど］

ステップ2。サイトのファイルとデータベースをバックアップする

手順5でデータベースを書き換えるので、ファイルとデータベースの両方を取ります。レンタルサーバーの自動バックアップを当てにする場合は、何日前まで戻せるか、戻す操作を誰が行えるかを先に確かめてください。

バックアップを取った日時はメモに残します。手順5以降で表示が崩れたとき、その日時に戻せば移行前の状態に戻ります。

ステップ3。証明書を有効にして、https://で表示できるか確かめる

無料SSLの場合は、サーバーの管理画面で対象のドメインを選び、SSLの設定を有効にします。メニューの名前はサーバーごとに違うので、契約しているサーバーの公式ヘルプで確認してください。有効にしてから実際に使えるようになるまで、時間がかかる場合があります。

有料SSLの場合は、次の流れになります。

1. サーバーの管理画面でCSR（証明書署名要求。証明書を発行してもらうための申込データ）を作る
2. 販売会社にCSRを送って申し込む
3. 認証局の確認に応じる（メール・DNS・ファイル設置のどれか。OV・EVは会社の実在確認も入る）
4. 発行された証明書と中間証明書を、サーバーの管理画面に設置する

設置できたら、ブラウザのアドレスバーに「https://自社ドメイン/」と直接入力して開きます。wwwありとwwwなしの両方を開き、どちらも警告が出ないことを確かめます。この時点では、まだWordPressの設定もhttpからの転送も変えません。

ステップ4。WordPressのアドレス2か所をhttpsに変える

WordPressの管理画面で「設定」→「一般」を開き、「WordPress アドレス (URL)」と「サイトアドレス (URL)」の2か所の「http://」を「https://」に変えて保存します。保存すると一度ログアウトされるので、https://の管理画面にログインし直します。

ログインできなくなったときは、サーバーのファイルマネージャーなどで wp-config.php を開き、次の2行を一時的に足すとhttpの状態に戻せます。証明書の問題を解決したら、この2行は消してください。

// 一時的な戻し用。「/* 編集が必要なのはここまでです */」より上に書く
// example.com を自社ドメインに変更
define( 'WP_HOME', 'http://example.com' );
define( 'WP_SITEURL', 'http://example.com' );

ステップ5。データベースの中のhttp://を置き換える

記事や固定ページの本文、画像のURLは、手順4では変わりません。データベースの中に残っている「http://自社ドメイン」を「https://自社ドメイン」に置き換えます。

サーバーでWP-CLI（WordPressをコマンドで操作するツール）が使える場合は、次のように実行します。まず –dry-run で置き換わる件数だけを確かめ、件数に問題がなければ本番で実行します。

# 前提。SSHでサーバーに接続し、WordPressを置いたフォルダに移動してから実行する
# 手順2のバックアップを取ってから行うこと
# example.com を自社ドメインに変更。過去にwwwありを使っていた場合は、wwwありでも同じ作業を行う

# 1回目。何件置き換わるかだけを確認する（データは変わらない）
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

# 2回目。件数に問題がなければ本番で実行する
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

SSHが使えない場合は、置き換え用のプラグインを使います。選ぶときは「シリアライズされたデータに対応している」ものにしてください。

シリアライズとは、WordPressがテーマやウィジェットの設定を「文字数つき」で保存する形式のことです。httpをhttpsに変えると1文字増えるため、文字数を数え直さない置き換えを行うと、設定が読めなくなって消えたように見えます。データベースの管理ツールで単純な文字置換を行うのは避けてください。

ステップ6。混在コンテンツを探して修正する

混在コンテンツとは、https://のページの中に、http://で読み込む画像・スクリプト・動画などが残っている状態のことです。ブラウザはこれを安全でない読み込みとして扱い、鍵マークが出なかったり、画像やスクリプトが読み込まれなかったりします。

次のコードで、開いているページの中の「http://」を一覧にできます。

// 使い方。確認したいページをChromeで開き、F12キー（MacはCommand+Option+I）で
// 開発者ツールを開いて、「Console」タブに貼り付けてEnterを押す
// 初めて貼り付けるときは、貼り付けの許可を求める表示が出ることがある。表示に従って許可する
(() => {
  const attrs = ['src', 'href', 'srcset', 'action', 'data-src', 'poster'];
  const found = [];
  document.querySelectorAll('*').forEach((el) => {
    attrs.forEach((attr) => {
      const value = el.getAttribute(attr);
      if (value && value.includes('http://')) {
        found.push({ tag: el.tagName.toLowerCase(), attr: attr, value: value });
      }
    });
    const style = el.getAttribute('style');
    if (style && style.includes('http://')) {
      found.push({ tag: el.tagName.toLowerCase(), attr: 'style', value: style });
    }
  });
  console.table(found);
  console.log('http:// を含む箇所は ' + found.length + ' 件です');
  // 結果をクリップボードにコピーする（開発者ツールのConsoleで実行したときだけ動く）
  copy(JSON.stringify(found, null, 2));
})();

一覧に出たものは、種類ごとに次のように扱います。

• 自社ドメインの画像・ファイル：「https://」に書き換える。手順5で残ったものは、テーマのファイルやページビルダーの設定に直接書かれている可能性がある
• 外部の画像・スクリプト：URLを「https://」に変えて開けるか確かめ、開ければ書き換える。開けなければ差し替えるか外す
• iframe（地図・動画の埋め込み）：古い埋め込みコードのまま残っていることがある。提供元の画面から埋め込みコードを取り直して貼り直す
• a タグの href（外部サイトへのリンク）：混在コンテンツには当たらないので、急いで修正しなくてよい。ただし自社ページへのリンクはhttpsに揃える

CSSファイルの中で読み込んでいる背景画像は、このコードでは拾えません。開発者ツールのConsoleに「Mixed Content」から始まる警告が出ていないかもあわせて確認してください。確認するページは、トップ、問い合わせフォーム、送信完了ページ、記事1本、会社概要などの固定ページ1本が最低限です。

ステップ7。httpからhttpsへ301リダイレクトを設定する

ここまでで https:// のページに問題が無いことを確かめてから、http:// で開かれたときにhttpsへ転送する設定を入れます。301リダイレクトとは「このページは恒久的に移転しました」とブラウザと検索エンジンに伝える転送のことです。Googleは、恒久的なリダイレクトを、リダイレクト先が正規版であることを示すシグナルとして使うと、Google検索セントラルの「リダイレクトと Google 検索」で説明しています。

Apacheのサーバーでは、サイトの一番上のフォルダにある .htaccess に次を書き足します。WordPressの場合は「# BEGIN WordPress」の行より上に置きます。

# ここから。httpからhttpsへの301リダイレクト
# 前提。Apacheで mod_rewrite が使えるサーバー。編集前に .htaccess をコピーして残しておく
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>
# ここまで

サーバーの管理画面にhttpsへ転送する設定項目がある場合や、転送用のプラグインを入れている場合は、そのどれか1つだけを使います。複数を重ねるとリダイレクトループの原因になります。書き方の違いや注意点は.htaccessでhttpをhttpsへ301リダイレクト｜コピペ設定と失敗回避で詳しく解説しています。

設定できたら、ターミナルで次を実行して確かめます。

# httpで開いたときに、httpsへ301で転送されるかを確かめる（example.com を自社ドメインに変更）
curl -I http://example.com/
curl -I http://www.example.com/

# 1行目に「301」が含まれ、
# 「Location: https://example.com/」の行があれば成功

ステップ8。Search Console・GA4・外部サービスの登録URLを変える

手順1で書き出した外部サービスのURLを、https://に変えます。301リダイレクトがあれば多くのリンクは転送されますが、予約・決済などのサービスは、登録したURLと実際のURLが違うと動かないことがあります。

外部サービス	変える場所	変えないと起きること
Google Search Console	http://で登録したURLプレフィックスのプロパティなら、https://のプロパティを追加してサイトマップを送り直す。ドメインプロパティならhttpとhttpsの両方が含まれる	https://のページのデータが古いプロパティに出ず、数字が減ったように見える
GA4	データストリームに登録したサイトのURL	設定画面の表示と実際のURLが食い違う
Googleビジネスプロフィール	ウェブサイトの欄	Googleマップから来た人が転送を1回経由する
広告	リンク先URL（最終ページURL）	転送のぶん表示が遅れ、計測用のパラメータが落ちる設定の場合もある
予約・決済・外部フォーム	戻り先URL、許可するドメインの設定	予約や決済のあと、自社サイトに戻れない
サイトの中の設定	SEOプラグインが出すcanonical・og:url、robots.txtのSitemapの行	検索エンジンやSNSにhttpのURLを伝え続ける

ドメインプロパティとURLプレフィックスプロパティの違いは、Search Consoleヘルプの「ウェブサイトまたはプラットフォームのプロパティを Search Console に追加する」で確認できます。Search Consoleにhttpsのプロパティを追加する手順は、Search Console登録3ステップ｜所有権確認とサイトマップ送信で解説しています。

ステップ9。自動更新が動くかと、次の期限を確かめる

最後に、証明書の有効期限を確かめ、次に誰が何を確認するかを決めます。

ブラウザでは、アドレスバー左のアイコンから証明書の詳細を開くと有効期間が表示されます（表示の文言はブラウザのバージョンで変わります）。opensslのコマンドはWindowsには標準で入っていないため、Windowsをお使いの方はこの方法で確かめてください。

Macのターミナルでは、次のコマンドで確かめられます。

# 証明書の有効期限を確かめる（example.com を自社ドメインに変更）
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

# notAfter= の日付が期限。時刻はグリニッジ標準時（日本時間より9時間前）で表示される

無料SSLの場合は、管理画面で自動更新が有効になっているかを確かめ、最初の更新予定日の翌日に、もう一度このコマンドで期限が延びたかを見ます。手作業で入れ替える有料証明書の場合は、期限の30日前に担当者へ通知が届くよう、共有カレンダーに登録してください。

移行作業でAIに任せられる確認と、自分で見る確認

手順6で出た一覧の仕分けや、.htaccessの書き方の確認は、AIに任せると時間を短くできます。出発点の指示文は、次の程度の短さで十分です。

WordPressサイトの常時SSL化を進めています。
次の一覧は、自社サイト（［自社ドメインを入力］）のページで見つかった「http://」を含む箇所です。
1. 自社ドメインのURLか、外部サービスのURLかに分けてください。
2. 画像・スクリプト・CSS・iframe・リンクのどれに当たるかを書いてください。
3. 対応の候補（https://に書き換える／埋め込みコードを取り直す／外すか検討する）を1つずつ付けてください。
分からないものは推測せず「確認が必要」と書いてください。

［ここにConsoleでコピーした結果を貼り付け］

あとはAIと対話しながら、自社のサイトの事情に合わせて詰めてください。AIの出力でご自身が確かめるのは次の3点です。

• 外部URLが本当にhttpsで開けるか：AIはそのURLを実際に開いていない。ブラウザで1つずつ開いて確かめる
• .htaccessの提案が今の構成に合うか：AIはサーバーの設定やCDNの有無を見ていない。バックアップを取ってから試し、手順7のcurlで結果を見る
• 渡してはいけない情報を貼っていないか：wp-config.php、管理画面のパスワード、データベースの中身そのものはAIに貼らない

移行後の確認チェックリスト

• 表示：wwwあり・なしの両方で、https://のページが警告なしで開く
• 転送：http://で開くと、301でhttps://の同じページへ転送される
• 混在コンテンツ：主要な5ページで、手順6のコードの結果が外部リンク以外0件
• フォーム：問い合わせフォームから実際に送信し、通知メールと自動返信メールが届く
• 送信完了ページ：送信完了ページがhttpsで表示され、GA4のイベントが記録される
• 管理画面：https://の管理画面にログインでき、記事の保存ができる
• 外部サービス：手順1の表の「変更した日」がすべて埋まっている
• Search Console：httpsのURLでサイトマップを送信済み
• SNS共有：ページのURLをSNSに貼ったとき、画像付きで表示される
• 期限：次の更新予定日と、確認する担当者が決まっている

この章の結論。順番は「証明書 → https表示の確認 → 内部のURL → 転送 → 外部サービス → 期限」です。転送を、https表示の確認とサイト内のURLの書き換えのあとに入れれば、https側の問題を転送の前に見つけて修正できます。

常時SSL化でつまずきやすい6つの失敗と戻し方

常時SSL化の失敗は、ほとんどが「順番」と「設定の重なり」から起きます。ここでは、条件と結果、防ぎ方、起きたときの戻し方をセットで書きます。

DNSが別の場所を向いていて、無料SSLの発行や更新が失敗する

ドメインが前の制作会社のサーバーやCDNを向いたままだと、新しいサーバーで無料SSLを申し込んでも発行されません。発行できていても、あとでDNSを切り替えたときに自動更新だけが失敗し、数か月後に突然期限が切れることがあります。

防ぐには、手順1のnslookupで向き先を確かめてから申し込みます。起きてしまったときは、ドメインの管理会社でDNSの向き先を今のサーバーに変え、反映を待ってからサーバーの管理画面で証明書を取り直します。

301転送を先に入れて、表示崩れが全ページに広がる

手順3の確認をせずに転送を入れると、https側で画像やCSSが読み込めない状態が、すべての訪問者に見えてしまいます。httpのページに戻る手段も無くなります。

防ぐには、転送を手順7まで入れません。起きてしまったときは、.htaccessに足した行を消して転送を止め、https側の表示を修正します。301はブラウザに記憶されるため、一度転送された訪問者は、行を消したあともhttpsへ転送されることがあります。httpに戻すことより、https側の修正を優先してください。

データベースを単純な文字置換で書き換え、テーマの設定が消える

データベースの管理ツールで「http://」を「https://」に一括置換すると、手順5で説明したシリアライズのデータの文字数が合わなくなります。ウィジェットやテーマのカスタマイズ、ページビルダーの配置が、消えたように見えます。

防ぐには、WP-CLIの search-replace か、シリアライズ対応をうたうプラグインを使います。起きてしまったときは、手順2のバックアップからデータベースだけを戻し、正しい方法で置き換え直します。

サーバーの転送設定と.htaccessが重なり、リダイレクトループになる

サーバーの管理画面の転送設定、.htaccess、転送用プラグインのうち2つ以上を入れると、ブラウザに「リダイレクトが繰り返し行われました」と表示されてページが開かなくなることがあります。CloudflareなどのCDNを使っていて、CDNとサーバーの間がhttpの設定になっている場合も、サーバー側が毎回httpと判定して同じ状態になります。

防ぐには、転送の設定を1か所だけにします。起きてしまったときの切り分けはリダイレクトループの原因切り分けと直し方｜htaccess対処で解説しています。

有料証明書を「1年契約」のつもりで放置し、200日で期限が切れる

2026年3月15日以降に発行された証明書は、1年契約の商品でも最大200日で期限が切れます。以前の感覚で「来年の同じ月に更新すればよい」と考えていると、契約期間の途中で警告画面が出て、問い合わせフォームにも入れなくなります。

防ぐには、手順9のコマンドで実際の期限を確かめ、カレンダーに登録します。起きてしまったときは、販売会社の管理画面で証明書を再発行し、サーバーに設置し直します。

HSTSを長い期間で入れたあとに証明書が切れ、サイトに入れなくなる

HSTSとは、「このサイトは今後httpsでしか開かないでください」とブラウザに覚えさせる設定です。HSTSの仕様（RFC 6797）では、HSTSを覚えたサイトで証明書のエラーが起きたとき、ブラウザは警告を無視してページを開く手段を利用者に出さないと定められています。

ブラウザが覚えた設定は、HSTSで指定した期間（max-age）が過ぎるまで残ります。防ぐには、自動更新が1回以上成功したことを確かめてからHSTSを検討し、最初は短い期間で入れます。起きてしまったときは、証明書の更新を最優先で行います。

この章の結論。301転送の失敗とリダイレクトループは、転送の順番と設定の重なりで起きます。HSTSでサイトに入れなくなるのは、HSTSを入れたあとに証明書の期限が切れたときです。転送はサイト内のURLを書き換えたあとに1か所だけ入れ、HSTSは自動更新の成功を確かめてから、と決めておけば防げます。DNSの向き先、データベースの置き換え方、証明書の期限切れは、手順1・手順5・手順9の確認で防げます。

常時SSL化で変わること、変わらないこと

常時SSL化で確実に変わるのは、ブラウザの警告表示と、アクセス解析で流入元が正しく記録されることです。検索順位が大きく上がる、サイトの乗っ取りが防げる、といった効果は期待しないでください。

変わること

• ブラウザの表示：Chromeでは、httpのページのアドレスバーに「保護されていない通信」と表示される（Chromeヘルプの「サイトの接続が安全かどうかを確認する」）。常時SSL化すると、この表示が出なくなり、取引先の担当者が問い合わせフォームを開いたときにためらう理由が1つ減る
• 流入元の記録：ブラウザの標準の設定では、httpsのサイトからhttpのページへ移動するとき、参照元の情報は送られない（W3CのReferrer Policyの仕様）。参照元の情報が届かない訪問は、GA4では参照元「(direct)」・メディア「(none)」として記録されることが多く（アナリティクスヘルプの『[GA4] 「(direct) / (none)」トラフィックについて』）、チャネルでは「直接」に分類される（アナリティクスヘルプの「デフォルト チャネル グループ」）。httpのままだと、他社サイトやSNSから来た人が「直接」の流入として数えられ、どこから問い合わせが来ているか分からなくなる
• 検索エンジンの扱い：httpとhttpsの両方で開ける状態は、同じページが2つある状態になる。301転送でhttpsに1本化すると、検索エンジンにどちらを表示すべきかを明確に伝えられる

変わらないこと

Googleは2014年に、Google検索セントラルブログの「HTTPS as a ranking signal」で、HTTPSを検索順位の要素の1つに加えると発表しています。ただし影響は小さいと説明されており、SSL化だけで順位が大きく上がることは期待できません。順位を上げたいなら、記事の中身や内部リンクなど別の施策が要ります。

SSL化で守れるのは、ブラウザとサーバーの間の通信の中身です。WordPressの脆弱性を突いたサイトの乗っ取りや改ざんは、SSL化では防げません。そちらはWordPress乗っ取り対策｜更新と二段階認証を今日から始める手順で別に行います。

移行の前後で比べる数字

移行の効果を確かめるなら、移行前の1か月分の数字を先に記録しておきます。記録が無いと、移行後に問い合わせが増えても減っても、原因が分かりません。

記録する数字	どこで見るか	比べる時期
問い合わせフォームの送信完了数	GA4のイベント、またはフォームの通知メールの件数	移行前1か月と移行後1か月
流入のうち「直接」の割合	GA4の集客のレポート	移行前1か月と移行後1か月
httpsのURLのインデックス登録数	Search Consoleのページのインデックス登録	移行後、週に1回
httpのURLが301で転送されているか	手順7のcurl	移行当日と1週間後
証明書の期限	手順9のopensslコマンド	更新予定日の翌日

「直接」の割合が移行後に下がり、SNSや他社サイトからの流入が増えて見える場合、その変化には、参照元が記録されるようになった影響が含まれます。この違いを知らずに「SSL化で流入が増えた」と社内で報告すると、翌月以降の判断を誤ります。

この章の結論。SSL化の効果は、警告が消えることと、流入元が正しく記録されることです。移行前1か月の数字を記録しておけば、移行後の変化を「記録のされ方の変化」と「本当の増減」に分けて読めます。

見積書に出ない費用と、制作会社への確認事項

常時SSL化の見積もりで抜けやすいのは、証明書の入れ替え作業と外部サービスの設定変更です。どちらも「SSL化作業一式」と書かれた見積もりの中に入っているかどうかが、見積書だけでは分かりません。

見積書に出にくい4つの費用

• 証明書の入れ替え作業：手作業で入れ替える有料証明書の場合、2026年3月以降は年2回以上、2027年3月以降は年4回以上の作業が発生する。移行の見積もりには入っていても、翌年以降の入れ替えが保守契約に入っているかは別の話
• テーマやプラグインの中のhttp://の修正：データベースの置き換えでは変わらない箇所。見つかった数で作業時間が変わるため、「見つかった場合は別途」とされやすい
• 外部サービスのURL変更：各サービスの管理者アカウントが必要なので、制作会社が作業できず、社内の担当者の作業になることがある
• 前の制作会社や管理会社との調整：DNSやサーバーの管理者が社外にいる場合、変更の依頼と日程の調整が必要になる

「SSL対応済み」の中身を確かめる質問文

制作会社のプランに「SSL対応」「SSL化込み」と書かれている場合は、次の質問をそのまま送ると、作業範囲と翌年以降の費用が分かります。

常時SSL化について、見積もりの範囲を確認させてください。

1. 証明書の種類（DV・OV・EV）と、発行する認証局を教えてください。
2. 証明書は自動で更新されますか。手作業の場合、年に何回の入れ替え作業が保守費に含まれていますか。
3. 更新に失敗したとき、誰が気づき、弊社のどなたに連絡が来ますか。
4. wwwあり・なし、サブドメイン（例 shop.）のうち、どれが対象に入っていますか。
5. サイト内のhttp://の書き換えと、混在コンテンツの修正は作業範囲に入っていますか。
6. Search Console・GA4・Googleビジネスプロフィールなど、外部サービスのURL変更はどちらが行いますか。
7. 契約を終了するとき、証明書・サーバー・ドメインの管理者権限はどのように引き継がれますか。

7番目は、契約時に確認しておかないと、あとから確認する機会がありません。ドメインやサーバーが制作会社の名義で契約されていると、制作会社を変えるときに証明書の再発行やDNSの変更が自社だけでは行えなくなります。

有料証明書の保証とサイトシールの見方

有料証明書の販売ページでは、保証額やサイトシール（証明書を導入していることを示すバッジ画像）が比較の項目として並びます。保証がどのような損害に対して支払われるかと、その条件は認証局ごとに違うため、購入前に認証局の約款で確認してください。

BtoBの問い合わせで、相手の担当者がサイトシールを見て判断する場面は限られます。取引先から種類の指定が無いなら、保証額やサイトシールのために有料を選ぶより、自動更新できる証明書を選ぶほうが、証明書が切れて問い合わせフォームが開けなくなる事態を防げます。

自社で行う範囲と依頼する範囲

作業	自社で行える条件	依頼したほうが早い条件
無料SSLの有効化	サーバーの管理画面に入れる	サーバーの契約者が分からない
WordPressのURL変更と置き換え	バックアップから戻す方法が分かっている	戻し方が分からない、ページビルダーを多く使っている
混在コンテンツの修正	見つかったのが画像とリンクだけ	テーマのファイルや外部のスクリプトに埋め込まれている
301リダイレクト	.htaccessを編集でき、CDNを使っていない	CDNを使っている、リダイレクトループが起きた
外部サービスのURL変更	各サービスに社内の担当者がログインできる	管理者が退職している、前の制作会社の名義のまま
証明書の期限管理	自動更新で、確認する担当者と日を決めた	手作業で入れ替える有料証明書を使っている

入れ替え作業や期限の確認を保守契約に含めるかどうかは、ホームページ保守の費用相場｜月額に含む作業と別料金の一覧で、ほかの保守作業と並べて確認できます。

この章の結論。見積もりで確かめるのは「翌年以降の入れ替えを誰が何回行うか」と「外部サービスのURL変更はどちらが行うか」の2つです。質問文の7項目を送れば、見積書に書かれていない費用が契約前に分かります。

常時SSL化の費用と移行についてのよくある質問

常時SSL化の移行作業のご相談

今日できる最初の一歩は、ブラウザのアドレスバーに「http://自社ドメイン/」と入力し、httpsへ転送されるかを確かめることです。転送されていれば、鍵のアイコンから証明書の有効期間も見ておいてください。期限の管理まで進めたい方は、次にドメイン・SSL期限切れでサイトが止まる前に｜更新管理の手順をご覧ください。

ここまで読んで、サーバーの契約先が分からない、転送や混在コンテンツの修正を社内で進めるのは不安だと感じた方は、ホームページ制作・LP制作のページからご相談ください。公開後の任意の月額保守には、サーバー・ドメイン・SSLの管理、WordPressとプラグインの更新、バックアップの取得と復元確認が含まれます。