HelpWithWebGet Help Now

Point your domain from Bluehost to SiteGround nameservers

Nameservers decide which company answers DNS for your domain. Changing them hands the whole zone over in one move — website, email, subdomains and verification records all at once.

Moving to SiteGround has a specific wrinkle: its zone editor only becomes available once the domain already points at its nameservers. So unlike a move to a provider where you can stage the zone in advance, here the switch comes first and the records follow immediately after.

That makes preparation the whole game. The change itself is two fields and a save button.

Hands-on time
10 minutes to change
Start to finish
24–48 hours to propagate fully
Difficulty
Easy
Steps
5

Downtime risk: High unless you have the full record list ready to enter the moment the zone unlocks.

Check this first

Do you actually need to change nameservers at all?

Often not, and here there is a stronger reason than usual to skip it. Nameservers decide who manages DNS, which is a different question from where the site is hosted. SiteGround itself documents pointing the A record instead, noting that your other records and your email stay intact at your current provider. That avoids the whole no-import, no-pre-staging problem.

The short version — 5 minutes instead of 48 hours

  1. 1Ask what you actually want: a website on a different server, or a different company managing DNS?
  2. 2If it is only the website, edit the A record at Bluehost and stop here.
  3. 3If your DNS is at a third party such as Cloudflare, that is where the A record lives — neither Bluehost nor SiteGround is involved.
  4. 4Only if you want SiteGround managing the zone should you continue below.

Not what you need? If you are closing the Bluehost account entirely and your nameservers point at Bluehost, you cannot skip this — the DNS service goes away with the account, so the zone has to move somewhere.

Can I do just this, and nothing else?

Not on its own — read this before you start

Not really — and this is the one task on this page where the honest answer is no. Changing nameservers to SiteGround without immediately populating the zone will take down your email and anything else that depends on a record you have not recreated. It is only a single step in the sense that the click is single; the work around it is not optional.

What changes

  • SiteGround answers every DNS question for the domain
  • Email, subdomains and verification records all resolve from Site Tools' zone

What stays exactly as it is

  • The domain stays registered wherever it is now — this is not a registrar transfer
  • Website files are not moved by this step
  • Bluehost's zone remains intact and unedited, which is what makes rollback instant

Before doing nameservers on its own: Every DNS record written down and ready to enter, because SiteGround will not let you create them until after this change lands.

Before you start

  • Every DNS record from the Bluehost export, written down and ready to type
  • TTLs lowered at Bluehost at least a day earlier
  • The website already tested on SiteGround
  • An hour set aside straight after the change, not the following morning

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.

  1. 1At SiteGround

    Confirm SiteGround's nameservers

    SiteGround publishes one standard pair, which makes this simpler than moving to a provider that assigns a different pair per domain.

    • Some accounts are issued account-specific nameservers — if Site Tools shows a different pair, use that
    • Private DNS is a paid add-on and has its own hostnames
    SiteGround nameservers
    ns1.siteground.net
ns2.siteground.net
  2. 2At Bluehost

    Change the nameservers at Bluehost

    The registrar controls the delegation, so this happens wherever the domain is registered — in this case the Bluehost portal.

    • Bluehost portal → Domains → select the domain → Nameservers tab
    • Click Change Nameservers, enter the SiteGround pair and Save
    • Allow 24 to 48 hours for propagation
    Replacing
    ns1.bluehost.com   →   ns1.siteground.net
ns2.bluehost.com   →   ns2.siteground.net
  3. 3At SiteGround

    Enter the DNS records straight away

    Site Tools unlocks the zone editor once the domain points at SiteGround. This is the window you prepared for.

    • Site Tools → Domain → DNS Zone Editor
    • MX records first, then A, CNAME and the TXT records
    • Work from the checklist, not from memory
  4. 4On your computer

    Watch propagation rather than guessing

    Check what resolvers actually return. Your own browser caches aggressively and will mislead you in both directions.

    • whatsmydns.net shows resolution from several locations at once
    • A mixed picture for a while is normal, not a fault
    Check the delegation
    dig NS example.com +short
dig @8.8.8.8 example.com A +short
dig +trace example.com
  5. 5At SiteGround

    Re-issue SSL once the domain resolves to SiteGround

    Certificate issuance validates by checking the domain points at the requesting server, so it can only succeed after propagation.

    • SiteGround issues Let's Encrypt certificates automatically once DNS resolves to it
    • Confirm the site still forces HTTPS afterwards
    • Check no stale CAA record is blocking issuance

What goes wrong

The failures that actually happen on this step, rather than a generic warning to be careful.

  • The zone editor unlocks only after the switch

    Can cause downtime

    This is the defining constraint of moving DNS to SiteGround, and it inverts the safe order. You cannot build and verify the zone before delegating to it, so there is an unavoidable window where SiteGround is authoritative for a zone you are still filling in. Minimise it with preparation, or avoid it entirely by leaving DNS where it is and pointing only the A record.

  • Changing nameservers moves email too, whether you meant it to or not

    Can cause downtime

    People change nameservers to move a website and are surprised when mail stops. The nameservers determine the whole zone, MX records included. If email is staying where it is, its MX records still need to exist in the new zone.

  • You cannot shorten nameserver propagation with TTLs

    Can cause delays

    Lowering the TTL on your A and MX records genuinely speeds up record changes. It does not speed up a nameserver change: the delegation TTL is set by the TLD registry — typically 48 hours for .com — and is not yours to adjust. Plan for the full window rather than expecting your TTL work to cover it.

  • Both zones stay live during propagation

    Can cause downtime

    For a day or two, some visitors reach the old host and some reach the new one. If both can accept form submissions, orders or comments, you will end up with data split across two databases. For an ecommerce site, put the old one in maintenance mode at cutover.

  • Half-changed nameserver pairs

    Can cause delays

    Entering the new primary and leaving the old secondary produces intermittent, maddening behaviour — resolvers get different answers depending on which nameserver they happen to ask. Replace the whole set at once.

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 NS example.com +short returns only the new nameservers
  • dig @8.8.8.8 example.com A +short returns the new hosting IP
  • whatsmydns.net shows consistent results across most global locations
  • The site loads over HTTPS with a valid certificate, without a warning
  • A test email to the domain arrives, confirming MX survived the switch

If it goes wrong

Set the nameservers back to ns1.bluehost.com and ns2.bluehost.com. Bluehost's zone is unchanged and correct the moment it takes effect — though you wait out propagation a second time, which is the real cost of getting this wrong.

Questions about this step

What are SiteGround's nameservers?

ns1.siteground.net and ns2.siteground.net. Some accounts are issued account-specific nameservers, and private DNS is available as a paid add-on, so check Site Tools if the pair shown there differs.

Why can't I edit my DNS records at SiteGround yet?

Because the domain does not point at SiteGround's nameservers. Site Tools only manages zones for domains delegated to it, and it will show a warning until that is true. This is expected, not a fault — it is also why you prepare the record list in advance.

Why does my site still show the old version?

Almost always your own browser or your ISP's resolver still holding the previous answer. Check with dig against a public resolver such as 8.8.8.8 before concluding anything is wrong — that tells you what the internet sees, rather than what your laptop remembers.

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.

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.

Get Help With This MigrationMigration service details

← All Bluehost to SiteGround stepsMigration guide tool

CallTextMessage