Changing a WordPress domain is more than editing Settings > General. The old domain may still receive search traffic, email, payment callbacks, and bookmarked customer visits. Inventory those dependencies before changing the live URL.
Keep a named owner for the domain registration, DNS, hosting, email provider, and connected services. Confirm access while the old site still works. Avoid combining the move with a redesign and major plugin upgrades, which makes failures harder to attribute.
Build the Cutover Inventory
Export important landing pages from Search Console, collect sitemap URLs, and add campaign pages, downloads, and high-value backlinks. Decide which URLs keep their paths and which need an explicit new destination. Use the migration redirect map for that mapping task.
Create a second inventory for domain-bound services: transactional email, payment webhooks, social login, CAPTCHA registrations, license checks, analytics filters, and CDN configuration. These settings are often outside the WordPress database.
Prepare the Destination
Provision the new host name and valid HTTPS certificate before sending visitors there. Check both preferred and alternate host variants. Preserve email DNS records such as MX and the relevant authentication records when moving DNS management; do not copy only the website address record.
Use a private test environment or a documented host preview to check the destination. Keep access restrictions out of the final public configuration without accidentally exposing a staging copy.
Explanatory evidence sheet. Record your own observations.
Replace URLs Without Damaging Stored Data
WordPress stores URLs in settings and content, and plugins may use serialized values. Follow the WordPress migration handbook for your installation layout, especially multisite or a separate core directory.
For an authorized administrator using WP-CLI, the following is a preview only. Replace both example hosts and confirm the database context first:
wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --skip-columns=guid --dry-run
WP-CLI documents the dry-run and table options. Review the affected tables and create a recoverable backup before approving the real replacement. Do not use an unrestricted database-wide replacement on a shared installation.
Test the Cutover as a Customer
Open an old bookmarked product or service page and verify its final content, not merely a 200 status. Submit a designated inquiry, check the stored lead, and confirm a reply reaches the intended mailbox. Use the gateway's approved test method to verify callbacks and the resulting order state.
Update campaign destinations and internal links. Check canonical tags and the new sitemap. Google's move guidance recommends permanent server redirects and monitoring both old and new URLs. Use Search Console's Change of Address where applicable to the type of move; it does not replace redirects.
Keep the Old Domain Under Control
Do not cancel the old registration or hosting dependency while it still handles redirects or email. Define how long the old infrastructure stays in service and who renews it. Search visibility can fluctuate during processing, so compare both properties before treating a fall on the old host as a loss across the business.
For an isolated broken redirect, callback, or WordPress URL setting, request help with that migration fault and include the exact old and intended new URL.
Sources checked September 27, 2026. Examples and diagrams are explanatory, not customer measurements.