2026年10月1日

Duplicatorでサイトを複製したのにURLが書き換わらないときの原因と対処

プラグイン関連

Duplicatorで複製したサイトに旧URLが残る原因は、主に「インストーラーに入力した新URLの誤り」「wp-config.phpでのURL固定」「置換の届かない場所に書かれたURL」「キャッシュ」の4つです。この記事では、旧URLがどこに残っているかを調べる方法と、原因ごとの直し方を説明します。最後にWP-CLIで安全に一括置換する手順も紹介します。

DuplicatorにはLite（無料版）とPro版があり、インストーラーの画面構成や選べるオプションはバージョンで変わります。本文では各設定を目的で説明しています（2026年10月現在）。データベースを書き換える作業になるため、始める前に複製先サイトのデータベースをエクスポートしておいてください。

旧URLがどこに残っているかを調べる

まず「どこで」旧URLが使われているかを特定します。症状によって原因の候補が変わるからです。

管理画面にログインすると旧サイトに飛ばされる：siteurl と home の設定が旧URLのまま、または wp-config.php で固定されています。
ページは新URLで開くが、画像やリンクだけ旧URLを指している：本文やメタデータ内のURLが置換されていません。
見た目（CSS）だけ旧サイトから読み込まれている：ページビルダーが生成したCSSファイルや、テーマ設定に保存されたURLが残っています。
ログインしていると正しいが、ログアウトすると旧URLが出る：キャッシュの問題である可能性が高いです。

ブラウザでページのソースを表示し、旧ドメインで検索すると、どのタグ（img、link、a など）に残っているかが分かります。WP-CLIが使える環境なら、次のコマンドでサイトURLの設定値を直接確認できます。

wp option get home
wp option get siteurl

原因1：インストーラーに入力した新URLが正しくない

Duplicatorのインストーラー（installer.php）は、新しいURLとパスを入力させ、データベース内の旧URLをその値に置き換えます。ここで入力したURLが本来のものと違うと、置換自体は成功しても結果が意図と合いません。

よくある間違いは次のとおりです。

http と https の取り違え
www の有無の取り違え
サブディレクトリへ設置したのに、ドメインだけを入力した
末尾にスラッシュを付けた（WordPressのサイトURLは末尾スラッシュ無しが基本です）

インストーラーは自動で現在のURLを候補として入れることが多いので、そのまま進めずに目で確認してください。間違えた場合は、後述のWP-CLIで正しいURLへもう一度置換すれば直せます。

原因2：wp-config.phpでURLが固定されている

複製元の wp-config.php に次のような定数があると、データベースの値に関係なくこのURLが使われます。管理画面の「設定」→「一般」でURL欄がグレーアウトしているなら、この状態です。

define( 'WP_HOME', 'https://old.example.com' );
define( 'WP_SITEURL', 'https://old.example.com' );

複製先の wp-config.php を開き、新URLに書き換えるか、データベースの値を使うなら行ごと削除します。マルチサイトの場合は DOMAIN_CURRENT_SITE や PATH_CURRENT_SITE も確認対象です。マルチサイトの複製は Duplicator の Pro 版の機能とされているため、Lite 版で複製した場合は構成に無理がないかも確認してください。

原因3：置換が届かない場所にURLがある

Duplicatorはデータベース内のURLを置換し、PHPのシリアライズ形式で保存されたデータも壊さないように処理します。それでも、次の場所は置換の対象外になったり、書式の違いで一致しなかったりします。

テーマやプラグインのファイルに直接書かれたURL子テーマの PHP や CSS、カスタムHTMLに旧URLをそのまま書いていると、データベースの置換では変わりません。テーマフォルダ内を旧ドメインで検索して書き換えます。今後のためには、home_url() や get_stylesheet_directory_uri() のような関数でURLを組み立てる書き方に直しておくと、移転のたびに困ることがなくなります。

スラッシュがエスケープされたURLページビルダーなどがJSON形式でデータを保存すると、URLが https:\/\/old.example.com のように \/ で記録されることがあります。通常の文字列置換ではこの形に一致しないため、エスケープされた形でも別途置換が必要です（手順は後述）。

ページビルダーが生成したCSSファイルElementorなどのビルダーは、デザイン設定から CSS ファイルを生成して uploads フォルダに保存します。データベースを置換しても、生成済みのCSSファイルには旧URLが残ります。ビルダーの管理画面にあるCSSの再生成機能や、URL置換のツールを使ってください（メニューの位置はバージョンで異なります）。

置換対象から外れたテーブルインストーラーの詳細オプションで置換するテーブルを絞った場合や、WordPress以外のプラグインが独自の接頭辞で作ったテーブルは、置換されていないことがあります。

原因4：キャッシュに旧URLが残っている

ページキャッシュ、オブジェクトキャッシュ、CDN、ブラウザのキャッシュのいずれかに、複製元の内容が残っている場合があります。特に複製元のキャッシュプラグイン設定や wp-content 内のキャッシュフォルダをそのまま持ち込むと、旧URLのHTMLが返り続けます。

キャッシュプラグインの管理画面からキャッシュを削除し、オブジェクトキャッシュを使っているなら次のコマンドで消去します。CDNを使っている場合はCDN側のパージも行ってください。

wp cache flush

WP-CLIで旧URLを安全に一括置換する

原因が分かったら、WP-CLIの wp search-replace で残りを置換します。このコマンドはシリアライズされたデータを解析して長さを調整しながら置換するため、SQLで直接 REPLACE するより安全です。逆に、SQLファイルをテキストエディタで一括置換すると、シリアライズデータの文字数がずれてウィジェットやテーマ設定が消えることがあるので避けてください。

まずバックアップを取り、--dry-run で何件置換されるかだけを確認します。

wp db export before-replace.sql
wp search-replace 'https://old.example.com' 'https://new.example.com' --all-tables --dry-run

件数とテーブルに問題がなければ、--dry-run を外して実行します。続いて、スラッシュがエスケープされた形も同じように置換します。

wp search-replace 'https://old.example.com' 'https://new.example.com' --all-tables
wp search-replace 'https:\/\/old.example.com' 'https:\/\/new.example.com' --all-tables --dry-run

2つ目の置換も件数を確かめてから --dry-run を外してください。--all-tables は接頭辞の違うテーブルも対象にするオプションです。同じデータベースに別サイトのテーブルが同居している場合は、このオプションを外し、対象テーブルを引数で指定します。

投稿の guid 列は投稿の識別子として扱われるため、公開中のサイトを移転する場合は書き換えないことが WordPress の公式ドキュメントで推奨されています。気になる場合は --skip-columns=guid を付けて除外できます。

WP-CLIが使えないレンタルサーバーでは、「Better Search Replace」のような管理画面から置換できるプラグインを使う方法もあります。こちらも試験実行（dry run）の機能があるので、件数を見てから本実行してください。

置換後の確認

置換が終わったら、次の点を確かめます。

管理画面の「設定」→「一般」でサイトURLが新しい値になっている
「設定」→「パーマリンク」を開いて保存し、リライトルールを更新する
ページのソースを旧ドメインで検索し、残りが無い
画像、フォーム送信、ログイン、問い合わせメールの送信元設定などが新URLで動く

複製元のURLを wp search-replace でもう一度 --dry-run 検索し、0件になれば置換は終わっています。

まとめ

まずページのソースと wp option get home で、旧URLがどこに残っているかを特定します。
インストーラーの新URL入力（https・www・サブディレクトリ・末尾スラッシュ）と、wp-config.php の WP_HOME／WP_SITEURL を最初に確認します。
テーマファイルへの直書き、エスケープされたURL、ビルダーの生成CSS、置換対象外のテーブルはデータベース置換で直らない典型例です。
残りは wp search-replace を --dry-run から始めて置換し、SQLファイルの手作業置換は避けます。
作業前のデータベースバックアップと、置換後のキャッシュ削除を忘れないようにします。