Website down after a move? Understanding and fixing DNS problems
by Marcel, Senior software engineer
Hardly any topic causes website owners as much stress as DNS: the site got moved, and suddenly it's unreachable. Or worse — the site works fine, but no email has arrived since the move. Cases like this land on our desk regularly, often with the line "but the move was three days ago". So you know where to look when it happens to you, here are the typical pitfalls — and how to fix them.
Quick explainer: what DNS actually does
DNS is the address book of the internet. When someone types your domain, their device asks DNS: "Which server belongs to this address?" The answer lives in your domain's DNS records. The most important ones:
- A record: points to your web server's IP address — it decides where your website lives.
- MX records: define which server accepts your email — independent of the website.
- CNAME: a pointer to another name, often used for subdomains like www.
- TXT records: contain SPF and DKIM for sending mail, among other things.
The crucial point a lot of people don't know: website and email are separate concerns in DNS. That's exactly where the most common migration disaster comes from.
Pitfall 1: the website moves — and drags the email with it
By far the most common problem we see on websites we take over: during a hosting switch, the domain's entire nameservers get pointed at the new provider. From that moment on, that provider's DNS records apply — and they know nothing about your email setup. The website runs beautifully after the move, but the MX records point nowhere or at the new host's default. The result: mail doesn't arrive for days, and senders get a bounce message at best.
The fix — better yet, the prevention: document all existing DNS records before any move (a simple screenshot of the DNS panel is enough). If only the website is moving, it's usually enough to change the A record to the new server — the nameservers, and with them all mail records, stay untouched. If the damage is already done: re-enter the old MX, SPF and DKIM records at the new provider. By the way, the mail from that window is rarely lost — reputable mail servers keep retrying delivery for several days.
Pitfall 2: "works for me, not for the client" — TTL
Every DNS record has a lifetime, the TTL (time to live). It tells the servers asking: "Remember this answer for X hours." When you change a record, some visitors see the change immediately, others only after hours — depending on when their provider last checked. That explains the familiar phenomenon where the moved website already works on your phone but the office still gets the old one.
The fix: lower the TTL of the affected records well before a planned move — to 300 seconds, say, and at least a day ahead while the old TTL still applies. Then the actual switch takes effect in minutes instead of hours. After the move you can raise the TTL again.
Pitfall 3: the domain works without www — but not with it (or the other way around)
From a DNS point of view, your domain and the www variant are two different names, each with its own record. If only one of the two gets updated during a move, the other still points at the old server — and depending on what visitors type, they land on the new website, an error page or the old version.
The fix: check both records and point them at the new server. On the server itself, a redirect should then make sure only one of the two variants is the "real" one — that matters for Google too, so you don't end up with two identical websites competing. We covered how to set this up cleanly in our piece on technical SEO basics.
Pitfall 4: the site loads, but the browser warns about the connection
After a move, an SSL warning likes to show up: "This connection is not secure." The cause is almost always that no certificate for your domain has been set up on the new server yet — or that one couldn't be issued because the DNS change hadn't propagated everywhere when the server tried.
The fix: have the certificate (re-)issued on the new server once the DNS change has taken effect. With most hosts that happens at the push of a button or automatically — sometimes it just needs a second attempt a few hours later.
Top tip
With free online tools like a "DNS checker" you can see which IP address your domain is currently returning from different parts of the world. That tells you right away whether a change has propagated everywhere — instead of guessing blind about whether you still need to wait or something is genuinely broken.
Our advice: never do DNS changes "real quick"
Almost every DNS emergency we handle has the same backstory: a change was made on the side, without capturing the current state and without knowing which records exist for what. Half the battle is simply care — document, change only what's necessary, then test the website and the email.
If your website is down after a move, your email stops arriving, or you'd rather not handle an upcoming switch on your own: we'll take care of it — from taking stock to the clean cutover to testing afterwards. For Weblication websites in particular we do this regularly as part of ongoing care, so a case like this doesn't come up in the first place. Get in touch and we'll look at it together.