2026年7月11日
2026年7月11日
WordPressのシリアライズされたデータを安全に検索・置換するツールと手順
WordPress のデータベースで URL やドメインを一括置換するときは、SQL の REPLACE 文やテキストエディタでのダンプ書き換えではなく、シリアライズされたデータを解釈して置き換えるツールを使います。代表的なのは WP-CLI の wp search-replace と、プラグインの Better Search Replace です。シリアライズされた値は文字数を内部に持っているため、単純な置換では文字数がずれて値が読めなくなり、ウィジェットやテーマの設定が消えたように見えるからです。この記事では、壊れる仕組み、ツールの選び方、バックアップから確認までの安全な手順を説明します。
なぜ単純な置換で壊れるのか
WordPress やプラグインは、配列やオブジェクトを wp_options や wp_postmeta に保存するとき、PHP の serialize() で文字列に変換します。文字列の値には、その長さ(バイト数)が一緒に記録されます。
a:1:{s:4:"logo";s:31:"http://example.com/img/logo.png";}
s:31 は「次の文字列は31バイト」という意味です。ここで http://example.com を https://www.example.jp に SQL で置き換えると、中身は35バイトに増えるのに s:31 は残ります。
a:1:{s:4:"logo";s:31:"https://www.example.jp/img/logo.png";}
実際の長さと記録された長さが合わないため、読み込み時の unserialize() が失敗し、WordPress はその値を正しく取り出せません。結果として、テーマのカスタマイザー設定、ウィジェット、プラグインの設定などが初期状態に戻ったように見えます。日本語を含む値ではバイト数のずれがさらに起きやすくなります。
シリアライズ対応のツールは、値をいったん読み解いてから文字列を置き換え、長さを計算し直して保存し直します。これが「安全に置換できる」理由です。
使えるツール
WP-CLI の wp search-replace(サーバーで作業できるなら第一候補)
WP-CLI に標準で含まれるコマンドです。シリアライズされたデータに対応し、事前に変更件数を確認する --dry-run が使えます。SSH で接続できる環境なら、大きなデータベースでもタイムアウトの心配が少なく、作業の記録も残しやすい方法です。
Better Search Replace(管理画面から作業したい場合)
管理画面から対象テーブルを選んで置換できるプラグインです。実行前に件数だけを確認するドライラン相当の機能があります。大きなテーブルではブラウザ経由の処理が長くなるため、時間がかかる場合は WP-CLI を検討してください。作業が終わったらプラグインを停止・削除しておくと、管理画面に強力な操作の入口を残さずに済みます。機能の詳細や無料版・有料版の区別は、提供元の説明で確認してください。
移行系プラグインの置換機能
WP Migrate や Duplicator など、サイト移行用のプラグインにはエクスポートや移行の過程で URL を置き換える機能があります。サーバー移転とドメイン変更を同時に行うなら、移行ツールの置換機能に任せる方が手順を減らせます。
単体スクリプト型ツールの注意点
Search Replace DB(interconnect/it)のように、PHP ファイルをサーバーに置いてブラウザから実行するツールもあります。作業後にそのファイルを残すと、第三者にデータベースを書き換えられる入口になります。使った場合は作業直後に削除し、可能なら IP 制限やベーシック認証をかけた状態で使ってください。
WP-CLI での安全な手順
ここでは http://old.example.com から https://new.example.com への置換を例にします。作業は先にステージング環境で通してから本番に適用します。
1. バックアップを取る
cd /var/www/example.com/public # WordPress のインストール先
wp db export ~/backup/before-replace-$(date +%Y%m%d-%H%M).sql
置換は元に戻すコマンドがありません。エクスポートしたファイルのサイズが極端に小さくないかも確認しておきます。
2. 置換文字列を決める
置換する文字列は、できるだけ長く具体的にします。old.example.com だけを指定すると、メールアドレスや別サブドメインの一部まで置き換わることがあります。プロトコルを含む完全な URL で指定し、http と https、www の有無が混在している場合は、それぞれを別の実行として扱う方が結果を追いやすくなります。
3. ドライランで件数を確認する
wp search-replace 'http://old.example.com' 'https://new.example.com' \
--skip-columns=guid --report-changed-only --dry-run
--dry-run を付けると、実際には書き換えずにテーブル・カラムごとの置換件数を表示します。--skip-columns=guid は、投稿の識別子として使われる guid を対象から外す指定です。guid は RSS リーダーなどが記事を識別するために使うことがあり、公開済みサイトでは変えない方がよいとされています。
想定外のテーブルで大量に件数が出た場合は、そこで止めて中身を確認します。
4. 本番実行
wp search-replace 'http://old.example.com' 'https://new.example.com' \
--skip-columns=guid --report-changed-only
WordPress のテーブル接頭辞に一致しない独自テーブルにも URL が入っている場合は、--all-tables-with-prefix(接頭辞が付いたテーブルすべて)や --all-tables を検討します。範囲が広がるほど意図しない置換の可能性も増えるため、ドライランの結果を見て判断してください。
5. エスケープされた形の URL も確認する
ページビルダーの中には、データを JSON で保存し、スラッシュを \/ とエスケープしているものがあります。その場合、通常の URL 表記では一致しません。
wp search-replace 'http:\/\/old.example.com' 'https:\/\/new.example.com' \
--skip-columns=guid --report-changed-only --dry-run
Elementor のように、プラグイン自体が URL 置換の機能を用意しているものもあります。そうした機能がある場合は、プラグインの説明に従う方が安全です。base64 で符号化して保存されたデータなど、ツールが中身を解釈できない形式は置換されない点にも注意してください。
6. キャッシュを消して表示を確認する
wp cache flush
wp rewrite flush
オブジェクトキャッシュやページキャッシュ、CDN に古い URL が残っていると、置換が効いていないように見えます。キャッシュを消したうえで、トップページ、固定ページ、ウィジェット、メニュー、テーマのカスタマイザー、主要プラグインの設定画面を確認します。
マルチサイトの場合
マルチサイトでは、サイトごとにテーブルが分かれています。ネットワーク全体を対象にするなら --network を付けます。ドメインの情報は wp_blogs や wp_site にも保存されているため、ドメイン変更ではこれらの値も一致しているかを確認してください。特定のサイトだけを対象にする場合は --url でそのサイトを指定します。
よくあるつまずき
- 置換後にカスタマイザーの設定が消えた: 置換前に SQL やエディタで書き換えたことがあると、その時点でシリアライズが壊れています。バックアップから戻して、ツールでやり直すのが近道です。
- 一部の画像だけ古い URL のまま: 投稿本文に直書きされた URL、エスケープされた JSON、CSS ファイルの中など、データベース以外に書かれている可能性があります。
- 処理が途中で止まる: 管理画面のプラグインではタイムアウトしやすくなります。WP-CLI に切り替えるか、テーブルを分けて実行します。
コマンドのオプションはバージョンで追加・変更されることがあります。使う前に wp help search-replace で手元のバージョンの説明を確認してください。この記事の内容は WP-CLI 2 系の説明(2026年10月現在)に基づいています。
まとめ
- シリアライズされた値は文字列の長さを持つため、SQL の REPLACE やエディタでの置換では壊れる。
- サーバーで作業できるなら wp search-replace、管理画面からなら Better Search Replace が使いやすい。単体スクリプト型は作業後すぐ削除する。
- 置換前にバックアップを取り、--dry-run で件数を確認してから実行する。guid は対象から外す。
- エスケープされた JSON や独自テーブル、マルチサイトの wp_blogs など、標準の置換で届かない場所を個別に確認する。
- 実行後はキャッシュを消し、主要な画面と設定を目で確かめる。