You own a name. Your site is built. This is the part in between, and it is the part where most people get stuck, not because it is hard but because the words on the screen belong to whoever sold you the domain, and every company uses different ones.
Connecting a domain is two things: one record that sends visitors to us, and a few records that prove the name is yours so a certificate can be issued. Nothing moves until you add them, so there is no moment where your site is half-broken.
This one question causes more lost time than everything else on this page combined.
Where you bought the name and where its settings live are often not the same company. People buy a domain somewhere, later move its DNS to Cloudflare or a host, and then forget. The place you bought it keeps sending you renewal invoices, so it still feels like the right place, and its DNS screen sits there accepting records that do nothing.
To check, look for nameservers on your domain's page where you bought it. They
look like chad.ns.cloudflare.com or ns1.somehost.com. Whoever
those point at is who holds your records. Add them there and nowhere else.
Two of our own three domains are registered at one company and served by another. If you are not sure, the connect screen in your dashboard tells you which is which.
Your dashboard shows these with your own values filled in. Always use those, not the examples here. The shape is:
| Type | Name | What it does |
|---|---|---|
| CNAME | @ or www |
Sends visitors to your site. This is the one that makes the site appear. |
| TXT | _acme-challenge |
Proves the name is yours so a certificate can be issued. There are usually two of these. |
| TXT | _cf-custom-hostname |
Proves ownership without moving any traffic. Useful if your old site is still live and you are not ready to switch yet. |
You will be given two _acme-challenge records that share a name and have
different values. That is not a mistake in our instructions and you do not pick one.
Add both, as two separate records. The certificate cannot be issued until both are
visible.
yourdomain.com and www.yourdomain.com are two separate
addresses, and pointing one at us does nothing for the other. Whichever you connected in
your dashboard is the one to point here. If you connected the root, the record's name is
@; if you connected the www, it is www.
Want both to work? Connect both in your dashboard. Each gets its own records, and then neither one is a dead end for a visitor who typed the other.
A root domain cannot normally take a CNAME. Most providers solve this quietly under a different name: ALIAS, ANAME, or CNAME flattening. It works the same way. Cloudflare does it automatically. If yours genuinely cannot, connect the www version instead and send the root to it with a redirect.
Every company files this under a different word, which is why "set up a redirect" is such an unhelpful sentence on its own. It is at whoever holds your DNS, not necessarily where you bought the name.
| Where your DNS is | What it is called, and where |
|---|---|
| Cloudflare | Pick your domain, then Rules in the left sidebar, then Redirect Rules, then Create rule. Older accounts may instead have Rules → Page Rules with a "Forwarding URL" option, which does the same job. See the warning below, because this one has a catch. |
| CanSpace | Client area, open the domain, look for Domain Redirect. It is a separate section from the DNS or Zone Editor, which is why it is easy to miss. |
| GoDaddy | My Products, open the domain, Domain Settings, then Forwarding. |
| Namecheap | Domain List, Manage, then the Redirect Domain section. |
| Hostinger | Domains, open the domain, then Domain Redirect. |
| Porkbun | Domain Management, then URL Forwarding. |
On Cloudflare, a redirect rule only runs on proxied records. If the record is set to DNS only, the grey cloud, Cloudflare is not in the path at all. The visitor's browser goes straight to the destination and there is nothing sitting in between to send them anywhere else. The rule will save happily and never fire.
So a hostname that exists only to redirect needs a record that is Proxied, the orange cloud, even though nothing is really there.
This is the common case: your site is connected at yourdomain.com and you want
anyone who types www.yourdomain.com to arrive at it anyway. It is two steps, and
doing only the second is why people conclude redirect rules are broken.
First, give www something to redirect. If no www record exists there is
no traffic for the rule to catch. In DNS → Add record:
| Field | Value |
|---|---|
| Type | A |
| Name | www |
| IPv4 address | 192.0.2.1 |
| Proxy status | Proxied (orange cloud) |
192.0.2.1 is an address reserved for documentation. Nothing is there and
nothing ever reaches it, because Cloudflare answers first and sends the visitor on. This is
the one record that should be orange; the record pointing at us stays grey.
Then the rule. Rules → Redirect Rules → Create rule. Cloudflare offers a template called Redirect from WWW to root, and its own default values are already correct:
| Field | Value |
|---|---|
| Request URL | https://www.yourdomain.com/* |
| Target URL | https://yourdomain.com/${1} |
| Status code | 301, Permanent Redirect |
| Preserve query string | ticked |
The /* and ${1} are the part that matters. They carry the rest of
the address across, so www.yourdomain.com/about arrives at /about
rather than dropping every visitor on the homepage. Press Deploy, wait a moment, then
open the www address and check it lands on the right page with the padlock showing.
Check the direction before you deploy. A redirect points away from one address and towards another, and pointing it the wrong way takes a working site down: visitors get sent from the address that serves your site to one that does not exist.
The rule is simple. The address you connected in your dashboard is the one that serves. Everything else redirects to it. If you connected the root, then www redirects to the root. If you connected www, then the root redirects to www. Both are fine, and which is right for you is decided by what you connected, not by preference.
If your DNS is on Cloudflare, every record has a toggle: Proxied (orange) or DNS only (grey).
The record that points at us must be DNS only. Proxied means Cloudflare answers the request on your account and never passes it to us, so your site does not appear and the connection sits at "waiting" with no obvious reason why. This is the single most common reason a correctly-typed record does not work.
The verification TXT records are always DNS only. Cloudflare will not offer you a choice on those.
While you are in there you will see records you did not add and may not recognise:
MX records: where your email is delivered.v=spf1: which servers may send email as you._dmarc: what to do with email that fails that check._domainkey or similar: signing keys for your email.Leave all of them alone. None of them have anything to do with your website. Deleting the email ones stops your mail; deleting the SPF and DMARC ones lets other people send email pretending to be you. Adding a website record never requires removing one of these.
Once the records are in, the certificate is issued on its own. It usually takes minutes and can take up to a day. Your dashboard's domain page shows the real state, including what is still missing, so you do not have to guess.
If it still says waiting after a few hours, it is nearly always one of these five:
_acme-challenge records was added.www but the root was connected, or the other way round.www.yourdomain.com.yourdomain.com. Some
providers add the domain for you and some do not. If a saved record looks doubled, that
is this.Send us a screenshot of your DNS screen through the contact form. A person reads it, and a picture of the actual records settles in one message what a description takes five to narrow down. Hide anything you would rather not show. The records we need to see are not secret ones.