Change WordPress URLs After Migration Safely

A staging site has moved from a temporary subdomain to the production domain. The home page looks correct after changing two options, but images, page-builder buttons, widgets, canonical tags, and login cookies still reference the temporary address.

This guide shows how to identify which URLs actually need changing, update serialized WordPress data safely, and verify the references that are easy to miss after a migration.

What changing WordPress URLs involves

A URL change may affect the public site address, the location of WordPress application files, and absolute links stored in content, metadata, widgets, or plugin tables. The homeoption controls the public address; siteurlidentifies where WordPress itself is installed. They are usually the same, but they serve different purposes.

Many WordPress values are serialized and include the length of each stored string. A raw SQL replacement can change the text without correcting that length and make the value unreadable. DNS, TLS, proxy rules, server redirects, caches, and third-party callback URLs are separate from the database operation.

A realistic WordPress example

A staging site moves from preview.example.comto the production domain. Updating homeand siteurlfixes the main navigation, but a page builder still stores the preview host in serialized metadata. Images load from the old address, canonical tags disagree with the browser URL, and password-reset links point back to staging. A scoped, serialization-aware replacement is needed for those database values; the mail service callback must be changed in its own configuration.

Why it matters and when to use it

Replace stored URLs when the canonical domain, protocol, subdirectory, or installation path truly changed. If only DNS moved to a new server and the public address stayed the same, a database-wide replacement is unnecessary. Diagnose redirect loops separately: an old database value, a reverse proxy, the web server, WordPress, or a CDN can each issue a redirect.

A straightforward route for beginners

1. Back up the destination database and record old URL, new URL, scheme, path, table prefix, network scope, and excluded columns.
2. Confirm the intended home and siteurl values first, using a temporary configuration override only when dashboard access must be recovered.
3. Run a serialization-aware dry run, review affected tables and counts, then execute the exact replacement without changing GUID values unless a documented case requires it.
4. Clear relevant WordPress, object, page, browser, and CDN caches only after the stored values and server routing are correct.
5. Crawl representative pages and test media, menus, page-builder content, widgets, REST, login, password reset, canonicals, sitemap, redirects, forms, and callbacks.

The advanced route

Use WP-CLI search-replaceor another tool that understands serialized data. Start with a dry run, limit the table scope, review hit counts, and record the exact command, exclusions, output, and exit status. Avoid changing GUID values unless a documented migration case specifically requires it.

• On multisite, plan network tables, site-specific tables, domain mapping, and uploads explicitly.
• Search for the exact old scheme, host, port, and path; broad fragments can alter unrelated text or email addresses.
• After replacement, search again for the old host and classify every remaining match instead of deleting it automatically.

Risks, common mistakes, backup, and rollback

• A plain SQL replacement can corrupt serialized settings used by themes and plugins.
• Changing siteurlincorrectly can make the dashboard and application files unreachable.
• Replacing GUID values without a valid reason can affect feed readers and external consumers.
• Clearing caches before stored values and routing are correct can make diagnosis harder without fixing the source.

Back up the destination database immediately before the replacement and retain the dry-run counts. If verification fails, restore that database copy, clear only the caches affected by the rollback, and reassess the old and new URL scope.

Related AIOWS articles

• WordPress Migration: Move a Site to a New Host Safely
• WordPress Site Broken After Migration? Complete Fix Guide
• WordPress Migration Checklist: Before and After Moving

Conclusion and recommended route

Back up first, set the two canonical addresses deliberately, and use a serialization-aware dry run with reviewed scope. Replace only the intended old address, preserve command evidence, clear caches afterward, and test both visible pages and hidden callbacks. Remaining old-host matches must be classified, not blindly erased.

Official sources

• Migrating WordPress
• WP-CLI search-replace command