After a migration, a domain change or a switch to HTTPS, the old address remains inside posts, menus, widget settings and page builder data. Replacing it everywhere is easy, but only with a tool that understands WordPress's serialised data.
Why not plain SQL?
WordPress stores many settings as serialised PHP strings that include each string's length, for example s:22:"https://old-domain.com". A simple SQL REPLACE() changes the text but not the length, so PHP can no longer read the value. Widgets disappear, theme options reset and page builders lose layouts. WP-CLI and dedicated plugins unserialise, replace and re-serialise each value.
Before you start
- Back up the database: cPanel → Files → Backup → Download a MySQL Database Backup, or
wp db export. - Write down the exact old and new strings, including
https://and with or withoutwww. Do not include a trailing slash.
Method 1: WP-CLI
- Open cPanel → Advanced → Terminal and go to the site folder with
cd ~/public_html. - Do a dry run to see how many replacements will be made:
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables --precise --dry-run- If the numbers look sensible, run it again without
--dry-run. - Flush caches:
wp cache flushand purge LiteSpeed Cache.
Useful options: --skip-columns=guid leaves post GUIDs alone (recommended on established sites, since feed readers use them), and --report-changed-only keeps the output short.
Method 2: Better Search Replace plugin
- Install and activate Better Search Replace from Plugins → Add New.
- Open Tools → Better Search Replace.
- Enter the old string in Search for and the new one in Replace with.
- Select all tables (hold Ctrl or Cmd), leave Run as dry run? ticked and click Run Search/Replace.
- Review the report, untick the dry run option and run again.
- Deactivate and delete the plugin when finished.
Common replacements
| Situation | Search | Replace |
|---|---|---|
| HTTP to HTTPS | http://example.com | https://example.com |
| Add www | https://example.com | https://www.example.com |
| New domain | https://old.com | https://new.com |
| Staging to live | https://staging.example.com | https://example.com |
| Server path change | /home/olduser/public_html | /home/newuser/public_html |
Run the path replacement after migrations between cPanel accounts with different usernames; some plugins store absolute paths.
Page builders and CSS files
Some builders cache generated CSS in files. After replacing, regenerate them, for example Elementor → Tools → Regenerate CSS & Data, and purge all caches.
Troubleshooting
- Zero replacements: check for typos and whether the old URL used
wwworhttp. - Some images still use the old URL: they are hard-coded in theme files or in CSS; search the files too.
- Site broken after a replace: restore the database backup and repeat with the correct strings.
- The plugin times out on a large database: lower the Max Page Size setting, or use WP-CLI, which is not limited by web timeouts.
Replacing in a multisite network
In a Multisite install, tables for each site have their own prefix such as wp_2_posts. With WP-CLI add --network to process every site, or --url=site.example.com to target one. Also update the domain in the wp_blogs and wp_site tables and the DOMAIN_CURRENT_SITE constant in wp-config.php, which search and replace does not cover.