Use a serialisation-aware search-and-replace tool when changing URLs stored in a WordPress database. It can update values inside structured plugin and theme settings without the string-length corruption that a simple SQL text replacement can introduce.
IN THIS ARTICLE
01 Identify the exact target
Back up the database and confirm the WordPress directory, database and table prefix. Specify the full old and new URL, including the scheme and any subdirectory. A broad replacement of a short word or domain fragment can change email addresses, unrelated text and integration settings. Test on a staging copy first.
02 Preview with WP-CLI
If SSH and WP-CLI are available for your account, run the command from the verified installation directory. This example previews one URL change without saving it:
wp search-replace 'https://old.example.com' 'https://example.com' --skip-columns=guid --dry-runReview the table and replacement counts. By default WP-CLI works with the registered tables for the selected installation. Custom plugin tables may need an explicitly reviewed scope. Do not casually add an all-tables option on a database shared by other websites.
03 Apply and verify
- Save the dry-run report and investigate unexpected tables or large replacement counts.
- During the agreed change window, take a fresh backup if live data has changed since the test.
- Repeat the exact reviewed command without
--dry-run. - Clear only the relevant caches and check representative pages, images, settings and forms.
- Run another dry run for the same old URL to identify remaining matches, then assess whether each remaining value should actually change.
04 Example: preview a deliberately limited URL replacement
On a protected single-site staging copy, first verify the table prefix and take a database backup. This example previews three explicitly selected tables; replace their names if the installation uses another prefix. It does not write changes.
wp --path='/home/ACCOUNT/sites/staging.example.com' \
--url='https://staging.example.com' search-replace \
'https://old.example.com' 'https://example.com' \
wp_posts wp_postmeta wp_options \
--skip-columns=guid --dry-runReview the per-table counts and why each table is included. This intentionally limited preview is not a claim that every plugin or taxonomy table has been covered. Expand scope only after identifying the other relevant tables. Do not use this single-site example as an unreviewed Multisite network migration.
Expected result: The report shows only the expected old URL occurrences and preserves GUIDs. A later write uses the precisely reviewed scope during the planned change window, followed by checks of pages, images, forms and stored settings.
Why skip the GUID column?
WordPress uses post GUIDs as persistent identifiers, particularly for feeds. They are not a general field for the current public permalink. The normal domain-migration example therefore excludes them instead of rewriting every occurrence indiscriminately.
Can I use phpMyAdmin REPLACE instead?
A raw replacement does not understand PHP-serialised values. Use a maintained WordPress migration tool or WP-CLI's serialisation-aware operation for this task. If you cannot identify the tables or recover the database, ask us to review the scope before running a write. On Multisite, network tables and individual subsites need a deliberate migration plan rather than this single-site example applied broadly.