Use a serialization-aware tool—preferably WP-CLI’s wp search-replace—to change a domain, path, or other repeated value in WordPress. Back up the database first, run a dry run, limit the tables and columns you intend to change, then verify the site and keep a rollback copy. Do not apply a blanket SQL REPLACE() to a WordPress dump: PHP-serialized values contain string-length metadata that ordinary text replacement can invalidate.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Why WordPress database replacements need care
A domain migration can put the old URL in posts, pages, menus, widgets, theme settings, plugin options, attachment metadata, and custom tables. Finding every occurrence is straightforward; changing every occurrence safely is the difficult part.
As an Amazon Associate I earn from qualifying purchases.
Many WordPress settings are stored as PHP-serialized arrays or objects. A serialized string records its length, such as s:18:"old.example/path". If a replacement changes that length and the length marker is not updated, PHP can no longer decode the value. The visible URL may appear correct while a widget, menu, theme option, or plugin setting is corrupted.
The WordPress Advanced Administration Handbook warns about this serialization problem and recommends serialization-aware tools such as WP-CLI search-replace, Better Search Replace, Velvet Blues Update URLs, or a specialist database script. A plain SQL replacement or editing an exported SQL file is appropriate only for a narrowly understood field that is definitely not serialized.
#1 Best Overall
WP-CLI describes its command this way: “Search/replace intelligently handles PHP serialized data, and does not change primary key values.” That makes it the most controllable option when you have shell access.
Choose the right method
| Method | Serialized data | Preview or dry run | Scope controls | Multisite | Export or logging | Access required |
|---|---|---|---|---|---|---|
| WP-CLI | Handles PHP-serialized values and preserves primary keys. | --dry-run performs the operation without saving. |
Table arguments, --include-columns, --skip-columns, and --skip-tables. |
--network covers registered tables across the network. |
--export=database.sql creates an SQL artifact instead of writing in place. |
SSH or another shell with WP-CLI and database access. |
| Better Search Replace | Uses WordPress-native database functions and is built from the open-source Search Replace DB project; use its preview before writing. | Preview or dry-run capability is available in the plugin workflow. | Select the tables you want to process; review the reported replacement count. | Run it with a clear understanding of whether you are operating on one site or the network. | Review the on-screen report and retain your database backup. | WordPress dashboard access; useful when SSH is unavailable. |
| Manual SQL | No automatic serialized-data repair. A length-changing replacement can break values. | Only whatever read-only query you write yourself. | Whatever tables and columns you specify; easy to overreach. | No WordPress-aware network handling. | Depends on your database tools and backup process. | Database client or hosting control panel. |
For repeatable migrations, WP-CLI is usually the best choice. For a dashboard-only workflow, Better Search Replace is the practical alternative. Treat manual SQL as a specialist technique for a confirmed non-serialized field, not as the default URL-migration method.
Free tools Windows power users keep installed
One-click scans. No signup required.
Prepare a safe migration
1. Define exactly what will change
Write down the old and new values exactly, including the protocol, host, path, and trailing slash convention. For example, decide whether you are replacing http://old.example, https://old.example, or both. A replacement for old.example is broader and can also match email addresses, image paths, or text that you did not intend to edit.
Decide whether the change is a whole-domain migration, a subdirectory change, or a small correction in one plugin or table. The narrower the target, the lower the chance of changing unrelated content.
2. Take and preserve a database backup
Export the database before any write operation and store the file somewhere separate from the server. Confirm that the export can be opened or restored, and record how you would put it back. A database backup is your rollback path if a serialized option, login URL, widget, or custom table is damaged.
3. Check access and maintenance conditions
- Confirm that the site is running the WordPress installation you intend to modify.
- Make sure your shell user can run WP-CLI, or that you can sign in as an administrator for the dashboard method.
- Record the current home and site URLs and any multisite domains before editing.
- Plan a low-traffic maintenance window if the replacement will touch a large database.
- Pause deployments or content edits while the dry run and write operation are in progress, so the report matches the database you are about to verify.
Run the replacement with WP-CLI
Run these commands from the WordPress installation directory. Replace the example domains with your exact values. Quote the arguments so shells do not interpret special characters.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems1. Perform a read-only preflight search
wp db search 'old.example' --all-tablesThis shows where the old string occurs before you change anything. The --all-tables option searches every table in the database, including tables that WordPress does not register. Use the result to identify custom plugin tables or unrelated data that should be excluded.
2. Run a dry run
wp search-replace 'https://old.example' 'https://new.example' --dry-run--dry-run executes the search-and-replace logic and reports what would change without saving database writes. Read the table-by-table report. Unexpected tables, a surprisingly large count, or matches in data that should remain unchanged are reasons to stop and narrow the command.
3. Narrow the table and column scope when appropriate
Appending table names limits the operation to those tables:
wp search-replace 'https://old.example' 'https://new.example' wp_posts wp_postmetaUse --include-columns when only named columns should be processed, and --skip-columns for columns that must not change. Use --skip-tables to leave known tables untouched. A narrow first pass is safer than assuming that every occurrence belongs to the migration.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
4. Handle multisite and custom tables deliberately
On a single site, WP-CLI’s default scope is the tables registered to $wpdb. On multisite, the default command operates on the current site’s scope. Add --network when the replacement must cover all registered tables across the network:
wp search-replace 'https://old.example' 'https://new.example' --network --dry-runFor custom plugin tables that share the WordPress prefix, use --all-tables-with-prefix, or name the custom tables explicitly. Use --all-tables only when you have reviewed the preflight results and genuinely need every database table. A network-wide replacement and a single-site replacement are different operations; do not assume one will update the other.
5. Decide what to do with guid
WordPress post guid values are not ordinary display links. Decide deliberately whether they belong in your migration. WP-CLI documents --skip-columns=guid as an example for URL migrations:
wp search-replace 'https://old.example' 'https://new.example' --skip-columns=guid --dry-runUse that exclusion only when it matches your migration policy; do not add it automatically without deciding what your site’s feeds and historical identifiers require.
6. Execute only after reviewing the report
wp search-replace 'https://old.example' 'https://new.example'Use the same table, column, multisite, and exclusion options that passed your dry run. Save the terminal output or log. If you want a reviewable SQL artifact rather than in-place writes, use:
wp search-replace 'https://old.example' 'https://new.example' --export=database.sqlAn exported artifact lets you inspect the generated changes and apply them through your normal database-change process instead of writing directly during the command.
7. Use advanced processing only when the case justifies it
--precise forces PHP processing across columns. WP-CLI documents it as slower but more thorough, so reserve it for complex serialized structures or when the normal processing path does not give you confidence. Regex mode is substantially slower—about 15–20 times longer according to the command documentation—and should be used only for a pattern-based change that cannot be expressed as a literal replacement.
Use the dashboard with Better Search Replace
Better Search Replace is listed in the official WordPress.org Plugin Directory. Its listing says the plugin is based on the open-source Search Replace DB script and uses WordPress native database functions. Activating it adds a page under the WordPress Tools menu.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Rank #4
- Complete and verify the database backup described above.
- Install and activate Better Search Replace from the WordPress dashboard.
- Open Tools and then the Better Search Replace page.
- Enter the old value and the new value exactly. Include the protocol when you intend to change a full URL.
- Select only the tables that belong to the migration. Include custom plugin tables only after confirming what they store.
- Enable the plugin’s preview or dry-run option and review the reported tables and replacement count.
- Run the replacement after the preview matches your plan, then retain the report for your change record.
- Deactivate or remove the plugin when you no longer need it, according to your site’s maintenance policy.
The dashboard route avoids SSH, but it does not remove the need for a backup, a narrow scope, and post-change testing. If you cannot identify which tables should change, stop and investigate before pressing the write button.
Scope decisions that prevent accidental edits
Single site versus multisite
For a single site, start with the registered WordPress tables and add custom tables only when the preflight search shows they contain migration data. For multisite, determine whether every site, domain, and path should change. Use --network for a network-wide WP-CLI operation; otherwise you may update one site while leaving another with the old domain.
Registered tables versus custom tables
Plugins often create tables that WordPress does not register in $wpdb. The default WP-CLI scope may therefore miss data such as logs, indexes, or plugin-specific records. Add those tables explicitly, use --all-tables-with-prefix for unregistered tables sharing the prefix, or use --all-tables only after inspecting the database inventory.
Columns that should not change
Use include and skip column options to protect identifiers, hashes, external URLs, or values that merely happen to contain the old text. The guid decision is the most common URL-migration example, but custom tables may have their own columns that require exclusion.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Verify the database and the site after replacement
A successful command is not proof that the site is correct. Verify both the data and the user-facing behavior.
- Review the WP-CLI or plugin report and note errors, skipped tables, and the total replacement count.
- Run a targeted search for the old value:
wp db search 'old.example' --all-tablesSome remaining matches may be intentional—for example, historical text, an excluded table, or a guid value—so compare the results with your scope decision rather than demanding a zero count blindly.
Best Value
- Open the home page and several representative posts or pages.
- Load images, downloadable files, menus, and embedded media to check that their URLs resolve.
- Sign in to
/wp-admin, open key settings and widgets, and confirm that serialized options still load. - Test forms, feeds, redirects, caches, and any integrations that store callback or API URLs.
- On multisite, sign in to and browse each affected domain or mapped site.
- Check browser developer tools or server logs for redirects, 404 responses, mixed-content warnings, and database errors.
Keep the backup until these checks pass and you have completed any cache purge or DNS work associated with the domain change.
Troubleshoot common failures
The old URL still appears
First determine whether the occurrence is in a table or column you intentionally skipped. Then search all tables with wp db search. If the value is generated from an environment variable, a configuration file, or a page-builder cache, a database replacement alone will not remove it. Clear the relevant cache only after confirming that the stored data is correct.
Recommended Free Tools
Widgets or plugin settings stop loading
This is a classic symptom of broken serialized lengths after a raw SQL edit. Restore the backup rather than trying to repair individual length markers by hand, then repeat the migration with WP-CLI or another serialization-aware tool.
The site redirects to the wrong domain or the dashboard is inaccessible
Check the home and siteurl options, web-server redirects, and any hard-coded values in configuration files. If you cannot reach the dashboard, use WP-CLI or the database backup to restore the correct values, then repeat verification before reopening the site.
Only one site in a network changed
The command probably ran in the current-site scope without --network, or the affected domain is stored in a custom table that was not selected. Review the dry-run scope, identify the missing tables, and run a separate, explicitly scoped operation.
The replacement takes too long
Reduce the table and column scope, avoid regex unless a pattern is essential, and schedule the operation during a maintenance window. The documented 15–20-times slowdown for regex mode is a reason not to enable it for a simple literal URL change.
When manual SQL is acceptable
Manual SQL can be reasonable when you have identified one ordinary, non-serialized column and have a tested rollback. For example, a custom table may contain a plain text status field whose values never appear inside serialized arrays. In that case, a database administrator can write a column-specific UPDATE with a restrictive WHERE clause, test it on a copy, and inspect the affected row count.
Do not use a broad statement such as UPDATE ... SET column = REPLACE(column, ...) across WordPress options, post metadata, term metadata, widgets, or plugin settings unless you have proved that those columns contain no serialized values. Exported SQL text editing has the same serialization risk because it changes characters without repairing PHP’s stored length metadata.
A repeatable decision path
- Need to change URLs or another value across normal WordPress data? Use WP-CLI search-replace, or Better Search Replace if you lack shell access.
- Need a network-wide change? Use WP-CLI with
--networkand verify every affected site. - Need plugin-created data? Identify the custom tables and include them explicitly or with
--all-tables-with-prefix. - Need an audit-friendly file? Use
--export=database.sqland review the artifact before applying it. - Need a pattern rather than a literal value? Use regex only when necessary, allowing for the documented performance cost.
- Unsure whether a field is serialized? Treat it as serialized and use a serialization-aware tool.
The safe sequence is consistent: define the exact old and new values, preserve a tested backup, inspect a dry run, constrain the scope, write the replacement with serialization-aware processing, and verify both representative content and every affected site.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
