HelpWithWebGet Help Now

Nameservers · SiteGround

Point your domain at SiteGround nameservers

Changing nameservers hands your entire DNS zone to one company in a single move — website, email, subdomains and verification records together. It is two fields and a save button, and everything that makes it safe happens beforehand.

This page covers SiteGround as the destination: which nameservers to use, what has to be in place first, and how to tell when it has actually taken effect.

Checked against SiteGround's documentation on August 9, 2026.

What is different about SiteGround

The process is standardised. These are the parts that are not — the things that are true of SiteGround and not of everyone else.

There is one standard pair

SiteGround publishes ns1.siteground.net, ns2.siteground.net for standard accounts, which makes this simpler than providers that assign them individually. Account-specific or private nameservers exist on some plans, so check your own control panel if what it shows differs.

The zone cannot exist until after you switch

SiteGround will not manage a zone until the domain already points at it, so there is an unavoidable window where it is authoritative for records you have not entered yet. The mitigation is preparation: every record written down, entered immediately, mail first.

SiteGround at a glance

Nameservers
ns1.siteground.net, ns2.siteground.net
Propagation
24 to 48 hours
Zone editor
Site Tools → Domain → DNS Zone Editor
Records before delegation
Not allowed

Step-by-step

  1. 1At SiteGround

    Get SiteGround's nameservers

    Standard accounts use the published pair.

    SiteGround nameservers
    ns1.siteground.net
ns2.siteground.net
  2. 2On your computer

    Write down every record first

    You cannot create the records yet, so the preparation happens on paper. This list is what replaces staging.

    • A record pointing at the correct server
    • www resolving, by CNAME or its own A record
    • MX records with correct priorities
    • SPF, DKIM, DMARC and any verification TXT records
  3. 3At your current provider

    Change the nameservers at your registrar

    The registrar controls the delegation, wherever the domain happens to be registered and regardless of who provides the hosting. Replace the whole set rather than one of the pair.

    • Find the nameserver setting in your registrar's domain settings
    • Replace every entry, not just the first
    • Allow 24 to 48 hours
  4. 4At SiteGround

    Enter the records immediately

    The zone editor unlocks once the domain points here. This is the window you prepared for.

    • Site Tools → Domain → DNS Zone Editor
    • MX records first, then everything else
  5. 5On your computer

    Watch propagation instead of guessing

    Check what public resolvers actually return. Expect a mixed picture for a while — some resolvers on the old answer, some on the new — which is normal rather than a fault.

    Check the delegation
    dig NS example.com +short
dig @8.8.8.8 example.com A +short
dig +trace example.com
  6. 6At SiteGround

    Re-issue SSL once it resolves here

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

    • Confirm the site still forces HTTPS afterwards
    • Check no stale CAA record is blocking issuance

Best practice

The habits that make this go smoothly, independent of which providers are involved.

  • Write every record down before switching, because SiteGround will not let you create them until afterwards
  • Replace the whole set with ns1.siteground.net, ns2.siteground.net at once, never one of a pair
  • Lower record TTLs a day ahead so corrections propagate quickly
  • Verify with dig against a public resolver rather than your browser, and allow 24 to 48 hours
  • Send a test email in both directions after the switch
  • Leave the old zone untouched for a fortnight so rollback stays instant

What goes wrong

The failures that actually happen when SiteGround is the destination.

  • 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.

  • The zone editor unlocks only after the switch

    Can cause downtime

    That inverts the safe order and creates a live window. Minimise it with preparation, or skip nameservers entirely and point just the A record.

  • You cannot shorten nameserver propagation

    Can cause delays

    Lowering your record TTLs genuinely speeds up record changes, but not this. The delegation TTL is set by the TLD registry — typically 48 hours for .com — and is not yours to adjust.

  • Both zones answer during propagation

    Can cause downtime

    For a day or two some visitors reach the old server and some the new one. If both accept orders or form submissions you end up with data split across two databases. For anything transactional, put the old side into maintenance mode at cutover.

Where are you coming from?

Most of this job depends on the destination. These are the bits that depend on where you are coming from.

If your registrar and host are the same company

Pointing at SiteGround does not cancel anything there, but watch the reverse: closing that account later removes its DNS service too, and takes the old zone with it — including the copy you were relying on as a rollback.

If your DNS is currently at Cloudflare

Pointing nameservers at SiteGround means losing the proxy, the CDN and any page rules with it — and since SiteGround will not let you pre-build the zone, you would be trading a working setup for one you cannot rehearse. Usually better: leave the nameservers at Cloudflare and change the A record.

If you only want the website to move

Then you probably do not need this page. Point the A record at SiteGround and leave the nameservers alone — email, subdomains and verifications never move, so they cannot break. SiteGround documents this route itself, which is a fair signal it is the expected choice.

Know exactly where you are moving from?

Common questions

What are SiteGround's nameservers?

ns1.siteground.net, ns2.siteground.net. Some plans use account-specific or private nameservers, so check your own control panel if it shows something different.

How long does it take?

SiteGround documents 24 to 48 hours. The delegation TTL is controlled by the TLD registry rather than by you, so this is the one part of DNS you cannot speed up.

Will this move my email?

Yes — that is the part people are surprised by. 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 before you switch.

How do I undo it?

Set the nameservers back to the previous pair. The old zone is untouched and correct the moment it takes effect, though you wait out propagation a second time — which is the real cost of getting this wrong.

Reference documentation

Provider interfaces change. When these steps and the official documentation disagree, the documentation wins.

The same job at other providers

Point your domain at Bluehost nameservers

There is one standard pair

Point your domain at GoDaddy nameservers

The nameservers are specific to your domain

Point your domain at Hostinger nameservers

The nameservers are specific to your domain

Point your domain at Cloudflare nameservers

The nameservers are specific to your domain

Want this done for you?

I move sites onto SiteGround regularly — files, database, DNS and the registrar — with the old provider kept as a rollback until it has settled.

Get Help With This MigrationMigration service details

← All migration guides

CallTextMessage