A client guide to website changes

Domains, DNS and hosting: what changes, and why it takes time

Your new website is ready, but your laptop still shows the old one. Someone mentions nameservers. You just want to know whether customers can find you and whether your email will keep working. This guide explains the moving parts.

By John Finnerty · Published 14 September 2026 · About 10 min read

The services behind one website address

A single bill can bundle several services together, which is why the names get muddled. It helps to separate the jobs they do.

Domain name: The name people use to find you, such as a business address ending in .co.nz. Registration gives you the right to use that name while it remains registered to you. It needs renewing; it is not the website itself.
Registrar or domain provider: The company you deal with for registration, renewals and domain settings. A reseller may handle this through a registrar. Keep the domain in the intended person's or business's name, with recovery details you control.
DNS: The Domain Name System. Its records tell other systems where to find services for your name, including your website and incoming email. Think of it as a set of directions, rather than a place where your pages are stored.
Nameservers: The servers that publish your domain's DNS records. The authoritative nameservers are the nominated source of those answers. The nameserver setting at your registrar points to them, so the correct place to edit DNS may be a different company's dashboard.
Website hosting: The service that stores or runs your pages, images and website software. A site builder may bundle the editor and hosting. Moving hosting means preparing the site at its new home, then directing visitors there.
Email hosting: The service that holds your mailboxes and handles your business email. It may share your web hosting account or be separate, such as Microsoft 365 or Google Workspace. Website hosting and email hosting need their own checks.

For .nz domains, the Domain Name Commission lists authorised registrars. Registration, DNS management and hosting are separate responsibilities even when one provider handles all three.

You may also hear record names: A and AAAA connect a name to an IPv4 or IPv6 address. A CNAME makes one name an alias of another. TXT records hold text used for things such as account verification and email authentication. You do not need to memorise them; the records need to match the service being connected.

How a visitor reaches your website
A simplified view of a lookup, not a list of accounts you must buy.

1. Enter the nameA visitor opens your website address.
2. Find the destinationA DNS resolver uses a cached answer or looks up the authoritative DNS records.
3. Load the websiteThe browser connects to the destination, which serves the site directly or through a delivery service.

The registrar manages the domain's delegation to its nameservers. It does not have to serve the web pages or handle every visitor's lookup.

Why a DNS change is not instant for everyone

DNS answers are cached: saved temporarily so the same question does not need to be asked repeatedly. Your broadband provider's resolver may have an old answer while your mobile network has already fetched the new one. Both can be behaving normally.

Each record has a time to live, or TTL, normally shown in seconds. A TTL of 300 is five minutes; 3,600 is one hour. This tells a cache how long it may reuse an answer. The wait depends on when that answer was fetched, not just when we clicked Save.

Example

A one-hour TTL example

A resolver fetches your old website address at 9:50 am with a one-hour TTL. We change the record at 10 am. That resolver may continue using the old answer until around 10:50 am. Another resolver with no cached answer may see the change straight away.

Lowering the TTL at 10 am does not shorten an old answer that was already cached for an hour. When a planned move calls for a lower TTL, it needs to be set far enough ahead for the previous TTL to expire. Cloudflare's TTL reference explains the record setting and why local caches can still delay what you see.

A nameserver change has a different clock. It changes where DNS answers come from. The parent domain's delegation and other cached nameserver information have their own lifetimes, which are not controlled by lowering your website's A record TTL. Old and new DNS services should remain consistent during the change.

You may be quoted 24 to 48 hours for a nameserver change. Treat that as a planning allowance, not a required outage or a promise that every problem will fix itself by then. Cloudflare's setup guidance allows up to 24 hours for registrar nameserver updates; cached answers add another consideration. I would give you a window based on the actual provider, records and planned change, then check what is happening.

A newly added name can also be affected by a cached “does not exist” answer. That is called negative caching. There is no single switch that flushes every customer's DNS cache. See Cloudflare's explanation of DNS caching issues.

What changes for the job we are doing?

Updating text, photos or a page layout

Usually, we publish new content to the existing hosting. The domain and DNS stay as they are. If you still see the old page, a browser cache, website cache or content delivery network may be serving an older copy. Waiting for DNS is not normally the answer.

Launching a new website

The site needs to be published, the domain connected and HTTPS working. We also test the mobile layout, links and enquiry forms. If the domain already has email, those records must be preserved. A working preview address does not prove the public domain is ready.

Moving to different hosting

First we prepare and test the new hosting. Then the relevant website records direct visitors to it. The registrar and nameservers can often stay unchanged. Keep the old hosting available during the agreed transition, especially while visitors may still reach it.

Changing nameservers or DNS providers

We prepare the full DNS record set at the new provider before changing the delegation. That includes email, verification records and less visible services. An automatic import can miss records. DNSSEC, a system for checking DNS answers, needs a coordinated handover too; a mismatched security record can make a correct-looking setup fail.

Transferring the domain to another registrar

This changes who manages the registration. By itself, it does not copy the website or move your mailboxes. Confirm that the current DNS service will continue, because a bundled service may end when you leave. Moving the domain name and moving the website are different jobs.

Changing the actual domain name

This changes the public address, such as a business rebrand. It needs a separate plan for old links, redirects, email addresses and search engines. Keep the old domain registered if it is still needed for redirects or email. This is more involved than moving the same address to a new host.

For a technical handover, my DNS migration checklist goes into the record inventory and cutover checks. Cloudflare's nameserver setup guidance also explains why imported records and DNSSEC need attention before the switch.

Your website can move without moving your email

Imagine a Christchurch electrician changing website hosts while keeping Microsoft 365. The website records need to point to the new site. The Microsoft 365 mailboxes should stay where they are, with their required DNS records intact. There is no reason to move the email just because the website design is changing.

MX records direct incoming mail. SPF, DKIM and DMARC help receiving systems check messages sent using your domain. Other records may verify an account or help an email app connect. Preserve the complete set required by your actual email provider, not just the MX record.

A website contact form has a separate sending setup too. We need to check that a submitted enquiry actually reaches the intended inbox. A form showing “Thank you” is not enough. Microsoft's domain connection guidance illustrates how website and email records can live at an external DNS provider.

If mailbox hosting is also moving, that adds account setup, message migration and a mail cutover. My small-business DNS and email checklist is useful when email forms part of the job.

Three other things that get mistaken for DNS

Website and browser caches

A cache can keep an old page, image or stylesheet after the live files change. A CDN, or content delivery network, may keep copies closer to visitors. These caches have their own settings. Clearing a browser cache does not clear everyone's DNS or the hosting provider's cache.

HTTPS certificates

HTTPS encrypts the connection between a browser and the website. The new hosting needs a valid certificate for the names people use, including www if it is supported. A provider may need to verify the domain before issuing it. A certificate warning deserves a check; do not click through it to enter passwords or payment details.

Google's search results

A page can be live while Google still shows its old title or description. Crawling and indexing are separate from DNS. Google says recrawling can take a few days to a few weeks, and requesting it does not guarantee immediate inclusion. Check the actual website address when reviewing a launch.

What to agree before, during and after a change

Confirm the scope. Write down whether we are changing the content, hosting, DNS provider, registrar or domain name. Identify who manages email and any booking, payment or other connected service.
Sort access and backups. Confirm the business can recover its accounts. Use an account invitation or an agreed secure sharing method for access. Keep a DNS export and a recoverable website backup. Do not send passwords or transfer codes through a public form.
Choose the window. Agree a date, a New Zealand time and a contact person. Allow time for checks after the switch. For a shop, booking system or other live database, plan how new orders and changes will be kept in sync.
Prepare before switching. Test the destination, preserve email records and review certificate and DNSSEC requirements. Agree what would trigger a rollback and how it would work.
Check the result. Test the main address and www, important pages, redirects, forms and email. Check from more than the office connection. Record the change time and any issue that appears.
Retire the old service deliberately. Wait for the agreed checks and overlap period. Confirm that no mailbox, DNS zone, backup or application still depends on it before cancelling. Record who now owns each renewal.

Moving a shop is particularly sensitive: two working copies can collect different orders. Switching DNS back will not automatically copy those orders into the old database. Keeping a backup and keeping live data consistent are separate parts of the plan.

What to send me if something looks wrong

Send the exact page address, the time you checked, the device and browser, whether you were on Wi-Fi or mobile data and what you expected to see. A screenshot of the error helps. Remove customer details, passwords and other private information first.

Trying mobile data as well as Wi-Fi can reveal a difference between networks. An incognito window may help identify some browser-storage issues, but it does not bypass every DNS or website cache. Neither test proves that every visitor can reach the new site.

Report broken email, certificate warnings, missing orders or a completely unavailable site promptly. Do not assume they are all part of propagation. Waiting will not repair a wrong record, missing certificate or incomplete website transfer.

If we are planning a move, these are useful next steps:

DNS and migration support Tell me what you want to change

A recent bill with sensitive details removed can help identify the providers if you are unsure who does what.

Frequently asked questions

Select a question to open the answer.

Why can I still see the old website when you can see the new one?

We may be using different DNS answers or different cached copies of the page. Send me the exact address and the network you are using. I can check which destination it reaches and whether a website cache is involved.

Does every website change take 24 to 48 hours?

No. Text and image edits normally publish without changing DNS. A nameserver change has a different timing window from a page edit or a website record change. The relevant provider and existing cache lifetimes determine what we should allow for.

Does DNS propagation mean my website has to be offline?

No. If the old and new destinations both work during the transition, visitors can still be served. That needs preparation and an overlap period. Some applications also need a short maintenance window to avoid conflicting data, so downtime should be discussed for the actual site.

Will changing the website stop my email working?

It should not if the email service and all its required records are preserved. Changing nameservers or cancelling a bundled hosting account can affect email, which is why we check those dependencies before making the change.

Do my domain, DNS and hosting have to be with the same company?

No. One company can handle them all, or different providers can do each job. What matters is knowing who controls each service, keeping access recoverable and understanding which subscriptions depend on each other.

Do I need to transfer my domain to get a new website?

Usually not. We can often keep the existing registration and connect the domain to the new hosting. A registrar transfer may still be useful for account management or service reasons, but it is a separate decision.

When can I cancel the old hosting?

After the agreed transition checks, once we know it is no longer serving needed website traffic or holding email, DNS or other services. Keep the required backup and deal with any new orders or form entries first. A new homepage loading on your phone is not enough to confirm that everything has moved.

Will clearing my cache or restarting the router speed it up?

It may change what your device sees, but it cannot force other networks to discard cached DNS answers. Let me check the cause before you reset equipment. There is no need to disrupt the office network just to review a new page.

Why does www work but the address without it does not?

They are different hostnames. Both need the appropriate DNS setup, hosting configuration and HTTPS coverage. We normally choose one main address and redirect the other. A DNS alias alone is not a browser redirect.

The website is updated. Why does Google still show old information?

Google keeps its own search index and needs to crawl and process changes. That timing is separate from website publishing and DNS. Use the direct website address to review the new content, then allow for search updates.

Can we switch back immediately if something goes wrong?

Sometimes a page release can be rolled back quickly. Reversing DNS has its own caching delay, and new data may need reconciling before an old site is safe to use. That is why the rollback plan is agreed before the change.

What do you need from me before we start?

The domain name, the providers you know about, who can approve the work and any important dates or connected services. We can then arrange the right account access securely and confirm what is moving. You do not need to understand every DNS record to get started.