What Happens to My Domain When I Replace My Website?
Your domain can usually stay registered in the same account while its website records are updated to point to the replacement site.
Part of our guide: How to Replace an Existing Website: A Step-by-Step Guide
Your domain name normally remains registered in the same account when you replace your website. At launch, its website-related DNS records are updated, or the existing hosting route is changed, so visitors reach the new site. Ownership does not need to transfer to the designer.
The domain, website hosting and email are connected services but not the same thing. Treating them separately prevents avoidable disruption.
Understand the three separate layers
The domain is the registered name, such as example.co.uk. DNS records direct different uses of that name to the appropriate services. Website hosting stores or serves the site itself.
Email may use the domain while running on a completely different provider. Other records can support verification, security, payments and external platforms.
Replacing the website usually changes the hosting destination, not the identity or ownership of the domain.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
Keep the domain in the business’s control
The registrant account should belong to the business with current contact details, secure authentication and a dependable payment method. Record renewal dates and recovery options.
A designer or agency may need technical access, but that does not require personal ownership. Use delegated access or a named account when the registrar supports it.
Avoid registering a core business domain in an employee’s private account. Ownership problems can become serious when a relationship ends.
Find the registrar and DNS provider
The registrar manages the registration, but DNS may be hosted elsewhere. Hosting may be provided by a third company. Identify each provider and account before planning launch.
Do not rely on a logo in an old invoice as proof of current control. Sign in, confirm the domain and check who can change its settings.
Record support contacts and any account verification process. Recovering lost access can take longer than the technical website switch.
Check expiry and automatic renewal
Confirm the expiry date, renewal status and payment details. A website project is a poor time to discover that a domain is about to lapse.
Keep administrative email addresses current. Use an address that the business controls independently where practical, rather than one that could fail with the domain being managed.
Renew for an appropriate period if the date is close. Do not allow a supplier to hold renewal as an informal dependency.
Record the complete DNS zone
Export or document current records before changing anything. Include A, AAAA, CNAME, MX, TXT and other entries, along with time-to-live values.
Label what each record supports where known. Some TXT and CNAME records verify email, analytics or third-party services and may not be obviously connected to the website.
Take screenshots only as a secondary record. A structured export or written list is easier to compare and restore.
Preserve email records
MX records direct incoming email. SPF, DKIM and DMARC records support authentication and delivery. They should remain unchanged unless the email service is intentionally moving.
Changing name servers replaces the whole DNS zone unless the existing records are recreated at the new provider. This is a common cause of email interruption during a website launch.
The article on what happens to email during a rebuild will cover mail migration separately. For a website-only project, preserve the known working mail configuration and test it after launch.
Decide whether a domain transfer is necessary
A registrar transfer moves domain management between providers. It is not normally required to launch a new website. DNS can point to new hosting while the registration stays where it is.
Avoid combining an unnecessary transfer with launch. Each change adds permissions, timing and failure points. Transfer later when there is a clear ownership or management benefit.
Some domains have transfer locks, authorisation codes or waiting periods. Check the registrar’s rules well before any contractual deadline.
Build the new site without changing the domain
Use a separate protected preview address while the replacement is built. The public domain can continue serving the old website.
Configure the new system for the final domain and HTTPS in advance where the host allows it. Keep staging indexing controls separate from production settings.
Read how to build a new site while the old one stays live for the full continuity process.
Choose the launch method
Some projects update DNS records to a new hosting address. Others deploy into the existing platform or change a proxy or hosting configuration without moving DNS.
The provider should explain which records will change, who will make the change and how rollback works. Avoid vague instructions to “point everything” at a new service.
Confirm whether both the root domain and www variant are covered and which one is canonical.
Plan DNS timing
DNS changes are cached for their time-to-live and can take time to reach every resolver. Lowering a relevant TTL in advance can reduce the caching window, but it must be done early enough to take effect.
Propagation is not a predictable countdown. During transition, different visitors may briefly reach different hosting destinations. Both should be safe to serve during that period.
Restore suitable TTL values after the launch is stable rather than leaving an emergency setting indefinitely.
Prepare HTTPS certificates
The new hosting must serve a valid certificate for every public domain variant. Many platforms issue certificates automatically after DNS validation, while others need advance configuration.
Test HTTP-to-HTTPS and hostname redirects. Avoid redirect loops between www, root and protocol variants.
Do not assume a certificate from the old server moves with the domain. HTTPS belongs to the hosting configuration as well as the name.
Keep URLs and redirects separate from the domain
Retaining the domain does not preserve every page address automatically. If paths change, the new website needs permanent redirects from old URLs to relevant replacements.
Create the redirect map during content planning and deploy it at launch. Test full URLs on the public domain after the switch.
The website replacement guide explains URL inventory, redirects and search monitoring.
Protect the canonical domain
Choose whether the preferred public address uses www and apply it consistently. Redirect other valid variants in one step and set canonical metadata to the public URL.
Prevent staging or hosting-provider addresses from appearing as indexable duplicates. Restrict previews and remove public links to them.
Update the sitemap, analytics and Search Console properties where necessary, while preserving historical access.
Test more than the homepage
After the change, open service pages, articles, images, forms and old redirected URLs. Test on another connection to reduce local cache effects.
Check email sending and receiving, even when mail records were not intentionally changed. Verify booking, payment and other domain-dependent services.
Inspect DNS with appropriate tools and compare it with the approved launch record. Record unexpected differences before making further changes.
Keep rollback possible
Retain the old hosting and its configuration until the new site is verified. A rollback might restore the previous website record or reverse a platform route.
Document exact values rather than relying on memory. Name the person authorised to decide and execute a rollback.
Do not use rollback to avoid fixing minor cosmetic issues. Reserve it for failures that materially affect availability, security or customer tasks.
Update ownership documentation
After launch, record the registrar, DNS provider, hosting provider, renewal dates, administrators and support process. Remove accounts that no longer need access.
Keep recovery methods current and use multi-factor authentication. Store backup codes securely. Review access when staff or suppliers change.
The business should know how to renew the domain even when a provider manages routine work.
Common domain mistakes
Do not cancel the domain because the old website is closing. Do not transfer ownership casually to a designer. Do not change name servers without copying mail and verification records.
Avoid launching while the domain is expired, locked unexpectedly or subject to an unresolved ownership dispute. Do not send account credentials through ordinary email.
Most domain incidents come from access and coordination problems rather than the complexity of DNS itself.
A launch checklist for the domain
- Confirm business ownership and registrar access.
- Check renewal, recovery and multi-factor authentication.
- Export the current DNS zone.
- Identify website, email and third-party records.
- Document the required change and rollback value.
- Prepare HTTPS and preferred hostname behaviour.
- Deploy page redirects with the new website.
- Test the website, forms, email and integrations.
- Record the final configuration and administrators.
Use named owners and evidence for each check.
Frequently asked questions
Do I need a new domain for a new website?
No. Keeping the established domain is normally preferable when the business identity remains the same.
Does changing hosting transfer the domain?
No. Hosting can change while registration stays with the same registrar.
Will DNS changes stop email?
Website-only record changes should not, but replacing name servers or removing mail records can. Preserve and test email configuration.
Should my web designer own the domain?
The business should retain ownership. A provider can receive suitable technical access without becoming the registrant.
How long does a domain change take?
DNS caching and provider behaviour vary. Plan a transition window and keep both environments safe rather than promising an exact minute.
Keep the name and change the destination
A website replacement usually leaves the domain exactly where it belongs: under the business’s control. Record the services attached to it, change only what launch requires and verify the complete configuration afterwards.
Afterworks includes domain and launch planning within website rebuilds so the change of website does not create avoidable ownership, email or access problems.
