ホームページをHTTPSにした後に確認すること 画像やフォームが表示されないとき

HTTPSに切り替えた後で画像が消えたり、フォームが開かなくなったりしたら、最初に「ページ自体を開けない」「ページは開けるが部品が動かない」を分けます。前者は証明書やアクセス先、後者は画像やスクリプトなどの参照先が手がかりです。証明書の警告が出る画面では入力や送信を始めず、使っている公開先の管理者へ確認します。

ページのURLがHTTPSでも、HTMLが古いHTTPの画像や外部スクリプトを呼び出している場合があります。この組み合わせは混在コンテンツと呼ばれます。ブラウザーが何を止めるかは読み込むものや条件によって違います。この記事は、公開URL、ページ内の参照先、フォームの結果を順に調べるための手順です。公開の作業全体は公開前のチェックリストで確認できます。

最初に開いたURLを文字で記録します。表示されているホスト名、HTTPSかHTTPか、トップか下層かを区別します。同じ店でも、旧ドメインや別のサブドメインへ進んでいれば原因が異なります。URLに認証用の文字列やフォームの入力値が含まれる場合は、共有するメモや画面から取り除きます。

証明書は、同じサイトに見えてもURLが違えば同じ状態とは限りません。トップだけで確認を終えず、営業時間やお問い合わせなど利用者が実際に開くページを2〜3件選びます。別の端末でも同じ症状か、公開先を切り替えた直後だけかも記録します。どの契約を使っているか不明な場合は、ドメインとサーバーの役割を参照して、確認できる人を特定します。

ブラウザーの警告に従って公開先の管理者へ相談し、警告を回避してログインする方法を利用者に勧めないでください。外部の埋め込み先が表示できない場合も、事業者の連絡先や利用者が次に取れる行動を先に確保します。

ページの一部だけが表示されない場合は、問題のページを開き、ブラウザーの開発者ツールの Console や Network を確認します。普段は使わない人でも、「Mixed Content」などの文言、止まったURL、資源の種類が分かれば、調べる場所を絞れます。別の理由で発生した404、通信拒否、外部サービスの障害も同じ画面に出るため、エラーがあるだけでHTTPSの問題と決めません。

画像の参照を確認する

画像が見えない場合は、HTMLの画像URLやCSSに書かれた背景画像の指定を確認します。自社サイトに置いた画像と、別サイトから取得する画像を分けます。ブラウザーがHTTPの参照をHTTPSへ自動的に変更しようとするケースがあっても、HTTPS側に同じ画像がなければ表示できません。IPアドレスを含む指定やリソースの種類で扱いが異なるため、実際に止まった参照を読み取ります。

スクリプトや埋め込みを確認する

フォームや予約部品を表示するためのスクリプトにHTTPのURLが残っていると、ブラウザーが読み込みを止める場合があります。本文のHTML、サイト共通の設定、テンプレート、外部サービスの貼り付けコードのどこにあるかを調べます。同じ部品が複数ページで使われているなら、どこが共通の入力欄なのかも確認します。

Chrome 156.0.8078.81で、通信を検証用レスポンスに限定したページを開きました。ページ本体をHTTPSとし、同じ内容のスクリプトの参照だけを切り替えています。HTTP参照ではConsoleに混在コンテンツのエラーが出てスクリプトは実行されず、HTTPS参照では検証用スクリプトが実行されました。下の図はこの結果を整理したもので、本番サーバーの証明書やメール受信を検証したものではありません。

HTTPの参照を見つけても、先頭を置換して終わりにしません。まず、同じ提供元がHTTPSのURLを案内しているか確認します。画像ならHTTPSのURLで意図した画像が表示されるか、スクリプトや埋め込みなら提供元の現在の貼り付け方法に合っているかを見ます。古いURLに案内ページが出るだけで、必要な部品が取れていないこともあります。

自社の画像を修正する場合は、公開先のHTMLだけを書き換えると次のサイト生成で元に戻ることがあります。編集元でどの欄から出力されたかを確かめ、変更前の控えを取ったうえで生成物を確認します。外部スクリプトの移行は、同じ用途で使用してよいものかも提供元に確認します。古い埋め込み先を維持できない時は、住所を本文に載せたり、受付の案内先を別の許可済みURLにしたりして、利用者が次に進める状態を用意します。

フォームでは、枠が表示されること、入力できること、送信が成功すること、事業者側が受け取ることを別々に確かめます。HTTPS化後に正常なフォームが見えていても、設定された送信先や通知メールの宛先が変わっていれば、画面だけで受信は判断できません。承認されたテスト宛先に、事業や個人を識別しないテスト内容を使います。

• テスト開始前に、フォームのURLと連絡先の担当者を確認する。
• 入力、確認画面、完了画面を実際にたどる。エラーや送信先URLを記録する。
• 事業者側の受付記録、通知、自動返信を必要に応じて照合する。
• テスト用の記録と本来の問い合わせを区別する。複数の方式を使う場合は経路別に試す。

サイトを開く入口も確認します。HTTP側からHTTPSへ転送する設定をした場合は、トップだけでなく旧URLから必要な下層に進めるかを調べます。フォーム入力中に予期せず別ドメインへ移動した場合は、利用者が何を操作しているか判断できる案内と、提供元が示す設定を照合します。申込が届かない場合は、受付記録と通知を分けて確認してください。ページの住所そのものを変えた場合は、変更前後のURLと、実際に開けたかを表に残します。

自分で直す場所を絞れないときは、「HTTPSにしたら全部壊れた」よりも、どのページで何が止まったかを伝えるほうが調べてもらいやすくなります。まず、自分の公開先の設定と、外部サービスから取得する部品の設定を分けて、相談する相手を選びます。

直した後は、同じページを同じ順番で開きます。画像、必要なスクリプト、フォーム、関連ページへ進むリンクを別々に検収します。キャッシュなどの影響を受けそうな場合は、通常の閲覧と新しいタブや別の環境を分けて記録します。公開先の証明書や外部サービスを変えた時はこの表を見直し、送信が使われるページでは受信側まで確認してください。

確認に使った資料

• MDN Mixed content
• Let's Encrypt よくある質問
• エックスサーバー 公式マニュアル
• エックスサーバー 公式マニュアル 2

情報確認 2026/11/09。製品・サービスの仕様は参照先でご確認ください。