How to Point a Domain to Your Website
You bought a domain (or a website) and need to connect the two so the domain shows your site — a five-minute change surrounded by a day of patience.
Common signs of this issue
- Your domain shows a registrar 'parked' page, ads, or a blank page instead of your site.
- Your host gave you an IP address or a pair of nameservers and you're not sure where they go.
- You moved hosts and the domain still shows the old site.
- The site works at a temporary host URL (something.hostname.com) but not at your real domain.
- Your domain and hosting are at two different companies and you're not sure which controls what.
Safe checks you can do yourself
None of these require sharing passwords with anyone.
- First get oriented — two companies, two jobs: the registrar is where the domain is registered (and where its DNS is controlled, initially); the host is where the site's files live. Pointing means telling the registrar's DNS where the host is. Know which company is which before touching anything.
- Find what your host wants set — the welcome email or hosting dashboard says either "use these nameservers" (two to four addresses like ns1.host.com) or "point an A record to this IP" (numbers like 203.0.113.10). That instruction decides your method.
- Nameserver method (simplest): at the registrar, find the domain's nameserver settings and replace the defaults with the host's pair. This hands ALL DNS management to the host — clean, but note it also moves where your email records live.
- A record method (more surgical): in the registrar's DNS records, set the root/@ A record to the host's IP, and set www as the host directs (often a CNAME to your domain). Everything else — including email — stays where it is.
- Before changing anything, screenshot the current DNS records — especially any MX (email) records. If email already works on this domain, those records must survive the change; the nameserver method in particular requires recreating them at the new DNS home, or mail dies silently.
- After saving, expect propagation: minutes to 48 hours for the world to learn the new address. A free "DNS checker" shows the change spreading; your own browser is the least reliable witness (its cache lies). Resist re-changing anything during the wait.
- When the domain loads your site: check https works (the host may need to issue an SSL certificate for the newly-connected domain — often automatic, sometimes a button), and send yourself a test email if the domain has mail.
What this usually means
A domain and a website are two separate rentals: the domain is the street address, the hosting is the building. Nothing connects them until DNS says so — and a parked page simply means the address currently points at the registrar's default instead of your building. That's the entire mystery; the fix is one setting made in the right place.
The two methods differ in scope, and that's the real choice. Nameservers delegate everything — simple, and afterward all DNS management (including email records) happens at the host. A record moves only the website — safer when email or other services already run on the domain, since nothing else changes. Neither is 'better'; use what your host recommends, and never both methods aimed at the same goal.
Nearly every horror story in this area is really an email story: someone changed nameservers, the MX records didn't exist at the new DNS home, and business mail bounced for a day before anyone noticed. The screenshot-first habit and a post-change test email prevent the whole genre.
What not to do
- Don't change nameservers AND set A records for the same purpose — pick one method; mixing them creates confusing half-states.
- Don't expect an instant switch — propagation takes up to 48 hours, and re-changing settings mid-wait restarts the clock and multiplies confusion.
- Don't delete existing DNS records you don't recognize — especially MX (email), TXT (verification/anti-spam), and records other services planted. Unknown ≠ unneeded.
- Don't make the change at 5pm before a busy day if email runs on the domain — do it when a few quiet hours can absorb any surprise.
- Don't panic if the old site shows for a while after the change — that's caches emptying, not failure. The DNS checker is the truth; your browser isn't.
When to get help
The change itself is small; the blast radius isn't — one wrong record takes down the site or email for hours in each direction. Worth doing yourself: a fresh domain with no email, following the host's exact instructions. Worth a helper's fifteen minutes: anything involving working email on the domain, multiple services, or uncertainty about which company controls what. Getting it right the first time is cheap; propagation makes every mistake a multi-hour mistake.
Not sure what to do next?
Answer a few short questions and we'll point you to the safest next step — DIY, a freelancer, or a direct review. No passwords required.
Frequently asked questions
Nameservers or A record — which should I use?
Whichever your host recommends. Nameservers are simplest (the host takes over all DNS); an A record moves only the website and leaves everything else — notably email — untouched, which makes it the safer choice on a domain with working mail. Never both for the same goal.
How long until my domain shows my site?
Typically under an hour, worst case 24–48 for full worldwide propagation. A free DNS checker shows the real state; your own browser caches the old answer longest. If a checker shows the new value everywhere and it's still wrong after 48 hours, a record is actually incorrect.
Will pointing my domain break my email?
The A-record method: no — email records are untouched. The nameserver method: yes, unless the MX and related records are recreated at the new DNS home. That's why you screenshot existing records first and send a test email after. If mail matters and this paragraph is news, have someone do the switch.
Where do I change DNS — my registrar or my host?
Wherever the nameservers currently point — initially the registrar. If you've delegated nameservers to your host, DNS lives there now. When you can't find a record you expect to see, you're probably looking at the company that no longer controls it.
The domain works without www but not with it (or the reverse). Why?
Only one form got a record. You need both: the root A record plus a www entry (usually a CNAME), with the site redirecting one to the other. See the www vs non-www guide.
My site shows 'not secure' now that the domain connects. Did I break something?
No — the host just hasn't issued an SSL certificate for the newly-pointed domain yet. Most issue one automatically within hours, or there's a button (Let's Encrypt/AutoSSL) in the hosting panel. Padlock first, then celebrate.