The Cloudflare setup itself takes about ten minutes. What takes a small site down is almost never Cloudflare — it is one of three settings changed in the hours after the nameserver switch: SSL mode left on Flexible, HTML pushed through Cache Everything, or a record proxied that should have stayed grey.

The order of operations matters more than any checkbox. Do it in this sequence and the site stays reachable throughout, including the day you switch nameservers.

The short version

• Export your DNS zone and compare it against what Cloudflare imports before you change nameservers.
• Lower the TTL on your A record a day ahead so a mistake costs five minutes, not twenty-four hours.
• Set SSL/TLS to Full (strict) before go-live. Flexible is the most common way to break a WordPress site.
• Keep mail, webmail and any untested subdomain on grey cloud (DNS only).
• After the switch, run five checks — including an admin login and a form submit — before you walk away.

Before you touch the nameservers

The nameservers are the last step, not the first. First make sure Cloudflare knows every record your domain actually uses.

Export the zone from your registrar or host’s DNS editor. Watch for what people forget: the MX records pointing at your mail server, SPF and DKIM TXT records, and any subdomain something else depends on — webmail, cPanel, an API endpoint, a verification record.

Then add the site in Cloudflare and let it scan. It reliably finds A and CNAME records and usually picks up MX, but it is weaker on SRV records, some TXT values, and subdomains it cannot guess. Compare the imported list line by line against your export. A missing record is invisible now and becomes a dead mailbox or broken subdomain the moment you switch.

Leave every record grey for now; you will turn website records orange one at a time.

Finally, drop the TTL on your main A record to 300 seconds and wait a day. If something goes wrong mid-migration you can point traffic back in five minutes instead of waiting out a cached day — the same logic I use when moving a site between hosts, covered in how to move a WordPress site without downtime.

The SSL setting that takes sites down

This is the one worth reading twice. Cloudflare’s SSL/TLS mode describes how Cloudflare talks to your origin, not how visitors talk to Cloudflare. Visitors always get HTTPS; the mode decides the second leg of the trip.

• Flexible — Cloudflare fetches from your server over plain HTTP. If the host forces HTTPS (most do), every request comes back as a redirect, Cloudflare follows it, the browser asks again, and you get an endless loop — the ERR_TOO_MANY_REDIRECTS everyone posts about. The trip to your server is also unencrypted, which defeats most of the point.
• Full — HTTPS to your server, but the certificate is not checked, which hides a problem instead of fixing it.
• Full (strict) — HTTPS with the certificate validated against the hostname. This is what you want, and it needs a valid certificate on the origin; a Let’s Encrypt certificate from your host’s panel is enough and renews itself.

Set Full (strict) before you switch nameservers. If your host already provisions a valid certificate, nothing else is needed. If not, install one first — either through the hosting panel, or a Cloudflare Origin CA certificate, which is issued for this leg specifically and is trusted by Cloudflare and nothing else. It is the right tool when your host makes free certificates awkward.

On the same page, turn on Always Use HTTPS and Automatic HTTPS Rewrites. The rewrites stop mixed-content warnings from images and scripts still loaded over http://. They do not repair URLs stored in your database — that needs a search and replace — but they stop the visible breakage.

If the site is already down, the error code narrows it fast. 525 means the TLS handshake with your origin failed, usually no certificate for that hostname. 526 means a certificate exists but is rejected: expired, self-signed under strict mode, or issued for a different name. 521 and 522 mean the origin refused or timed out — a server problem, not a certificate one. A 500 instead points at your host, and what HTTP 500 actually means will find it faster than guessing.

What to cache, and what to keep out

By default Cloudflare caches by file extension: images, CSS, JavaScript, fonts. That default is safe for WordPress and it is where most of the speed gain on a small site comes from.

The trouble starts with Cache Everything, a rule that tells Cloudflare to cache HTML too. On a brochure site that never changes, fine. On WordPress it is a trap: the same URL serves a logged-in administrator, a logged-out visitor and a customer with items in a cart. Cache the HTML and one of them gets somebody else’s page — usually the logged-out version, which is why people report being randomly logged out of /wp-admin.

If you do want HTML cached, add two exclusions to the same rule: bypass for /wp-admin and /wp-login.php, and bypass when the request carries the wordpress_logged_in_ cookie. That cookie check is what keeps the cache from logging people out.

Two more traps: subdomains like webmail. or cpanel. often break when proxied because they expect a direct connection or an unproxied port — leave them grey. And mail records stay grey always, because proxying mail does not work.

The three settings behind most outages

Under Attack Mode deserves its own warning. It is a five-second interstitial meant for an active flood, and people leave it on just in case. It breaks the REST API, form submissions and any scripted client, and it looks like a broken site to a real visitor. Turn it off when the attack ends and rate-limit instead.

The five checks before you walk away

These tell you what is actually happening.

# 1. Is traffic going through Cloudflare?
curl -sI https://yourdomain.com | grep -i cf-ray

# 2. Which datacentre answered, and over which protocol?
curl -s https://yourdomain.com/cdn-cgi/trace

# 3. Is the origin certificate valid for this hostname?
curl -sI https://yourdomain.com --resolve yourdomain.com:443:ORIGIN_IP

A cf-ray header means the proxy is live. Nothing printed means you are still hitting the origin directly. Then do the two things a terminal cannot test: log in to /wp-admin, edit a post and save it — that exercises cookies, POST and the admin path at once. Submit your contact form and confirm the email arrives, which tests the mail path. Last, load the site on mobile data; your laptop may be holding a cached DNS answer that hides the truth.

When not to use the orange cloud

Cloudflare is not automatically faster. If your pages are almost entirely dynamic, your host is already close to your visitors and caching only covers a logo and a stylesheet, the extra hop can cost more than it saves. Measure it: run your normal load test before the switch and again a week after, following how to test hosting speed properly, and compare time to first byte rather than a single ping.

The reasons to keep it anyway are not speed: free TLS that renews itself, DNS that resolves fast and survives a flood, and a firewall in front of a server you do not have to harden alone.

Do this today

Export your DNS zone and lower the TTL on your main A record to 300 seconds. That is the whole task for today — the nameserver switch can wait until tomorrow, when a mistake costs five minutes instead of a day.

Then set Full (strict) first, proxy one record at a time, and run the five checks before you close the laptop. That order is the difference between a quiet migration and an evening spent chasing redirect loops.