DNS is the internet’s address book. Pointing DNS at your website host means updating that book so yourdomain.com finds the place your files actually live. It is exacting work — wrong record type, leftover old values, impatient re-edits — but it is not programming. This guide covers TTL, propagation, common mistakes, and why you should finish the HTTPS preview first.

Preview first, DNS second

SiteHost gives you an HTTPS preview as soon as the site publishes. Use it to validate layout, forms, and mobile nav. Only when that preview is acceptable should you change public DNS. Otherwise every stakeholder tests a broken site through a fog of propagation delays.

Companion pieces: connect a domain to your website, how to make a website live.

TTL in plain language

TTL (time to live) is how long other computers may remember an answer before asking again. A TTL of 3600 seconds means “you can cache this for about an hour.”

Before a planned migration:

  • Lower TTL (for example to 300) a day ahead if your registrar allows
  • Make the cutover
  • Raise TTL later for slightly less DNS chatter

If you never lowered TTL, a change can still work; it may just take longer for everyone to see it. TTL is not a SiteHost setting — it lives on the DNS records at whoever hosts your DNS (often your registrar, sometimes Cloudflare).

Propagation is not magic smoke

“Propagation” means: caches around the world expiring and fetching your new answers. It is uneven. Your phone on LTE might see the new site while the shop Wi‑Fi still shows the old host.

What to do:

  • Wait longer than feels polite
  • Test with a cellular connection or an online DNS checker
  • Avoid changing the same record five times in ten minutes

Flapping creates more cached confusion.

Wrong record type — the classic own-goal

SiteHost will show you what to create. Typical patterns involve an A record and/or a CNAME. Problems appear when:

  • You create a CNAME where an A is required (or the reverse)
  • You CNAME the apex in a DNS provider that forbids it
  • You leave the old A record alongside the new one, sending traffic unpredictably
  • You edit records in the wrong account (registrar DNS vs Cloudflare DNS after a nameserver change)

Fix: screenshot the SiteHost instructions, screenshot your DNS panel, compare character by character. Delete obsolete host records for @ and www that still point at the previous host once you intend full cutover.

Nameservers vs records

If you once “moved DNS to Cloudflare,” your registrar’s DNS editor may be ignored. Check whether nameservers still point at the registrar or at a third party. Edit records at the place your nameservers indicate. This single check solves a shocking number of “I updated DNS and nothing happened” tickets.

Certificate timing

After SiteHost verifies DNS, the custom domain certificate can issue. Until then, use the preview’s HTTPS. Do not assume the custom domain is ready for ads the minute you click save on an A record. Free SSL for a small website.

Email MX records — hands off unless intentional

MX records control mail routing. Website pointing rarely requires touching them. If mail breaks after a “cleanup,” restore MX from your screenshot. SiteHost does not provide email hosting; protect the mail path you already have.

Migration sequence that reduces heartburn

  1. Preview approved on SiteHost.
  2. TTL lowered earlier if possible.
  3. Add domain in SiteHost; copy required records.
  4. Apply records at the real DNS host.
  5. Wait for verification / cert.
  6. Test https://yourdomain.com and https://www... as applicable.
  7. Update Google Business Profile and ads.
  8. Decommission old host only after confidence.

Plans (Starter $9/mo through Business $130) do not change DNS physics. Trial ~1 day is for proving hosting, not for learning DNS theory all month — practice on a subdomain if you are nervous.

Example: wrong CNAME adventure

A consultant pastes a CNAME target into the A record’s address field. Nothing verifies. They wait three hours, then paste again with a typo. On a call, a friend notices the record type mismatch, deletes the bad row, creates a proper A record with the IPv4 SiteHost provided, and verification succeeds in a short time. The site files were fine all along — DNS was the only broken layer.

Tools and habits that reduce guesswork

  • Screenshot DNS before changes
  • Change one hostname’s records at a time when learning
  • Keep a notepad of SiteHost’s required values
  • Test on cellular after verification
  • Leave MX alone

If you use optional Cloudflare, decide deliberately whether the orange cloud proxy is on. Mis-proxied records can confuse certificate issuance. SiteHost has no built-in CDN; Cloudflare is optional, not required for DNS pointing to work.

Starter through Business plans all follow the same DNS logic. Preview first, DNS second, ads third. Rollback restores files only.

Migration from an old host without a blind cut

  1. Preview new site on SiteHost HTTPS.
  2. Lower TTL ahead of time if you can.
  3. Note old record values so you can revert.
  4. Apply SiteHost’s records.
  5. Verify cert on custom domain.
  6. Watch analytics/mail for a day.
  7. Cancel old hosting only after confidence.

People who skip step 1 debug layout and DNS simultaneously — a miserable cocktail. Keep layers separate and boring.

Explaining delays to impatient stakeholders

Say this out loud: “The new site is already live on the preview link. We are waiting for the address book of the internet to remember the new location for our name. Some phones update faster than office networks. We will not flap the records every ten minutes.” Then send them the HTTPS preview so they can review content while DNS catches up. Content approval and DNS propagation should never be the same conversation.

Questions people actually ask

How long should I wait?

Often minutes to a few hours; occasionally longer with high TTLs and sticky caches. Longer than a day deserves a careful audit of where DNS is actually hosted.

Can SiteHost change DNS for me?

Not inside your registrar login. You (or someone you trust) must apply the values.

Should I use Cloudflare in front?

Optional. It can host DNS and provide CDN features SiteHost does not build in. Only enable proxying if you understand orange-cloud behavior; mis-proxying can confuse cert issuance. Optional means optional.

What is a staging subdomain DNS-wise?

A record like staging.yourdomain.com pointing as SiteHost instructs — useful on Pro with staging or a second site. Keeps experiments off the apex.

Does rollback fix DNS mistakes?

No. Rollback restores website files. DNS mistakes are fixed in the DNS panel.