Rebuild your DNS records in SiteGround Site Tools
SiteGround's DNS Zone Editor handles A, AAAA, CNAME, MX, SRV and TXT records. That covers almost everything a normal site needs, and it is a clean interface to work in.
What it does not do is import. There is no zone file upload, so every record is entered by hand — and SiteGround will only let you manage the zone once the domain already points at its nameservers. That combination creates a genuinely awkward order: you cannot build the zone in advance, but you also must not be inventing it live.
The way through is to treat the Bluehost zone export as a script. Have every record written down before you change anything, then enter them immediately after the switch.
- Hands-on time
- 45–90 minutes
- Start to finish
- Records apply within an hour of entry
- Difficulty
- Moderate
- Steps
- 6
Downtime risk: Real, and concentrated in the minutes after the nameserver change. Preparation is the entire mitigation.
Check this first
Is this just an A record update?
If you only want the website moved to SiteGround and are happy leaving email, subdomains and the registrar alone, then yes — one record edit at Bluehost. SiteGround explicitly documents this as an alternative to changing nameservers, noting that the rest of your DNS records and your email stay intact at your current provider. It also sidesteps the fact that Site Tools has no zone import.
The short version — 5 minutes, plus TTL
- 1Find your SiteGround IP address in Site Tools under the site's information panel.
- 2In the Bluehost portal, open Domains → your domain → the DNS tab.
- 3Lower the TTL on the A record to 300 first if you can wait an hour before the change.
- 4Edit the A record for @ and set it to the SiteGround IP address.
- 5Check the www record — a CNAME to the bare domain needs no change; its own A record does.
- 6Confirm with dig example.com A +short once the TTL has expired.
Not what you need? This does not move email, does not change who manages your DNS, and does not move the domain registration. If you want SiteGround managing the whole zone, follow the full steps below.
Can I do just this, and nothing else?
Yes — this works on its own
Yes, and usually in its smallest form — a single A record edit. If all you want is the website served from SiteGround, you do not need to move the zone or change nameservers at all. SiteGround documents this option itself: point the A record and leave everything else where it is.
What changes
- Where individual hostnames point — the website, or a subdomain
- Nothing else, if you edit the records where they already live
What stays exactly as it is
- The domain stays registered at Bluehost
- Nameservers are unchanged, so Bluehost still answers DNS
- Every record you do not touch keeps working, email included
Before doing dns records on its own: Know the SiteGround IP address, and confirm the site is actually serving there before you point at it.
Before you start
- Access to the Bluehost portal and SiteGround Site Tools
- A list of every service that depends on this domain — email, newsletter sending, Search Console, Microsoft 365, payment providers
- The SiteGround IP address for the new account
- Time set aside immediately after the nameserver change, not before
Step-by-step
Each step is labelled with which side you are working on, so you always know whether you should be signed in to Bluehost or SiteGround.
- 1At Bluehost
Export the zone file from Bluehost
Bluehost will hand you the whole zone as a text file. SiteGround cannot import it, but that is not why you want it — it is a dated, complete record of a configuration that currently works.
- Bluehost portal → Domains → select the domain → DNS tab
- Choose Export DNS zone, then Download DNS zone
- Keep the file somewhere you can read it while working in another tab
- 2On your computer
Turn the export into a checklist
Go through it line by line and decide the fate of each record before you touch anything. This is the work that makes the post-cutover window survivable.
- A and AAAA records must be updated to the SiteGround IP, not copied
- MX records and mail TXT records copy across exactly, unless you are changing email provider
- Verification TXT records for Google, Microsoft and similar must come across
- NS and SOA lines describe the old zone's authority and are not yours to recreate
- Drop records for subdomains and services you no longer run
- 3At SiteGround
Check what Site Tools can actually hold
SiteGround's zone editor documents six record types. If your zone uses anything outside that list, find out now rather than at cutover.
- Supported: A, AAAA, CNAME, MX, SRV and TXT
- CAA is not among the documented types — if you rely on one, confirm before you commit
- SPF and DMARC are ordinary TXT records, so those are fine
- 4At Bluehost
Lower the TTLs at Bluehost, a day ahead
Dropping TTLs to 300 seconds the day before means a mistake made during the cutover propagates its correction in five minutes rather than four hours. Given the ordering constraint here, that safety margin matters more than usual.
- Edit the TTL on the A, CNAME and MX records in Bluehost's DNS tab
- Do it at least one full old-TTL period before cutover
- Raise them back to 3600 or higher once things have settled
- 5At SiteGround
Enter the records the moment the zone unlocks
Immediately after the nameserver change, Site Tools will let you manage the zone. This is the window. Work from your checklist, mail records first.
- Site Tools → Domain → DNS Zone Editor
- MX records first, with the correct priorities — email is what nobody notices until it is expensive
- Then A, CNAME, SPF, DKIM, DMARC and any verification TXT records
- New records default to a one-hour TTL, which is fine once you are settled
- 6Either side
Diff the two zones
Put the Bluehost export next to SiteGround's record list and reconcile. Every record should exist, be deliberately changed, or be deliberately dropped.
- Watch for wildcard records — a * A record catches subdomains you have forgotten
- Anything you cannot explain is worth keeping until you can
What goes wrong
The failures that actually happen on this step, rather than a generic warning to be careful.
No zone import, and no zone access until you switch
Can cause downtimeThese two constraints compound. You cannot upload the zone, and you cannot pre-build it either, because Site Tools only manages DNS for domains already pointed at SiteGround's nameservers. Treat the nameserver change and the record entry as one operation, with the full record list written down first. If that sounds uncomfortable, use the A record shortcut above and leave DNS at Bluehost.
Losing MX records is the classic outage
Can cause downtimeNothing warns you. The website looks perfect, and inbound mail starts bouncing at the moment nameservers change. Senders get a rejection you never see, and you find out days later when someone mentions they emailed you. Confirm MX before cutover, every time.
Do not blindly copy the A record
Can cause downtimeThe A record in an export from your old provider points at your old server. Import it unchanged and you have moved your DNS while still sending all traffic to the old host — which works, confusingly, right up until you cancel that account.
Verification TXT records are load-bearing
Can cause delaysGoogle Search Console, Microsoft 365 domain ownership, and various payment and analytics providers verify via TXT records. Drop them and the service de-verifies — with Microsoft 365 that can affect mail flow, not just a dashboard badge.
DKIM values get truncated
Can cause delaysDKIM public keys exceed the 255-character limit for a single TXT string and must be split into quoted chunks. Pasting through a UI that does not handle the split silently produces an invalid key, and your mail starts failing authentication.
How to check it worked
Do not rely on the site looking fine in your own browser — it caches, and it will tell you what you want to hear.
- dig example.com A +short returns the SiteGround IP
- dig example.com MX +short lists exactly the mail servers you expect, with the same priorities as before
- dig example.com TXT +short shows one SPF record, not two
- Send a test message to and from the domain, and check the headers for SPF and DKIM passes
- Google Search Console still shows the property as verified
If it goes wrong
Point the nameservers back at ns1.bluehost.com and ns2.bluehost.com. Bluehost's zone is untouched and immediately correct again, which is exactly why you do not delete anything there until this has settled.
Questions about this step
Can I just point the A record instead of moving DNS?
Often, yes — and it is the lower-risk option. If you only want the website to move hosts, edit the A record where your DNS is managed today and leave everything else alone. Email, subdomains and verifications never move, so they cannot break. Move the whole zone only when you actually want a different provider managing DNS.
How long do DNS changes take to apply?
Record changes within a zone that is already authoritative apply within an hour for most resolvers, governed by the TTL you set. Nameserver changes are slower, because the delegation TTL belongs to the TLD registry — allow up to 48 hours.
Can I use Cloudflare for DNS instead of Site Tools?
Yes, and given the ordering constraint here it is worth considering. Moving DNS to Cloudflare lets you build the entire zone before delegating to it, verify it, and only then switch — which is the safe sequence that SiteGround's own zone editor will not let you follow.
Reference documentation
Provider interfaces change. When these steps and the official documentation disagree, the documentation wins.
Only if you are doing the full move
Stuck on this step?
Send me the domain and what you have tried. I do Bluehost to SiteGround moves regularly and can tell you what is actually blocking it.