Most Cloudflare Migration Problems Aren't Cloudflare's Fault
Every time someone tells me Cloudflare "broke" their site, the actual cause is almost always the same handful of things: a DNS record that didn't get carried over, an SSL setting that was never adjusted after the switch, or a caching rule that started serving the WordPress dashboard a page meant for a logged-out visitor. Cloudflare itself is reliable. The migration is where things go wrong, and it goes wrong in predictable, avoidable ways. Here's the order that actually works.
Step 1: Audit Every DNS Record Before You Touch Anything
Before you create a Cloudflare account, go into your current DNS provider and write down — literally, in a spreadsheet or a text file — every A record, CNAME, MX record, and TXT record currently in your zone. This includes the obvious ones pointing to your website, but also the easy-to-forget ones: email routing (MX), SPF and DKIM records for email authentication, subdomains for anything else you run (a staging site, an app, a third-party tool verification record). Cloudflare will scan and try to auto-import your existing records when you add your domain, and it's usually accurate, but "usually" isn't good enough here. Treat the scan as a draft, not the final answer, and check it line by line against what you wrote down first.
Step 2: Add Your Site to Cloudflare
Create a Cloudflare account and add your domain. Cloudflare will scan your current DNS and present you with an imported record list. This is the point where you compare that list against your own audit from Step 1 — not after you've already switched nameservers, when a missing record means active downtime instead of a quick fix.
Step 3: Set the Right Proxy Status on Every Record
Every DNS record in Cloudflare has a toggle between "proxied" (the orange cloud icon) and "DNS only" (the grey cloud icon). Proxied means traffic to that record routes through Cloudflare's network first — that's how you get the CDN, the caching, and the security features. DNS-only means Cloudflare just answers the DNS query and traffic goes straight to the origin, with none of those benefits.
Your main site record (usually the A record for your root domain and the www subdomain) should typically be proxied. Your MX records — the ones that route email — should almost always be DNS-only. Proxying is built for web traffic, not mail routing, and email records don't work correctly when it's toggled on. This single setting is the source of a lot of "why did my email stop working" support tickets.
Step 4: Update Your Nameservers at the Registrar
Once every record is verified and the proxy settings are correct, Cloudflare will give you two nameservers to set at your domain registrar (Namecheap, GoDaddy, Google Domains, wherever the domain itself is registered — this is a different login than your hosting account). Replace whatever nameservers are currently listed with the two Cloudflare provides. This step is what actually activates the migration; everything before it was preparation.
Propagation isn't instant. It can take anywhere from a few minutes to about 48 hours for the change to fully reach every DNS resolver worldwide, though most visitors see the switch within a couple of hours. Cloudflare will notify you once it detects the nameserver change and activates your zone.
Step 5: Set the Correct SSL/TLS Encryption Mode
This is the step that causes the most confusion, and the most support tickets. Cloudflare has four SSL/TLS modes, but for a WordPress site there are really only two worth considering: Full and Full (Strict). Both encrypt the connection between Cloudflare and your origin server, with Full (Strict) additionally validating that your origin's SSL certificate is legitimate and not expired.
What you want to avoid is Flexible mode. Flexible encrypts the connection between the visitor and Cloudflare, but connects to your origin server over plain, unencrypted HTTP. If WordPress is also configured to force HTTPS — which most sites are, correctly — you end up with Cloudflare and WordPress each redirecting the request to HTTPS in a way that creates an infinite redirect loop. If your site suddenly won't load and the browser reports "too many redirects" right after a Cloudflare migration, this is almost always why.
Step 6: Configure Caching Rules for WordPress Specifically
Cloudflare's default caching behavior is built for static content, not a dynamic CMS with logged-in sessions. Without adjustment, it's possible for a cached page to be served to a logged-in administrator, or for the WordPress dashboard itself to get cached and served incorrectly to a different visitor. Set up cache rules (or page rules, depending on your Cloudflare plan) that explicitly bypass caching for wp-admin, wp-login.php, and any cart, checkout, or account pages if the site runs WooCommerce or handles logged-in user sessions. Everything else — static pages, images, CSS, JS — can generally be cached aggressively, which is where most of the real performance gain comes from.
Step 7: Turn On Security Features, Then Test Immediately
Cloudflare's Web Application Firewall and bot protection features are genuinely useful, but they're also the most common cause of "why isn't my contact form working" after a migration. An overly aggressive WAF rule or bot-fight setting can flag legitimate form submissions or login attempts as suspicious traffic. Turn these features on, then immediately test your own contact form, your login page, and checkout flow if applicable, from a normal browser — not just an admin session that might already be whitelisted. Catching a false positive in the first ten minutes is a lot easier than catching it after a week of silently lost leads.
Step 8: Verify Before You Consider It Done
Once nameservers have propagated, don't just glance at the homepage and call it finished. Check that the site loads correctly, confirm there are no mixed-content warnings in the browser console (a sign that some assets are still loading over HTTP), and send yourself a test email to confirm mail flow wasn't disrupted by the DNS change. Keep an eye on the site for the first 48 hours in particular — that's the window where any missed record or edge case is most likely to surface.
If You'd Rather Not Run This Yourself
Every site on a CriticalWP managed plan already runs behind Cloudflare Enterprise CDN as part of the base plan — the DNS audit, proxy configuration, SSL mode, and WordPress-specific caching rules are handled as part of onboarding, not something you're left to configure and troubleshoot on your own. If you're weighing whether to run this migration yourself or hand it off, the Managed Stability plan is where that oversight starts.
