A company is moving from example.netto example.com. DNS already points both names at the new server, but WordPress still generates the old canonical host, the certificate covers only the new name, and a database-wide replacement could lock administrators out before cookies and redirects are ready.
A domain change must coordinate the WordPress addresses and stored URLs with DNS, TLS, proxy rules, cookies, email identities, and external callbacks. Prepare the new host and a recovery route first, then preview only the database values that genuinely belong to the site.
What it means
Changing a WordPress domain involves more than replacing one hostname in the database. The homevalue controls the public site address, while siteurlidentifies where the WordPress application files are served. Constants in wp-config.phpcan override both, and multisite stores additional network and subsite mappings.
Content, media metadata, widgets, menus, and plugin settings may also contain the old domain. A serialization-aware replacement can update confirmed site-owned values, but DNS, certificates, redirects, cookie behavior, mail authentication, and third-party services must be changed in their own systems.
- Record both hostnames, WordPress addresses, DNS records and TTL, certificate coverage, proxy origin, and administrator recovery access.
- Map OAuth callbacks, payment webhooks, license endpoints, analytics, email identities, and any hard-coded server configuration.
- Decide which old-domain references should be replaced, redirected, or deliberately retained.
A realistic WordPress example
Before the company cutover, the new domain resolves to the correct origin and has a valid certificate. The team confirms a separate administrator session, lowers DNS TTL where appropriate, and inventories callbacks and mail settings. A preview then finds the old domain in page content, media metadata, options, and an external payment webhook.
The site-owned content is approved for replacement, but the webhook is changed through the payment provider instead of the WordPress database. After updating the canonical WordPress settings, the team applies the reviewed replacement, tests login and transactions on the new host, and adds one-hop redirects from matching old paths only after the new routes work.
Why it matters and when to use it
Change the database during a planned cutover while both names remain available for testing and rollback. The new origin, certificate, and proxy path must already accept the new host. Every integration that uses the domain needs an owner and a documented update route.
If only homechanges, the public site and administration paths can split unexpectedly. If the database changes before TLS or host routing is ready, users may see certificate errors or redirects to an unavailable address. If login, cookies, multisite routing, callbacks, or critical transactions fail, restore the previous canonical settings before making further changes.
A straightforward route for beginners
- Take a restorable database backup and document the current WordPress addresses and administrator recovery route.
- Verify the new domain at the origin, install valid TLS, and confirm DNS and proxy routing.
- Map the old and new values, including
www, schemes, subdomains, paths, and multisite domains. - Update the canonical WordPress settings through a supported method, then run a serialization-aware preview for the remaining site-owned references.
- Review table-level matches and exclude GUID history, external services, email addresses, and literal archive text unless they require a change.
- Apply the approved replacement, clear relevant caches, and test the new host before enabling old-domain redirects.
Keep both domains and the previous settings available until the public site, admin area, and integrations have passed their checks.
The advanced route
Inspect the effective configuration, not only the database. Check WP_HOMEand WP_SITEURL, load-balancer host headers, reverse-proxy trust, cache keys, object caches, and any host-level redirects. On multisite, distinguish network domains, subsite domains, and domain-mapping components.
- Test public and admin login, cookies, password reset, REST requests, cron, media, forms, checkout, and account pages.
- Review canonical and hreflang output, sitemaps, feeds, CORS and CSP rules, and mixed-content requests.
- Update OAuth callbacks, payment webhooks, analytics, licenses, email identities, and mail authentication with their respective providers.
- Trace one permanent redirect from each approved old-host path to its matching new path; avoid chains and blanket redirects that hide missing content.
Watch the old host during a representative traffic and scheduled-job window. Unexplained requests show dependencies that are not ready for retirement.
Risks, common mistakes, backup, and rollback
A premature database change can cause an outage, a login loop, broken cookies, or a site split between two canonical hosts. An overbroad replacement can alter unrelated addresses, signed callback values, license endpoints, or historical identifiers.
- Do not change database values before the new host and TLS path are proven.
- Do not assume a global replacement can update outside providers or server configuration.
- Stop if preview and write counts differ unexpectedly or if login, multisite routing, callbacks, email, or transactions fail.
- Do not retire or redirect the old host until assets, scheduled jobs, and integrations no longer depend on it.
Keep the old canonical values, verified backup, and redirect configuration ready. Roll back the WordPress addresses first when the cutover fails, then restore or reverse the database change according to whether newer production data must be preserved.
How AIOWS helps:
AIOWS Replace Manager
AIOWS Replace Manager handles the database portion of a domain change through a preview-first, serialization-aware workflow. Once the new host, TLS certificate, and recovery access are ready, enter the exact old and new values and select only the approved tables and columns.
Review the preview by table and inspect examples from content, media metadata, options, widgets, and plugin settings. Exclude references that belong to outside services or should remain historical. Save the dry-run result, apply the replacement only when its counts and samples match the cutover plan, and then compare the write result with the preview. Test the new domain in public and administrator sessions, including login, media, forms, transactions, and connected services.
Replace Manager cannot change DNS, install a certificate, configure a reverse proxy, update a payment provider, or decide which old-domain references should remain. It also cannot make an untested backup usable or preserve later production writes during a broad restore. If the database scope changes, preview again. If host-sensitive workflows fail, stop further writes and return to the previous WordPress addresses while the cause is investigated. Keep the backup, values, exclusions, counts, application tests, redirect checks, and recovery decision with the cutover record.
Related AIOWS articles
- How to Search and Replace WordPress URLs After Migration
- How to Replace HTTP URLs with HTTPS in WordPress
- How to Undo a WordPress Search and Replace Operation
Conclusion and recommended route
Prepare DNS, TLS, proxy routing, and administrator recovery access before changing WordPress. Update the canonical settings in a planned order, preview the remaining site-owned database references, and apply only the approved scope. Keep both names available until login, content, integrations, and one-hop redirects have all been verified.
