WordPressの本文内リンクや表記ゆれを、WP-CLIのsearch-replaceで安全に一括置換したい人向けの実務ガイドです。
最短で「バックアップ→Dry-run→本番→検証」の流れを押さえ、URL置換と汎用的な文字列置換の両方に迷わず対応できる到達点まで案内します。検索・置換の基礎から落とし穴まで、現場でそのまま使えるコマンド例で解説します。
この記事で解決できること（URLと文字列の一括置換）
WP-CLIのsearch-replaceを使い、記事本文のURL変更や任意の文字列置換を安全かつ再現性高く実行できます。
具体的には、Dry-runで差分を事前確認し、除外指定やバックアップと組み合わせて本番反映、置換後の検証までをひとつの手順として回せるようになります。HTTP→HTTPSやドメイン移行のような大きな変更にも、表記ゆれ修正のような細かな調整にも同じ流れで対応できます。
典型例（本文リンク変更／ドメイン移行／表記ゆれ修正）
ブログ記事の本文に残った旧URLを新URLにそろえる、ステージングから本番ドメインへ移行する、ブランド名の表記ゆれや余計な文言を統一するといった用途に使えます。
小規模サイトでは一度きりの置換で完了しますが、更新頻度の高いメディアでは再利用できる置換レシピとしてBashにまとめることで、運用負荷を大幅に下げられます。カスタム投稿タイプやメタ情報にも影響するため、サイト全体の整合性を短時間で確保できます。
注意点（シリアライズ破損・uploads直リンク・マルチサイト）
WordPressはオプション値やメタ情報にシリアライズ（配列・オブジェクトの文字列化）を多用するため、DB直編集や不適切な置換は破損を招きます
search-replaceはシリアライズ対応ですが、uploads直リンクのようにファイルシステムとDBが混在するケースは漏れやすいため、正規表現や除外指定、最終の動作確認が重要です。マルチサイトではネットワーク全体と個別サイトで検索範囲が異なるため、対象とオプションの取り扱いを誤らないようにしましょう。
WP-CLI search-replace の基本手順
WP-CLIのsearch-replaceは、WordPressデータベース内のテキストを一括で置換するコマンドです。最大の強みはシリアライズに対応している点で、オプション値やメタデータも安全に処理できます。流れは「Dry-runで確認 → 本番実行 → 検証」の3ステップです。
Dry-runでの事前確認
まずはDry-runで変更箇所を確認します。--dry-runを付けると実際には置換されず、対象件数だけ表示されます。
wp search-replace 'http://old.example.com' 'https://new.example.com' --dry-run
この結果を見て件数やテーブルを確認し、想定通りなら本番置換に進みます。
URL置換（http→https／旧ドメイン→新ドメイン）
サイトのHTTPS化やドメイン変更では、以下のように使います。
# http → https
wp search-replace 'http://example.com' 'https://example.com'
# 旧ドメイン → 新ドメイン
wp search-replace 'old.example.com' 'new.example.com'
メディアURLや内部リンクも含めて一括で修正できます。uploadsディレクトリ内の実ファイルは対象外なので注意が必要です。
汎用文字列置換（表記ゆれ修正・不要文言の削除）
ブランド名の統一や不要文言の削除にも使えます。
# 「Word Press」を「WordPress」に統一
wp search-replace 'Word Press' 'WordPress'
# 記事本文から「（PR）」を削除
wp search-replace '（PR）' ''
このようにURL置換と同じ要領で使えるため、記事修正や全体調整に幅広く活用できます。
Bashでの安全運用（バックアップ・除外・復元）
置換前にデータベースの完全バックアップを必ず取得し、Dry-run→本番→検証の各段で復元ポイントを用意しておくと安全です。wp db系コマンドで高速にエクスポート／インポートでき、gzip圧縮と組み合わせると大規模サイトでも扱いやすくなります。置換対象テーブルの除外指定や、マルチサイトでのスコープ制御もBashにまとめておくと再現性が高まります。
DBバックアップと復元コマンド（gzip併用）
バックアップは日時付きのファイル名で世代管理すると復旧が素早くなります。以下は標準出力→gzipで高速保存、復元はgunzip -c → wp db importのパイプ構成です。
# バックアップ（例: backup-YYYYmmdd-HHMM.sql.gz）
STAMP="$(date +%Y%m%d-%H%M)"
wp db export - | gzip > "backup-${STAMP}.sql.gz"
# 復元（特定のバックアップから）
gunzip -c backup-20251001-0930.sql.gz | wp db import -
置換の直前にバックアップ、置換直後にアプリの動作確認を行い、問題があれば上記の復元で即時ロールバックします。必要に応じてwp db optimizeやwp cache flushで後処理も行うと状態が安定します。
特定テーブルの除外・マルチサイト対応
キャッシュやログ系テーブルは置換対象から外すと作業が安定します。search-replaceにはテーブル対象の絞り込みと除外の両アプローチがあります。
# （推奨）対象テーブルを明示して実行
wp search-replace 'http://old' 'https://new' \
--tables=wp_posts,wp_postmeta,wp_options \
--skip-columns=guid
# 逆に「全テーブル対象」から一部を除外（複数指定可）
wp search-replace '旧表記' '新表記' \
--all-tables-with-prefix \
--skip-tables=wp_actionscheduler_actions,wp_actionscheduler_logs,wp_wfconfig \
--report-changed-only
--skip-columns=guidはフィード用の固定識別子を守るための定番設定です。マルチサイトではネットワーク全体か特定サイトかでスコープが変わります。
# ネットワーク全体（全サイト横断）
wp search-replace 'old.example.com' 'new.example.com' --network
# 特定サイトだけ（--urlでサイトを指定）
wp search-replace 'http://sub.example.com' 'https://sub.example.com' \
--url=sub.example.com --skip-columns=guid
除外・対象指定はBashスクリプトに変数として一覧化し、案件ごとに差し替えるだけにしておくと、ヒューマンエラーを防ぎながら何度でも安全に再実行できます。
置換後の確認と次アクション
置換が完了したら、キャッシュの無効化→リンク検証→設定の整合確認を順に行います。ここでの数分が、後日の不具合対応を大幅に減らします。WP-CLIの補助コマンドと簡易チェックを組み合わせ、search-replace後のURL置換や表記統一の漏れを早期に洗い出します。
キャッシュクリアとリンク動作確認
まずはアプリ側・サーバー側のキャッシュを空にして、古い内容が表示されない状態にします。
# WordPressオブジェクトキャッシュ/トランジェントのクリア
wp cache flush
wp transient delete --all
# パーマリンクルールを再生成（404やリダイレクト不整合の予防）
wp rewrite flush --hard
プラグインのページキャッシュ（例：W3TC, WP Super Cache, LiteSpeed Cache など）は管理画面で全削除するか、用意されていればWP-CLI用のサブコマンドで削除します。サーバー側（Nginx FastCGI、CDN）も可能なら一括パージを実施します。
続いて、置換の効果と漏れを簡易確認します。
# まだDBに旧ドメインやhttpが残っていないか件数を確認（ドライラン監査）
wp search-replace 'http://old.example.com' 'https://new.example.com' --dry-run
# 代表的な設定が想定どおりか確認
wp option get home
wp option get siteurl
ブラウザでは以下を重点チェックします。
- トップ／記事詳細／カテゴリ一覧の内部リンクが期待どおりか
- 画像やCSS/JSが**混在コンテンツ（http混在）**になっていないか
- 管理画面でメディア挿入・プレビューが正常か
不具合時のロールバック手順
想定外の置換や表示崩れが出た場合は、迷わずDB復元→原因特定→再実行の順で戻します。バックアップを取っていれば数十秒で原状回復できます。
# 直前のバックアップへ復元（例のファイル名を差し替え）
gunzip -c backup-20251001-0930.sql.gz | wp db import -
# 復元後、キャッシュ類を再度クリア
wp cache flush
wp transient delete --all
wp rewrite flush --hard
原因の切り分けは、
①対象テーブル/カラムの過剰指定
②uploads直リンクの取りこぼし
③guid更新によるフィード不具合
④マルチサイトでのスコープ誤り
の順に当たりを付けます。
修正した置換パラメータをBashスクリプトの変数に反映し、再度 --dry-run で件数を確認してから本実行すると安全です。再発防止として、運用フローにバックアップ→Dry-run→本番→検証→記録を固定化しておくと、WP-CLIのsearch-replaceによるURL置換や文字列統一が安定運用できます。
参考リンク（公式・外部リソース）
置換作業をさらに深く理解し、安全に運用するための参考ページをまとめました。公式ドキュメントを中心に、実務で役立つ外部リソースも含めています。
WP-CLI公式ドキュメント（search-replace／db）
WordPress.orgガイド（ドメイン変更・SSL化）
その他参考記事
まとめ
WP-CLI定型タスクまとめをあわせて読むことで、置換に加えてバックアップや権限管理まで一連の流れで効率化できます。
今回紹介したsearch-replaceは、本文内のURL変更から文字列統一まで幅広く対応できる汎用ツールです。Dry-runとバックアップを組み合わせれば、リスクを最小限に抑えて実行できます。
次の一歩として、DBバックアップの取り方も確認して、より安全な運用に役立ててください。
コメント