You connected your domain and your website still isn’t there? How to check what’s wrong

Captions available · press CC · Also on YouTube

You connected your domain to your new website, and when you type your address, your website isn't there. Instead you see one of four things: a parked page, your old site, a security warning, or an error page. Each one tells you how far the connection has got, and so what to check.

Everything below, and in the film above, was done on our own test website, a WordPress site for a flower shop, on our own private test network: our own name servers, our own test certificates, and a parked page and an old site of our own making. We made each fault, and we fixed it.

What you see tells you what to check

Connecting a domain changes its records, so that your name leads to your host's address. Those records are kept on your domain's name servers; ICANN describes a domain's authoritative name server as the server that "hosts the official database of resource records" for it. Then your host needs a certificate for your name, so the site can open on a secure connection. Our test site runs on WordPress, but this happens on the way to your site, so it is the same on any platform.

• A parked page: your name still leads somewhere else. Go to step 1.
• Your old site: your name still leads to your old host, or the change hasn't reached you yet. Go to step 2.
• A security warning (Your connection is not private): your name may reach your host before there is a certificate for it there. Go to step 3.
• An error page: read its message and its code. Go to step 4.

Step 1: a parked page

A parked page comes from wherever your name leads now. On our test site, that was the domain company's own parking page: the records still held its address.

1. In your hosting account, look for the address to point your domain at.
2. Open the records, where your name servers point. Not sure where that is? Another film in this series covers it, written up as Your website says "This site can't be reached"? (check 2 there).
3. Look for an A record for your domain itself, and one for www. In the film the domain itself is written as @, the zone-file sign that, in the standard for these records, "is used to denote the current origin". On our test site, both held the parking address.
4. Change both to your host's address, and save. Records already hold your host's address? Then ask your host: the page may be coming from them.
5. Then open your address in a private window, or a fresh browser, one that has never visited your site. Step 2 says why. On our test site, a fresh browser showed the site.

Step 2: your old site

Your old site means your name still leads to your old host, or the change hasn't reached you yet.

1. Check the records the same way as in step 1. Ours still held the old host's address. We changed it to the new host's, and saved.
2. Reload. On our test site: still the old site.

Two things can keep an old answer. Networks can keep an answer for as long as the record allows: ICANN's definition of a record's time to live is "the length of time (in seconds) a resolver can keep the resource record in its cache". So a change can take a while to reach you. And your browser can hold on to the old site too. On our test site, the same window kept showing the old site, reload after reload, though our test network already gave the new address. A private window of the same browser, and a fresh browser, showed the new site at once. (On our test network we emptied the network's memory of the old answer after each change, which stands in for waiting; what stayed was the browser's own.)

• So check in a private window.
• The old site there too? Check the records again. If only the www form, or only the plain form, shows the old site, another film in this series covers that.
• Records right, and still the old site? A change can take a while to reach you.

Step 3: a security warning

Your connection is not private can mean your name does reach your host, but there's no certificate for it there yet. On our test site, the host had no certificate for our name yet, so it sent its own, made out to another name. First check the records, as in step 1: they should hold your host's address.

Why does the certificate come after the records? A certificate authority checks your name before it issues a certificate. One authority's own guide to its checks says the one that puts a file on your web server "is the most common challenge type today", and in the standard for that check, the authority connects to "the hosts found in the DNS A and AAAA records" of your name. So that check can only pass once your name reaches your host.

1. In your hosting account, find the certificate for your domain, and its www form. If your host gets certificates for you, it may happen by itself, or there's a setting to turn on: the same authority's getting-started guide says that where a host gets and manages certificates for you, "it will either happen automatically or there will be a configuration option that you will need to enable". Not sure? Check your host's own documentation.
2. On our test site, it was off. We turned it on, and it was issued.
3. Reload. On our test site, the site opened securely.

Or does your site open, but say Not secure? On our test site, with the host not sending visitors to https, that was the same cause. Your website says "Not secure"? covers that marker in full. If the warning stays after the certificate is issued, another film in this series covers this warning and its other causes: Visitors see "Your connection is not private" on your website?

Step 4: an error page

If you get an error page instead, read its message, and its code.

• This site can't be reached, with DNS_PROBE_FINISHED_NXDOMAIN: your name led to no address. Your website says "This site can't be reached"? covers it.
• This page isn't working … redirected you too many times, with ERR_TOO_MANY_REDIRECTS: your browser was sent round in a loop (the browser's own source code describes it as "too many redirects"). Your website "redirected you too many times"? covers it.
• Your address works with www, but not without it (or the other way round): another film in this series covers that too.
• Something else? Read its message, and its code, and give both to your host.

Then: check it, the way a visitor would

1. From a fresh browser, type your address plain. Your site should open, and the panel at the left of the address should say Connection is secure.
2. Then try the www form. On our test site, it reached the site too. If yours doesn't, another film in this series covers that.

Or, there is another way

Ullbek is an AI website builder. You hand it your site's words and your own photos, and it builds a new, custom website with a new look. When we tried it with the words and photos of the Ottermoor Flowers site from this post, every page was kept, with all of the wording word for word. It asked one question, about the colours, and took about a quarter of an hour.

Every Ullbek site is served over a secure connection, and anyone who types the plain http address is sent to the secure one. On a domain you bring, the certificate renews by itself, as long as the records you added stay in place.