Keep the host and URL paths unchanged where possible, prepare HTTPS and email separately, rehearse the supported WordPress URL change, then redirect matching old pages and verify the whole journey before retiring anything.
A WordPress domain change is a website move and an email decision, not one setting to edit. Prepare the new address, HTTPS and a recovery copy first. Change WordPress through a supported method, send each old page to its matching new page, and keep old-domain email working separately. Leave the old domain and required services active until the checks and retention plan justify retiring them.
This guide covers a single self-hosted WordPress site that you own or are authorized to manage. It is researched guidance, not a migration we performed. A Multisite network, mapped domains, a complex store or a host-managed domain feature needs its own supported procedure. If you cannot access the registrar, hosting controls and recovery account, resolve ownership before changing addresses.
First, confirm what is changing
| Your goal | What changes | Use this route |
|---|---|---|
| A new website name, keeping the same host | Public domain and stored website URLs | This guide; keep paths and other services stable where practical |
| A different registrar, keeping the same domain | Registration management | Registrar transfer; do not rename WordPress |
| A different host, keeping the same addresses | Website infrastructure | Hosting migration; do not replace URLs without a separate reason |
| New email addresses or a new mail provider | Mailbox identities, routing or data | A separate mail plan; a web redirect does not deliver email |
If you only need to point a domain at the existing site, use our domain connection guide. For the other two operations, follow registrar transfer without disruption or moving WordPress to another host. Avoid combining a domain rename, host move, redesign and mail migration unless there is a concrete reason and someone responsible for each part.
1. Write the old-to-new plan before editing
Record the current canonical domain, whether it uses www, the HTTPS address, WordPress’s installation directory, registrar, authoritative DNS provider, host and mail provider. Identify who controls each account and who can authorize rollback. Save existing DNS records and relevant host/CDN redirect settings privately. Domain registration, DNS hosting, web hosting and mail hosting can be supplied by different companies.
List important pages, posts, media/download URLs and business journeys. Map each old URL to its destination, keeping the path unchanged when the content is unchanged. In this illustrative mapping, the reserved example domains are placeholders: https://old.example/about/ becomes https://new.example/about/. An intentionally removed page needs an appropriate replacement or a genuine not-found response, not an unrelated homepage redirect.
Google’s site-move guidance recommends mapping and testing before the move and changing one major thing at a time. Include image and download destinations, not just the homepage. Agree a lower-impact change window, an acceptance checklist and who decides whether to continue when a check fails.
2. Make recovery practical
Take a corresponding backup of the WordPress files and database, including uploads, configuration and custom redirect rules. WordPress explains why both parts are needed. Record their capture times, private storage location and restoration procedure. A host’s website copy does not necessarily include an independently hosted mailbox or the registrar’s DNS configuration.
Rehearse the proposed change on a separate copy through the host’s supported preview or staging procedure. Ensure it has its own database and prevent copied forms, scheduled emails, payments and webhooks from contacting real customers. Read how to verify a restorable WordPress backup. Do not treat a successful export as proof of a usable restore.
For a store or membership site, plan how to preserve orders, registrations and edits arriving after the backup. A scheduled write pause or supported synchronization may be needed. Restoring an older database after new orders arrive can discard legitimate records; agree how these will be reconciled before the cutover.
3. Prepare the new domain and HTTPS
Add the new domain to the correct website in the host’s dashboard using that host’s domain-change procedure. Obtain the exact web DNS destination and certificate-validation instructions from the host. Change the necessary web records at the authoritative DNS provider, preserving unrelated mail and verification records. Changing nameservers is unnecessary merely because a website gets a new name.
Check that the new domain reaches the intended installation and that HTTPS works for its chosen www/non-www variants before making it the public address. Use a host-supported preview or administrator-assisted test; do not assume an IP-address browser visit tests the correct virtual host or certificate. Keep a valid HTTPS route on the old hostnames too: an HTTPS visitor must connect successfully before receiving a redirect.
Inventory domain-bound integrations: payment callbacks, sign-in providers, form return addresses, API/webhook endpoints, licenses and CDN settings. Ask each provider which exact addresses must change and whether its test mode can verify the change. Avoid replaying real payments. Do not force the website live while a required certificate or critical integration is still failing.
4. Change WordPress’s addresses through the supported route
On a standard single-site installation, WordPress Address identifies the core-file location and Site Address the public website location. They are often equal, but a deliberate subdirectory installation can differ. The WordPress migration handbook defines both and warns about old URLs remaining in stored data. Do not remove a legitimate subdirectory simply to make the fields match.
If the host manages these values, use its documented domain-change operation. Otherwise an authorized administrator can use Settings → General after preparing the new domain and recovery access. Confirm both intended full HTTPS addresses before saving; expect the login location to change. Stop if the fields are locked or the host says they are managed elsewhere.
The WP_HOME and WP_SITEURL constants can override the database values without updating them. A temporary override may help a qualified operator access the new address, but it does not rewrite posts or plugin settings. Decide whether the host/configuration or the database is authoritative; reconcile stored values before removing a temporary override. Do not leave competing values and hope the dashboard resolves them.
5. Update stored links without damaging serialized data
Use the host’s supported migration tool or a serialization-aware replacement tool, first on the separate copy. A plain SQL text replacement can corrupt structured settings. Identify exact old URL variants, their intended new values and the tables/columns belonging to this installation. A bare domain replacement can also touch email addresses or unrelated text that was supposed to remain unchanged.
For a qualified operator with WP-CLI available, wp search-replace supports serialized data, an explicit table/column scope and --dry-run. A dry run reports proposed changes without saving them. Check the correct installation, scope, expected counts and exclusions before any write. Default registered tables may not cover every plugin’s data; expanding to every database table can affect other sites. Preserve existing post GUIDs using the appropriate exclusion, such as --skip-columns=guid, rather than treating identifiers as broken visitor links.
A dashboard alternative is Better Search Replace, whose published features include serialization support, table selection and a dry run under Tools. With the backup secured, choose the correct full old/new URL strings and agreed tables, leave dry run enabled and inspect the result. Its free count report does not prove every proposed field is correct. Confirm GUID handling and plugin-specific requirements before executing a real replacement; ask the host or developer if the chosen interface cannot express the needed exclusions.
Run only the reviewed operation, then inspect menus, buttons, widgets, media, reusable content and affected plugin settings. Regenerate plugin-generated files or caches through their documented controls where required. Search for remaining old web references and classify them: a deliberate historic mention, retained email address or stable identifier is not automatically an error. Do not repeatedly replace increasingly broad strings to make a count reach zero.
6. Keep email working on its own terms
A website redirect does not forward email, rename a mailbox or preserve the old address. If your mail addresses stay on the old domain, keep that domain registered, its mail service active and its required DNS records intact. Test receiving and sending from an outside account. If nameservers also change, reproduce the mail provider’s exact MX, authentication and verification records at the new authoritative DNS service.
If people will use the new mail domain, decide whether you need aliases to existing mailboxes or separate accounts. Verify the new domain and complete the provider’s mail routing and sender-authentication setup; preserve the old inbound addresses and check outbound identity and replies. Our SPF, DKIM and DMARC guide explains those distinct controls. Do not copy placeholder MX values or create a second SPF record by guesswork.
Provider procedures differ. Google Workspace distinguishes a user alias domain from a secondary domain; replacing the organization’s primary domain is another planned operation. In Zoho, an individual email alias differs from converting a domain to a domain alias. Zoho warns that the latter disables that domain’s mail hosting and removes associated addresses, groups and domain settings. Do not apply that conversion to an existing mail domain as a casual shortcut. Have the mail administrator check the actual account first.
7. Redirect matching pages and align discovery signals
Once the new site passes the essential checks, configure permanent one-to-one redirects from old pages to their new equivalents using the host/server/CDN’s supported mechanism. Google supports permanent 301 and 308 server-side redirects. Check the returned status and final address, avoiding loops, chains and a homepage destination for every old path. Test both relevant www/non-www and HTTP/HTTPS entry points.
Point internal links directly to the new addresses. Review page canonical tags and relevant language annotations, ensuring they agree with the new preferred URLs; Google’s canonical guidance treats consistency as useful evidence. Refresh the website’s actual sitemap and submit its new location, using fully qualified intended canonical URLs. Remove temporary staging noindex/access restrictions only from the intended public site, and verify crawl rules. A submitted sitemap is not an indexing guarantee.
For an eligible domain/subdomain move, use Search Console’s Change of Address tool after the move and redirects work. The tool’s pre-work specifically requires a 301 redirect from the old homepage to the new homepage; follow that requirement even though general migration guidance also supports 308. The same Google account must own both properties. Check every affected old subdomain variant; the tool does not automatically move subordinate hostnames. It is not for HTTPS-only, same-domain path, www/non-www or host/CDN-only changes. Its process lasts 180 days, and its sample checks do not validate your whole mapping.
Plan to retain working redirects generally for at least a year, following Search Central’s site-move guidance, and longer where old links or business email still matter. The tool’s 180-day period is not a reason to let the old domain expire then. Keep ownership and verification current on both sides. Search traffic may fluctuate; neither the tool nor a redirect guarantees preserved positions.
8. Verify, then decide whether to continue or roll back
| Check | Expected result | If it fails |
|---|---|---|
| Important old page and media URLs | Correct permanent redirect and usable matching destination | Fix mapping/certificate/rule; do not add another broad redirect |
| Admin, forms and relevant checkout/account journeys | Correct new address, working sessions and safe test completion | Pause the move and review URL/integration configuration with the host |
| Old and new email addresses in scope | External receive/send/reply tests reach the intended mailbox | Review mail account and authoritative DNS separately from web redirects |
| Canonical, sitemap and crawl controls | Intended public new URLs agree and are accessible | Correct the actual output; submission alone is insufficient |
If a critical check fails, record the first failing URL, exact message, time/timezone and last change; stop unrelated edits. Follow the rehearsed host-specific recovery plan. Reverting DNS alone cannot reverse database replacements or accepted new orders, and cached permanent redirects may outlast a rule change. Preserve the current state and reconcile new records before restoring older data. If a Change of Address request was already submitted, follow its official cancellation procedure rather than creating contradictory redirects.
After acceptance, monitor both domains, server errors, important journeys, mail delivery and Search Console reports. Our measurement guide separates indexing and traffic evidence from a successful technical move. Keep a dated review of unresolved old references and retention obligations; there is no universal propagation or search-recovery deadline.
Copy a private domain-change handover
These bracketed fields are deliberately unfilled. Copy them into a private change record; this is a template, not a migration result. Keep passwords, backup contents and customer records out of the checklist.
- Authorized owner, operator and change window: [names/roles; date/time/timezone]
- Old/new public and core URLs; DNS/host/mail owners: [exact intended values and account references]
- Backup set and restore rehearsal: [private location; capture time; observed result]
- URL mapping, replacement scope and dry-run review: [private reference; exclusions; approval]
- HTTPS, redirect, admin/form/commerce and mail checks: [test; actual result; limits; time]
- Rollback trigger and new-data reconciliation: [failure condition; responsible operator; procedure]
- Old-domain, mail and redirect retention; next review: [renewal/retention decisions; owner; date]
You usually do not need a new host or mail subscription simply to rename a website. Compare a registrar’s renewal and account controls only if registration needs changing; compare Google Workspace and Zoho Mail only for a separate mail-service requirement. Pay for migration help when the operator, recovery or integration work exceeds your capacity, with the actual scope and price agreed first.
Sources and verification
Editorial review 2026-10-10. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- WordPress: Migrating WordPressChecked Single-site URL meanings, stored old URLs, serialization risk and preserving existing post GUIDs during a domain move.
Limits: The handbook contains historical examples and inconsistent table-scope shorthand; this guide uses a scoped supported tool rather than copying raw SQL or obsolete scripts. - WordPress: Editing wp-config.phpChecked WP_HOME and WP_SITEURL override their database values without updating those stored values; a subdirectory installation can have different public and core URLs.
Limits: Configuration and database were not inspected. Constants are not a substitute for changing content references or planning a move. - WordPress: BackupsChecked A typical restoration requires corresponding website files and database, with configuration matching the restored environment.
Limits: No backup or restoration was performed; provider retention, consistency and recovery need site-specific verification. - WP-CLI: wp search-replaceChecked Serialization-aware replacement, explicit table/column scope, dry-run and skip-columns options; default scope does not imply all plugin or network tables.
Limits: No command was executed. Correct installation, tables, URL variants and exclusions must be determined by an authorized operator. - WP Engine plugin listing: Better Search ReplaceChecked The plugin provides serialization support, table selection, a dry-run and a Tools screen; its author warns that incorrect replacement can damage a database.
Limits: Availability is not an endorsement of compatibility or a backup guarantee. No plugin was installed or tested, and free dry-run counts do not establish correctness of every change. - Google Search Central: Site moves with URL changesChecked Plan mapping and testing, update content and discovery signals, monitor both domains and generally retain redirects for at least one year.
Limits: A move can change search visibility; no traffic preservation, crawl schedule or ranking outcome is guaranteed. - Google Search Central: Redirects and Google SearchChecked Permanent server-side 301 and 308 redirects express a permanent URL move; implementation depends on the actual server.
Limits: This guide supplies mapping decisions, not an Apache, Nginx, host or CDN configuration to paste universally. - Google Search Central: Canonical URLsChecked Use consistent canonical signals, internal links and sitemap destinations rather than conflicting preferred URLs.
Limits: Canonical is a signal, not a guaranteed instruction or a substitute for a working visitor redirect. - Google Search Central: Build and submit a sitemapChecked Sitemaps should contain intended canonical fully qualified URLs; submission assists discovery.
Limits: Submission does not guarantee indexing. This tutorial does not assume a particular SEO plugin or sitemap path. - Google Search Console: Change of Address toolChecked Applicable domain/subdomain moves, excluded HTTPS/path/www/infrastructure-only moves, ownership prerequisites, variant handling and 180-day tool period.
Limits: The tool checks a sample rather than every URL. Its minimum 180-day redirect guidance differs from Search Central's generally at-least-one-year recommendation; use the longer plan, not a day-180 shutdown. - Google Workspace: Add a user alias domain or secondary domainChecked An alias domain supplies alternate addresses to existing users; a secondary domain serves different user accounts or a planned primary-domain replacement. Verification and mail setup are separate.
Limits: Edition, account conflicts and existing domain state affect the supported route. No Google Workspace tenant or mailbox was accessed. - Zoho Mail: Domain aliasing and subdomain strippingChecked Alias domains require verification and mail routing; converting a hosted domain to an alias disables its mail hosting and removes associated domain settings, addresses and groups.
Limits: That conversion can be destructive. This article warns against using it on an existing production mail domain without a provider-reviewed plan. - Zoho Mail: User-specific Admin Console settingsChecked An authorized administrator can add an individual email alias on a configured domain and optionally choose the mailbox address.
Limits: Aliases, domain aliasing and changing an organization's primary identity are different operations. Current limits and account support must be checked directly.