Five Cloudflare settings that can quietly break your website

Cloudflare is an excellent place to host a website, and we host ours there. But several of its features work by changing your pages as they are served, or by changing your DNS during setup. When you have tuned a site carefully, those changes can undo the work without any error you would notice.

These are the five we dealt with when we moved tuwastudio.com in September 2026: four caused real problems, and one we made sure was off before it could. Dashboard menus move around, so for each one the quickest route is to search the dashboard for its name.

1. Email Address Obfuscation

What it does: finds email addresses in your pages and replaces them with a scrambled link plus a small script that unscrambles them in the visitor’s browser. The aim is to hide addresses from spam harvesters.

What it broke: every mailto: link on our site. For a studio whose main call to action is an email address, that is the worst possible place for a script to sit. A visitor whose browser blocks the script sees a placeholder instead of the address, and it added a script our security policy hadn’t approved.

Where to turn it off: open your domain, search the dashboard for Email Address Obfuscation, and switch it off. On older dashboards it sits under Scrape Shield.

2. Real User Monitoring

What it does: adds Cloudflare’s analytics beacon to every page, to measure how fast pages load for real visitors.

What it broke: our Lighthouse best-practices score, which fell from 100 to 93 on every page. Our content security policy correctly blocked the injected script, and the browser logged an error each time. The analytics never worked, and the error cost us points.

It was also the hardest to find. We had already switched off Web Analytics in two other places, for the Pages project and for the account, and the script kept appearing. It only appeared on the custom domain, never on the pages.dev address, and only in requests that looked like a real browser, so a quick check from the command line missed it.

Where to turn it off: your domain’s Speed → Real user monitoring, then Disable completely.

3. Rocket Loader

What it does: rewrites your script tags so scripts load after the page, to speed up sites with a lot of JavaScript.

Why it matters to a site like ours: if your site uses a content security policy with script hashes, Rocket Loader changes the scripts the hashes describe, and the browser blocks them. On a site with little JavaScript it has almost nothing to speed up anyway.

What we did: made sure it was off before launch, as part of setting up the domain. Search the dashboard for Rocket Loader and check it, even if you never turned it on.

4. The DNS import that misses records

What it does: when you add a domain, Cloudflare scans your existing DNS and imports what it finds, so you don’t have to type your records in by hand.

What it missed: both of our DKIM records, the records that prove our email really comes from us. They sit at names like secureserver1._domainkey, and a scan can only find names it knows to look for. Had we switched nameservers without checking, our mail would have started failing authentication, and messages would have landed in spam or been rejected.

How to check: before changing nameservers, export the zone file from your current DNS provider and compare it line by line with Cloudflare’s imported list. Better still, query Cloudflare’s assigned nameservers directly before the switch: they already answer for your domain, so you can confirm every record matches while your old DNS is still live.

5. Proxied mail records

What it does: by default, the import marks some records as proxied (the orange cloud), meaning traffic goes through Cloudflare rather than straight to the server.

What it broke, nearly: our webmail record was imported as proxied. Mail-related records must be DNS only (the grey cloud), because Cloudflare’s proxy only handles web traffic. A proxied DKIM or mail record stops working.

How to check: in DNS → Records, every MX, SPF, DKIM, DMARC and mail-related record should show a grey cloud.

A five-minute check for your own site

1. Open your site, view the page source, and search for email-protection, cloudflareinsights and rocket-loader. Any hit means a feature is rewriting your pages.
2. Open your browser’s developer console on a few pages and look for security policy errors.
3. In Cloudflare’s DNS list, make sure every mail record is grey.
4. Send a test email to a Gmail address and check the message headers for dkim=pass.

None of these features is bad. They just make decisions for your site that you might not make yourself, so it is worth knowing they are there.

If your site has picked up scripts it shouldn’t have, or got slower after a hosting move, our speed fix starts with exactly this kind of audit.