How to Move WordPress to a New Domain Safely

Moving WordPress to a new domain changes the public identity of every page, not merely the server address. WordPress settings, database values, media references, cookies, TLS, redirects, email authentication, API callbacks, analytics, and search signals may all contain the old hostname. The migration succeeds only when users and automated systems reach the correct new URL without losing data or entering redirect loops.

Quick answer: Inventory all old URLs and domain-dependent integrations, prepare the new domain and TLS, clone and test the site privately, then replace stored URLs with a serialization-aware tool. At cutover, synchronize final writes, activate direct permanent redirects from every old URL to its equivalent new URL, update canonicals and internal links, publish a clean sitemap, and monitor both domains. Keep ownership, DNS, TLS, and redirects on the old domain for the long term.

Separate the domain change from the hosting decision

You may keep the same server and change only the domain, or change domain and hosting together. Combining both increases the number of possible failure points. If practical, stabilize the new infrastructure first with the existing domain, then perform the URL migration as a separate controlled release.

If both changes must happen together, maintain two checklists: infrastructure and URL identity. The general WordPress hosting migration guide covers files, database, DNS cutover, and rollback.

Inventory everything tied to the old domain

WordPress Address and Site Address
post content, widgets, menus, options, and page-builder data
media, CSS, JavaScript, fonts, and CDN origins
canonical, hreflang, Open Graph, feeds, and structured data
email sender domains, SPF, DKIM, and DMARC
OAuth, payment, webhook, storage, and API callback URLs
analytics, tag managers, ad landing pages, and consent settings
Search Console, business profiles, social profiles, and external links

Search source code, configuration, database reports, DNS records, and external dashboards. A database replacement cannot update a payment provider dashboard or an email DNS record.

Build a complete old-to-new URL map

For a pure domain change, paths should normally remain identical. Map each old page to the same path on the new hostname. Include posts, pages, categories, products, language variants, media pages where indexed, feeds, and valuable historical URLs.

If paths also change, record the intended equivalent page individually. Do not redirect unrelated missing URLs to the homepage. The WordPress SEO migration checklist explains redirect relevance, canonical consistency, and crawl verification.

Prepare the new domain before copying production

Confirm registrar access, authoritative DNS, renewal ownership, and DNSSEC implications. Create the required records and verify that the destination can serve the new hostname. If email will use the new domain, prepare its authentication and provider configuration separately from web traffic.

Do not abandon the old domain. Losing control breaks redirects, email continuity, security recovery, and links that users may continue to follow.

Issue and verify TLS for both domains

The new domain must present a valid certificate with a complete chain before users are redirected to it. The old domain must also retain valid HTTPS because an HTTPS request reaches TLS before receiving an HTTP redirect. An expired certificate on the old hostname prevents a clean redirect experience.

Test apex, www, language subdomains, and any other public hostname. Confirm automatic renewal and origin TLS if a CDN sits in front.

Create a private test copy

Copy the files and database into the target environment, then test with controlled hostname resolution or restricted access. Prevent the preview from being indexed and from sending production email, payment requests, or webhooks.

Use the final new hostname for testing. A temporary preview hostname can hide cookie, redirect, CORS, canonical, and mixed-content defects.

Change WordPress home and site URLs deliberately

The home value is the public site address; siteurl identifies where WordPress core is addressed. They are often equal but can differ in supported directory layouts. Update them to the intended HTTPS URL and check whether WP_HOME or WP_SITEURL constants override database values.

WP-CLI can update these options from the correct WordPress root:

wp option update home 'https://new.example'
wp option update siteurl 'https://new.example'

The domains are placeholders. Take a database backup and confirm the expected directory layout before changing production values.

Replace stored URLs without corrupting serialized data

WordPress plugins, themes, and page builders may store PHP serialized values whose string lengths are part of the data. Raw SQL or text-editor replacement can corrupt those values. The official WordPress migration guide recommends serialization-aware approaches.

WP-CLI supports a dry run:

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --dry-run
wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix

Review affected tables and counts before the write. Search separately for HTTP variants, www, escaped URLs, CDN hostnames, and email addresses; do not replace broad domain fragments that may belong to user email or external services.

Know which identifiers should not be rewritten blindly

Some identifiers are not display URLs. GUID values, license records, cryptographic signatures, external object keys, and historical logs may have application-specific meaning. Follow the owning system's documentation rather than assuming every appearance of the old domain must change.

After replacement, scan for remaining old-host references and classify them. A remaining value may be a bug, an intentional historical record, or an external endpoint that requires manual change.

Update cookies, CORS, and security policy

Review cookie domain and secure settings, allowed origins, Content Security Policy, firewall rules, OAuth redirect URIs, REST authentication, and cross-origin media. Domain-bound sessions may require users to log in again; state this expected behavior.

Do not loosen CORS to * or disable security controls merely to make the migrated site load. Add the exact required new origins and remove obsolete rules after verification.

Configure one-to-one permanent redirects

Redirect each old URL directly to its new equivalent with a server-side permanent redirect, generally 301 or 308. Preserve path and query parameters only where the destination understands them. Avoid chains such as old HTTP → old HTTPS → new HTTP → new HTTPS.

Google's official site-move guidance recommends direct permanent redirects and warns against irrelevant redirects. Test a generated sample from every URL template plus all high-value pages.

Update internal SEO and discovery signals

On the new site, internal links, canonicals, hreflang, structured-data URLs, Open Graph tags, feeds, sitemap entries, image URLs, and form actions should use the new domain directly. Remove staging noindex and restrictive robots rules from production while keeping the preview protected.

Every canonical should agree with the final redirect destination and sitemap. Check rendered HTML and HTTP headers rather than assuming a plugin setting applied everywhere.

Update email and third-party integrations

Change sender identities, SMTP settings, SPF, DKIM, DMARC, bounce handling, webhook endpoints, OAuth callbacks, payment return URLs, storage CORS, captcha domains, maps, analytics, tag managers, and API allowlists as applicable.

Use sandbox or test modes where available. A successful homepage says nothing about payment reconciliation or email authentication.

Run a controlled final synchronization

Stop content and transactional writes or enter a controlled read-only period.
Synchronize the final database and uploads.
Apply the reviewed URL replacement to the final dataset.
Verify configuration, cache, redirects, TLS, and primary transactions.
Switch traffic and enable production workers only on the chosen environment.

If continuous writes are required, use the architecture described in the zero-downtime WordPress migration guide.

Validate the migration externally

Test old and new URLs with an HTTP client and browser. Confirm status, redirect destination, canonical, robots, language alternates, content, media, and structured data. Crawl both URL inventories to find loops, chains, 404s, mixed content, and references to the old host.

Test login, password reset, forms, email delivery, scheduled jobs, search, checkout, callbacks, and mobile behavior. Inspect fresh application and proxy logs.

Notify search and external platforms

Verify the relevant Search Console properties, submit the new canonical sitemap, and follow the current Change of Address procedure where applicable. Update analytics, ad destinations, business listings, social profiles, and high-value external links.

Do not remove the old sitemap, domain, or redirects prematurely. Search systems and users need time to discover and revisit old URLs.

Monitor and retain the old domain

Track crawl errors, redirect hits, indexing, traffic, conversions, server errors, and third-party callback failures. Old-domain logs reveal valuable URLs missing from the original inventory.

Google generally recommends keeping migration redirects for at least a year and as long as possible. For users, keeping them indefinitely is often preferable. Maintain domain registration, DNS, and TLS accordingly.

Plan rollback around two URL spaces

Rollback after a public domain change can confuse users and crawlers if some references already point to the new domain. Define whether rollback returns only the application origin while keeping the new public URLs, or reverses the URL migration. The former is usually simpler when the new domain has already accepted traffic.

Account for new orders, uploads, accounts, email, and callbacks. DNS reversal alone does not reconcile application data.

Common domain-migration mistakes

Replacing domain fragments with raw SQL
Forgetting constants that override WordPress URL options
Redirecting all old pages to the new homepage
Letting the old-domain certificate expire
Leaving staging canonicals, noindex, or robots rules
Ignoring email authentication and external callbacks
Creating redirect chains across hostname variants
Releasing the old domain after the move

When is professional migration support useful?

A large URL inventory, multilingual routing, WooCommerce transactions, custom callbacks, or previous domain moves make mapping and verification more complex. The WordPress migration service can cover backup, URL replacement, redirect implementation, cutover, and post-migration checks.

Frequently asked questions

Can I change only the domain and keep the same hosting?

Yes. The application can remain on the same infrastructure, but WordPress URLs, TLS, redirects, integrations, and search signals still need migration.

Should I change WordPress GUID values?

Do not rewrite them blindly. Their semantics and plugin use vary; follow WordPress and application-specific guidance for the actual data model.

How long should I keep the old domain?

Keep ownership, DNS, TLS, and redirects for the long term. Google generally recommends redirects for at least one year, while users may rely on old links much longer.

Will users need to log in again?

Often yes, because cookies are domain-bound. Test carts, memberships, and SSO behavior and communicate the expected impact.