How to search and replace text in a WordPress database
You can search and replace WordPress database text with WP-CLI, but take a backup first and use a serialisation-aware method. A raw SQL replacement can corrupt settings stored as serialised data. If you do not have command-line access, use an admin search-and-replace tool with preview mode.
- 01Identify the exact replacement
- 02Back up the database first
- 03Run the manual WP-CLI method
- 04Avoid raw SQL replacements
- 05Check the replacement worked
- 06Use the fast admin route
What you need
- A full database backup
- Administrator or hosting access
- The exact old and new text
- WP-CLI access or a serialisation-aware database tool
Identify the exact replacement
Write down the exact old value and the replacement value, including http://, https://, trailing slashes, capital letters and any path. For a domain move, search for the complete old URL rather than a short fragment that might match unrelated data.
Decide whether you need every table or only WordPress tables. On an existing site, do not normally replace values in the guid column; WordPress documentation treats those as permanent identifiers.
Back up the database first
Create a full database backup before changing anything, and store a copy outside the public web root. You need a way to restore the database if the replacement changes the wrong records or a plugin does not read its saved settings correctly.
Pause other database-changing work while the replacement runs. Keep the backup until you have checked the site from the front end and in the WordPress admin.
Run the manual WP-CLI method
If you have SSH and WP-CLI, run a dry run before saving changes:
wp search-replace 'old-value' 'new-value' --dry-run
Review the reported tables and replacement count. If the result is correct, run the same command without --dry-run. For a URL change on an existing site, add --skip-columns=guid. WP-CLI handles PHP serialised data and can use --precise when you want PHP to process every column, although that is slower. On multisite, use --network when the whole network must be changed.
Avoid raw SQL replacements
Do not use a blanket MySQL REPLACE() query across the database unless you fully understand the tables and data types involved. WordPress and plugins commonly store arrays and objects as PHP serialised values; changing text without recalculating their lengths can make those values unreadable. A serialisation-aware tool is safer for database-wide changes.
phpMyAdmin is still useful for inspecting records or changing a known plain-text value, such as a single setting, but it is a poor choice for a site-wide replacement involving options, post meta or page-builder data.
Check the replacement worked
Open the homepage, several posts or pages, menus, forms and the WordPress admin. Check images, internal links, CSS and JavaScript, especially if you changed a domain or HTTP scheme.
Search again for the old value if your tool supports a report. If the site uses caches, clear the relevant page, object and CDN caches, then test again. If only some URLs changed, check plugin-specific data and multisite tables rather than repeating a broader blind replacement.
Use the fast admin route
For the quickest route without SSH, install the WordPress Database Search And Replace plugin, open its screen under Tools, enter the old and new values, select the required tables and run its preview before applying changes.
This is a practical choice when you need serialised-data-safe replacement for a domain, HTTPS change, branding update or widespread typo. Keep the database backup, review the preview, apply the replacement, and then complete the same front-end checks.
Let WordPress Database Search And Replace plugin do it
Serialized-data-safe database replacement with preview mode, ideal for domain, HTTPS, branding, and bulk text changes.
Sources
- developer.wordpress.org /cli/commands/search-replace/?utm_source=openai
- make.wordpress.org /hosting/handbook/wp-cli/?utm_source=openai
- developer.wordpress.org /advanced-administration/upgrade/migrating/?utm_source=opena…
Questions
- Can I use a simple SQL REPLACE query?
- You can use a simple SQL replacement for a carefully identified plain-text field, but it is unsafe for a database-wide WordPress change. Options, post meta and plugin settings may contain PHP serialised data whose length markers must be recalculated. Use WP-CLI or another serialisation-aware tool for broad replacements, and take a backup first.
- Why can search and replace break WordPress settings?
- Search and replace can break settings when it edits serialised data as ordinary text. Serialised values record the length of stored strings, so replacing a URL or phrase with a different-length value can make the stored structure invalid. A tool that unserialises, changes and reserialises the value avoids that particular failure.
- Should I replace the URL in the guid column?
- No, normally skip the <code>guid</code> column when changing an existing site’s domain. WordPress uses post GUIDs as identifiers, so changing them can create unnecessary problems for feeds and applications that rely on stable values. With WP-CLI, use <code>--skip-columns=guid</code> for this type of migration.
- What changes on a WordPress multisite network?
- A multisite replacement may need to cover every site’s tables as well as network tables. WP-CLI searches only the current site by default, so use <code>--network</code> when the replacement applies across the network, and review domain, path and site settings carefully before saving.
- What is the fastest way without command-line access?
- Use a database search-and-replace tool from the WordPress admin that supports serialised data and offers a dry run or preview. Select the tables, preview the match count, check the values, apply the change and test the site. Always keep a restorable database backup because a preview cannot protect against choosing the wrong search string.