WordPress移行後に発生しがちな不具合と解決策｜SSL設定・URL置換ミス例など徹底解説 | WPセンターブログ

WordPressサイトを別サーバーへ移行した後、「思ったように画像が表示されない」「内部リンクが404になる」「プラグインが動かない」などの細かな不具合に頭を抱えた経験はありませんか？移行自体は問題なく完了していても、SSL設定ミスやデータベースのURL置換漏れ、キャッシュプラグインの残留設定など、現場レベルでは頻繁にトラブルが発生します。本記事では、Mixed Content問題やURL置換ミスといった移行後の“あるある”不具合を徹底解説。自力で解決できるステップから、移行後の保守サービス検討までを網羅し、万一のトラブル時にも安心して対処できるようナビゲートします。

画像・CSSが読み込まれないMixed Content問題
内部リンクとパーマリンクの404エラー
プラグイン動作不良とキャッシュ系設定残留
PHPバージョン・サーバー環境の不一致によるエラー
wp-config.php・.htaccessの設定ミス
リダイレクト・パーマリンク設定の不整合
移行後のセキュリティ・保守対応の重要性
まとめ

画像・CSSが読み込まれないMixed Content問題

WordPress移行後、HTTPS対応したはずなのにブラウザのデベロッパーツールで「Mixed Content」エラーが出て画像やスタイルシートが読み込まれないケースが非常に多いです。結論から言うと、SSL化はサイト全体がHTTPSで統一されていないと機能せず、移行後のURL置換ミスが原因です。

Mixed Contentとは

「Mixed Content」とは、HTTPSサイト内でHTTPリソース（画像、CSS、JavaScriptなど）を読み込もうとした際に発生するブラウザのセキュリティ警告です。Google ChromeやFirefoxは、外部から読み込むHTTPリソースをブロックしてしまい、結果としてページの表示崩れや機能不全を引き起こします。特にWordPressの移行では、旧サイトのURL（http://～）がデータベースやテーマファイル、プラグイン設定に残っているため、意図せずHTTP版のリソースを参照してしまいがちです。

原因とリスク

データベース内のURL置換漏れ：投稿本文・カスタムフィールド・ウィジェット設定などに旧URLが残る
テーマやプラグインのハードコーディング：functions.phpやheader.phpで直接http://example.comを読み込む
外部サービス呼び出し：Google FontsやCDNをHTTPで参照している

これらが混在すると、ユーザーに「鍵マーク」が表示されず、サイトの信頼性低下や検索順位の影響が懸念されます。また、証明書発行元によってはSSL設定が適切でないと再発行が拒否される場合もあり、運用コストや作業時間が余計にかかるリスクがあります。

解決策（SSL再構成手順とプラグイン紹介）

まずは、データベース全体のURL置換を行い、HTTP→HTTPSに一括置換します。以下の手順をおすすめします。

バックアップ取得：万が一のトラブルに備え、データベースとファイル一式をバックアップ。
プラグイン導入：Search & Replace ProやBetter Search Replaceなどで、http://your-domain.com を https://your-domain.com に一括置換（シリアライズ対応機能必須）。
テーマ内ハードコード確認：header.php・footer.php・functions.phpを開き、http:// の記述をすべて https:// に修正。
外部リソース呼び出し見直し：Google FontsやCDNはプロトコル相対URL（//fonts.googleapis.com）やHTTPS版URLに書き換え。
プラグイン設定クリア：キャッシュ系プラグイン（WP Super Cache, W3 Total Cacheなど）が残した一時ファイルを削除し再生成。

加えて、Really Simple SSLプラグインを使うと、サイト全体のHTTPSリダイレクトやMixed Content修正を自動化でき、手動作業のミスを減らせます。導入後は、ブラウザでデベロッパーツールの「Console」を開き、Mixed Contentエラーが解消されたことを必ず確認してください。

これらの手順を踏むことで、移行後の「画像やCSSが読み込まれない」Mixed Content問題は確実に解消できます。SSL設定とURL統一が完全に行われれば、鍵マークが表示され、ユーザーの信頼性も回復します。

内部リンクとパーマリンクの404エラー

移行後、サイト内のリンクをクリックすると「404 Not Found」が頻発する場合、結論としてはデータベース内に旧URLのまま残存しているリンクが原因です。特にWordPressでは内部リンクやパーマリンク構造がデータベースの複数箇所に保持されるため、URL置換の不備が404エラーを生み出します。

データベースURL置換の落とし穴

WordPressでは投稿本文だけでなく、カスタムフィールド、ウィジェット内テキスト、メニュー設定、さらにはテーマのオプションなど、さまざまな箇所で旧URLを参照しています。単純に「wp_postsテーブルのpost_contentだけ」を置換しても、他テーブルに残ったままの旧URL参照がリンク切れを誘発します。特に「wp_postmeta」テーブルの serialized（シリアライズ）データは、文字列長まで保持されており、単純置換ツールでは破損を招きやすいため要注意です。

serializedデータ対応方法

シリアライズされたデータを安全に置換するには、以下のプラグインやCLIツールが有効です：

WP-CLIの search-replace コマンド：
wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --precise --recurse-objects
これによりserializedデータも安全に更新されます。
Better Search Replace プラグイン（Delicious Brains社製）：
WordPress管理画面でのシリアライズ対応置換が可能。テストモードでプレビューチェックも行えます。
Search & Replace Pro：
高度なシリアライズ・データベース検索・置換機能を提供し、テーマオプションやウィジェット内のURLも一括変換。

これらのツールを用いることで、wp_optionsやwp_postmeta内の深部データまで誤りなくHTTPS化できます。

検証手順とツール

テストドメインで検証：本番環境に置換をかける前に、移行済みのステージング環境でURL置換を実行し、「404エラー一覧」を生成します。
Broken Link Checker プラグイン導入：管理画面→プラグイン→新規追加で「Broken Link Checker」をインストール。サイト全体をスキャンし、リンク切れURLのリストを可視化。
外部ツールによるクロール検証：Screaming Frog SEO Spiderなどを用いて全URLをクロール。HTTPステータスコードが「404」「410」になっているURLをピックアップ。
置換漏れ箇所を手動/自動で修正：プラグイン検出箇所やクロール結果を元に、該当テーブルやテーマ設定、ウィジェット画面で直接修正。

このように、シリアライズ対応の一括置換とリンク検証ツールを組み合わせることで、ほぼ全ての内部リンク切れを事前に発見・修正できます。移行後の404トラブルを減らすには、ステージング環境での徹底検証が不可欠です。

以上の手順を実施すれば、内部リンクやパーマリンクの404エラーは大幅に撲滅され、ユーザー体験の向上とSEO評価の維持につながります。

プラグイン動作不良とキャッシュ系設定残留

WordPress移行後、プラグインの機能が正しく動作しない、あるいはキャッシュ系プラグインが旧環境の設定を残したまま動き続けることでサイト表示が崩れるケースが頻出します。結論としては、移行前エンジンや設定がプラグイン内部にキャッシュされており、そのまま新環境へ持ち越されることが原因です。

キャッシュプラグインの影響

代表的なキャッシュ系プラグイン（WP Super Cache、W3 Total Cache、WP Rocketなど）は、移行時に以下の問題を引き起こします。まず、プラグインが生成したキャッシュファイル（.htmlやオブジェクトキャッシュ）やminify済みCSS・JSファイルが新サーバーへコピーされることで、新しいパスやドメイン名に対応せず古いURL参照のまま残ってしまいます。結果的に「404エラー」「Mixed Content」「JavaScriptエラー」など複数の不具合を同時に引き起こし、サイトの表示・機能を破綻させるのです。

設定クリア手順

これらを解決するには、まずキャッシュ関連ファイルと設定を完全にリセットすることをおすすめします。具体的には：

WordPress管理画面から対象プラグインを「無効化」→「アンインストール」
FTP/SFTPで wp-content/cache/ フォルダおよび wp-content/w3tc-config/ 配下のディレクトリを完全削除
テーマや functions.php、 .htaccess に手動で追記したキャッシュ設定（Expiresヘッダー、gzip圧縮など）があれば全てコメントアウトまたは削除
データベースのオプションテーブル（wp_options）内に残るキャッシュ設定（w3tc_ や rocket_ で始まるオプション）を検索し、該当レコードを削除
サーバー側のOPcacheやMemcached、Redisキャッシュが有効なら、管理ツールまたはSSHからクリアコマンドを実行

代表的プラグイン再設定法

設定をクリアしたら、改めてキャッシュプラグインを導入し直します。以下の手順で再構築してください。

WP Rocket（推奨）を例に、キャッシュ保存パスを移行後の wp-content/cache/rocket/ に指定。ドメイン変更オプションを必ず有効化し、古いキャッシュの残留を防止。
W3 Total Cache 使用時は、プラグインダッシュボードの「General Settings」でキャッシュディレクトリを再設定し、Database Cache・Object Cacheのチェックを外してから再保存。
設定後は必ず「Cache Purge」→「Preload」を実行し、最新のHTMLファイルを生成。プラグインのプリロード機能が旧データを参照しないことを確認。
最終的にブラウザキャッシュを無効化したうえで表示検証し、ページソースに古いURLやファイルパスが残っていないことをデベロッパーツールでチェック。

この手順を踏むことで、移行後のプラグイン動作不良は根本的に解消し、キャッシュ設定の残留による複合的不具合から脱却できます。サイトパフォーマンスを向上させつつ、新しい環境変数に最適化されたキャッシュ体制を構築しましょう。

PHPバージョン・サーバー環境の不一致によるエラー

WordPress移行後、「500 Internal Server Error」や「Parse error」など致命的なエラーが発生する場合、結論としては旧環境と新環境のPHPバージョンやPHP拡張モジュール、メモリ上限設定が合致していないことが大きな原因です。

例えば、移行先サーバーのPHPが7.4から8.0へアップグレードされているにもかかわらず、テーマやプラグインの一部がPHP8.0非対応の書き方（廃止された関数呼び出しや古い構文）を含んでいると、移行直後にサイト全体が真っ白になってしまいます。また、imagickやgdなどの画像処理拡張、mbstringやcurlといった必須モジュールがインストールされていない場合、管理画面の一部機能やフロントの表示が動作せず、予期せぬエラーが頻発します。

さらに、memory_limitやmax_execution_timeなどのPHP設定が小さいと、データベース検索置換やプラグイン更新、大量ファイルの読み書き処理時にタイムアウトが発生しやすく、500エラーの原因となります。特に大規模サイトでは、移行先のサーバー設定が旧環境よりも厳しめになっていることが多く、注意が必要です。

環境差異の主要ポイント

PHPバージョン：7.4→8.x移行時の非推奨・廃止関数対応
必須PHP拡張モジュール：gd, imagick, mbstring, curl, zip, xml などの有無
PHP設定値：memory_limit, post_max_size, upload_max_filesize, max_execution_time
サーバーOSおよびWebサーバー：Apache vs Nginx設定ファイルの違い、モジュール読み込み方法の違い

エラーメッセージ例と原因特定

Fatal error: Uncaught Error: Call to undefined function mb_strlen() → mbstringモジュール未インストール
Parse error: syntax error, unexpected ':' → PHP7.x以前の構文をPHP8.0で実行しようとしている
Allowed memory size of 67108864 bytes exhausted → memory_limitが64MBに設定されており、大量処理時にメモリ不足
Maximum execution time of 30 seconds exceeded → スクリプトの実行上限が30秒のままになっている

これらのメッセージは、移行後すぐに表示されるWPの白画面（WSOD）やPHPエラー画面で確認できるため、まずはログ（error_log）をチェックし、原因モジュールや設定を特定しましょう。

環境合わせ手順

PHPバージョンの統一：サーバー管理画面やSSH上で php -v コマンドを実行し、旧サーバーと同じMajor/Minorバージョンへ合わせる。
必須拡張モジュールの確認・インストール：php -m コマンドでインストール済みモジュールを確認し、足りないものはパッケージマネージャ（apt/yum）やPECLで追加。
PHP設定の最適化：php.ini の memory_limit を最低128MB以上、可能なら256MBに設定し、post_max_size と upload_max_filesize はサイト規模に応じて増加。max_execution_time は60秒以上に設定。
Webサーバー設定調整：Apacheなら mod_php 設定、Nginx＋PHP-FPMなら php-fpm.conf の実行ユーザー・プロセス数・タイムアウト設定を確認。必要に応じて再起動。
PHPコード互換性チェック：WP-CLIの phpcompatibility チェックツールやIDEの静的解析プラグインを使い、テーマ・プラグイン内の非互換コードを洗い出して修正。

これら一連の手順を実施することで、移行後の致命的なPHPエラーやタイムアウト問題を防ぎ、旧環境と同等またはそれ以上の安定稼働を実現できます。特に大規模サイトやミッション・クリティカルな業務サイトでは、事前にステージング環境で徹底検証すると安心です。

wp-config.php・.htaccessの設定ミス

移行後、「データベース接続確立エラー」や「403 Forbidden」、「500 Internal Server Error」が表示される場合、結論としては wp-config.php または .htaccess の記述に誤りがあることが多いです。特にパスや認証情報、リダイレクトルールの変化に未対応だと、WordPressが正常に動作しません。

wp-config.phpのDB接続エラー

移行元と移行先でデータベース名、ユーザー名、パスワード、ホスト名（DB_HOST）のいずれかが異なると、以下のようなエラーが発生します。

Error establishing a database connection → wp-config.php の DB_NAME / DB_USER / DB_PASSWORD / DB_HOST に誤り
Access denied for user 'user'@'localhost' → データベースユーザーに適切な権限が付与されていない

対策手順：

FTPで移行先の wp-config.php をダウンロードし、テキストエディタで開く。
移行先ホスティングのコントロールパネルでデータベース情報（DB名・ユーザー名・パスワード・ホスト）を確認。
wp-config.php の該当定数を正確に上書きし、改行や引用符の有無にも注意。
保存後、再アップロードしてブラウザで再読み込み。
問題解消しない場合は、phpMyAdmin などでユーザー権限（GRANT ALL）を再付与。

.htaccess書き換えミス

.htaccess ファイルはリライトルールやアクセス制御を担う重要設定ファイルです。移行に伴いパスやディレクティブの記述が変わると、以下のような不具合につながります。

403 Forbidden → 権限ブロックや無限リダイレクト
500 Internal Server Error → 記述ミスやモジュール未ロード

よくあるミス例と修正例：

問題修正内容

旧ドメインがハードコーディングされている RewriteBase /new-folder/ に修正

Options +FollowSymLinks が無効サーバー設定に合わせ Options +SymLinksIfOwnerMatch または削除

WordPress標準リライトルールが欠如

問題	修正内容
旧ドメインがハードコーディングされている	`RewriteBase /new-folder/` に修正
`Options +FollowSymLinks` が無効	サーバー設定に合わせ `Options +SymLinksIfOwnerMatch` または削除
WordPress標準リライトルールが欠如	以下のデフォルト設定を再追加： `# BEGIN WordPress RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # END WordPress`

以下のデフォルト設定を再追加：

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

正しい再生成方法

管理画面→「設定」→「パーマリンク」→「変更を保存」をクリックし、WordPressに .htaccess を自動生成させる。
FTPで .htaccess が上書きされたことを確認し、不要なカスタムルールを再追加。
サーバーApache設定で AllowOverride が適切に許可されていることを確認。
再度ブラウザキャッシュをクリアし、アクセス制御やリダイレクト動作を検証。

これらの手順により、wp-config.php・.htaccess 関連の致命的エラーを迅速に解消し、移行後のWordPressサイトが正しく稼働します。

リダイレクト・パーマリンク設定の不整合

別ドメインへの移行やサブディレクトリ構成の変更時にリダイレクト・パーマリンク設定が不整合を起こすと、結論としては適切な301リダイレクトとパーマリンクの再生成が必須です。放置するとSEO評価の著しい低下やユーザー離脱が発生します。

301リダイレクト設定

移行前のURL（例：/old-page/）から移行後のURL（例：/new-page/）へ適切にリダイレクトするには、.htaccess に以下を追加します。

# Redirect 301 old to new
Redirect 301 /old-page/ https://your-domain.com/new-page/

サイト全体を一括リダイレクトする場合は、

# Redirect entire site to new domain
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

これにより、旧URLへの流入ユーザーや検索エンジン評価を新サイトへ継承できます。

パーマリンク再生成

旧サイトと同じパーマリンク構造を使用している場合でも、移行後に内部キャッシュや .htaccess の古いルールが残ると、パーマリンクが正しく適用されません。管理画面→「設定」→「パーマリンク」→「変更を保存」 で再生成し、最新のリライトルールを反映させましょう。

注意ポイント

リダイレクトループ防止のため、.htaccess の書き換えルールは上部に配置。
HTTP⇔HTTPS両方向のリダイレクトは避け、常時HTTPS化 を徹底。
モバイル用サブドメインやサブディレクトリがある場合は、個別にリダイレクト設定を追加。
リダイレクト設定後に Screaming Frog などで検証し、ステータスコードが301になっているか全URL確認。

これらの対策により、移行後のリダイレクト・パーマリンク関連のトラブルを回避し、SEO評価とユーザー体験を損なわないサイト移行が可能になります。

移行後のセキュリティ・保守対応の重要性

移行作業が完了して一安心……ではありません。結論としては、移行後こそセキュリティチェックと定期保守が重要です。移行時に新たな脆弱性が混入しやすく、SSL設定やファイアウォール、プラグイン・テーマの更新ルールなどを放置するとリスクが高まります。

移行後リスク管理

SSL設定の自動更新不備：Let’s Encrypt など無料SSLは90日ごとに更新が必要。自動更新スクリプトを設定。
管理者アカウントの脆弱性：パスワード管理と二段階認証（Two-Factor Authentication）の導入。
プラグイン・テーマの更新：移行直後はバージョンアップが集中しやすい。ステージング環境で更新検証後、本番へ適用。
Webアプリケーションファイアウォール（WAF）：Cloudflare や Sucuri などでIP制限・攻撃シグネチャ防御を導入。

保守サービスの必要性

自社でメンテナンスできない場合、専門の保守サービス利用を検討しましょう。24時間監視・バックアップ・セキュリティパッチ適用・トラブル対応がセットになったプランなら、万一の障害時にも迅速に復旧できます。特に金融系・会員制サイト・ECサイトなど、ダウンタイムが大きな損失につながる場合は不可欠です。

次にやるべきこと

移行直後のサイト診断レポート作成（WPScan など脆弱性スキャンツール活用）
定期バックアップスケジュールの設定（データベース＋ファイルを週次以上で取得）
更新ルールのドキュメント化と担当者共有
セキュリティプラグイン（Wordfence, iThemes Security 等）の導入と初期設定
保守サービス選定・契約検討（SLA、対応時間、費用を比較）

以上を踏まえ、移行後の運用フェーズで万全のセキュリティ・保守体制を構築することで、サイトの安定稼働と企業信頼性を長期的に維持できます。

まとめ

WordPress移行後に頻発する不具合は、SSL設定、URL置換、キャッシュクリア、環境合わせ、設定ファイル再生成、リダイレクト設定、そして運用後の保守体制構築という一連のステップを漏れなく実行すれば確実に解消・予防できます。移行前のバックアップ取得とステージング環境での徹底検証が成功の鍵。万一のトラブル時も、本記事の手順に従えば迅速に復旧可能です。さらにセキュアな運用と定期的な保守をプロに任せれば、リスクを最小限にでき、サイト運営に集中できます。