WordPress SSL 化後の表示崩れ（mixed content）対処
目次
この記事でわかること
- WordPress SSL 化後に表示が崩れる「mixed content」の原因
- 画像 / CSS / JS / 内部リンクのそれぞれの直し方
- データベース一括置換ツールの使い方と注意点
- 再発を防ぐ運用ルール
「mixed content」とは何が起きているか
mixed content（混在コンテンツ）は、HTTPS ページの中で HTTP 経由のリソース（画像・CSS・JavaScript 等）を読み込んでいる状態です。
ブラウザは「ページは保護されているが、中身が一部保護されていない」と判断し、次のような挙動を取ります。
- 画像が表示されない、または読み込み拒否
- CSS が適用されずレイアウトが崩れる
- JavaScript が動かず、フォームやスライダーが機能停止
- 鍵マークが灰色や警告マーク付きになる
WordPress の SSL 化直後に多発する定番トラブルです。Chrome の警告全体についてはChrome「保護されていない通信」警告の直し方を参照。
原因はデータベース内の URL
WordPress は記事内の画像 URL、メニュー、ウィジェット、テーマ設定など多くの場所で完全 URL（http://example.com/...）をデータベースに保存しています。SSL 化直後は、これらが http:// のまま残ったままです。
サイトアドレス変更だけでは直らない
「設定 → 一般 → サイトアドレス」を https:// に変更しても、過去に投稿した記事内の http:// リンクや、テーマ設定に保存された URL は変わりません。これが mixed content の根本原因です。
直し方の手順
ステップ 1: サイトアドレスを HTTPS に変更
「設定 → 一般」で「WordPress アドレス（URL）」と「サイトアドレス（URL）」の両方を https:// に変更。変更後、自動ログアウトされるので再ログインします。
ステップ 2: データベース内の URL を一括置換
過去記事の http://example.com/... を https://example.com/... に一括置換します。手段は次の 2 つです。
プラグインを使う場合: 「Better Search Replace」プラグインをインストール。「Search/Replace」で http://example.com を https://example.com に置換します。最初は「Run as dry run?」にチェックを入れて影響範囲を確認してから本実行します。
手動 SQL の場合: phpMyAdmin から実行。事前にデータベースのバックアップを必ず取得します。
UPDATE wp_options SET option_value = REPLACE(option_value, 'http://example.com', 'https://example.com');
UPDATE wp_posts SET guid = REPLACE(guid, 'http://example.com', 'https://example.com');
UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://example.com', 'https://example.com');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://example.com', 'https://example.com');
guid の更新は本来推奨されない場合がありますが、SSL 化に伴う変更では実施する判断もあります。サイト構成によって調整します。
ステップ 3: テーマ・プラグインの設定を確認
カスタマイザーや各プラグインの設定画面で、固定 URL を入力する欄が http:// のままになっていないか確認します。よく漏れる箇所:
- ヘッダー / フッターのロゴ画像 URL
- メニュー項目のカスタムリンク
- スライダー / カルーセル画像
- SNS リンクや埋め込み URL
- 外部 CDN を経由した画像
ステップ 4: .htaccess に HTTPS 強制を追加
サイトのルートの .htaccess に次を追記して、http:// でアクセスされても https:// にリダイレクトします。
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
確認と検証
ブラウザの DevTools（Chrome なら F12）の Console タブで、mixed content の警告が残っていないかを確認します。
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS,
but requested an insecure image 'http://example.com/img/logo.png'.
このような警告が出ているファイルが、まだ http:// で読み込まれているリソースです。該当箇所を特定して修正します。
再発を防ぐ運用ルール
- 新規記事の画像挿入時: メディアライブラリから挿入すれば自動的に HTTPS URL になる。外部画像を直接 URL 指定するときは必ず
https://を使う - テーマ・プラグインの更新時: ベンダーの設定リセットで URL がデフォルトに戻ることがある。月次でトップページの DevTools 確認を
- キャンペーンページ追加時: 一時的なページや LP は SSL 設定が漏れがち。年 1 回の棚卸しとサブドメイン SSL は個別取得が必要？で方式を整理
業務影響を考えると、SSL 関連のトラブルは早期発見が重要です。失効時の影響はSSL 失効の業務影響で整理しています。
まとめ
- mixed content は HTTPS ページに
http://リソースが混在することで発生 - WordPress では DB 内の URL が
http://のまま残るのが根本原因 - 直し方は サイトアドレス変更 → DB 一括置換 → 設定確認 → .htaccess 強制の 4 ステップ
- DevTools の Console で残存箇所を必ず確認
まずは現状を把握しましょう
自社の SSL 証明書の有効期限と設定状況は、ドメイン番人のSSL 単発チェックで確認できます。メール認証も含めた総合点検は無料診断をご利用ください。