WordPressでHTTPSの警告や画像の欠落が出るとき｜証明書・混在コンテンツ・参照元の確認

WordPressでHTTPSの警告や画像の欠落が出たときは、ページへ接続できない警告なのか、開いたページの一部が読み込めないのかを分けて確認してください。証明書の問題と、HTTPSのページからHTTPの資源を要求する混在コンテンツは、同じ原因とは限りません。

企業担当者は、対象URLと警告の内容、端末、発生時刻を整理できます。制作会社は、接続先、証明書、資源の通信と参照元を調べ、必要な修正と公開検収を分けて進めます。警告を無視して入力する方法や、一括の設定変更で済ませる方法は採りません。

1. 接続の警告と、ページ内の欠落を分ける

対象URLを確認し、ブラウザーがページを開く前に警告するのか、ページは開くが画像・CSS・スクリプトなどが欠けるのかを記録します。表示された警告の文面、発生日時、端末とブラウザー、正常なページがあるかも控えてください。

管理画面だけ、特定のページだけ、別の配信先の画像だけなど、範囲を限定します。誤入力や別の確認用ドメインへアクセスしていないかも確かめます。警告のある接続へ、ログイン情報や顧客データを入力しないでください。

本文の変更後に画像だけが古く見える場合は、通信の警告と分けて画像URLとキャッシュの確認を使います。

2. 証明書は対象ホストと配信構成を確認する

保守担当は、警告が出たホスト名、証明書の対象、有効期間、接続先と配信構成を確認します。wwwの有無、サブドメイン、CDNやプロキシなどで、同じ会社のサイトでも通信の経路が異なる場合があります。

証明書の契約・自動更新があることだけで、現在の公開接続が正常とは確認できません。期限、更新結果、通知先、担当、複数の配信箇所を照合します。WordPress公式のHTTPS説明も、サーバー側の設定と配信構成を前提にしています。

時刻や通信環境など、端末側の条件が関係する場合もあります。原因を証明書の期限切れだけに固定せず、確認した範囲と未確認を担当へ渡してください。

3. 混在コンテンツの警告を資源ごとに読む

MDNの混在コンテンツの説明では、HTTPSで読み込むページが安全でない経路の資源を要求する状態を説明しています。ブラウザーが自動的にHTTPSへ変える資源と、ブロックする資源があり、すべてが同じ動作になるとは限りません。

制作担当は開発者ツールのConsoleとNetworkを開き、記録しながら対象ページを読み込みます。警告された資源の元URL、最終URL、状態、種類を控えます。画像、CSS、スクリプト、埋め込み、フォームやAPIの要求、ダウンロードは個別に確認してください。

ブラウザーが補正して表示した画像も、元の参照が正しいとは限りません。また、404やアクセス拒否など別の原因の欠落を、すべて混在コンテンツと呼ばないようにします。

4. HTTPの参照が、どこから出力されたかを探す

問題のURLを、投稿本文、入力項目、テーマ設定、テンプレート、CSS、追加機能、外部の埋め込みなどへ対応づけます。画面の一つの画像を直す場合も、そのURLが保存される場所と出力される場所を確認してください。

データベース内に文字があることだけで、一括置換を実行しません。独自の保存形式や外部URL、メールや連携先などへ影響する場合があります。更新画面の仕様が関係するなら入力項目と出力の確認と合わせて調べます。

5. HTTPSに対応する行先を確かめて修正する

対象資源がHTTPSで正しく取得できるかを先に確認します。文字列をhttpからhttpsへ変えれば、提供元が必ず同じファイルを返すとは限りません。外部の資源では、提供元の現在の埋め込み方法や利用条件も確認します。

修正は対象を限定し、原本、差分、影響、試験、戻し方を準備して承認後に行います。WordPressアドレスやサイトアドレス、転送、DNS、認証、索引の設定変更は、ページ内の資源修正と同じ作業ではありません。

プロキシを使う構成では、HTTPSの判定や転送の条件が関係する場合があります。サーバーへ例の設定をそのまま加えず、実際の経路を担当と確認します。試験環境はデータと連携先の隔離を確認して利用してください。

6. 画面と、必要な操作を読み戻す

修正後は同じURLと条件でページを開き、通信の警告、画像、スタイル、処理、行先を確認します。PCとスマートフォン、サイズ別の画像、共通部品が使われる関連ページも、対象範囲に応じて試験します。

フォームやAPI連携があるなら、入力・送信・保存・受信を合意した試験で分けて確認します。ページに画像が戻ったことだけで、受付や連携も正常と判断しません。APIの保存失敗は、要求と応答を調査担当へ渡します。

確認日時、修正した参照、変更後の結果、未確認を記録します。特定の端末でだけ再現する場合も、解決済みとせず条件を残してください。

7. 証明書と、素材の運用を引き継ぐ

証明書の通知先、更新担当、異常時の連絡先を、ドメインとサーバーの運用表へ加えます。素材や埋め込みを追加する担当には、承認した行先を使い、公開後の通信と表示を確かめる手順を残します。

WordPressの保守チェックリストと合わせ、契約の予定と実際の接続確認を分けて記録します。HTTPSで接続できることは、サイトの不正アクセスやアプリケーション全体の安全を保証するものではありません。

8. 記録をそろえ、必要な修正を依頼する

企業担当者はURL、警告と症状、発生時刻、影響する仕事を整理します。制作担当は証明書と配信構成、資源の参照元、必要な差分と検収、戻し方を確認します。

AcquaへはWordPressの表示・参照元の調査、合意した修正と公開検収を相談できます。企業向けWeb制作・運用と制作会社向けWordPress実装・既存修正で現在の案内を確認してください。サーバー・証明書の管理者との分担も個別に決めます。

相談窓口には対象URL、警告、欠けた内容、確認環境、直前の変更をお知らせください。支援後は合意した公開URLと資源が正しく取得され、必要な表示・操作、更新担当と残る課題が確認できる状態を目指します。接続が正常になったことを、検索順位の改善や完全な安全と報告しません。

証明書を更新すれば画像も直りますか？

ページと画像の接続先、参照元、警告を照合します。証明書と混在コンテンツが別の原因の場合があります。

httpを全部httpsへ置換すべきですか？

行先の実体と保存形式、影響を確認します。対象を限定し、承認と試験・復元を用意してください。

PCでは見えるので正常ですか？

スマートフォンやサイズ別画像では異なる資源を使う場合があります。必要な条件で通信と表示を確認します。

HTTPSならサイト全体が安全ですか？

暗号化された通信と、権限・更新・コードの安全性は別です。必要な保守確認も続けます。