What is Cloudflare?
Cloudflare is an intermediary layer that takes over your domain's DNS management and routes visitor requests to your origin server through its own network. Technically, it's a reverse proxy: the visitor doesn't connect directly to your site's server but to a Cloudflare data center geographically close to them. The request is inspected there; if it can be served from cache, it's served from there, and if not, it's forwarded to your server.
It isn't a single product but three functions managed from the same dashboard: authoritative DNS for your domain, a content delivery network (CDN) that distributes static files, and a security layer that filters incoming traffic. The network spans more than 300 cities, so the phrase "nearby server" genuinely describes a nearby location for most countries.
Cloudflare is not a hosting service. Your site files stay on your own server; Cloudflare is the traffic layer that sits in front of that server. Adding a domain and switching nameservers doesn't mean moving the site to Cloudflare.
How does traffic flow through Cloudflare?
The only thing that determines the flow is the proxy status of your DNS records. In the dashboard, there's a cloud icon next to every A, AAAA and CNAME record. If the icon is orange, the record is proxied: DNS queries for that name return Cloudflare's anycast IP addresses instead of your server's real IP address, and HTTP traffic passes through the network. If the icon is gray, the record is in DNS-only mode, the query returns your origin IP address and traffic never touches Cloudflare.
This distinction leads to the most practical rule of the setup: records that carry web traffic should be proxied, and those that don't shouldn't be. For proxied records, your origin IP address is hidden and firewall rules and caching kick in. Every DNS-only record, on the other hand, exposes your origin IP address to anyone who queries it and removes a layer of protection against targeted attacks.
There's a common misunderstanding about caching. By default, Cloudflare caches based on file extension rather than MIME type, and with default settings it doesn't cache HTML or JSON content. Images, CSS, JavaScript, fonts, PDFs and archive files are served from edge servers; the page HTML is fetched from your server on every request. If you also want HTML cached, you have to enable it with a separate cache rule, and that decision comes with its own costs: we cover where aggressive cache settings backfire separately.
What does the free plan actually cover?
The free plan isn't a trial period; it's a permanent tier. It includes authoritative DNS, unmetered DDoS protection, the CDN, a Universal SSL certificate and the free managed firewall ruleset. It doesn't ask for a credit card and has no time limit.
What's excluded is clear too. Lossless image optimization, extended security rulesets and an uptime commitment are reserved for paid tiers. The Pro plan costs $20 per month billed annually or $25 billed monthly; the Business plan is around $200 per month billed annually or $250 billed monthly. That difference usually can't be justified for a small corporate site. The sensible route is to start with the free plan and upgrade when the need becomes concrete.
A notable detail: HTTP/3 support isn't tied to a paid tier; it's a setting you can turn on from the dashboard on the free plan as well. That makes the protocol-level gain independent of budget. We explain what HTTP/3 and QUIC change in a separate guide.
Setting up Cloudflare step by step
The setup doesn't require writing code; the core of the job is handing your domain's authoritative nameservers over to Cloudflare. The sequence goes like this:
- Create a Cloudflare account and add your domain in its root form from the dashboard (without www, in the form example.com). When choosing a plan, Free is enough.
- An automatic scan imports your existing DNS records into the dashboard. This scan isn't guaranteed to find every record, so compare the list one by one with the records at your old provider. A missing record stops that service from resolving the moment the handover completes.
- Keep records that carry web traffic proxied, and keep email and domain verification records in DNS-only mode.
- If DNSSEC is enabled on your domain, disable it in your registrar's dashboard before changing nameservers. If you skip this step, the domain may become unreachable.
- Enter the two nameserver names Cloudflare gives you in your registrar's dashboard in place of the old nameservers. The names must be copied exactly; a one-letter difference breaks resolution.
- Wait for propagation. Cloudflare allows up to 24 hours for this. When the domain is activated, its status shows as Active in the dashboard and you receive a notification email.
- Once the domain is active, turn DNSSEC back on, this time from the Cloudflare dashboard.
If you want to see whether the handover is really complete without waiting, you can query from your own machine:
dig ns example.com @1.1.1.1
whois example.comIf the query returns Cloudflare's nameservers, the delegation is in place. Browser-based DNS checker sites show cached results, so a direct query gives a more reliable answer.
Why is the SSL/TLS mode so often set wrong?
Cloudflare manages two separate connections at once: the connection between the visitor and Cloudflare, and the connection between Cloudflare and your origin server. The encryption mode determines how the second one is established. For new domains, the default is Automatic SSL/TLS; Cloudflare scans your site with its own checker and tries to choose the appropriate mode.
The problematic mode is Flexible. In this mode, Cloudflare connects to your origin server over unencrypted HTTP. If your server automatically redirects HTTP requests to HTTPS, which most modern setups do, a closed loop forms: Cloudflare turns the request into HTTP, the server sends it back to HTTPS, and after a while the browser throws an ERR_TOO_MANY_REDIRECTS error. The site suddenly becomes completely inaccessible, and Cloudflare is rarely the first place anyone looks for the cause.
There are two ways to fix it: either remove the HTTPS redirect on the origin server, or raise the mode to Full or Full (strict). Cloudflare recommends using Full or Full (strict) to block malicious connections to the origin server, which requires a valid certificate on the server. The same loop is possible in reverse: if the mode is Full and the server redirects HTTPS requests to HTTP, the error appears again. After setup, checking the certificate and security headers end to end catches this class of error early.
Email records and the origin IP address
MX and TXT records can't be proxied; Cloudflare always keeps these types in DNS-only mode. So you can't turn the cloud orange on an MX record in the dashboard anyway. The real breaking point is elsewhere: if the A record of the mail server name your MX record points to (usually a subdomain like mail.example.com) is proxied, that name resolves to Cloudflare IP addresses and mail traffic can't find its destination. Cloudflare's own setup documentation shows this A record in DNS-only mode.
This has a hidden cost. Every DNS-only record exposes your origin server's real IP address to everyone. If your mail server is on the same machine as your web server, an attacker can find the IP address from the mail record and go directly to the server, bypassing the proxy layer. Moving mail traffic to a separate IP address or an external mail provider closes this gap, and it's a step that shouldn't be neglected on corporate sites.
What do you gain and risk on the SEO side?
The mechanism on the gain side is clear. Because static files come from an edge server geographically close to the visitor, load time shortens, and the difference is most visible on sites whose server is in a single country but that receive visitors from abroad. Google's crawler notices this too: the faster and more consistently a site responds, the more crawl volume rises. For teams working on page speed, the network layer is the infrastructure side of the effort to bring LCP time down.
The risk side gets talked about less, and it's entirely configuration-driven. It can be grouped under three headings.
Overly strict bot rules. Google's own documentation says crawl rate is reduced when a site returns 5xx server errors or rate-limiting signals such as HTTP 429. If an aggressive rate limit or custom firewall rule you write on the Cloudflare side returns these signals to a search engine crawler, your crawl volume quietly shrinks. Cloudflare states that it keeps verified bots out of its default bot configurations, so no problem is expected out of the box. The risk arises in the rules you write by hand.
Bot Fight Mode can't be bypassed. This feature, which can be enabled on the free plan, can't be bypassed with custom firewall rules or page rules. Because it runs in a separate evaluation pipeline, Skip and Allow actions don't apply to it, and it can send challenges to API and mobile app traffic. If you have traffic you need to make exceptions for (your own API clients, your monitoring tools), you need to switch to Super Bot Fight Mode, which runs on the rules engine. If you use a service that monitors your site from outside, verify right after setup that your uptime monitoring tool isn't getting caught by this filter.
AI bot policies. Cloudflare divides AI bots into three groups by behavior: Search, which indexes your content to answer questions later; Agent, which acts in real time on behalf of a user; and Training, which trains models. Each group can be blocked separately. Blocking the Search group directly cuts the chance of your content being used as a source in AI answers; so if you meant to stop only training crawlers and ticked the wrong box, the mistake is reversible but easy to miss. Cloudflare has announced that it will change the default for new domains added after September 15, 2026: bots in the Training and Agent classes will be blocked on pages that show ads, while the Search class will remain allowed. Make sure to review this screen after setup.
Who needs Cloudflare and who doesn't?
The need is clear in these profiles: sites where a significant share of visitors are in a different country or continent from the server, e-commerce and news sites with a large attack surface, projects running on a single server that struggle at traffic peaks, and corporate sites that want to hide their origin IP address. In these profiles, even the free plan makes a measurable difference.
Others don't need it. Sites hosted on a managed platform that includes its own delivery network in the service needlessly complicate caching behavior when they add a second proxy, and debugging becomes harder. On a small brochure site whose visitors are all in a single city, the speed gain may not be noticeable. For organizations whose corporate policy requires keeping DNS management at their own registrar, handing over the nameservers would be a forced fit.
You can reduce the decision criteria to three questions: are your visitors geographically spread out, do you have a single server, and does your site receive regular bot traffic? If you answer yes to at least one, the layer pays off. If the answer to all three is no, there's no urgency, and it's wiser not to disturb your current setup.
Frequently Asked Questions
Does Cloudflare replace hosting?
No. Your files stay on your own server; Cloudflare is the DNS and traffic layer that sits in front of that server. The two complement each other; one doesn't replace the other. Although Cloudflare has separate products for running applications, adding a domain is not the same as using those products.
Can Cloudflare WARP be installed on my site?
No, because WARP is a separate product designed for end users, not site owners. It's installed on a phone or computer and carries that device's internet traffic over the Cloudflare network. It often gets mixed up with Cloudflare's site services because it shares the brand name. You don't need WARP to speed up and protect your site.
Does changing nameservers cause downtime?
The risk of downtime comes not from the change itself but from missing records. Cloudflare notes that if the domain is activated without the correct records defined, visitors may get resolution errors. That's why taking a screenshot of the old dashboard's record list before switching nameservers and comparing the new list line by line is practical insurance. The second risk is DNSSEC: a handover done without disabling it can leave the domain completely unreachable.
Is it possible to move away from Cloudflare later?
Yes, and the process is the reverse of the setup. You change the nameservers back to their old values in your registrar's dashboard, and once propagation completes, traffic goes directly to your server without touching Cloudflare. Check two things before switching back: your current DNS records must also exist at the old provider, and if DNSSEC is enabled on the Cloudflare side, it must be disabled before the handover. Otherwise, the domain won't resolve during the transition.
