Cloudflare sits between your visitors and your server: it caches what it can, encrypts everything, and absorbs a lot of the junk traffic the open internet throws at any site. The free plan is genuinely enough for most sites. The setup is mostly pointing DNS — so if records and nameservers are fuzzy, read the DNS lesson first, because this whole move is one big DNS change. You’ll need your registrar login and about 45 minutes, most of it waiting.

Add your site and import DNS

Make a free account at Cloudflare, add your domain, and pick the Free plan. Cloudflare scans your existing DNS and imports what it finds — but scanners miss things. Before moving on, compare the imported list against your current records at your DNS host, record by record. Pay special attention to MX and TXT records: a missing A record breaks the site visibly, but a missing MX record breaks your email quietly, and you find out from a client days later.

Point your nameservers at Cloudflare

Cloudflare assigns you two nameservers. At your registrar (not your host — your registrar), replace the current nameservers with those two. Propagation usually takes under an hour, sometimes up to a day; Cloudflare emails you when the domain shows “Active.” Nothing about your site changes yet — the same records now just get answered by Cloudflare.

Set the SSL mode correctly (this is the footgun)

Go to SSL/TLS in the Cloudflare dashboard and check the encryption mode. The one you want is Full (strict): encrypted from visitor to Cloudflare, and encrypted from Cloudflare to your server, with a valid certificate checked on both legs. The trap is “Flexible,” which sounds harmless and means Cloudflare talks to your server over plain HTTP — on most CMS setups that produces an infinite redirect loop, and on all of them it sends your traffic across the wire unencrypted. If your server doesn’t have a certificate yet, fix that first with Let’s Encrypt, then set Full (strict). While you’re in this section, turn on “Always Use HTTPS.”

Start with conservative caching

Out of the box, Cloudflare caches static files — images, CSS, JavaScript — and passes HTML through to your server. Leave it that way for now. The “Cache Everything” style of rule is where the horror stories come from: cached HTML served to the wrong person means one visitor seeing another’s account page. Static-only caching gets you most of the speed with none of the drama. Earn your way into page caching later, deliberately.

Exempt logged-in and cart traffic from the cache

If you do move toward caching HTML, add a Cache Rule that bypasses cache whenever a session cookie is present, before any rule that caches pages. The cookie names to match: WordPress uses wordpress_logged_in_ and wp-settings-, WooCommerce adds woocommerce_cart_hash and woocommerce_items_in_cart, and Drupal sessions start with SESS (or SSESS over HTTPS). In Rules → Cache Rules, create a rule matching “Cookie contains” those names, with the action “Bypass cache.” Logged-in users and shoppers then always reach your real server, and everyone else gets the fast cached copy.

Verify with a cache-status header check

Cloudflare labels every response it handles. Ask for a static file twice:

curl -sI https://example.com/some-image.jpg | grep -i cf-cache-status

First request says MISS, second says HIT — caching works. Then check a page while logged in (browser dev tools, Network tab, look at the response headers): you want BYPASS or DYNAMIC, never HIT. Finally click through a login and, if you sell things, a cart. If those behave and the headers say what they should, you’re behind Cloudflare properly — faster for strangers, honest for the folks signed in.