ワードプレスで文字列を一括置換する方法｜プラグイン・SQL・注意点を初心者向けに解説

はじめに

ワードプレスを長く運用していると、誤字の修正、会社名や商品名の変更、HTTPからHTTPSへの移行、ドメイン変更などに伴い、サイト内の文字列をまとめて変更したくなることがあります。

記事数が少なければ1ページずつ編集できますが、数十件、数百件の記事に同じ文字列が含まれている場合、手作業では時間がかかるうえ、修正漏れも発生しやすくなります。このようなときに役立つのが、ワードプレスの一括置換です。

ただし、一括置換はデータベースの内容を直接変更する作業です。検索文字列や対象テーブルを間違えると、文章だけでなくURLやサイト設定まで書き換わり、管理画面にアクセスできなくなる可能性があります。

この記事では、プラグイン、SQL、WP-CLIを使ってワードプレスの文字列を一括置換する方法を解説します。初心者は、必ずバックアップを取得したうえで、ドライラン機能のあるプラグインから試しましょう。

1. ワードプレスの一括置換とは

ワードプレスの一括置換とは、データベース内に保存されている特定の文字列を検索し、別の文字列へまとめて変更する作業です。

例えば、サイト内にある「旧サービス名」という文字列を「新サービス名」へ変更するとします。通常の編集では各記事を開いて修正しますが、一括置換を使えば、条件に一致するデータをまとめて変更できます。

1-1. 一括置換が必要になる主なケース

ワードプレスで一括置換が必要になる主なケースは、次のとおりです。

  • 複数の記事にある誤字をまとめて修正したい

  • 会社名、店舗名、商品名、サービス名が変わった

  • 内部リンクのURL構造を変更した

  • HTTPからHTTPSへ移行した

  • サイト移転に伴ってドメインを変更した

  • 画像URLやアップロード先のパスを変更した

  • 古いショートコードやHTMLタグを削除したい

  • テーマやプラグインが保存した設定値を更新したい

特にURLやドメインの変更では、投稿本文だけでなく、カスタムフィールド、ウィジェット、テーマ設定、プラグイン設定などにも旧URLが残ることがあります。

1-2. 投稿・固定ページだけでなくデータベース全体が対象になる理由

ワードプレスのデータは、投稿や固定ページだけに保存されているわけではありません。

投稿本文、タイトル、抜粋などは主にwp_postsテーブルへ保存されます。カスタムフィールドはwp_postmeta、サイトURLやテーマ・プラグインの設定はwp_optionsに保存されます。そのほか、コメント、ユーザー情報、カテゴリー、タグ、独自テーブルなどに文字列が含まれている場合もあります。

そのため、サイト移転やドメイン変更では、投稿本文だけを置換しても、画像、メニュー、ウィジェット、プラグイン設定などに旧URLが残る可能性があります。

ただし、データベース全体を無条件で置換すればよいわけではありません。対象を広げるほど誤置換のリスクも高くなるため、目的に必要なテーブルだけを選ぶことが重要です。

1-3. 通常の検索・置換では対応できない範囲

ブラウザやテキストエディターの検索・置換機能では、現在開いている文章やファイルしか変更できません。

一方、ワードプレスの文字列は、次のような場所にも保存されています。

  • 非公開記事や下書き

  • 再利用パターンやカスタム投稿タイプ

  • カスタムフィールド

  • コメントやユーザープロフィール

  • ウィジェット設定

  • テーマカスタマイザーの設定

  • プラグイン独自の設定

  • データベース内のシリアライズデータ

  • プラグインが作成した独自テーブル

これらを横断して変更するには、データベースを対象とした一括置換が必要です。

2. ワードプレスで一括置換する前に必ず行う準備

ワードプレスの一括置換は、実行後に「元に戻す」ボタンを押せば取り消せる作業ではありません。実行前の準備が、トラブルを防ぐうえで最も重要です。

2-1. データベースとファイルのバックアップを取る

一括置換を行う前に、必ずデータベースをバックアップしてください。

URL変更やサイト移転を伴う場合は、データベースだけでなく、次のファイルも保存します。

  • wp-contentディレクトリ

  • テーマファイル

  • プラグインファイル

  • アップロード画像

  • wp-config.php

  • .htaccess

  • 必要に応じてワードプレス本体のファイル

データベースは、レンタルサーバーのバックアップ機能、phpMyAdminのエクスポート、バックアッププラグイン、WP-CLIなどで保存できます。

バックアップは取得するだけでなく、復元方法も事前に確認しておきましょう。Better Search Replaceの公式ページでも、誤った検索文字列や置換文字列によってデータベースを損傷する可能性があるため、事前のバックアップが推奨されています。WordPress.org

2-2. 置換前の文字列と置換後の文字列を確認する

一括置換を実行する前に、検索する文字列と置換後の文字列をメモ帳などへ書き出して確認します。

例えば、ドメインを変更する場合は、次の違いに注意してください。

http://example.com
https://example.com
https://www.example.com
https://example.com/

プロトコル、wwwの有無、末尾のスラッシュが異なると、別の文字列として扱われます。

また、「株式会社ABC」を「ABC株式会社」に変更する場合、記事本文だけを対象にするのか、タイトルや設定値も変更するのかを決めておきます。

2-3. 本番環境ではなくテスト環境で試す

可能であれば、本番サイトを複製したステージング環境やローカル環境で一括置換を試してください。

テスト環境では、次の項目を確認します。

  • 想定した文字列だけが変更されるか

  • 記事や固定ページが正常に表示されるか

  • 画像や内部リンクが切れていないか

  • 管理画面へログインできるか

  • テーマやプラグインの設定が壊れていないか

  • 文字化けが発生していないか

テスト環境を用意できない場合は、少なくともドライランを実行し、置換件数を確認してから本番処理を行いましょう。

2-4. キャッシュ系プラグインを一時停止する

キャッシュ系プラグインやサーバーキャッシュが有効になっていると、データベースの置換が完了していても、古い内容が表示されることがあります。

作業前にキャッシュ系プラグインを一時停止するか、作業後に次のキャッシュを削除してください。

  • ワードプレスのページキャッシュ

  • オブジェクトキャッシュ

  • ブラウザキャッシュ

  • レンタルサーバーのキャッシュ

  • CDNのキャッシュ

キャッシュを削除するまでは、置換に失敗したと判断しないことが大切です。

2-5. シリアライズデータを直接置換してはいけない理由

ワードプレスでは、配列やオブジェクトなどをシリアライズ形式に変換してデータベースへ保存することがあります。シリアライズデータには、文字列の内容だけでなく文字数も記録されています。

例えば、次のデータには「example.com」が11文字であることを示す情報が含まれています。

s:11:"example.com";

通常のSQLで「example.com」を文字数の異なるドメインへ置換すると、文字数情報と実際のデータが一致しなくなり、設定を読み込めなくなる可能性があります。

WordPress公式の移行ガイドでも、データベース全体を通常の検索・置換で変更すると、URLの長さを含むシリアライズデータが壊れる可能性があると説明されています。シリアライズデータを含む範囲では、対応プラグインやWP-CLIを利用してください。WordPress Developer Resources

3. プラグインで文字列を一括置換する方法

3-1. 初心者にはプラグインによる一括置換がおすすめ

ワードプレスの管理画面へログインできる場合、初心者にはプラグインを使った一括置換がおすすめです。

SQLを直接書く必要がなく、対象テーブルの選択やドライランを管理画面から実行できます。特に、サイト全体のURL変更にはBetter Search Replace、投稿内容を条件付きで検索・置換したい場合にはSearch Regexが便利です。

ただし、プラグインを使っても入力ミスによる誤置換は防げません。バックアップとドライランは必ず行ってください。

3-2. Better Search Replaceのインストール方法

Better Search Replaceをインストールする手順は次のとおりです。

  1. ワードプレスの管理画面へログインする

  2. 「プラグイン」から「新規プラグインを追加」を開く

  3. 検索欄に「Better Search Replace」と入力する

  4. 対象のプラグインを確認して「今すぐインストール」をクリックする

  5. インストール後に「有効化」をクリックする

  6. 管理画面の「ツール」からBetter Search Replaceを開く

公式ページでも、管理画面のプラグイン追加画面から検索、インストール、有効化し、有効化後は「ツール」メニューから利用する手順が案内されています。WordPress.org

3-3. 置換する文字列と対象テーブルの設定方法

Better Search Replaceの画面を開いたら、検索文字列と置換文字列を入力します。

例えば、旧ドメインを新ドメインへ変更する場合は、次のように設定します。

検索: https://old-example.com
置換: https://new-example.com

次に、置換対象のテーブルを選択します。

投稿本文だけを変更したい場合は、主にwp_postsを選びます。カスタムフィールドも対象にする場合はwp_postmeta、サイト設定やプラグイン設定も対象にする場合はwp_optionsを追加します。

すべてのテーブルを選択すると、プラグインの独自テーブルや不要なデータまで変更される可能性があります。目的が限定されている場合は、必要なテーブルだけを選びましょう。

3-4. ドライランで置換件数を確認する手順

ドライランとは、実際のデータを書き換えず、何件が置換対象になるかを確認する機能です。

Better Search Replaceでは、ドライランの設定を有効にした状態で処理を実行します。結果が表示されたら、テーブルごとの一致件数を確認してください。

想定より件数が多い場合は、次のような原因が考えられます。

  • 検索文字列が短すぎる

  • 部分一致で別の単語も対象になっている

  • 投稿以外のテーブルを選択している

  • テーマやプラグイン設定にも同じ文字列がある

  • HTTPとHTTPSの両方が混在している

件数に違和感がある場合は、本番置換を実行せず、検索文字列や対象テーブルを見直します。

3-5. 本番の一括置換を実行する手順

ドライランの結果に問題がなければ、次の手順で本番の置換を実行します。

  1. バックアップが保存されていることを確認する

  2. 検索文字列と置換文字列を再確認する

  3. 対象テーブルを再確認する

  4. ドライランの設定を解除する

  5. 一括置換を実行する

  6. 処理結果と置換件数を記録する

  7. サイトと管理画面を確認する

  8. キャッシュを削除する

一度の操作で大量のデータを変更するため、実行ボタンを連続して押さないようにしてください。

3-6. Search Regexで投稿本文を一括置換する方法

Search Regexは、投稿、固定ページ、カスタム投稿タイプ、コメント、メタデータ、ワードプレス設定などを検索・置換できるプラグインです。正規表現や検索フィルターにも対応しており、カテゴリーや日付などで対象を絞り込めます。WordPress.org 日本語

基本的な手順は次のとおりです。

  1. 「プラグイン」からSearch Regexをインストールして有効化する

  2. 「ツール」から「Search Regex」を開く

  3. 検索元として投稿や固定ページを選択する

  4. 検索文字列を入力する

  5. 必要に応じてカテゴリー、投稿タイプ、日付などで絞り込む

  6. 検索結果を確認する

  7. 置換文字列を入力する

  8. 対象を再確認して置換を実行する

Search Regexは、単純な文字列の置換だけでなく、正規表現を使ったHTMLタグや一定パターンの文字列の変更にも向いています。

正規表現の指定を間違えると広範囲のデータが対象になるため、最初は通常検索で対象を確認し、少数の記事で試してから実行してください。

3-7. 一括置換後にプラグインを削除すべき理由

一括置換専用のプラグインを常時使用しない場合は、作業後に無効化し、不要であれば削除しましょう。

管理者権限でデータベースを広範囲に変更できる機能を残しておくと、誤操作の原因になります。また、利用していないプラグインを減らすことで、更新管理の手間も少なくなります。

再び一括置換が必要になったときは、最新版をインストールし直せます。

4. SQLを使ってデータベース内の文字列を一括置換する方法

SQLによる一括置換は、対象のテーブルとカラムが明確で、データ構造を理解している場合に有効です。

ただし、通常のSQLはシリアライズデータの文字数を調整しません。投稿本文など、シリアライズされていないことが明確なカラムに限定して使用してください。

4-1. phpMyAdminからSQLを実行する手順

phpMyAdminからSQLを実行する一般的な手順は次のとおりです。

  1. レンタルサーバーの管理画面へログインする

  2. phpMyAdminを開く

  3. 対象のワードプレスが使用しているデータベースを選択する

  4. データベースをエクスポートしてバックアップする

  5. 「SQL」タブを開く

  6. 実行するSQLを入力する

  7. テーブル名と文字列を確認する

  8. SQLを実行する

  9. 更新件数を確認する

本番のUPDATE文を実行する前に、同じ条件を使ったSELECT文で対象データを確認する方法が安全です。

SQL
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%置換前の文字列%';

4-2. 投稿本文の文字列を一括置換するSQL

投稿本文は、通常wp_postsテーブルのpost_contentカラムに保存されています。

SQL
UPDATE wp_posts
SET post_content = REPLACE(
    post_content,
    '置換前の文字列',
    '置換後の文字列'
)
WHERE post_content LIKE '%置換前の文字列%';

旧URLを新URLへ変更する場合は、次のように記述します。

SQL
UPDATE wp_posts
SET post_content = REPLACE(
    post_content,
    'https://old-example.com',
    'https://new-example.com'
)
WHERE post_content LIKE '%https://old-example.com%';

WHERE句を付けることで、対象文字列を含む行だけを更新できます。

4-3. 投稿タイトルや抜粋を一括置換するSQL

投稿タイトルはpost_title、抜粋はpost_excerptに保存されています。

投稿タイトルを変更するSQLは次のとおりです。

SQL
UPDATE wp_posts
SET post_title = REPLACE(
    post_title,
    '旧サービス名',
    '新サービス名'
)
WHERE post_title LIKE '%旧サービス名%';

抜粋を変更するSQLは次のとおりです。

SQL
UPDATE wp_posts
SET post_excerpt = REPLACE(
    post_excerpt,
    '旧サービス名',
    '新サービス名'
)
WHERE post_excerpt LIKE '%旧サービス名%';

公開済みの投稿だけを対象にする場合は、条件を追加できます。

SQL
UPDATE wp_posts
SET post_content = REPLACE(
    post_content,
    '旧サービス名',
    '新サービス名'
)
WHERE post_content LIKE '%旧サービス名%'
  AND post_status = 'publish';

投稿タイプも限定する場合は、さらに条件を追加します。

SQL
AND post_type = 'post';

4-4. カスタムフィールドの文字列を一括置換するSQL

カスタムフィールドは、通常wp_postmetaテーブルのmeta_valueに保存されています。

SQL
UPDATE wp_postmeta
SET meta_value = REPLACE(
    meta_value,
    '置換前の文字列',
    '置換後の文字列'
)
WHERE meta_value LIKE '%置換前の文字列%';

特定のカスタムフィールドだけを対象にする場合は、meta_keyを指定します。

SQL
UPDATE wp_postmeta
SET meta_value = REPLACE(
    meta_value,
    '旧サービス名',
    '新サービス名'
)
WHERE meta_key = 'service_name'
  AND meta_value LIKE '%旧サービス名%';

ただし、meta_valueにはシリアライズデータが保存されている場合があります。値の形式を確認できない場合は、通常のSQLではなくBetter Search ReplaceやWP-CLIを使用してください。

4-5. wp_options内のURLや設定値を置換する際の注意点

wp_optionsには、サイトURL、テーマ設定、プラグイン設定、キャッシュ、一時データなどが保存されています。

サイトURLを変更するだけであれば、対象のオプション名を限定して更新します。

SQL
UPDATE wp_options
SET option_value = 'https://new-example.com'
WHERE option_name = 'siteurl';
SQL
UPDATE wp_options
SET option_value = 'https://new-example.com'
WHERE option_name = 'home';

wp_options全体に対して単純なREPLACE()を実行するのは危険です。テーマやプラグインの設定値がシリアライズされていることがあり、データが壊れる可能性があります。

また、WP_HOMEやWP_SITEURLがwp-config.phpに定義されている場合、データベースのhomeやsiteurlを変更しても管理画面上のURLへ反映されません。これらの定数はデータベースの値を上書きしますが、データベース自体の保存値は変更しません。WordPress Developer Resources

4-6. テーブル接頭辞がwp_ではない場合の確認方法

ワードプレスのテーブル接頭辞は、必ずしもwp_とは限りません。

接頭辞はwp-config.phpの次の記述で確認できます。

PHP
$table_prefix = 'wp_';

例えば、次のようになっている場合があります。

PHP
$table_prefix = 'abc123_';

この場合、SQL内のテーブル名も次のように変更します。

SQL
UPDATE abc123_posts
SET post_content = REPLACE(
    post_content,
    '置換前の文字列',
    '置換後の文字列'
)
WHERE post_content LIKE '%置換前の文字列%';

WordPress公式ドキュメントでも、$table_prefixはデータベーステーブル名の先頭に付く値であり、wp_以外に変更できると説明されています。WordPress Developer Resources

4-7. SQLによる置換が向いているケースと向いていないケース

SQLによる置換が向いているのは、次のようなケースです。

  • 対象テーブルとカラムが明確

  • 投稿本文やタイトルだけを変更したい

  • シリアライズされていないデータだと確認できる

  • SQLやデータベースの操作に慣れている

  • プラグインをインストールできない

一方、次のようなケースには向いていません。

  • データベース全体のURLを変更したい

  • wp_optionsやwp_postmetaを広範囲に変更したい

  • シリアライズデータの有無が分からない

  • マルチサイトを運用している

  • テーブル構造を理解していない

  • バックアップからの復元方法が分からない

不明点がある場合は、SQLを直接実行せず、ドライランとシリアライズデータに対応した方法を選びましょう。

5. WP-CLIで文字列を一括置換する方法

WP-CLIは、コマンドラインからワードプレスを管理するためのツールです。サーバーへSSH接続でき、WP-CLIが利用可能な環境では、高速かつ柔軟に一括置換できます。

5-1. wp search-replaceコマンドの基本的な使い方

基本的な書式は次のとおりです。

Bash
wp search-replace '置換前の文字列' '置換後の文字列'

例えば、会社名を変更する場合は次のように実行します。

Bash
wp search-replace '旧会社名' '新会社名'

標準では、ワードプレスが認識しているテーブルを対象に検索・置換します。WP-CLIのwp search-replaceはPHPのシリアライズデータを考慮して処理し、主キーの値は変更しません。WordPress Developer Resources

5-2. dry-runで変更内容を確認する方法

実際に変更せず、置換対象を確認するには--dry-runを付けます。

Bash
wp search-replace '旧会社名' '新会社名' --dry-run

ドメイン変更の場合は次のように実行します。

Bash
wp search-replace \
'https://old-example.com' \
'https://new-example.com' \
--all-tables-with-prefix \
--skip-columns=guid \
--dry-run

結果には、対象テーブルや変更件数などが表示されます。件数を確認した後、問題がなければ--dry-runを外して本番処理を実行します。

--dry-runは処理結果をレポートしますが、データベースには変更を保存しません。WordPress Developer Resources

5-3. 特定のテーブルだけを対象にする方法

テーブル名を指定すると、対象を限定できます。

Bash
wp search-replace \
'旧サービス名' \
'新サービス名' \
wp_posts

投稿本文とカスタムフィールドを対象にする場合は、複数のテーブルを指定します。

Bash
wp search-replace \
'旧サービス名' \
'新サービス名' \
wp_posts wp_postmeta \
--dry-run

接頭辞がwp_ではない場合は、実際のテーブル名へ変更してください。

WP-CLIではワイルドカードにも対応しています。

Bash
wp search-replace \
'旧サービス名' \
'新サービス名' \
'wp_post*' \
--dry-run

5-4. URLをhttpからhttpsへ一括置換するコマンド例

HTTPからHTTPSへ変更する場合は、自サイトのドメインを含めて指定します。

Bash
wp search-replace \
'http://example.com' \
'https://example.com' \
--all-tables-with-prefix \
--skip-columns=guid \
--dry-run

確認後、本番処理を行います。

Bash
wp search-replace \
'http://example.com' \
'https://example.com' \
--all-tables-with-prefix \
--skip-columns=guid

単純にhttp://をhttps://へ置換すると、記事内の外部リンクまで変更する可能性があります。必ず自サイトのドメインを含む完全な文字列を指定してください。

5-5. ドメイン変更時に旧URLを新URLへ置換するコマンド例

旧ドメインから新ドメインへ変更する場合は、次のように実行します。

Bash
wp search-replace \
'https://old-example.com' \
'https://new-example.com' \
--all-tables-with-prefix \
--skip-columns=guid \
--dry-run

結果に問題がなければ、本番処理を実行します。

Bash
wp search-replace \
'https://old-example.com' \
'https://new-example.com' \
--all-tables-with-prefix \
--skip-columns=guid

--all-tables-with-prefixを付けると、接頭辞が一致する独自テーブルも対象になります。ただし、別のワードプレス環境と同じデータベースを共有している場合は、対象範囲を慎重に確認してください。

5-6. シリアライズデータを安全に置換できる理由

WP-CLIのwp search-replaceは、データを単純な文字列として置換するだけではありません。シリアライズデータを認識し、内部の値を変更したうえで、変更後の文字数を含む正しい形式へ再構築します。

そのため、文字数の異なるURLやドメインへ変更する場合でも、通常のSQLより安全に処理できます。

ただし、コマンドの検索文字列や対象テーブルを間違えた場合の誤置換までは防げません。WP-CLIを使う場合も、バックアップ、--dry-run、--skip-columns=guidなどを組み合わせましょう。

6. 目的別のワードプレス一括置換例

6-1. サイト内の誤字や古い表記を修正する

複数の記事に同じ誤字がある場合は、投稿本文を対象に置換します。

例えば、「シュミレーション」を「シミュレーション」へ変更する場合、まず検索機能で一致件数と使われ方を確認します。

短い単語や一般的な言葉は、別の文章の一部まで変更する可能性があります。前後の文字を含めた長い検索文字列にすると、誤置換を減らせます。

6-2. 会社名・商品名・サービス名を変更する

名称変更では、投稿本文だけでなく、次の場所も確認します。

  • 投稿タイトル

  • 抜粋

  • 固定ページ

  • カスタムフィールド

  • メニュー

  • ウィジェット

  • SEOプラグインのタイトルや説明文

  • 構造化データ

  • フッターやテーマ設定

  • お問い合わせフォーム

  • メール通知の文面

旧名称を完全に消す必要があるのか、「旧○○」として残す必要があるのかを事前に決めましょう。商標、会社沿革、過去のニュースなどは、機械的に変更しないほうがよい場合があります。

6-3. 内部リンクのURLを一括変更する

内部リンクを変更するときは、ドメインとパスをできるだけ具体的に指定します。

置換前:
https://example.com/old-category/

置換後:
https://example.com/new-category/

old-categoryだけを置換すると、本文中の通常の単語や画像ファイル名まで変更される可能性があります。

URLを変更したページには、旧URLから新URLへの301リダイレクトも設定します。

6-4. httpをhttpsへ一括置換する

HTTPからHTTPSへ移行するときは、次の順序で進めます。

  1. SSL証明書を設定する

  2. HTTPSでサイトが正常に表示されることを確認する

  3. ワードプレスアドレスとサイトアドレスをHTTPSへ変更する

  4. データベース内の自サイトURLを置換する

  5. HTTPからHTTPSへのリダイレクトを設定する

  6. 内部リンクや画像を確認する

  7. キャッシュを削除する

  8. Search Consoleやアクセス解析の設定を確認する

外部サイトのHTTPリンクまで変更しないよう、http://example.comのように自サイトのドメインを含めて検索してください。

6-5. サイト移転で旧ドメインを新ドメインへ変更する

ドメイン変更では、単なるデータベース置換だけでなく、移転全体の設計が必要です。

主な作業は次のとおりです。

  • 新サーバーへファイルとデータベースを移す

  • 新ドメインで表示確認する

  • 旧URLを新URLへ一括置換する

  • 旧URLから対応する新URLへ301リダイレクトする

  • canonical URLを確認する

  • XMLサイトマップを更新する

  • Search Consoleへ新サイトを登録する

  • 必要に応じてアドレス変更を申請する

  • 旧ドメインを一定期間維持する

  • クロールエラーやアクセス数を監視する

Googleは、URL変更を伴うサイト移転では、新サイトのテスト、旧URLと新URLの対応表作成、リダイレクト設定、移転後の監視を推奨しています。Google for Developers

6-6. 画像URLやアップロード先のパスを変更する

画像URLは、投稿本文、アイキャッチ画像のメタデータ、カスタムフィールド、テーマ設定、CSSなどに含まれている場合があります。

例えば、次のURLを変更するとします。

https://example.com/wp-content/uploads/old/
https://example.com/wp-content/uploads/new/

データベース内のURLを置換しても、画像ファイル自体が新しい場所へ移動していなければ表示されません。先にファイルをコピーまたは移動し、新URLへ直接アクセスできることを確認してください。

また、テーマや子テーマのCSSに記述された画像URLは、データベース置換では変更されません。

6-7. ショートコードやHTMLタグを削除・変更する

古いプラグインのショートコードが本文に残っている場合、完全に同じ文字列であれば単純置換で削除できます。

置換前:
[old_shortcode]

置換後:
空欄

属性や内容が記事ごとに異なる場合は、Search Regexなどの正規表現に対応したツールを使います。

HTMLタグの変更では、開始タグだけを削除すると閉じタグが残る可能性があります。また、ブロックエディターのコメントやHTML構造を壊すこともあるため、少数の記事で表示確認してから実行してください。

7. 一括置換で失敗しないための注意点

7-1. 部分一致による意図しない置換を防ぐ

短い文字列を指定すると、別の単語の一部まで置換される可能性があります。

例えば、「ABC」を「XYZ」へ変更すると、商品コード、画像ファイル名、URLパラメータなどに含まれる「ABC」も変更されるかもしれません。

可能な限り、前後の文脈を含む具体的な文字列を指定します。

悪い例:
ABC

よい例:
旧サービス「ABC」

置換前に検索結果を一覧で確認することも重要です。

7-2. 大文字・小文字や全角・半角の違いを確認する

次の文字列は、見た目が似ていても別のデータです。

WordPress
wordpress
WORDPRESS
ワードプレス
ﾜｰﾄﾞﾌﾟﾚｽ
ABC
ＡＢＣ

表記が混在している場合は、一度の置換ですべて変更しようとせず、文字列ごとに検索と置換を繰り返します。

アルファベットの大文字と小文字を区別するかどうかは、使用するツールやデータベース設定によって異なるため、ドライランや検索結果で確認してください。

7-3. URL末尾のスラッシュの有無を統一する

次のURLは、置換処理では別の文字列として扱われます。

https://example.com/page
https://example.com/page/

検索文字列に末尾のスラッシュを含めるかどうかで、対象件数が変わります。

サイト内で両方が混在している場合は、それぞれ検索して状況を確認してください。置換後は、内部リンク、canonical URL、リダイレクト先の形式を統一します。

7-4. GUIDを安易に変更しない

wp_postsテーブルにはguidカラムがありますが、ドメイン変更時でも原則として一括置換しません。

GUIDは投稿を一意に識別するための値で、フィードリーダーなどが既読判定に使用することがあります。GUIDを変更すると、過去の記事が新しい記事として再配信される可能性があります。

WordPress公式の移行ガイドでも、wp_postsのguidは変更しないよう明記されています。WordPress Developer Resources

WP-CLIを使用する場合は、次のオプションでGUIDを除外できます。

Bash
--skip-columns=guid

7-5. シリアライズデータを通常のSQLで置換しない

wp_optionsやwp_postmetaには、テーマ、ウィジェット、プラグインなどのシリアライズデータが保存されていることがあります。

通常のSQLで文字数の異なる文字列へ置換すると、データの長さ情報が合わなくなり、設定の消失や表示エラーにつながります。

シリアライズデータを含む可能性がある場合は、Better Search ReplaceまたはWP-CLIのwp search-replaceを利用してください。

7-6. テーマ・プラグインファイルはデータベース置換の対象外

データベース内の一括置換を実行しても、次のファイルに書かれた文字列は変更されません。

  • テーマのPHPファイル

  • CSSファイル

  • JavaScriptファイル

  • プラグインファイル

  • .htaccess

  • wp-config.php

  • サーバー設定ファイル

ファイル内の文字列を変更するときは、FTP、SSH、コードエディターなどを使用します。

親テーマやプラグイン本体を直接編集すると、アップデート時に変更が消えるため、子テーマ、独自プラグイン、フィルターフックなどを利用しましょう。

7-7. 大規模サイトではタイムアウトやサーバー負荷に注意する

記事数やデータ量が多いサイトでは、管理画面からの一括置換が途中で停止する場合があります。

主な原因は次のとおりです。

  • PHPの実行時間制限

  • メモリ不足

  • データベースの負荷

  • レンタルサーバーの処理制限

  • 通信の切断

  • 対象テーブルが大きすぎる

大規模サイトでは、対象テーブルを分ける、時間帯を選ぶ、メンテナンスモードを利用する、WP-CLIを使用するなどの対策が必要です。

処理が途中で止まったときに同じ一括置換を再実行すると、置換文字列の内容によっては二重置換になる可能性があります。再実行前に現在のデータを確認してください。

8. 一括置換後に確認すること

8-1. サイトの表示崩れやエラーを確認する

一括置換後は、トップページだけでなく、複数のページを確認します。

  • トップページ

  • 投稿ページ

  • 固定ページ

  • カテゴリーページ

  • 検索結果

  • お問い合わせページ

  • 会員ページ

  • 商品ページ

  • 404ページ

  • スマートフォン表示

PHPエラー、データベース接続エラー、レイアウト崩れ、メニューのリンク切れなどがないか確認してください。

8-2. 投稿・固定ページの置換結果を確認する

検索機能を使って、置換前の文字列が残っていないか調べます。

同時に、置換後の文字列が不自然な場所に入っていないかも確認します。代表的な記事だけでなく、古い記事、下書き、非公開ページ、カスタム投稿タイプも確認してください。

SQLを使える場合は、次のような検索で残存データを確認できます。

SQL
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%置換前の文字列%';

8-3. 内部リンクや画像が正しく表示されるか確認する

URLを変更した場合は、次の項目を確認します。

  • 内部リンクをクリックできるか

  • リンク先が404にならないか

  • 画像が表示されるか

  • PDFなどの添付ファイルを開けるか

  • CSSやJavaScriptが読み込まれているか

  • 混在コンテンツの警告がないか

  • 外部リンクを誤って変更していないか

ブラウザの開発者ツールやリンクチェックツールを使うと、404エラーや読み込み失敗を見つけやすくなります。

8-4. キャッシュを削除して変更を反映する

一括置換が完了したら、次のキャッシュを削除します。

  • キャッシュプラグイン

  • サーバーキャッシュ

  • CDNキャッシュ

  • オブジェクトキャッシュ

  • ブラウザキャッシュ

その後、シークレットウィンドウや別の端末からサイトを確認します。

キャッシュを削除しても変更が反映されない場合は、テーマファイルへの直接記述、wp-config.phpの定数、外部CDN、別データベースの参照などを確認してください。

8-5. リダイレクトとSearch Consoleの設定を確認する

URLやドメインを変更した場合は、旧URLから対応する新URLへ恒久的なリダイレクトを設定します。

すべての旧URLを新サイトのトップページへ転送するのではなく、可能な限り内容が対応するページへ個別に転送してください。

あわせて、次の項目を確認します。

  • 301リダイレクトが正常に動作しているか

  • リダイレクトループがないか

  • XMLサイトマップが新URLになっているか

  • canonical URLが新URLになっているか

  • Search Consoleに新しいプロパティを登録したか

  • ドメイン変更ではアドレス変更の手続きを行ったか

  • インデックス登録やクロールエラーに異常がないか

8-6. 問題が起きた場合にバックアップから復元する

表示崩れや管理画面のエラーが発生し、原因をすぐに特定できない場合は、追加の置換を繰り返さず、バックアップから復元します。

復元するときは、データベースだけを戻すのか、ファイルも戻すのかを判断してください。

置換作業後に新しい記事や注文、問い合わせなどが追加されている場合、古いバックアップへ戻すとそれらのデータが失われる可能性があります。ECサイトや会員サイトでは、復元前に最新データを保全する必要があります。

9. ワードプレスの一括置換でよくあるトラブルと対処法

9-1. 置換してもサイトに反映されない

置換件数が表示されているのにサイトへ反映されない場合は、次の原因を確認します。

  • キャッシュが残っている

  • 別のテーブルを参照している

  • テーマファイルに直接記述されている

  • ページビルダー独自のデータに保存されている

  • 置換したサイトと表示しているサイトが異なる

  • CDNが古いページを配信している

  • 多言語プラグインの別言語データに保存されている

最初にすべてのキャッシュを削除し、データベース内に置換後の文字列が保存されているか確認します。

9-2. 置換後に文字化けが発生した

文字化けの主な原因は、データベースの文字コードや照合順序、SQLファイルのエンコード、インポート時の設定です。

次の項目を確認します。

  • データベースの文字コード

  • テーブルやカラムの照合順序

  • SQLファイルがUTF-8で保存されているか

  • phpMyAdminのインポート設定

  • 置換前のバックアップに文字化けがないか

文字化けした状態で追加の置換を行うと復旧が難しくなります。作業を中断し、正常なバックアップから復元してください。

9-3. 画像や内部リンクが表示されなくなった

画像や内部リンクが表示されない場合は、置換後のURLを直接ブラウザで開きます。

404になる場合は、次の原因が考えられます。

  • ファイルが新しい場所へ移動されていない

  • URLのパスが間違っている

  • ドメインやサブディレクトリの指定が違う

  • 末尾のスラッシュが重複している

  • http://やhttps://が二重になっている

  • 相対URLと絶対URLの変換を間違えた

誤った置換例は次のとおりです。

https://new-example.comhttps://old-example.com/image.jpg

置換前後のURLと、実際のファイル配置を照合してください。

9-4. 管理画面やサイトにアクセスできなくなった

一括置換後に管理画面へアクセスできなくなった場合、homeまたはsiteurlが誤ったURLへ変更された可能性があります。

phpMyAdminでwp_optionsを開き、次のオプションを確認します。

home
siteurl

必要に応じて正しいURLへ戻してください。

緊急時は、wp-config.phpへ一時的に次のような定義を追加する方法もあります。

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

復旧後は、データベースの値と設定内容を整理し、不要になった定義を残さないようにします。

9-5. プラグインの処理が途中で止まる

処理が途中で止まる場合は、次の対策を試します。

  • 対象テーブルを分割する

  • 不要なテーブルを除外する

  • キャッシュやセキュリティプラグインを一時停止する

  • サーバーのPHPメモリ上限を確認する

  • アクセスの少ない時間帯に実行する

  • WP-CLIへ切り替える

  • サーバー管理者へ制限値を確認する

処理画面が止まったように見えても、データベース側では処理が続いている可能性があります。ブラウザの再読み込みや再実行をする前に、ログやデータベースの状態を確認してください。

9-6. 置換前の状態に戻したい

一括置換を元に戻す最も確実な方法は、作業前のバックアップから復元することです。

置換前後の文字列を逆にして再置換する方法もありますが、必ず元に戻るとは限りません。

例えば、「A」を「B」へ変更した後に「B」を「A」へ戻すと、もともと存在していた「B」まで「A」に変わってしまいます。

そのため、逆置換は対象を完全に特定できる場合に限り、基本的にはバックアップから復元してください。

10. ワードプレスの一括置換に関するよくある質問

10-1. プラグインを使わずに一括置換できますか

SQLまたはWP-CLIを使えば、プラグインをインストールせずに一括置換できます。

投稿本文など、対象カラムが明確でシリアライズされていないデータにはSQLを利用できます。サイト全体のURL変更やシリアライズデータを含む置換には、WP-CLIのwp search-replaceが適しています。

ただし、どちらもデータベースやサーバー操作の知識が必要です。

10-2. 投稿本文だけを対象に置換できますか

投稿本文だけを対象にできます。

SQLでは、wp_postsテーブルのpost_contentだけを更新します。

SQL
UPDATE wp_posts
SET post_content = REPLACE(
    post_content,
    '置換前',
    '置換後'
)
WHERE post_content LIKE '%置換前%';

WP-CLIでは、wp_postsだけを指定したうえで、必要に応じてタイトルやGUIDなどのカラムを除外します。

投稿本文だけを確実に限定したい場合は、実行前の検索結果を確認してください。

10-3. 特定のカテゴリーや記事だけを置換できますか

Search Regexなどのフィルター機能に対応したプラグインを使えば、カテゴリー、投稿タイプ、日付などで対象を絞り込めます。

SQLでも対象を限定できますが、カテゴリー情報は複数のテーブルに分かれているため、テーブル結合が必要です。初心者は、検索結果を画面で確認できるプラグインを利用するほうが安全です。

記事を数件だけ変更する場合は、一括置換より手動編集のほうが確実なこともあります。

10-4. 一括置換した内容を元に戻せますか

多くの一括置換ツールには、すべての変更を安全に取り消す共通の機能はありません。

元に戻すには、基本的に作業前のデータベースバックアップが必要です。一括置換前には、日時が分かる名前でバックアップファイルを保存してください。

database-before-search-replace-2026-06-20.sql

バックアップを復元すると、その取得後に追加された記事、コメント、注文なども失われる可能性がある点に注意が必要です。

10-5. URLの一括置換はSEOに影響しますか

データベース内のURL文字列を置換しただけで、必ず検索順位が下がるわけではありません。ただし、公開URLが変わる場合はSEOへの影響が生じる可能性があります。

特に重要なのは、次の対応です。

  • 旧URLから新URLへ301リダイレクトする

  • 内部リンクを新URLへ更新する

  • canonical URLを更新する

  • XMLサイトマップを更新する

  • Search Consoleで状態を確認する

  • 404エラーやリダイレクトループを監視する

  • 旧ドメインをすぐに手放さない

URLを変えず、記事本文内の表記だけを変更する場合は、通常のコンテンツ更新として扱われます。ただし、ページの主題や検索意図が大きく変わる変更では、検索評価が変動する可能性があります。

10-6. 初心者にはプラグイン・SQL・WP-CLIのどれがおすすめですか

初心者には、ドライラン機能があり、管理画面から操作できるBetter Search Replaceがおすすめです。

目的別の目安は次のとおりです。

方法向いている人・用途
Better Search Replace初心者、URLや文字列をデータベース内でまとめて変更したい
Search Regex投稿を条件で絞り込みたい、正規表現を使いたい
SQL対象テーブルとカラムが明確で、データベースに詳しい
WP-CLISSHを利用できる、大規模サイトやサイト移転を扱う
手動編集対象の記事が少ない、誤置換を確実に防ぎたい

どの方法を選ぶ場合でも、バックアップと事前確認は必要です。

まとめ

ワードプレスの一括置換を利用すると、投稿本文、タイトル、カスタムフィールド、URL、各種設定などに含まれる文字列を効率よく変更できます。

初心者が作業する場合は、次の流れで進めると安全です。

  1. データベースとファイルをバックアップする

  2. 検索文字列と置換文字列を正確に決める

  3. 可能であればテスト環境で試す

  4. Better Search Replaceなどでドライランを行う

  5. 対象件数とテーブルを確認する

  6. 本番の一括置換を実行する

  7. キャッシュを削除する

  8. 記事、画像、内部リンク、管理画面を確認する

  9. URL変更時はリダイレクトやSearch Consoleも確認する

SQLは限定されたカラムの変更には便利ですが、シリアライズデータを含む範囲へ安易に使用してはいけません。サイト全体のURL変更では、シリアライズデータに対応したプラグインまたはWP-CLIを利用しましょう。

一括置換では、実行方法よりも、バックアップ、ドライラン、対象範囲の確認が重要です。少しでも結果に不安がある場合は本番処理を実行せず、検索条件を見直してから作業してください。