{"id":334,"date":"2026-09-05T09:14:22","date_gmt":"2026-09-05T08:14:22","guid":{"rendered":"https:\/\/www.webfort.co.uk\/blog\/?p=334"},"modified":"2026-09-05T09:14:22","modified_gmt":"2026-09-05T08:14:22","slug":"dns-problems-why-website-wont-load","status":"publish","type":"post","link":"https:\/\/www.webfort.co.uk\/blog\/dns-problems-why-website-wont-load\/","title":{"rendered":"DNS Problems Explained: Why Your Website Won\u2019t Load"},"content":{"rendered":"<p>When a customer tells you your website will not load, the instinct is to blame the hosting. Often the real culprit sits one layer earlier, in the Domain Name System. DNS problems are among the most common causes of a site that seems to vanish while the server itself is running perfectly well.<\/p>\n<p>This guide explains what DNS actually does, which record types matter for a small business, how to diagnose faults safely, and how to avoid the mistakes that take websites and email down during a hosting move. No jargon for the sake of it, and no guesswork.<\/p>\n<h2>What&#8217;s in This Post<\/h2>\n<ul>\n<li><a href=\"#what-dns-does\">What DNS does in plain English<\/a><\/li>\n<li><a href=\"#common-dns-problems\">Common DNS problems and the records involved<\/a><\/li>\n<li><a href=\"#nxdomain-errors\">NXDOMAIN and DNS server errors<\/a><\/li>\n<li><a href=\"#troubleshooting\">Safe step-by-step troubleshooting<\/a><\/li>\n<li><a href=\"#dns-hosting-website\">Telling DNS, hosting and website faults apart<\/a><\/li>\n<li><a href=\"#after-a-move\">Checks after moving hosting<\/a><\/li>\n<li><a href=\"#email-records\">Business email records and DNS changes<\/a><\/li>\n<li><a href=\"#checklist\">Practical checklist and when to call for help<\/a><\/li>\n<\/ul>\n<h2 id=\"what-dns-does\">What DNS Does in Plain English<\/h2>\n<p>DNS is the system that maps names to services. People remember words, while computers connect using numbers and hostnames. When someone types your domain into a browser, their device asks a resolver for the address behind that name, the resolver works its way up to the servers that hold the authoritative answer, and the browser then connects to whatever it is given.<\/p>\n<p>Two ideas matter here. First, your domain name and your hosting are separate things. The registrar holds the name, the nameservers publish the answers, and the hosting account runs the site. Any of those three can fail independently.<\/p>\n<p>Second, answers are cached. Resolvers store results for a set period so they are not asking the same question thousands of times a second. That caching is why a change you made an hour ago may be visible to you and invisible to a customer twenty miles away. Understanding this separation makes most DNS problems far less mysterious.<\/p>\n    <aside class=\"wf-blog-cta wf-blog-cta--hosting\">\n      <div class=\"wf-blog-cta__inner\">\n        <span class=\"wf-blog-cta__kicker\">Webfort Hosting<\/span>\n                <p class=\"wf-blog-cta__title\">Looking for fast, reliable UK hosting?<\/p>\n        <p class=\"wf-blog-cta__body\">Our plans start from <strong>\u00a34.99\/month<\/strong> with everything included: SSL, backups, email, and 24\/7 support.<\/p>\n        <a class=\"wf-blog-cta__btn\" href=\"https:\/\/www.webfort.co.uk\/web-hosting\/\">\n          View Hosting Plans          <svg class=\"wf-blog-cta__arrow\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2.5\" stroke-linecap=\"round\" stroke-linejoin=\"round\" aria-hidden=\"true\"><path d=\"M5 12h14M13 6l6 6-6 6\"\/><\/svg>\n        <\/a>\n      <\/div>\n    <\/aside>\n    \n<h2 id=\"common-dns-problems\">Common DNS Problems and the Records Involved<\/h2>\n<p>Most faults trace back to a handful of record types. Cloudflare maintains a clear reference on <a href=\"https:\/\/www.cloudflare.com\/learning\/dns\/dns-records\/\" rel=\"nofollow noopener\" target=\"_blank\">what each DNS record does<\/a>, and it is worth bookmarking before you touch a zone file.<\/p>\n<h3>The records you will actually meet<\/h3>\n<p>An <strong>A record<\/strong> points a name at an IPv4 address. An <strong>AAAA record<\/strong> does the same for IPv6. A <strong>CNAME<\/strong> makes one name an alias of another, which is why it cannot sit alongside conflicting records on the same host. <strong>NS records<\/strong> declare which nameservers are authoritative for your domain. <strong>MX records<\/strong> direct mail. <strong>TXT records<\/strong> hold service text, including email authentication such as SPF and DKIM.<\/p>\n<h3>Where it usually goes wrong<\/h3>\n<p>Expired domains are the bluntest failure of all, because the name stops resolving regardless of how healthy your server is. Mismatched nameservers are next, where the registrar points one way and you edit records somewhere else. Broken DNSSEC signatures cause resolvers to refuse answers outright. Stale caching and long TTL values then stretch every mistake out over hours.<\/p>\n<h3>TTL and the propagation myth<\/h3>\n<p>TTL is the number of seconds a resolver may keep an answer before checking again. Lowering it a day or two before a planned move shortens the window of inconsistency. It does not make propagation instant, and there is no universal propagation time. Some resolvers ignore short TTLs, and some devices cache independently of the network.<\/p>\n<h2 id=\"nxdomain-errors\">NXDOMAIN and DNS Server Errors<\/h2>\n<p>NXDOMAIN is an authoritative answer meaning the name does not exist. It is not a timeout and not a server fault. If you see it for a domain you own, check the obvious causes first: an expired registration, a deleted record, a subdomain that was never created, or nameservers that no longer host the zone.<\/p>\n<p>SERVFAIL is different. It usually means the resolver tried and could not produce a valid answer, and broken DNSSEC is a frequent cause. If you enabled DNSSEC at the registrar and then changed DNS providers without updating the DS record, resolvers that validate signatures will reject your domain even though everything else looks fine.<\/p>\n<p>REFUSED normally means the server you asked is not willing to answer for that zone, which often points to a nameserver change that was only half completed. Cloudflare&#8217;s overview of <a href=\"https:\/\/www.cloudflare.com\/learning\/dns\/common-dns-issues\/\" rel=\"nofollow noopener\" target=\"_blank\">common DNS issues<\/a> covers these response codes and the misconfigurations behind them. Reading the exact error rather than assuming a general outage saves a great deal of time.<\/p>\n<figure style=\"max-width:100%\"><img decoding=\"async\" src=\"https:\/\/images.pexels.com\/photos\/479359\/pexels-photo-479359.jpeg?auto=compress&#038;cs=tinysrgb&#038;fit=crop&#038;h=627&#038;w=1200\" alt=\"DNS problems and website connection troubleshooting\" style=\"max-width:100%;height:auto\" \/><figcaption>DNS connects your domain to the services that deliver your website and email.<\/figcaption><\/figure>\n<h2 id=\"troubleshooting\">Safe Step-by-Step Troubleshooting<\/h2>\n<p>Diagnose before you change anything. Editing records while you are still guessing is how a slow site becomes a dead one.<\/p>\n<h3>Work outwards from your own machine<\/h3>\n<p>Confirm the fault is not local. Try the site on mobile data, in a private browsing window, and from a second device. If it loads elsewhere, you are looking at local cache or a router issue rather than a public DNS problem.<\/p>\n<h3>Query the records directly<\/h3>\n<p>Use <code>nslookup<\/code> or <code>dig<\/code> to ask for the A, AAAA, NS and MX records. Then repeat the query against a second resolver so you are comparing at least two independent answers rather than trusting one cached view.<\/p>\n<h3>Check the source of truth<\/h3>\n<p>Log in to your registrar and confirm the domain is registered, unexpired and pointing at the nameservers you expect. Then log in to whoever runs those nameservers and confirm the zone contains the records you think it does. Our <a href=\"https:\/\/www.webfort.co.uk\/blog\/website-down-checklist-small-business\/\">website down checklist for small businesses<\/a> sets out the wider order of checks when the cause is not yet clear.<\/p>\n<h2 id=\"dns-hosting-website\">Telling DNS, Hosting and Website Faults Apart<\/h2>\n<p>The symptom you see usually narrows the layer. A name that will not resolve at all is DNS. A name that resolves to an address that refuses the connection is usually hosting or a firewall. A page that loads with a 500 error is almost always the website or application itself, because the request reached the server and the server ran your code.<\/p>\n<table>\n<thead>\n<tr>\n<th>Symptom<\/th>\n<th>Likely layer<\/th>\n<th>First check<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>NXDOMAIN or &#8220;server not found&#8221;<\/td>\n<td>DNS or registration<\/td>\n<td>Domain status and NS records<\/td>\n<\/tr>\n<tr>\n<td>SERVFAIL on some networks only<\/td>\n<td>DNSSEC or resolver<\/td>\n<td>DS record matches DNS provider<\/td>\n<\/tr>\n<tr>\n<td>Resolves, then connection timeout<\/td>\n<td>Hosting or firewall<\/td>\n<td>Server status and IP address<\/td>\n<\/tr>\n<tr>\n<td>Certificate name mismatch<\/td>\n<td>DNS pointing at wrong host<\/td>\n<td>A and AAAA records<\/td>\n<\/tr>\n<tr>\n<td>500 error or blank page<\/td>\n<td>Website or application<\/td>\n<td>Error logs and recent changes<\/td>\n<\/tr>\n<tr>\n<td>Site fine, email bouncing<\/td>\n<td>MX or TXT records<\/td>\n<td>Mail routing and SPF<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>When the request is clearly reaching the server, stop editing DNS and start reading logs. Our guide to <a href=\"https:\/\/www.webfort.co.uk\/blog\/website-error-logs-hosting-problems\/\">using website error logs to diagnose hosting problems<\/a> explains what to look for and where the files usually live.<\/p>\n<h2 id=\"after-a-move\">Checks After Moving Hosting<\/h2>\n<p>A migration is where DNS problems cluster, because several things change at once and each has its own cache. The safest sequence is to copy the site, test it on the new server before touching public records, then switch.<\/p>\n<h3>Before you switch<\/h3>\n<p>Lower TTL values a day or two ahead so resolvers pick up the change more quickly. Decide whether you are changing nameservers or just an A record, because they behave differently. A nameserver change hands over the whole zone and every record in it. An A-record change moves one hostname and leaves mail routing untouched.<\/p>\n<h3>After you switch<\/h3>\n<p>Query from several independent resolvers rather than refreshing your own browser. Watch the old server&#8217;s logs to see whether traffic is still arriving, and keep it running until that traffic stops. Check the new server&#8217;s logs for errors that only appear under real visitors. Our walkthrough of <a href=\"https:\/\/www.webfort.co.uk\/blog\/cpanel-migration-for-agencies-no-downtime\/\">cPanel migration without downtime<\/a> covers the sequencing in detail.<\/p>\n<h3>Search visibility<\/h3>\n<p>Keep Google Search Console open through the move. Google&#8217;s guidance on a <a href=\"https:\/\/developers.google.com\/search\/docs\/crawling-indexing\/site-move-no-url-changes\" rel=\"nofollow noopener\" target=\"_blank\">site move without URL changes<\/a> recommends watching crawl statistics and coverage reports so you catch fetch failures early rather than weeks later.<\/p>\n<h2 id=\"email-records\">Business Email Records and DNS Changes<\/h2>\n<p>This is the failure that costs the most and gets noticed the least quickly. Website DNS changes can silently break email, because mail routing lives in the same zone as your web records.<\/p>\n<p>The classic mistake is switching nameservers to a new host and letting that host generate a default zone. The new zone contains A records for the website and MX records pointing at the new server&#8217;s own mail service, which is not where your mail actually lives. Messages then route to a mailbox nobody reads, and outbound mail may start failing SPF checks because the TXT record was not carried across either.<\/p>\n<p>Before any nameserver change, export the existing zone and confirm the MX, TXT and any mail-related CNAME records are recreated exactly on the new provider. That includes SPF, DKIM selectors and DMARC. Test by sending mail in both directions once the change has settled, not just by loading the website. If you are setting up mail on your domain for the first time, our guide to <a href=\"https:\/\/www.webfort.co.uk\/blog\/business-email-with-your-domain\/\">business email with your own domain<\/a> covers the records you need in place.<\/p>\n<h2 id=\"checklist\">Practical Checklist and When to Call for Help<\/h2>\n<p>Run through these in order before changing anything:<\/p>\n<ul>\n<li>Confirm the domain is registered and not expired at the registrar.<\/li>\n<li>Check the NS records match the DNS provider you are actually editing.<\/li>\n<li>Query A, AAAA, CNAME, MX and TXT records from two separate resolvers.<\/li>\n<li>Confirm DNSSEC is either off, or on with a DS record that matches your provider.<\/li>\n<li>Note the current TTL values so you know how long a change will take to settle.<\/li>\n<li>Test the site by IP address to see whether the server itself is responding.<\/li>\n<li>Send and receive a test email before declaring the job finished.<\/li>\n<\/ul>\n<p>Contact your host when the name resolves correctly but the server does not respond, or when logs show application errors. Contact your registrar when the domain status looks wrong, nameserver changes will not save, or DNSSEC settings need updating. Choosing the right name and registrar in the first place makes this simpler, which we cover in our comparison of <a href=\"https:\/\/www.webfort.co.uk\/blog\/how-to-choose-a-domain-name-co-uk-vs-com\/\">.co.uk and .com domain names<\/a>.<\/p>\n<p>Keep registrar security tight as a matter of routine. Enable two-factor authentication, turn on registrar lock, keep the registrant email address current and monitored, and review who has access to the account. A domain lost to a lapsed renewal notice or a compromised login is far harder to recover than a misconfigured record is to fix.<\/p>\n<h2 id=\"final-thoughts\">Final Thoughts<\/h2>\n<p>Most DNS problems come down to three questions: is the domain still registered, are the nameservers the ones you think they are, and do the records in the zone match the services you actually use. Work through those in order, query from more than one resolver, and resist the urge to change records while you are still diagnosing.<\/p>\n<p>Plan changes rather than reacting to them. Lower TTLs in advance, export your zone before a migration, and treat mail records with the same care as web records. If you would rather not manage any of this yourself, a host that handles DNS, migrations and email records as part of the service takes the guesswork out of it, and leaves you free to get on with running the business.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Learn how to diagnose DNS problems, understand common errors, check your records, and get your UK business website loading again.<\/p>\n","protected":false},"author":1,"featured_media":333,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[111,116,30,22,106],"class_list":["post-334","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hosting","tag-dns","tag-domains","tag-hosting","tag-small-business","tag-website-troubleshooting"],"_links":{"self":[{"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/posts\/334","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/comments?post=334"}],"version-history":[{"count":1,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/posts\/334\/revisions"}],"predecessor-version":[{"id":336,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/posts\/334\/revisions\/336"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/media\/333"}],"wp:attachment":[{"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/media?parent=334"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/categories?post=334"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webfort.co.uk\/blog\/wp-json\/wp\/v2\/tags?post=334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}