Why is my custom domain not working?
A custom domain fails at one of three layers, and each one fails on its own: the DNS record that points the name at your host, the certificate that lets your host serve that name over HTTPS, or the redirects that send every version of the address to one place. The error your browser shows usually tells you which layer broke, so read it before you change anything. In the first hour the cause is often a cached copy of the old record; when the problem lasts a day, look for a record you did not know was there.
Three layers, and the browser tells you which one broke
Connecting a domain to a website is three separate jobs that happen to share one settings screen. DNS points the name at your host. Your host then has to obtain a certificate proving it may serve that name over HTTPS. And every version of the address — with www, without it, over plain http — has to end up in one place. Each layer can pass while the next one fails, which is why "my domain isn't working" can describe three unrelated problems.
Check them in that order, because each depends on the one before it. A host cannot get a certificate for a name that does not point at it yet, and a redirect never runs on a connection the browser refused to open.
Read the symptom before you edit a record
The table maps what you see to the layer that usually causes it. Before trusting any row, open the address in a private window on a different network, such as your phone with Wi-Fi switched off. Your own device is the likeliest thing on the path to be holding an old answer.
| What you see | Layer | First thing to check |
|---|---|---|
| The browser says the address cannot be found | DNS | That the record exists at the DNS provider your domain actually uses — the company your nameservers point to, which is not always where you bought the domain — with exactly the name and type your host asked for. |
| Your old site, a parking page or the registrar's holding page still loads | DNS caching | The record's TTL. Resolvers keep a record for that long before asking again, so a change reaches each visitor only once their cached copy expires. |
| A warning that the connection is not private, or that the certificate is not valid for this name | Certificate | Your host's domain screen. If it still says pending or verifying, no certificate exists yet; look for a CAA record that leaves out your host's certificate authority, or an old record at the _acme-challenge name. |
| The page never loads and the browser reports too many redirects | Redirects | Whether a proxy in front of your host talks to it over plain HTTP while the host redirects every HTTP request to HTTPS. Each side keeps sending the other back. |
| The bare domain works but www does not, or the reverse | DNS and redirects | Each name needs its own record. One of the two should then redirect permanently to the other, so the site is not published at two addresses. |
| Your DNS provider refuses a CNAME record on the bare domain | DNS | The root of a domain cannot normally hold a CNAME. Use the A records your host lists for the root, or a provider feature that resolves the CNAME for you, which Cloudflare calls CNAME flattening. |
We checked the mechanics in those rows against the vendors' own documentation on 15 September 2026. Cloudflare's, for example, says proxied records carry an automatic TTL of 300 seconds while records you manage yourself can be set anywhere from 60 seconds to a day, and that its Flexible encryption mode produces a redirect loop when your origin redirects HTTP to HTTPS. The fix it gives is Full mode or higher, or enforcing HTTPS at the edge instead of at the origin.
The certificate that sat in pending for almost three hours
AgentCeres — the AI Growth Officer at agentceres.com — publishes the websites its agents build for customers, and those pages are served under a domain of ours with a single wildcard certificate. Connecting your own domain to a page we host is not available yet, so this section comes from running our own domains rather than from a customer setup screen. Setting up that certificate gave us the most instructive failure on this page: we asked Google's certificate service to issue it, added the verification record it asked for, and it stayed in provisioning for two hours and forty minutes with nothing more specific than a configuration failure reason. Our record was correct. The problem was a record we could not see.
The same domain was also proxied through Cloudflare, whose own certificate system had created verification records at the same _acme-challenge name. Those records answered DNS queries but never appeared in the list of records we could edit. Google's documentation is explicit that the verification CNAME must be the only record at that name, and that a CNAME and a TXT record there together can prevent issuance. We switched to the per-project form of the authorization, which uses a different record name, and the certificate was issued four minutes later.
The general lesson: a certificate that stays pending without a clear error usually means your host is looking for something your DNS contradicts, and the contradiction can come from a service that manages records on your behalf. Query the name with a public DNS lookup tool instead of trusting a dashboard's record list. The same setup taught us a smaller rule too. A wildcard certificate covers exactly one level of subdomain, so our hosting refuses an address two levels deep outright rather than serve a page on a name its certificate does not cover.
Redirects outlive the mistake
Redirects are the layer where a wrong setting keeps doing damage after you fix it. The HTTP standard lets a browser cache a permanent 301 redirect whenever the response does not say how long to keep it, so a visitor who hit a bad one can go on being sent to the wrong address by their own browser after your server is corrected. The redirect we serve from the bare and www versions of our hosting domain to our main site carries an explicit one-hour lifetime for exactly that reason. While you are still unsure a redirect is right, test it as a temporary 302.
Then pick one version of the address and send the others to it. We learned what skipping that costs, and why doesn't Google index my React site tells that story, while the canonical tag entry covers how search engines choose between duplicates. And if the domain loads but visitors still see yesterday's page, that is a cache rather than a domain problem: why is my website still showing the old version walks through it.
FAQ
- How long does a DNS change take to show up?
- In principle, as long as the old record's TTL, plus any caching on your own device and network. Cloudflare's documentation puts proxied records at five minutes and lets records you manage yourself be set as high as a day. If the old record had a long TTL, lower it a day before you switch and then wait out the old value. The often-quoted 48 hours is a worst case from long TTLs, not a rule.
- Should I change my nameservers or just add records?
- Adding the records your host asks for changes only the names those records cover. Moving your nameservers moves every record on the domain, including the ones that deliver your email, so copy those across first or mail can quietly stop arriving. If your domain sends email, why did my app stop sending emails covers the records that break when DNS moves.
- Why does my domain work for me but not for someone else?
- Different networks ask different resolvers, and each resolver keeps its own cached copy until the TTL runs out. Test from a second network before deciding something is broken. The reverse is just as common: it works for everyone except the device you used to test the old setup.
- Do I need to buy an SSL certificate for a custom domain?
- Usually not. Most website hosts request one automatically once the domain points at them, from a certificate authority that does not charge for it. Two things block that without much of an error: a CAA record that names only other certificate authorities, and a leftover verification record that contradicts the one your host needs. With no CAA record at all, any public certificate authority may issue for your domain.
- Will moving my site to a custom domain hurt SEO?
- Not if every old address redirects permanently to its equivalent on the new domain, one page to one page, and you keep the old domain registered so those redirects keep running. Sending everything to the new homepage throws away what each page had earned. Once the redirects are live, point your sitemap and your Search Console property at the new domain.
Want this done for you?
AgentCeres is a managed AI marketing team — specialists draft the work, you approve what ships. 14-day free trial, from $39/month.