SiteGround DNS Name Servers How to Point Your Domain Correctly

Switching your hosting to SiteGround is straightforward until you hit the name server step and realize your domain is still pointing at your old host. Traffic keeps landing on the wrong server, email stops working, and the site alternates between showing and breaking depending on which DNS resolver your visitors happen to hit. This guide cuts through the confusion: here are SiteGround's exact name servers, how to update them at the most common registrars, and how to confirm everything is actually working after the change.

What Are SiteGround's Name Servers

SiteGround uses two authoritative name servers for all shared, cloud, and reseller hosting accounts. They are the same regardless of which data center your account sits in (US, Europe, Asia-Pacific, or UK):

These are the values you will type into your domain registrar's control panel. Do not confuse them with the IP addresses listed inside SiteGround's Site Tools under DNS Zone Editor — those are the A records for your specific hosting account and live behind these name servers. The name servers themselves point the entire DNS zone to SiteGround's infrastructure; once they're set, SiteGround controls all the records for your domain.

If your domain is registered through SiteGround (not just hosted there), name servers are already set correctly and you do not need to change anything. Log into the SiteGround Client Area, go to Services > Domains, and check the name server column. If it already shows ns1.siteground.net and ns2.siteground.net, your domain is fully delegated and you can skip ahead to the verification section.

Why Name Servers Matter and Why People Get This Wrong

The domain registrar is the company that sold you the domain name — GoDaddy, Namecheap, Google Domains (Squarespace Domains), Cloudflare Registrar, and so on. The web host is the company running the actual server where your files live. These two are frequently different companies, and that separation is the source of most "my site isn't loading" tickets right after a hosting migration.

When a visitor types your domain into a browser, their ISP's resolver asks a root server where to find authoritative DNS for your domain. The root server responds with your registered name servers. If those name servers still point to your old host, every DNS record lookup — your A record, MX records, everything — comes from the old host's zone file, not SiteGround's. Updating the name servers at your registrar is the single action that transfers DNS authority to SiteGround.

A common mistake is editing individual A records inside the registrar's own DNS editor instead of switching name servers. That works too, but then you're managing two separate DNS zones (one at the registrar, one at SiteGround), which gets messy fast, especially for email. The cleaner approach for most people is to point name servers at SiteGround and manage everything from Site Tools.

Before You Make the Switch

A few things to do before touching the name servers:

• Lower your TTL ahead of time. If you have access to your current DNS zone (old host or registrar), set the TTL on your A record and MX record to 300 seconds (5 minutes) at least 24 hours before the change. This forces resolvers to re-check records frequently, making propagation faster once you switch.
• Note your current MX records. SiteGround will set up default MX records if you use their email service, but if you use Google Workspace, Microsoft 365, or another external mail provider, you will need to re-add those MX records in SiteGround's DNS zone editor manually after the switch. Switching name servers without preparing your MX records is the fastest way to kill email for a day.
• Verify your site is working on SiteGround before switching. You can preview it using the temporary URL shown in Site Tools under Websites > Preview, or by editing your local hosts file to map your domain to SiteGround's IP. Confirm the site loads, database connects, and any forms or payment integrations work before you point DNS over.

How to Update Name Servers at Major Registrars

GoDaddy

1. Log in at godaddy.com and go to My Products.
2. Next to your domain, click DNS.
3. Scroll to the bottom of the DNS Management page and click the Change button next to Nameservers.
4. Select Enter my own nameservers (advanced).
5. Replace both existing entries with ns1.siteground.net and ns2.siteground.net.
6. Click Save and confirm the warning that existing DNS records managed by GoDaddy will no longer be in effect.

Namecheap

1. Log in at namecheap.com, go to Domain List, and click Manage next to your domain.
2. Under the Nameservers section, change the dropdown from "Namecheap BasicDNS" to Custom DNS.
3. Enter ns1.siteground.net in the first box and ns2.siteground.net in the second.
4. Click the green checkmark to save.

Cloudflare Registrar

Cloudflare locks name servers for domains registered through their registrar — you cannot point them to SiteGround's name servers. Instead, import your SiteGround DNS zone into Cloudflare and proxy through Cloudflare. In Site Tools, go to Websites > [Your Site] > DNS Zone Editor, note your A record IP address, and enter it as the A record in Cloudflare's DNS editor with the proxy (orange cloud) enabled. This is actually a better setup for performance and security, just a different workflow.

Google Domains / Squarespace Domains

1. Go to domains.squarespace.com (the successor to Google Domains) and select your domain.
2. Click DNS in the left sidebar, then Name servers.
3. Select Use custom name servers and enter ns1.siteground.net and ns2.siteground.net.
4. Click Save.

Network Solutions

1. Log in and go to My Domain Names.
2. Select the domain, click Manage, then Change Where Domain Points.
3. Choose Domain Name Servers and enter both SiteGround name servers.
4. Save changes.

Adding Records Inside SiteGround's DNS Zone

Once name servers are delegated to SiteGround, you manage all DNS from inside Site Tools. Navigate to Websites > [Your Site] > DNS Zone Editor. Here you will find the A record SiteGround already created pointing your domain to your hosting account's IP. If you use an external email provider, this is where you add or update MX records.

For Google Workspace, the MX records look like this:

For Microsoft 365, you will get a single MX record from the Microsoft 365 Admin Center that looks like yourdomain-com.mail.protection.outlook.com with priority 0. Add that in the DNS Zone Editor under the MX record type.

You can use the DNS Lookup tool to check what MX records are currently being returned for your domain globally and confirm your new records are visible.

How to Verify Name Server Propagation

After saving your name server change at the registrar, propagation can take anywhere from a few minutes to 48 hours. The realistic expectation for most major registrars is 1 to 4 hours. Here is how to check:

From the command line (Windows, Mac, Linux):

When propagation is complete, the response will show ns1.siteground.net and ns2.siteground.net as the authoritative name servers. If you still see your old registrar's or old host's name servers, wait and try again.

Check from multiple global locations:

Common Problems and How to Fix Them

Site Shows SiteGround's Default "Under Construction" Page

This usually means name servers are pointed correctly but WordPress or your app is not installed yet, or Site Tools has not detected the domain. Go to Websites in Site Tools, confirm your domain is listed, and verify the WordPress installation is active. If you migrated manually, make sure the files are in the correct public_html directory and the database credentials in wp-config.php match the database SiteGround created.

SSL Certificate Shows an Error After Switching

SiteGround uses Let's Encrypt for free SSL. After name server propagation completes, go to Security > SSL Manager in Site Tools and install an SSL certificate for your domain. If it fails immediately after propagation, wait 15 to 30 minutes — Let's Encrypt needs to be able to resolve your domain to your SiteGround IP before it can issue the cert. Force an HTTPS redirect only after the certificate is active.

Email Stopped Working

This is the most common post-migration problem. Before the switch, your registrar's DNS had MX records pointing at your old host or email provider. After switching name servers to SiteGround, only SiteGround's DNS zone matters. If you did not add your external MX records there, email delivery will fail. Go to Site Tools DNS Zone Editor, check the MX section, and add the correct records from your email provider. Changes to DNS records inside SiteGround propagate within minutes since SiteGround controls the authoritative zone.

www Subdomain Not Resolving

SiteGround creates a CNAME record for www pointing to your root domain automatically. If www is not resolving, check the DNS Zone Editor for a CNAME record with host www and value yourdomain.com. If it is missing, add it manually: record type CNAME, name www, value yourdomain.com, TTL 3600.

When to Use SiteGround's Name Servers vs. Cloudflare

SiteGround's name servers are perfectly reliable and fast enough for most sites. But if you want a Web Application Firewall, DDoS mitigation, global CDN, or more granular DNS control, routing through Cloudflare's name servers is worth considering. The workflow is: keep your domain registered anywhere, point name servers at Cloudflare (ns1.cloudflare.com / ns2.cloudflare.com), and inside Cloudflare's DNS editor set an A record to your SiteGround hosting IP. SiteGround and Cloudflare work well together — SiteGround's support documentation explicitly covers this setup. The tradeoff is that you manage DNS in Cloudflare rather than Site Tools, which adds a layer but also adds a lot of capability.

Summary

SiteGround's name servers are ns1.siteground.net and ns2.siteground.net. Update them at your domain registrar, wait for propagation (typically under 4 hours), verify with a propagation checker or the dig command, and then handle any MX records or SSL setup inside Site Tools. The most important step people skip is auditing their DNS records — especially MX — before making the switch. Do that, and the cutover will be smooth.