Table of Contents
To change WordPress domain safely, update the site URL in the database with a serialization-aware tool such as WP-CLI search-replace or the Better Search Replace plugin, then move files and set 301 redirects from the old domain to the new one. Verification is done by checking that no old URLs remain in wp_options, wp_posts, and wp_postmeta, that media library items load, and that curl -I on old paths returns HTTP/1.1 301 Moved Permanently pointing to the new domain. If serialized strings were edited with a naive SQL REPLACE, widgets and options break — that is the failure mode to avoid.
Symptoms and Fast Triage Commands
After a domain swap you may see a blank front end, a redirect loop, missing images, or widgets that reset to defaults. Those symptoms usually mean the database still holds the old domain inside serialized PHP arrays. Start triage with these commands from the WordPress root in 2026 (WP-CLI 2.11+):
wp option get siteurl
wp option get home
wp search-replace --dry-run 'https://old.example' 'https://new.example' --all-tables
wp post list --fields=ID,post_title --posts_per_page=5
The --dry-run output shows how many rows would change per table. If widgets or theme mods are listed, serialized data is present. Check media with wp post list --post_type=attachment --fields=ID,guid. If old URLs appear in guid or post_content, you have not finished the replacement. A redirect loop often means home and siteurl disagree or .htaccess still forces the old host.
Step-by-Step Migration Process
- Back up files and database with
wp db export backup-$(date +%F).sqland tar the uploads folder. - Run
wp search-replace 'https://old.example' 'https://new.example' --all-tables --preciseto rewrite URLs without breaking serialization. - Update DNS and web server config for the new domain, keeping the old vhost alive for redirects.
- Set 301 rules on the old domain pointing to identical paths on the new domain.
- Crawl the site and query the database to confirm zero old-domain strings remain.
- Test media URLs, permalinks, and login flow, then roll forward only when verification passes.
Why Serialized Data Breaks
WordPress stores many settings as PHP serialized strings, where every value is prefixed with its byte length, for example a:2:{s:5:"email";s:15:"a@old.example";}. A plain SQL UPDATE or a text editor find-and-replace changes the domain string but not the s:15 length marker, so PHP’s unserialize() fails and returns false. That is why widget areas, theme options, and plugin settings vanish after a naive replace. The fix is to use a tool that rewrites the string and recomputes the serialized length. For deeper background on how WordPress stores options, see the Options API documentation. If you already corrupted data, restore the backup SQL dump you made before the change; there is no reliable way to repair broken serialization after the fact.
How to Confirm Serialization Is Intact
Get a Quote
Email + requirement + budget range — we reply with a quote within 24 hours.
After replacement, run wp option get widget_text or inspect a known array option. Valid output prints a readable array, not false or empty. You can also check with wp eval 'var_dump( is_serialized( get_option("my_theme_options") ) );' using the WordPress is_serialized() function.
Correct Tools for the Job
The only safe 2026 tools are serialization-aware. WP-CLI search-replace is the command-line standard; it parses each column, unserializes, replaces, and re-serializes correctly. The Better Search Replace plugin (version 1.4+) offers the same logic in the admin UI for users without shell access. Never use phpMyAdmin’s inline edit or a raw UPDATE wp_options SET option_value = REPLACE(...) statement. If you manage many sites, our team covers this in WP-CLI commands worth automating in 2026. For complex builds, custom WordPress development ensures the data layer is mapped before any domain change.
Command Reference
# Full replacement with serialization support
wp search-replace 'https://old.example' 'https://new.example'
--all-tables --precise --report-changed-only
# Skip GUID column to avoid feed confusion (optional)
wp search-replace 'https://old.example' 'https://new.example'
wp_posts --include-columns=post_content,post_excerpt
Pitfall: forgetting --all-tables leaves multisite or custom tables stale. Rollback is wp db import backup-2026-05-14.sql plus restoring files from your tar archive.
301 Redirects From the Old Domain
Keep the old domain’s DNS and TLS active for at least six months. On Apache, place this in the old vhost’s .htaccess:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old.example$ [NC]
RewriteRule ^(.*)$ https://new.example/$1 [R=301,L]
On Nginx 1.26 use a dedicated server block: return 301 https://new.example$request_uri;. Verify with curl -I https://old.example/sample-post/ and confirm the response is HTTP/1.1 301 and the Location header uses the new host. This preserves SEO equity and inbound links. A common mistake is a 302 temporary redirect, which does not pass authority. For full infrastructure moves, review WordPress server migration without downtime.
Checking Links and Media URLs
After replacement, scan content and attachments. Run wp search-replace --dry-run 'https://old.example' 'https://new.example' --all-tables again; a count of zero means clean. Then query media:
SELECT ID, guid FROM wp_posts WHERE post_type = 'attachment'
AND guid LIKE '%old.example%';
Empty result means media URLs are correct. Use wp post list --post_type=attachment --fields=ID,guid | grep old.example as a shell alternative. Also open the Media Library in wp-admin and confirm thumbnails render. Internal links in post_content should already be rewritten; if you skipped tables, add them now. Finally, use a crawler such as wget --spider -r https://new.example to catch 404s on assets.
Prevention and Rollback
Always snapshot before starting: wp db export and a file-level backup. Stage the domain change on a clone subdomain first. Keep a maintenance window and monitor wp-content/debug.log with WP_DEBUG enabled temporarily. If something fails, restore the SQL dump, revert DNS to the old host, and clear object cache with wp cache flush. Document every command in a runbook so the next migration is faster. Teams that follow a repeatable process, like the one in a safe WordPress upgrade process, rarely hit corruption.
Action Checklist
- Export database and archive uploads before touching anything.
- Run serialization-aware replacement with WP-CLI or Better Search Replace.
- Verify zero old-domain rows with a second dry run.
- Configure 301 redirects on the old host and test with curl.
- Confirm media GUIDs and content links contain only the new domain.
Need help executing this safely? Our engineers handle domain moves daily. See our WordPress development services for hands-on migration support and architecture review.
Frequently asked questions
Can I just change the domain in WordPress general settings?
No. The Settings screen updates only siteurl and home; all other content and serialized options keep the old domain, which breaks widgets and media.
How long should old-domain 301 redirects stay live?
Keep them for at least six months, ideally twelve, so search engines and inbound links transfer authority to the new domain.
What if I already ran a bad SQL replace?
Restore your pre-change database backup immediately; broken serialization cannot be reliably repaired by another query.
