Changing a WordPress domain does not, by itself, corrupt the database. The common danger is replacing URLs with ordinary text or blanket SQL: some stored settings contain PHP-serialized data, whose strings include recorded lengths. If a replacement changes a URL’s length but leaves that count unchanged, PHP may fail to decode the value correctly. Use a serialization-aware method, back up first, and preview the scope before applying changes.
Why a domain change can break database data
A WordPress database can hold URLs in post content, options, widgets, plugin data, theme settings, and other locations. Changing the public address may leave old-domain references behind, producing broken links or media. The WordPress migration guide also warns that themes and widgets can store values in serialized form.
| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
How to Migrate Your WordPress Site with WordPress Duplicator Plugin: Duplicator is a free and... | $7.00 | Buy on Amazon |
As an Amazon Associate I earn from qualifying purchases.
PHP serialization encodes the structure and the lengths of strings. A plain replacement may change the URL text without updating its recorded length. The resulting value can be malformed, so the code that reads it may fail or behave unexpectedly. WP-CLI’s search-replace command is designed to handle PHP-serialized data intelligently.
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 →First identify what is changing
Correcting a mistaken site URL is not the same job as moving to a new domain, changing hosts, or moving WordPress from a subdirectory to the root. The appropriate database scope depends on which change you are making. The migration guide’s general instructions also do not apply unchanged to Multisite.
For a single-site installation, WordPress distinguishes two address settings:
- WordPress Address (URL): where the WordPress core files live.
- Site Address (URL): the public address visitors use to reach the site.
Use the intended canonical addresses, include https:// when appropriate, and omit a trailing slash, as the WordPress migration guide advises. Updating these settings can correct the addresses WordPress uses, but it does not necessarily replace old URLs elsewhere in the database.
How to replace URLs without damaging serialized data
1. Make a restorable backup
Back up both the database and site files before editing. Keep the database copy outside the live database environment, and make sure you know how to restore it before proceeding. A backup is useful only if it can be recovered.
Recommended Free Tools
2. Set the canonical addresses
Update the WordPress Address and Site Address to the values appropriate for the installation. If WP_HOME or WP_SITEURL is defined in wp-config.php, that constant overrides the corresponding stored option. The constants do not rewrite the database values; removing them later can expose the old values again. See the WordPress migration guidance for the settings and move details.
3. Preview a serialization-aware replacement
With shell access and WP-CLI available, preview the intended change before writing to the database:
wp search-replace 'https://old.example' 'https://new.example' --dry-runReplace the example addresses with your actual old and new URLs. The --dry-run option reports the changes without saving them. Review the output and table scope; WP-CLI supports selecting tables and excluding columns. Its documentation says the command handles PHP-serialized data and does not change primary-key values.
After checking the preview, run the intended replacement without --dry-run, or use WP-CLI’s --export option to write transformed SQL for review and import. Avoid applying a broad replacement automatically just because a preview completes: verify that the selected tables and columns match the migration you intend.
4. Keep GUIDs out of ordinary domain replacement
Do not casually rewrite the guid column. WordPress treats GUIDs as persistent identifiers used by feed readers, not as ordinary links to update during a domain change. The migration guide’s example excludes that column; WP-CLI also documents column-exclusion options.
5. If working in the WordPress admin
A plugin such as Better Search Replace provides an admin workflow for search and replacement. Check which tables it will affect and whether its access model fits the site, particularly for Multisite. Its listing warns that incorrect replacement strings can damage data, so back up first and review the inputs and scope carefully.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why changing only the address settings may not finish the move
The home and siteurl options are important, but changing them does not guarantee that every old-domain reference has been updated. Links in content, media references, widget values, plugin settings, theme settings, or other database records may still point to the former address. Conversely, a replacement intended only for a specific migration should not alter unrelated values simply because they contain a matching string.
For that reason, choose a tool and scope based on the actual move. WordPress cautions against a blanket ordinary-SQL replacement because of serialized data; WP-CLI’s documented command or a suitable plugin can handle serialized values, but you still need to decide which tables and columns to include.
How to verify the site after replacement
- Open representative front-end pages and check that navigation, links, and media load from the intended address.
- Sign in to the WordPress admin and confirm that the address settings behave as expected.
- Test forms and features that depend on plugins or theme settings.
- Review redirects and custom rewrite rules. If permalink behavior is wrong, regenerate permalinks as needed and retest; the WordPress migration guide discusses these checks.
- If something fails, restore from the verified backup rather than attempting more unreviewed replacements on the damaged data.
What changes for WordPress Multisite
Multisite stores additional domain and path information across network and per-site tables. A single-site replacement workflow may not cover all of it. WP-CLI requires --network when working with network tables, but that does not remove the need to review the network and each site’s settings manually. WordPress describes Multisite migration as requiring careful database review rather than assuming the process is easily automated. If you cannot account for the network-wide scope, stop before applying a broad replacement.
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.
