How to Connect a Website to Cloudflare

How to Connect a Website to Cloudflare

Cloudflare can sit in front of a website in two very different ways. You can move the whole domain to Cloudflare’s DNS and proxy, or you can keep a narrow setup and turn on only one feature at a time. That choice changes the steps, the risk, and the rollback plan.

Start there. A marketing site with a few pages has different needs from a mail-heavy company domain, and a domain that already powers a corporate website needs more careful record handling than a brand-new launch. If you are also thinking about website security, Cloudflare often enters the conversation for that reason first.

1. Decide whether you need full DNS control or just one Cloudflare feature

Cloudflare is not one single switch. It can manage DNS, proxy web traffic, cache content, filter requests, and sit between visitors and your origin server. If you only want one feature, such as DNS management or a security layer, you should still understand that the domain’s nameservers are usually the point where Cloudflare takes over control.

For a simple brochure site, full control is often fine. For a setup with mail routing, verification services, and several subdomains, the decision is sharper. A private network infrastructure, for example, may need certain hostnames to stay out of the proxy path, while web pages can go through Cloudflare without issue.

Ask one practical question: what must keep working on day one? If the answer includes email, API callbacks, or a payment flow, you are not just “connecting a website to Cloudflare”; you are changing how the domain resolves. That difference matters.

One short rule helps: don’t guess. If the site depends on any service outside the web server, list it before you touch nameservers. That list becomes your safety net.

2. Audit your current domain setup before changing nameservers

Before you move anything, check where DNS is managed now. The registrar and the DNS host are not always the same company, and that mismatch causes avoidable mistakes. Look up the current nameservers, then inspect the zone records that exist there.

You need the full picture: A and AAAA records for the website, CNAME records for subdomains, MX records for mail, TXT records for verification, and any unusual records used by third-party tools. A missing TXT record can break a login flow. A wrong MX record can stop mail.

Do not rely on memory. A domain that has been live for years may contain records added by different people at different times, and some of them may no longer be documented anywhere else. If the site owner cannot explain a record, that is a reason to preserve it until you know what it does.

This is also the moment to list redirects and old hostnames. If traffic still arrives on an old subdomain, note it now. A redirect that works at the origin can fail later if the hostname was not copied into Cloudflare.

Keep one copy of the current zone outside the registrar account. A plain text file is enough. So is a spreadsheet. The point is recovery.

3. Create the Cloudflare site and import the existing DNS records

After the audit, add the domain to Cloudflare. Cloudflare will scan for existing DNS records and try to import them into its zone. That scan saves time, but it is not a promise that everything came over cleanly.

Review the imported records line by line. A record may be missing, a subdomain may be duplicated, or a value may be stale. The first pass is about accuracy, not speed. If you see a hostname that should point to your web server but now points somewhere else, fix it before you touch the registrar.

Two small checks catch many errors. First, compare the imported records with your audit list. Second, confirm that the apex domain and the common “www” hostname both resolve to the right place. These are the records users will hit first.

If you manage a site that behaves like a corporate website, watch the subdomains closely. A support portal, a staging hostname, and a file host often sit beside the main site, and one missing record can be enough to create a hard-to-diagnose outage.

One practical aside: Cloudflare’s import is helpful, but it is not an excuse to skip your own review. The scan is a starting point. Your audit is the final check.

4. Choose which records should stay proxied and which should remain DNS-only

Cloudflare gives you a choice on many records. The orange cloud means traffic passes through Cloudflare’s proxy. The gray cloud means DNS only. That choice is not cosmetic. It changes how requests travel.

Web traffic for the public site is often proxied. Mail records are not. Verification records are not. Some subdomains that serve APIs or specialized tools should also stay DNS-only unless you have tested the full path carefully. If you want a quick rule, proxy the website and leave non-web services alone unless you have a reason to change them.

One common mistake is proxying everything because it looks tidy. It does not stay tidy for long. An MX record behind the proxy will fail. A verification hostname may stop being recognized by another service. A file transfer endpoint may behave strangely because it was never meant to pass through the web proxy.

Think in terms of function, not appearance. The website can be proxied for performance and security. Mail should usually stay DNS-only. If your setup includes tracking pixels, webhook endpoints, or third-party verification hosts, test each one separately.

Traffic that must remain plain DNS is often the traffic you least want to break. Keep that sentence in mind before you click the orange cloud too many times.

5. Update the domain’s nameservers at your registrar

Cloudflare will assign two nameservers for the domain. You replace the current nameservers at your registrar with those two values. This is the step that hands authority for DNS over to Cloudflare, so copy them exactly as shown.

At the registrar, find the nameserver section and remove the old pair. Then enter Cloudflare’s assigned pair. Save the change.

Do not panic if the site does not switch instantly. DNS changes are not synchronized on a single clock. A visitor may still reach the old path for a while, and that is normal. If the old DNS host remains live during the transition, you reduce the risk of failed lookups.

One short sentence here: be exact. A single character error in the nameserver entry can stop the delegation from working.

Also, do not change more than one moving part at the same time. If you rename records, switch hosts, and edit nameservers in one sitting, you make troubleshooting much harder than it needs to be.

6. Confirm the domain is active in Cloudflare and test real traffic paths

After the nameserver change, Cloudflare should show the domain as active. If it does not, the issue is usually one of three things: the registrar change was not saved, the nameservers were entered incorrectly, or the registrar still has cached data. Check those before you blame the origin server.

Then test real paths, not just the homepage. Open the main domain, the “www” version, a key subpage, and any important subdomains. If the site has a login page, test that too. If it has a file download or a form submission, test those actions. Pages can load while a hidden endpoint is broken.

This is where a monitoring tool helps. If you use a website analytics & monitoring platform, compare the first live requests after the switch with the normal pattern. A sudden rise in errors on one hostname is often the first sign that a DNS record or proxy setting needs attention.

Use a second browser or a private window for a clean test. Cached data can hide problems. So can an old login session.

If something fails, test the path from the domain outward: DNS, edge response, origin response, then application logic. That order saves time.

7. Set the first safe Cloudflare options for a new connection

Once the domain is active, keep the first settings conservative. Choose an SSL/TLS mode that matches what your origin can actually support, and do not guess. If the origin certificate is not ready, the browser may show errors or Cloudflare may refuse the connection. That is a bad surprise on launch day.

Basic security settings should be the next step. If you already care about website security, this is where Cloudflare begins to help beyond DNS. Start with the obvious controls, then test the site again. Aggressive tweaks can wait until you know the baseline behaves correctly.

Cache behavior deserves a careful first look too. A page that changes often should not be treated the same way as a page that barely changes. If you are unsure, keep the default behavior first, observe how the site responds, then make one change at a time.

One useful habit is to separate “safe now” from “nice later.” Safe now includes getting the SSL path right and confirming the site still opens. Nice later includes tuning cache headers or tightening rules once you have logs to read. That order prevents self-inflicted outages.

Keep this phase small. Small changes are easier to undo.

8. Verify edge cases: email, subdomains, redirects, and mixed-content issues

This is where many sites stumble. Email usually depends on DNS records that should remain DNS-only. Verify that MX records still point to the right mail host and that SPF, DKIM, or DMARC TXT records were preserved. If mail stops, the website may still look fine while business messages disappear.

Subdomains deserve their own checklist. A staging hostname, an image host, and an upload endpoint may each need different treatment. If one of them was proxied by mistake, you may see strange behavior only on that single hostname. That kind of bug wastes time because the homepage works.

Redirects can also expose mistakes. If the old site sent visitors from one hostname to another, test that path again after the switch. A redirect chain that used to work may now point at a hostname that was never added to Cloudflare. A single missing record can break the whole path.

Mixed-content problems appear when the site loads some assets over HTTP while the page itself is served over HTTPS. Browsers dislike that combination. Images may disappear, scripts may fail, and a form may stop submitting. Fix the source URLs at the application level, not just in the browser.

If your domain powers an website support after launch workflow, keep a short list of the most fragile hosts: mail, staging, uploads, redirects, and third-party verification. Those five areas are where the first tickets usually appear.

One final practical check: try the site from a network you do not normally use. A mobile connection can expose a cache issue or a DNS delay that your office network hides. Different paths reveal different problems.

And if you are connecting a site that already has strict operational demands, document every DNS record you touched. Not later. Now.