ワードプレスで文字列を一括置換する方法｜プラグイン・SQL・注意点
はじめに
ワードプレスを運用していると、「過去記事に入っている会社名を変更したい」「旧ドメインのURLを新ドメインに置き換えたい」「特定の文言を全記事から一括で修正したい」といった場面があります。
記事数が少なければ手作業でも対応できますが、数十記事、数百記事になると、1ページずつ編集するのは現実的ではありません。そこで役立つのが、ワードプレスの文字列を一括置換する方法です。
ワードプレスの置換には、プラグインを使う方法、SQLでデータベースを直接操作する方法、WP-CLIを使う方法があります。それぞれ難易度や向いている作業が異なるため、目的に合った方法を選ぶことが重要です。
ただし、一括置換は便利な反面、操作を誤るとサイト表示の崩れ、リンク切れ、画像表示エラー、ログイン不可などのトラブルにつながることがあります。特にデータベースを直接変更する場合は、作業前のバックアップが必須です。
この記事では、ワードプレスで文字列を一括置換する方法を、プラグイン・SQL・WP-CLIに分けて解説します。あわせて、置換前後の注意点やよくある失敗、作業チェックリストも紹介します。
1. ワードプレスで文字列を一括置換する前に知っておくこと
ワードプレスの置換作業は、単に「古い文字を新しい文字に変える」だけではありません。ワードプレスは投稿本文だけでなく、設定情報、メニュー、ウィジェット、テーマ設定、プラグイン設定など、さまざまなデータをデータベースに保存しています。
そのため、どこに保存されている文字列を置換したいのかを理解してから作業する必要があります。
1-1. ワードプレスの置換でできること
ワードプレスの一括置換では、主に以下のような作業ができます。
| 置換内容 | 例 |
|---|---|
| 旧社名から新社名への変更 | 株式会社A → 株式会社B |
| 古いサービス名の変更 | 旧サービス名 → 新サービス名 |
| 旧URLから新URLへの変更 | http://example.com → https://example.com |
| ドメイン変更 | old-domain.com → new-domain.com |
| 画像パスの変更 | /wp-content/uploads/old/ → /wp-content/uploads/new/ |
| ショートコードの修正 | [old_shortcode] → [new_shortcode] |
| アフィリエイトリンクの差し替え | 古いリンク → 新しいリンク |
| 表記ゆれの統一 | WordPress → ワードプレス |
このように、ワードプレスの置換は記事本文の修正だけでなく、サイト移行やSSL化、リニューアル、内部リンク整理などにも使われます。
1-2. 置換が必要になる主なケース
ワードプレスで文字列の一括置換が必要になる代表的なケースは、次のとおりです。
まず多いのが、サイトURLやドメインを変更した場合です。たとえば、テスト環境から本番環境へ移行したときに、記事本文や画像URLにテスト環境のURLが残ってしまうことがあります。この場合、旧URLを本番URLに置換する必要があります。
次に、SSL化によってURLを「http」から「https」に変更するケースです。ワードプレスの一般設定だけを変更しても、過去記事内の画像URLや内部リンクに「http://」が残っていると、混在コンテンツの警告が出ることがあります。
また、会社名、店舗名、商品名、サービス名が変更された場合も、一括置換が役立ちます。長年運営しているブログやオウンドメディアでは、過去記事に古い名称が大量に残っていることがあるためです。
そのほか、不要になったショートコードの削除、古いアフィリエイトリンクの差し替え、表記ルールの統一、誤字脱字の一括修正などにも使われます。
1-3. 投稿・固定ページ・カスタム投稿・ウィジェットなど置換対象の違い
ワードプレスでは、置換したい文字列がどこに保存されているかによって、確認すべきデータベーステーブルが変わります。
代表的な保存場所は以下のとおりです。
| 対象 | 主な保存先 |
|---|---|
| 投稿本文 | wp_posts の post_content |
| 投稿タイトル | wp_posts の post_title |
| 固定ページ本文 | wp_posts の post_content |
| カスタム投稿 | wp_posts |
| 抜粋 | wp_posts の post_excerpt |
| カスタムフィールド | wp_postmeta |
| サイトURL・管理画面設定 | wp_options |
| ウィジェット設定 | wp_options |
| メニュー情報 | wp_posts、wp_postmeta、wp_terms など |
| コメント本文 | wp_comments |
| ユーザー情報 | wp_users、wp_usermeta |
たとえば、記事本文内の文言だけを置換したい場合は、主に wp_posts テーブルの post_content が対象になります。一方で、テーマ設定やウィジェット内の文字列を置換したい場合は、wp_options に保存されている可能性があります。
ただし、ワードプレスのテーブル接頭辞は必ずしも wp_ とは限りません。セキュリティ対策やサーバー設定によって、abc_posts のように異なる接頭辞になっている場合もあります。
1-4. 通常の検索・置換とデータベース置換の違い
ワードプレスの管理画面で記事を開き、エディタ上で文字を検索して置換する方法は、あくまでその記事単体に対する編集です。対象記事が少ない場合には安全ですが、大量の記事を修正するには時間がかかります。
一方、プラグインやSQL、WP-CLIによるデータベース置換は、ワードプレスのデータベース内に保存されている文字列を一括で変更します。大量の投稿や設定値を短時間で置換できる反面、誤った条件で実行すると広範囲に影響が出ます。
たとえば、「test」という文字列を不用意に置換すると、記事本文だけでなくURL、設定値、プラグインデータの一部まで変更される可能性があります。短い文字列や一般的すぎる単語を置換するときは、特に注意が必要です。
1-5. 一括置換で失敗しやすいポイント
ワードプレスの一括置換で失敗しやすいポイントは、次の5つです。
1つ目は、バックアップを取らずに本番環境で直接作業してしまうことです。置換後に不具合が起きても、バックアップがなければ復旧が難しくなります。
2つ目は、置換対象を広げすぎることです。記事本文だけを変更したいのに、全テーブルを対象にしてしまうと、テーマ設定やプラグイン設定まで変更される可能性があります。
3つ目は、シリアライズデータを壊してしまうことです。ワードプレスの一部データは、文字列の長さ情報を含む特殊な形式で保存されています。SQLの単純な REPLACE で文字数が変わる置換を行うと、データが壊れる場合があります。
4つ目は、URLの末尾やスラッシュの有無を確認せずに置換することです。https://example.com と https://example.com/ では意味が変わることがあります。
5つ目は、キャッシュの影響で置換結果を正しく確認できないことです。置換が成功していても、ページキャッシュやブラウザキャッシュが残っていると、古い内容が表示されることがあります。
2. ワードプレスで文字列を一括置換する方法の選び方
ワードプレスで文字列を置換する方法は複数ありますが、どの方法が最適かは、作業内容やスキルレベルによって変わります。
初心者が記事本文の一部を置換するならプラグイン、URLやドメインを大量に変更するなら専用プラグインやWP-CLI、データベース構造を理解している人ならSQLというように使い分けるのが基本です。
2-1. 初心者はプラグインでの置換がおすすめ
ワードプレス初心者には、プラグインを使った置換がおすすめです。管理画面から操作できるため、phpMyAdminやコマンドラインに慣れていなくても作業しやすいからです。
特に「Better Search Replace」や「Search Regex」などのプラグインは、置換前にドライランで確認できるため、いきなりデータを変更せずに影響範囲を確認できます。
プラグインを使う場合も、完全に安全というわけではありません。置換対象のテーブルや文字列を誤ると、意図しない箇所まで変更される可能性があります。そのため、プラグインを使う場合でもバックアップは必ず取っておきましょう。
2-2. 大量データやURL変更はSQL・データベース操作が向いている
大量のデータを素早く置換したい場合や、特定のテーブル・カラムだけを確実に変更したい場合は、SQLでの置換が有効です。
たとえば、投稿本文に含まれる旧URLだけを新URLに変更したい場合、以下のようなSQLで対応できます。
SQLUPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://old-domain.com', 'https://new-domain.com');
ただし、SQLは強力な反面、取り消しが簡単ではありません。実行した瞬間にデータベースが更新されるため、初心者が本番環境で直接操作するのはリスクがあります。
特に wp_options や wp_postmeta にはシリアライズデータが含まれることがあるため、単純なSQL置換は避けたほうがよいケースもあります。
2-3. 開発者や運用担当者はWP-CLIも選択肢になる
サーバーにSSH接続できる環境であれば、WP-CLIを使う方法もあります。WP-CLIは、コマンドラインからワードプレスを操作できる公式ツールです。
WP-CLIの search-replace コマンドを使うと、データベース内の文字列を一括置換できます。ドライランや対象テーブルの指定もできるため、開発者や運用担当者にとっては非常に便利です。
たとえば、次のようなコマンドでURLを置換できます。
Bashwp search-replace 'http://old-domain.com' 'https://new-domain.com' --dry-run
--dry-run を付けると、実際には置換せず、どの程度変更されるかを確認できます。
2-4. 置換したい内容別のおすすめ方法
置換したい内容によって、おすすめの方法は異なります。
| 置換したい内容 | おすすめ方法 |
|---|---|
| 記事本文の文言を変更したい | プラグイン、SQL |
| 固定ページ内のテキストを変更したい | プラグイン、SQL |
| URLやドメインを変更したい | Better Search Replace、WP-CLI |
| ショートコードを削除・変更したい | Search Regex、SQL |
| 正規表現で複雑な置換をしたい | Search Regex |
| テスト環境から本番環境へ移行したい | WP-CLI、移行系プラグイン |
| 大量データを高速に置換したい | WP-CLI、SQL |
| シリアライズデータを含む可能性がある | Better Search Replace、WP-CLI |
初心者が迷った場合は、まずプラグインのドライランで対象範囲を確認するのがおすすめです。いきなりSQLを実行するよりも安全に進められます。
2-5. 作業前に必ずバックアップを取るべき理由
ワードプレスの置換作業では、作業前のバックアップが最も重要です。
一括置換は、実行後に「やっぱり戻したい」と思っても、簡単に元に戻せないことがあります。特に、複数の文字列を連続して置換した場合や、広範囲のテーブルを対象にした場合、どこがどのように変更されたのかを正確に把握するのは困難です。
バックアップすべきものは、主に以下の2つです。
| バックアップ対象 | 内容 |
|---|---|
| データベース | 投稿、固定ページ、設定、コメント、メニューなど |
| ファイル | テーマ、プラグイン、画像、アップロードファイルなど |
文字列置換だけであれば主にデータベースが対象ですが、万が一に備えてファイルも含めたサイト全体のバックアップを取っておくと安心です。
3. プラグインでワードプレスの文字列を一括置換する方法
プラグインを使った置換は、ワードプレス管理画面から操作できるため、初心者でも比較的取り組みやすい方法です。
ここでは、代表的な置換プラグインとして「Better Search Replace」と「Search Regex」を使った方法を紹介します。
3-1. 置換プラグインを使うメリット・デメリット
置換プラグインのメリットは、専門的なSQL知識がなくても使えることです。管理画面上で検索文字列、置換後文字列、対象テーブルを指定すれば、一括置換を実行できます。
また、プラグインによってはドライラン機能があり、実際に置換する前に変更件数を確認できます。これは本番環境で作業する際に非常に便利です。
一方で、デメリットもあります。大量データを処理すると、サーバー環境によってはタイムアウトすることがあります。また、対象テーブルの意味を理解せずに全テーブルを選択すると、意図しない設定まで変更されるリスクがあります。
プラグインは簡単に使えますが、「簡単だから安全」というわけではありません。必ずバックアップとドライランを行いましょう。
3-2. Better Search Replaceを使った置換手順
Better Search Replaceは、ワードプレスの文字列置換でよく使われるプラグインです。URL変更やドメイン変更、記事本文の文言修正などに利用できます。
基本的な手順は以下のとおりです。
ワードプレス管理画面にログインする
「プラグイン」から「新規追加」を開く
「Better Search Replace」を検索してインストールする
プラグインを有効化する
「ツール」から「Better Search Replace」を開く
「Search for」に置換前の文字列を入力する
「Replace with」に置換後の文字列を入力する
対象テーブルを選択する
まずはドライランで実行する
結果を確認してから本番置換を実行する
たとえば、旧ドメインを新ドメインに変更する場合は、以下のように入力します。
| 項目 | 入力例 |
|---|---|
| Search for | http://old-domain.com |
| Replace with | https://new-domain.com |
| 対象テーブル | wp_posts、wp_postmeta、wp_options など |
URL置換の場合は、記事本文だけでなくカスタムフィールドやオプションテーブルにもURLが保存されている可能性があります。ただし、全テーブルを対象にする前に、ドライランで影響範囲を確認してください。
3-3. Search Regexを使った置換手順
Search Regexは、正規表現を使った検索・置換に対応しているプラグインです。単純な文字列置換だけでなく、パターンに一致する文字列をまとめて変更したい場合に便利です。
たとえば、特定のショートコードを削除したい場合や、一定の形式で書かれたテキストをまとめて修正したい場合に向いています。
基本的な使い方は以下のとおりです。
ワードプレス管理画面で「プラグイン」から「新規追加」を開く
「Search Regex」を検索してインストールする
プラグインを有効化する
管理画面のメニューから「Search Regex」を開く
検索対象を選択する
検索文字列または正規表現を入力する
置換後の文字列を入力する
検索結果を確認する
問題なければ置換を実行する
Search Regexは柔軟な置換ができる反面、正規表現の指定を誤ると想定以上の範囲が変更されることがあります。正規表現に慣れていない場合は、まず検索だけを行い、対象が正しいか確認してから置換してください。
3-4. 置換前にドライランで確認する方法
ワードプレスの一括置換では、ドライランが非常に重要です。
ドライランとは、実際にはデータを変更せず、どのテーブルで何件の置換が発生するかを確認する機能です。Better Search Replaceでは、実行前に「Run as dry run」のような項目にチェックを入れることで、置換件数を確認できます。
ドライランで確認すべきポイントは以下です。
| 確認項目 | チェック内容 |
|---|---|
| 置換件数 | 想定より多すぎないか |
| 対象テーブル | 不要なテーブルが含まれていないか |
| 置換前文字列 | 誤字や余計なスペースがないか |
| 置換後文字列 | URLや表記が正しいか |
| 対象範囲 | 投稿本文だけか、設定値も含めるか |
たとえば、会社名を10箇所程度変更する想定なのに、ドライランで数千件ヒットした場合は、検索文字列が広すぎる可能性があります。そのまま実行せず、条件を見直しましょう。
3-5. プラグインで置換できないケース
プラグインを使えば多くの置換作業に対応できますが、すべてのケースで万能というわけではありません。
たとえば、非常に大規模なサイトでは、処理中にサーバーがタイムアウトすることがあります。共有サーバーでは実行時間やメモリに制限があるため、大量の置換には向かない場合があります。
また、独自テーブルを使うプラグインのデータや、特殊な形式で保存されているデータは、通常の置換プラグインでは正しく処理できないことがあります。
さらに、テーマファイルやプラグインファイル内に直接書かれている文字列は、データベース置換では変更されません。たとえば、テーマの functions.php やテンプレートファイルに書かれた文言は、ファイルを直接編集する必要があります。
4. SQLでワードプレスの文字列を一括置換する方法
SQLを使うと、ワードプレスのデータベース内にある文字列を直接置換できます。特定のテーブルやカラムを指定して処理できるため、目的が明確な場合には効率的です。
ただし、SQLでの置換は失敗時の影響が大きいため、必ずバックアップを取ったうえで実行してください。
4-1. SQLで置換する前に確認すべきこと
SQLでワードプレスの文字列を置換する前に、以下を確認しましょう。
| 確認項目 | 内容 |
|---|---|
| データベース名 | 操作対象のデータベースが正しいか |
| テーブル接頭辞 | wp_ 以外になっていないか |
| 対象テーブル | どのテーブルを置換するか |
| 対象カラム | どのカラムを置換するか |
| 置換前文字列 | 完全一致で問題ないか |
| 置換後文字列 | 誤字・URLミスがないか |
| バックアップ | 復元できる状態か |
特に、複数のワードプレスを同じサーバーで運用している場合、誤って別サイトのデータベースを操作しないよう注意してください。
また、SQLを実行する前に、まず SELECT 文で対象データを確認すると安全です。
SQLSELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%置換前の文字列%';
このように事前に検索しておくと、どの記事が対象になるかを確認できます。
4-2. phpMyAdminからデータベースを操作する手順
phpMyAdminを使えば、ブラウザ上からデータベースを操作できます。多くのレンタルサーバーでは、管理画面からphpMyAdminにアクセスできます。
基本的な手順は以下のとおりです。
サーバー管理画面にログインする
phpMyAdminを開く
対象のデータベースを選択する
置換対象のテーブルを確認する
SQLタブを開く
実行するSQLを入力する
内容を再確認する
SQLを実行する
ワードプレスの表示を確認する
phpMyAdminでは、一度SQLを実行すると元に戻すボタンはありません。必ず作業前にデータベースをエクスポートし、復元できる状態にしておきましょう。
4-3. 投稿本文を置換するSQL例
投稿本文に含まれる文字列を置換する場合は、wp_posts テーブルの post_content を対象にします。
たとえば、記事本文内の「旧サービス名」を「新サービス名」に置換する場合は、以下のSQLを使います。
SQLUPDATE wp_posts
SET post_content = REPLACE(post_content, '旧サービス名', '新サービス名')
WHERE post_content LIKE '%旧サービス名%';
WHERE 条件を付けることで、対象文字列を含む投稿だけを更新できます。
投稿タイトルも置換したい場合は、post_title を対象にします。
SQLUPDATE wp_posts
SET post_title = REPLACE(post_title, '旧サービス名', '新サービス名')
WHERE post_title LIKE '%旧サービス名%';
抜粋文も置換する場合は、post_excerpt を対象にします。
SQLUPDATE wp_posts
SET post_excerpt = REPLACE(post_excerpt, '旧サービス名', '新サービス名')
WHERE post_excerpt LIKE '%旧サービス名%';
記事本文だけを置換したい場合は、post_content のみを対象にしましょう。タイトルや抜粋まで変更したくない場合に、まとめて実行しないよう注意してください。
4-4. URLやドメインを置換するSQL例
ドメイン変更やSSL化の際には、記事本文に含まれるURLを置換することがあります。
たとえば、旧URLを新URLに変更する場合は、以下のように実行します。
SQLUPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://old-domain.com', 'https://new-domain.com')
WHERE post_content LIKE '%http://old-domain.com%';
固定ページやカスタム投稿も wp_posts に保存されているため、このSQLで投稿本文と同じように置換できます。
画像URLを置換する場合も同様です。
SQLUPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://old-domain.com/wp-content/uploads/', 'https://new-domain.com/wp-content/uploads/')
WHERE post_content LIKE '%http://old-domain.com/wp-content/uploads/%';
ただし、URLやドメインは wp_postmeta や wp_options にも保存されている場合があります。カスタムフィールド内のURLを置換する場合は、次のように wp_postmeta を対象にします。
SQLUPDATE wp_postmeta
SET meta_value = REPLACE(meta_value, 'http://old-domain.com', 'https://new-domain.com')
WHERE meta_value LIKE '%http://old-domain.com%';
ただし、meta_value にはシリアライズデータが含まれることがあります。文字数が変わる置換ではデータ破損の可能性があるため、SQLではなく専用プラグインやWP-CLIの利用を検討してください。
4-5. wp_optionsやシリアライズデータを置換するときの注意点
wp_options は、ワードプレスのサイト設定、テーマ設定、プラグイン設定、ウィジェット設定などが保存される重要なテーブルです。
たとえば、サイトURLは wp_options の siteurl や home に保存されています。
SQLSELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');
サイトURLだけを変更する場合は、以下のように更新できます。
SQLUPDATE wp_options
SET option_value = 'https://new-domain.com'
WHERE option_name = 'siteurl';
UPDATE wp_options
SET option_value = 'https://new-domain.com'
WHERE option_name = 'home';
ただし、wp_options にはシリアライズデータが多く含まれます。シリアライズデータとは、配列やオブジェクトなどを文字列として保存した形式で、文字列の長さ情報を含んでいます。
たとえば、以下のような形式です。
s:18:"http://example.com";
この文字列を単純なSQLで https://example.com に置換すると、文字数が変わるため、長さ情報と実際の文字数が一致しなくなり、データが壊れる可能性があります。
そのため、wp_options や wp_postmeta の広範囲なURL置換では、シリアライズデータに対応したプラグインやWP-CLIを使うのが安全です。
4-6. SQL置換後に確認すべき項目
SQLで置換を実行した後は、すぐにサイト全体を確認しましょう。
確認すべき項目は以下です。
| 確認項目 | 内容 |
|---|---|
| トップページ | 正常に表示されるか |
| 投稿ページ | 本文・画像・リンクに問題がないか |
| 固定ページ | レイアウトが崩れていないか |
| 管理画面 | ログイン・編集ができるか |
| 内部リンク | 旧URLが残っていないか |
| 画像 | 表示切れがないか |
| メニュー | リンク先が正しいか |
| 問い合わせフォーム | 送信できるか |
| キャッシュ | 古い表示が残っていないか |
また、置換後に再度SQLで検索し、旧文字列が残っていないか確認すると安心です。
SQLSELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%旧文字列%';
検索結果が0件であれば、対象の文字列は投稿本文から置換されています。
5. WP-CLIでワードプレスの文字列を一括置換する方法
WP-CLIを使うと、コマンドラインからワードプレスのデータベースを一括置換できます。開発環境や本番サーバーでSSHが使える場合に便利です。
特に、ドメイン変更や大量データの置換では、プラグインよりも安定して処理できることがあります。
5-1. WP-CLIのsearch-replaceとは
WP-CLIの search-replace は、ワードプレスのデータベース内にある文字列を検索し、指定した文字列に置換するコマンドです。
基本的な特徴は以下です。
| 特徴 | 内容 |
|---|---|
| コマンドラインで実行 | SSH環境で操作する |
| ドライラン対応 | 実行前に置換件数を確認できる |
| テーブル指定可能 | 対象テーブルを絞り込める |
| URL変更に便利 | 開発環境から本番環境への移行で使いやすい |
| シリアライズ対応 | 単純なSQLより安全に置換しやすい |
WP-CLIが使える環境であれば、ワードプレスの置換作業において非常に有力な選択肢になります。
5-2. WP-CLIで置換する基本コマンド
WP-CLIで文字列を置換する基本コマンドは以下です。
Bashwp search-replace '置換前の文字列' '置換後の文字列'
たとえば、旧ドメインを新ドメインに変更する場合は、次のように実行します。
Bashwp search-replace 'http://old-domain.com' 'https://new-domain.com'
特定のテーブルだけを対象にする場合は、テーブル名を指定します。
Bashwp search-replace '旧サービス名' '新サービス名' wp_posts
投稿本文を含む wp_posts だけを対象にしたい場合に便利です。
テーブル接頭辞が異なる場合は、実際のテーブル名に合わせて指定してください。
5-3. ドライランで置換内容を確認する方法
WP-CLIでも、実行前にドライランで確認できます。
Bashwp search-replace 'http://old-domain.com' 'https://new-domain.com' --dry-run
--dry-run を付けると、実際にはデータベースを変更せず、置換対象の件数を確認できます。
より詳細に確認したい場合は、レポート形式で出力できます。
Bashwp search-replace 'http://old-domain.com' 'https://new-domain.com' --dry-run --report
本番環境で作業する場合は、いきなり置換せず、必ずドライランで対象件数を確認してください。想定より件数が多い場合は、検索文字列や対象テーブルを見直しましょう。
5-4. 本番環境でWP-CLIを使うときの注意点
WP-CLIは便利ですが、本番環境で使う場合は慎重に操作する必要があります。
まず、作業前に必ずデータベースをバックアップします。WP-CLIを使ってバックアップを取得する場合は、次のように実行できます。
Bashwp db export backup-before-replace.sql
次に、置換前の文字列と置換後の文字列を正確に確認します。URLの場合は、プロトコル、末尾スラッシュ、サブディレクトリの有無に注意してください。
たとえば、以下は別の文字列として扱われます。
http://example.com
http://example.com/
https://example.com
https://www.example.com
また、作業中にアクセスが集中すると、キャッシュや一部ページの表示確認に時間がかかることがあります。アクセスの少ない時間帯に作業するのがおすすめです。
5-5. プラグイン・SQLとの使い分け
WP-CLI、プラグイン、SQLは、それぞれ向いている場面が異なります。
| 方法 | 向いている人 | 向いている作業 |
|---|---|---|
| プラグイン | 初心者・管理画面で作業したい人 | 記事本文、URL、表記変更 |
| SQL | データベース操作に慣れている人 | 特定テーブル・カラムの置換 |
| WP-CLI | 開発者・運用担当者 | 大量データ、URL変更、移行作業 |
初心者はプラグイン、開発者はWP-CLI、データベース構造を理解している場合はSQL、という使い分けが基本です。
6. ワードプレスの置換でよくある失敗と対処法
ワードプレスの置換作業では、実行後に思わぬトラブルが起きることがあります。ここでは、よくある失敗と対処法を紹介します。
6-1. サイト表示が崩れた場合の対処法
置換後にサイト表示が崩れた場合、まずキャッシュを削除して再確認します。ページキャッシュ、ブラウザキャッシュ、CDNキャッシュが残っていると、古いデータと新しいデータが混在して表示されることがあります。
キャッシュを削除しても直らない場合は、テーマ設定やウィジェット設定が壊れていないか確認します。特に wp_options をSQLで置換した場合、シリアライズデータが破損している可能性があります。
バックアップがある場合は、置換前のデータベースに復元するのが最も確実です。復元後、置換条件を見直して、プラグインやWP-CLIで再実行しましょう。
6-2. 画像URLや内部リンクが置換されない場合の原因
画像URLや内部リンクが置換されない場合、置換対象のテーブルが不足している可能性があります。
記事本文内の画像URLは wp_posts の post_content に保存されることが多いですが、カスタムフィールド、ブロックエディタの一部データ、テーマ設定、プラグイン設定に保存されていることもあります。
特に、ページビルダー系プラグインを使っている場合、URLが独自形式で wp_postmeta や専用テーブルに保存されていることがあります。この場合、通常の投稿本文だけを置換しても反映されません。
対処法としては、データベース全体で旧URLを検索し、どのテーブルに残っているか確認します。ただし、見つかったからといってSQLで単純置換するのではなく、シリアライズデータや独自形式かどうかを確認してから対応しましょう。
6-3. 置換後にログインできなくなった場合の確認点
置換後にワードプレスへログインできなくなった場合、siteurl や home の値が誤って変更されている可能性があります。
phpMyAdminで wp_options を開き、以下の項目を確認してください。
SQLSELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');
URLが間違っている場合は、正しいURLに修正します。
SQLUPDATE wp_options
SET option_value = 'https://example.com'
WHERE option_name = 'siteurl';
UPDATE wp_options
SET option_value = 'https://example.com'
WHERE option_name = 'home';
また、SSL設定やリダイレクト設定が原因でログインできない場合もあります。wp-config.php や .htaccess に不要なリダイレクト設定が入っていないか確認しましょう。
6-4. シリアライズデータを壊してしまった場合の対処法
シリアライズデータを壊してしまった場合、テーマ設定、ウィジェット、プラグイン設定などが正常に読み込めなくなることがあります。
最も確実な対処法は、置換前のバックアップからデータベースを復元することです。そのうえで、シリアライズデータに対応したプラグインやWP-CLIを使って再度置換します。
バックアップがない場合は、壊れたデータを手作業で修正する必要がありますが、難易度は高くなります。特に wp_options に保存されているテーマ設定やページビルダー設定が壊れた場合、管理画面から再設定が必要になることもあります。
SQLの単純な REPLACE は便利ですが、wp_options や wp_postmeta の広範囲な置換には慎重に使いましょう。
6-5. キャッシュが原因で変更が反映されない場合の対応
置換が成功しているのにページ上で変更が反映されない場合は、キャッシュが原因の可能性があります。
確認すべきキャッシュは以下です。
| キャッシュの種類 | 対応 |
|---|---|
| ブラウザキャッシュ | スーパーリロード、別ブラウザで確認 |
| ワードプレスのキャッシュプラグイン | キャッシュ削除 |
| サーバーキャッシュ | サーバー管理画面から削除 |
| CDNキャッシュ | CDN管理画面からパージ |
| オブジェクトキャッシュ | RedisやMemcachedをクリア |
特に、キャッシュプラグインやCDNを使っているサイトでは、データベース上の置換が完了していても、公開ページには古い内容が表示されることがあります。置換後は必ずキャッシュを削除し、シークレットウィンドウなどで確認しましょう。
7. ワードプレスで置換する前後に必ず行うチェックリスト
ワードプレスの置換作業を安全に行うためには、作業前後のチェックが欠かせません。ここでは、実際の作業時に使えるチェックリストを紹介します。
7-1. 作業前のバックアップ確認
置換前には、必ずバックアップを取得します。
チェックすべき項目は以下です。
| チェック項目 | 確認 |
|---|---|
| データベースのバックアップを取得した | □ |
| ファイルのバックアップを取得した | □ |
| バックアップの保存場所を確認した | □ |
| 復元手順を確認した | □ |
| 最新のバックアップであることを確認した | □ |
バックアップは「取ったつもり」では不十分です。実際にファイルが保存されているか、復元できる形式かを確認しておきましょう。
7-2. 置換対象文字列と置換後文字列の確認
置換前文字列と置換後文字列は、作業前に必ず見直します。
特にURLの場合、以下の違いに注意してください。
http://example.com
https://example.com
https://example.com/
https://www.example.com
末尾スラッシュの有無、www の有無、http と https の違いによって、置換結果が変わります。
また、会社名やサービス名を置換する場合は、表記ゆれも確認しましょう。
旧サービス
旧サービス名
「旧サービス」
旧サービス株式会社
完全一致で置換する場合、表記が少し違うだけで対象から漏れることがあります。
7-3. テスト環境での事前検証
可能であれば、本番環境ではなくテスト環境で事前に置換を試しましょう。
テスト環境で確認すべきことは以下です。
| 確認項目 | 内容 |
|---|---|
| 置換件数 | 想定どおりか |
| ページ表示 | 崩れていないか |
| 画像表示 | 正しく表示されるか |
| 内部リンク | 正しいURLになっているか |
| 管理画面 | 正常に操作できるか |
| フォーム | 送信できるか |
| メニュー | リンク先が正しいか |
テスト環境で問題がなければ、本番環境で同じ手順を実行します。テスト環境と本番環境でデータが異なる場合は、置換件数や対象範囲が変わることもあるため注意してください。
7-4. 置換後のページ表示・リンク・画像確認
置換後は、サイト全体を確認します。特に重要なページから優先的にチェックしましょう。
確認すべきページは以下です。
| ページ | 確認内容 |
|---|---|
| トップページ | 表示崩れがないか |
| 主要記事 | 本文・画像・リンクが正常か |
| 固定ページ | 会社概要、問い合わせ、サービスページなど |
| ランディングページ | CTAやフォームが機能するか |
| カテゴリーページ | 一覧表示に問題がないか |
| 管理画面 | 投稿編集や設定変更ができるか |
URL変更を行った場合は、内部リンクが正しく新URLに変わっているか、画像URLに旧ドメインが残っていないか確認してください。
7-5. キャッシュ削除とインデックス状況の確認
置換後は、キャッシュを削除してから表示を確認します。
また、ドメイン変更やURL変更を行った場合は、検索エンジンへの影響も確認しましょう。サイトマップのURL、canonicalタグ、内部リンク、リダイレクト設定などに旧URLが残っていないかチェックします。
確認項目は以下です。
| 項目 | 確認内容 |
|---|---|
| キャッシュ削除 | ページキャッシュ・CDNキャッシュを削除 |
| サイトマップ | 新URLになっているか |
| canonical | 正しいURLを指しているか |
| 内部リンク | 旧URLが残っていないか |
| リダイレクト | 旧URLから新URLへ転送されるか |
| Search Console | インデックス状況を確認 |
特にSEOに影響するURL変更では、単にワードプレス内の文字列を置換するだけでなく、リダイレクト設定やサイトマップ更新も忘れずに行いましょう。
8. ワードプレスの置換に関するよくある質問
ここでは、ワードプレスの文字列置換でよくある質問に回答します。
8-1. プラグインなしで文字列を一括置換できますか？
はい、プラグインなしでも一括置換は可能です。方法としては、SQLでデータベースを直接操作する方法や、WP-CLIを使う方法があります。
ただし、SQLは操作を誤るとデータベースを壊す可能性があります。初心者の場合は、まずプラグインを使うほうが安全です。
どうしてもプラグインなしで作業したい場合は、必ずバックアップを取り、テスト環境で検証してから本番環境で実行してください。
8-2. 記事本文だけを置換できますか？
はい、記事本文だけを置換できます。
SQLで行う場合は、wp_posts テーブルの post_content を対象にします。
SQLUPDATE wp_posts
SET post_content = REPLACE(post_content, '置換前', '置換後')
WHERE post_content LIKE '%置換前%';
プラグインを使う場合も、対象テーブルを wp_posts に絞ることで、記事本文や固定ページ本文を中心に置換できます。
ただし、wp_posts には投稿本文だけでなく、固定ページ、カスタム投稿、リビジョンなども含まれることがあります。必要に応じて post_type や post_status で条件を絞ると、より安全です。
たとえば、公開済みの投稿だけを対象にする場合は、以下のように指定できます。
SQLUPDATE wp_posts
SET post_content = REPLACE(post_content, '置換前', '置換後')
WHERE post_content LIKE '%置換前%'
AND post_type = 'post'
AND post_status = 'publish';
8-3. ドメイン変更時はどこまで置換すればよいですか？
ドメイン変更時は、投稿本文だけでなく、サイト全体に残っている旧ドメインを確認する必要があります。
主な確認対象は以下です。
| 対象 | 内容 |
|---|---|
| wp_posts | 投稿本文、固定ページ、カスタム投稿 |
| wp_postmeta | カスタムフィールド、ページビルダー設定 |
| wp_options | サイトURL、テーマ設定、ウィジェット設定 |
| メニュー | カスタムリンク |
| 画像URL | メディアファイルの参照先 |
| サイトマップ | XMLサイトマップ内のURL |
| canonicalタグ | 正規URL |
| リダイレクト設定 | 旧URLから新URLへの転送 |
ドメイン変更では、データベース置換だけでなく、301リダイレクト、Search Consoleの設定、サイトマップ送信、外部サービス連携のURL変更なども必要になる場合があります。
8-4. 置換後に元に戻す方法はありますか？
置換後に元に戻す最も確実な方法は、作業前のバックアップから復元することです。
単純な置換であれば、置換前と置換後を逆にして再置換できる場合もあります。
たとえば、以下のように戻せることがあります。
置換前：旧サービス名
置換後：新サービス名
この場合、再度「新サービス名」を「旧サービス名」に置換すれば戻せるように見えます。
しかし、置換後に新しく追加した記事にも「新サービス名」が含まれている場合、それまで旧サービス名に戻してしまう可能性があります。また、複数回の置換を行った場合や、URLの一部だけを変更した場合は、完全に元へ戻せないことがあります。
そのため、確実に戻すにはバックアップ復元が基本です。
8-5. 初心者でもSQLで置換して大丈夫ですか？
初心者がSQLで置換することは可能ですが、慎重に行う必要があります。
SQLはワードプレスのデータベースを直接変更するため、操作ミスの影響が大きいです。特に、WHERE 条件を付け忘れたり、対象テーブルを間違えたりすると、想定外のデータまで変更される可能性があります。
初心者の場合は、まずプラグインでドライランを行い、置換対象を確認する方法がおすすめです。どうしてもSQLで作業する場合は、次の手順を守りましょう。
| 手順 | 内容 |
|---|---|
| 1 | データベースをバックアップする |
| 2 | SELECT 文で対象を確認する |
| 3 | テスト環境でSQLを実行する |
| 4 | 問題がなければ本番環境で実行する |
| 5 | 実行後に表示・リンク・画像を確認する |
不安がある場合は、サーバー管理者やワードプレスに詳しい担当者に依頼するほうが安全です。
まとめ
ワードプレスで文字列を一括置換する方法には、プラグイン、SQL、WP-CLIの3つがあります。
初心者には、管理画面から操作できるプラグインがおすすめです。Better Search ReplaceやSearch Regexを使えば、記事本文やURL、ショートコードなどを比較的簡単に置換できます。作業前にドライランで確認できる点も安心です。
SQLは、特定のテーブルやカラムを直接置換したい場合に便利です。投稿本文だけを置換したい場合や、対象が明確な場合には効率よく作業できます。ただし、シリアライズデータを壊すリスクがあるため、wp_options や wp_postmeta を広範囲に置換する際は注意が必要です。
WP-CLIは、開発者や運用担当者に向いている方法です。大量データの置換やドメイン変更、テスト環境から本番環境への移行などで役立ちます。--dry-run を使えば、実行前に置換件数を確認できます。
どの方法を使う場合でも、最も重要なのは作業前のバックアップです。一括置換は便利ですが、失敗するとサイト全体に影響する可能性があります。バックアップ、ドライラン、テスト環境での検証、置換後の表示確認を徹底しましょう。
ワードプレスの置換は、正しい手順で行えば作業時間を大幅に短縮できます。置換対象と方法を見極め、安全に一括置換を進めてください。