WordPressサイトを別ドメインへ移行したり、デモ環境から本番環境へ切り替えたりすると、データベース内に残った古いURLを置換したくなることがあります。
この記事は、2016年に書いたphpMyAdminでURLを置換するSQLメモを、現在のWordPress運用に合わせて見直したものです。
結論から言うと、いまはphpMyAdminでSQLを直接打つ前に、バックアップと復元手段を用意し、可能ならWP-CLIのsearch-replaceやSearch Replace系ツールを使うほうが安全です。
とくにWordPressのデータベースにはシリアライズされたデータが含まれるため、単純なSQL置換だけで全体を直そうとすると、ウィジェットやテーマ設定、プラグイン設定を壊すことがあります。
ただし、phpMyAdminしか使えない場面もあります。
その場合にどこまでSQLで触るか、どこは触らないかを整理しておきます。
WordPress移行でURL置換が必要になる場面
- テスト環境のURLを本番URLへ置き換えたい
- HTTPからHTTPSへ切り替えたあと、本文や画像URLが古いまま残っている
- ドメイン変更後に、記事本文・画像・内部リンクの一部だけ古いURLを参照している
このあたりが、phpMyAdminでURL置換SQLを調べる典型的な場面です。
ただ、WordPress公式の移行ドキュメントでも、URL変更時にはデータベース内の参照が残ること、そして全体検索置換ではシリアライズデータに注意が必要なことが説明されています。
まずデータベースをバックアップする
phpMyAdminでSQLを実行する前に、必ずデータベースをバックアップします。
これは注意書きではなく、作業手順の一部として先にやるものです。
WordPress公式のデータベースバックアップ手順では、phpMyAdminで対象データベースを選び、ExportタブからSQL形式で書き出す流れが案内されています。
小さなサイトならQuick exportでも十分ですが、復元や一部テーブルの確認も考えるならCustom exportで内容を確認しておくと安心です。
参考: WordPress公式のデータベースバックアップ手順
参考: phpMyAdmin公式のImport / Exportドキュメント
WP-CLIが使えるならsearch-replaceを優先する
サーバーでWP-CLIが使えるなら、URL置換はphpMyAdminのSQLよりもWP-CLIのsearch-replaceを優先したいです。
WP-CLI公式ドキュメントでは、search-replaceはPHPのシリアライズデータを扱い、主キーは変更しないと説明されています。
まずはdry-runで置換件数だけ確認します。
問題なさそうなら、同じ条件で本実行します。
wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guid --dry-run wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guid
ここで大事なのは、--skip-columns=guid を付けることです。
WordPress公式の移行ドキュメントでも、wp_postsのguid列は変更しないものとして扱われています。
参考: WP-CLI公式 wp search-replace
phpMyAdminでSQLを実行する流れ
phpMyAdminで作業する場合は、対象のデータベースを選び、SQLタブから実行します。
以下の画面は古いスクリーンショットですが、作業の考え方は今も同じです。
- phpMyAdminに接続し、URLを変更したいWordPressのデータベースを選択します。
- 上部のタブから「SQL」を選択します。
- SQL入力欄に必要なSQLだけを入れ、内容を確認してから実行します。
phpMyAdminで使うなら最小限のSQLにする
以前の記事では、wp_options、wp_posts、wp_postmeta、guidをまとめて置換するSQLを載せていました。
ただ、現在の判断では、そのままコピペして全体置換するのはおすすめしません。
phpMyAdminでSQLを使うなら、まずはhomeとsiteurlの確認、本文中の画像URLや内部リンクなど、範囲が分かる場所に限定します。
テーブル接頭辞を変更している場合は、wp_の部分を自分の環境に合わせます。
-- home と siteurl を明示的に変更する UPDATE wp_options SET option_value = 'https://new.example.com' WHERE option_name = 'home'; UPDATE wp_options SET option_value = 'https://new.example.com' WHERE option_name = 'siteurl'; -- 記事本文内の古いURLだけを置換する UPDATE wp_posts SET post_content = REPLACE(post_content, 'https://old.example.com', 'https://new.example.com');
このSQLは、あくまで「本文中のURL置換」に寄せた最小サンプルです。wp_postmetaやwp_optionsの広い範囲をREPLACEすると、シリアライズされた設定値を壊す可能性があります。
テーマ設定、ウィジェット、ブロック、プラグイン設定まで含めて置換するなら、WP-CLIやSearch Replace系ツールを使うほうが安全です。
GUIDは置換しない
WordPress移行のURL置換で、昔のSQLサンプルによく出てくるのがwp_postsのguid列です。
ここは触らないほうがいいです。
WordPress公式の移行ドキュメントでは、GUIDは投稿の一意識別子として扱われ、ドメインを移しても変更しないものだと説明されています。
フィードリーダーなどが既読判定に使うため、URLが古く見えても、通常の移行作業ではguidを置換しません。
そのため、以前のように以下のSQLをそのまま実行する形にはしないほうが安全です。
-- 基本的には実行しない UPDATE wp_posts SET guid = REPLACE(guid, 'https://old.example.com', 'https://new.example.com');
実行後に確認すること
URL置換後は、SQLが成功したかだけで終わらせません。
公開ページ、管理画面、画像、内部リンク、ログイン、フォーム、RSS、サイトマップをひと通り確認します。
- トップページと代表的な記事が表示されるか
- 画像URLが新しいドメインやHTTPSになっているか
- 管理画面にログインできるか
- パーマリンクを再保存して404が出ないか
- Search Console、GA4、AdSenseなどの確認タグが残っているか
- 古いURLが残っていないか、DBや公開HTMLで再検索する
WordPress移行は、SQLを実行した瞬間よりも、その後の確認で差が出ます。
戻せるバックアップがあり、どこを置換したかが分かる状態で進めるのが大事です。
WordPress運用まわりの関連記事
WordPressの移行や運用で詰まりやすいところは、別記事にも残しています。
WordPressの基本やサイト運用を見直すなら、手元に1冊あると流れを確認しやすいです。
DBを触る前に、WordPress全体の構造をざっと見直しておくのも悪くありません。
ポチップ
ポチップ