When we ship a website for a small UK business, one of the first things we do after the DNS records are set up is point the domain at Cloudflare. It sits between the visitor and the actual server, and most clients never see it. They just get a faster site and fewer problems.

I'm writing this because I still meet small business owners who assume Cloudflare is for big tech companies with big budgets. It isn't. The free tier is genuinely useful, and the gap between "unprotected website on shared hosting" and "same website behind Cloudflare" is bigger than most people realise.

The assumption we hear most often

"Our site is small, nobody's trying to hack it."

This is consistently wrong, and every new client site proves it within a day of going live.

Within the first 48 hours of launching a brand new, unannounced business website, you can reliably expect:

Automated bot traffic hitting every page in your sitemap
Attempted logins to /admin, /wp-login.php, /phpmyadmin, and a dozen other paths that don't exist on your site
Form spam the moment a contact form is live
Attempts to exploit vulnerabilities in software you don't even run (WordPress, Drupal, outdated jQuery plugins)
Content scrapers pulling your pages to resell, train AI models, or build spam sites

None of this is personal. It's all automated, running against entire IP ranges on a schedule. The attackers don't know or care who you are. Their tools just walk the internet looking for unpatched vulnerabilities, and your domain ends up on the target list the moment DNS starts resolving.

Cloudflare stops most of this at the door, before it ever reaches your actual server.

What Cloudflare actually does, in plain English

Stripped of marketing language, there are five things Cloudflare gives you that matter for a small business site. Taking them one at a time.

1. It blocks the bots before they reach your server

This is the headline feature. When you turn on Cloudflare's proxy for your domain, every request to your site hits Cloudflare's network first. They look at the request, check it against their bot detection, and either:

Let it through if it looks like a real human (or a legitimate bot like Googlebot)
Challenge it with a puzzle if it looks suspicious
Block it outright if it's from a known bad IP or matches a pattern they trust

For a small site, the bot-to-human ratio is often 3:1 or worse. Every request Cloudflare handles is one less request your real server has to process, one less entry in your logs, one less attempt at brute-forcing a login form that may or may not exist.

On the free tier you get the core bot detection. Paid tiers give you more granular rules, but for most small business sites the free version already catches the vast majority of automated traffic.

2. It gives you a Web Application Firewall for free

The Web Application Firewall (WAF) is the layer that spots patterns in requests and blocks attacks that would otherwise reach your code. Cross-site scripting attempts, SQL injection in URL parameters, weird encoded payloads that target CMS vulnerabilities.

Even if you've written perfectly safe code (we try), the WAF is a second line of defence. If a zero-day drops for your CMS, your framework, or a library you depend on, the WAF often blocks the exploit attempts before a patch is even available. You get several days of cover while you work out what's going on and push a fix.

The free tier WAF covers the OWASP Top 10 and general nonsense. It's not as granular as the paid tiers, but for a brochure site or a simple ecommerce store, it's enough.

3. Free HTTPS with auto-renewing certificates

Every site deserves HTTPS. Google ranks HTTPS higher, browsers flag HTTP sites as "Not Secure", and a chunk of your visitors will bounce immediately if they see that warning.

The old way was to buy an SSL certificate, install it on your server, set calendar reminders to renew it, and hope you didn't forget. The new way, with Cloudflare, is to toggle a switch and forget about it. Cloudflare manages the certificate, renews it automatically, and serves it over modern TLS.

You can go further if you want (Full Strict mode with a certificate on your origin server too, which is what we do for client sites), but even the simplest setting gives you working HTTPS in about five minutes.

4. Global CDN and smart caching

Cloudflare runs data centres in roughly 300 cities worldwide. When your site sits behind their network, a visitor in Edinburgh hits a Cloudflare server in Edinburgh, not your shared hosting box in the Home Counties.

For static assets (images, CSS, JavaScript, fonts) this means near-instant loads for repeat visitors and substantially faster first loads for anyone outside the UK. For a small UK business with a UK-only audience the international boost matters less, but the caching benefit still applies because Cloudflare stores copies of your assets at every edge location and serves them without hitting your origin server.

The effect on Core Web Vitals is real. We've seen Lighthouse Performance scores climb five to fifteen points just from moving a site behind Cloudflare's CDN, without changing a line of code on the site itself. That translates directly into better search rankings because Core Web Vitals feed into Google's ranking signals.

5. DNS hosting with analytics you can actually read

Cloudflare is also a DNS provider. You move your nameservers to them, and you get a clean dashboard for managing records, fast DNS resolution, DNSSEC if you want it, and basic traffic analytics.

The analytics are the quiet win here. Without installing any JavaScript on your site (which means no cookie consent banner, no GDPR worries), you can see how many requests you're getting, how many bots were blocked, where your traffic is coming from, and what the most-hit pages are. For a small business that doesn't want to deal with Google Analytics setup, Cloudflare's free analytics give you a solid baseline overview.

How we actually set it up

For most client sites, the initial setup takes about fifteen minutes and costs nothing. The short version:

Sign up for a free Cloudflare account at cloudflare.com
Add your domain. Cloudflare scans your existing DNS records and imports them automatically.
Update your nameservers at your domain registrar to point at Cloudflare's nameservers. This is the only step that requires changes outside Cloudflare. Depending on your registrar, it takes anywhere from five minutes to a few hours for the change to propagate.
Once Cloudflare says "Active", turn on the proxy (the orange cloud icon) for your web records. This is what routes traffic through Cloudflare's network.
Set SSL/TLS to "Full (Strict)" if your origin server has its own certificate, or "Full" if you're relying on Cloudflare's cert alone.
Turn on "Always Use HTTPS" so that anyone who hits http:// gets redirected to https://.

That's the baseline. Everything else (page rules, firewall rules, rate limiting, custom error pages) is optional and can be added later.

The gotchas no one warns you about

Cloudflare is excellent but it isn't magic, and there are real things that will catch you out. Better to hit them in daylight than during a panic.

Cloudflare only proxies HTTP and HTTPS traffic

This is the big one, and it's what bit us when we set up automated deploys to our own site. Cloudflare's proxy works for web traffic on ports 80 and 443. It does not proxy FTP, SSH, SMTP, or any other protocol.

If your domain's A record is proxied (the orange cloud icon in the dashboard) and you try to FTP into yourdomain.co.uk, the connection will silently time out. The FTP client is resolving your domain to a Cloudflare IP, and Cloudflare's proxy drops the connection because it isn't serving FTP on that address.

The fix is to create a separate subdomain (for example, ftp.yourdomain.co.uk) with its A record pointing directly at your origin server, and the proxy status set to DNS only (the grey cloud icon, not the orange one). This bypasses Cloudflare for FTP while keeping the main domain fully protected.

We learned this by debugging our own GitHub Actions deploy pipeline for zimdigital.co.uk earlier this week. We fixed it in about a minute once we recognised the pattern, but the error messages from the FTP client are unhelpful, so it's worth knowing in advance.

Email is separate from the web

If your email is hosted on the same domain as your website (which is common for small businesses), your MX records should be left unproxied. Cloudflare's proxy doesn't do SMTP, and it will break mail delivery if you accidentally enable it on the wrong records.

Most of the time Cloudflare gets this right automatically because MX records can't be proxied in the first place. But if you ever see an orange cloud next to an A record that an MX record resolves to, that's a problem worth looking at.

Cached content can surprise you during development

When you first move a site behind Cloudflare, the cache starts doing its job. If you've had development habits that relied on "just refresh the page and see the change", those habits don't work any more. You either purge Cloudflare's cache (a single button in the dashboard, takes about five seconds) or serve a new version from your origin.

The fix is either better cache headers on your origin so Cloudflare respects them, or a development workflow that includes a cache purge after each deploy. We have a cache purge step built into our CI pipeline for clients where this matters.

Plesk shared hosting and FTPS are a known headache

For the specific case of clients on HostingUK or other Plesk-based shared hosts, we've had to fall back to plain FTP (not FTPS) for our deploy pipeline. Plesk's FTPS implementation breaks TLS session resumption on the data channel. The workaround is plain FTP on port 21 with regular credential rotation, rather than battling the TLS issue.

Cloudflare itself doesn't cause this, but it compounds the problem because the Cloudflare proxy also needs to be bypassed for FTP. Two separate issues that happen to intersect. If you're setting up CI for a Plesk-hosted site behind Cloudflare, this is what you'll hit. Solving it took us about twenty minutes once we understood both pieces.

Does the free tier actually cover a small business site?

Yes, almost always. We put every new client site on the free tier to start, and only upgrade to a paid plan if there's a specific need the free tier doesn't cover. The things that tend to justify a paid upgrade:

High traffic volumes. The free plan has generous limits but unusual traffic patterns can hit them.
More granular WAF rules, for sites handling sensitive data or payment information.
Image optimisation (Cloudflare Polish, resize on the edge) if the site is image-heavy.
Higher-priority support if the site is business-critical and downtime genuinely costs money.

For a brochure site, a booking form, a basic ecommerce shop, or even a moderately busy blog, the free tier is sufficient for years. Cloudflare's business model is built on the assumption that a tiny percentage of free users will eventually need paid features. The rest of us get genuinely excellent tooling for free.

Our recommendation

If you run a small UK business with a website, put it behind Cloudflare. If you've inherited a site that isn't behind Cloudflare, move it. It's roughly fifteen minutes of work, it's free, and it will:

Block most automated attack traffic before it reaches your hosting
Give you free HTTPS with auto-renewing certificates
Make your site measurably faster for visitors outside your immediate region
Give you basic analytics without installing cookies
Protect you from several classes of vulnerability you don't even know you have

There's no scenario where not using Cloudflare is better than using it for a small business site, unless you have very specific requirements that the free tier doesn't handle (which is rare).

Want help setting this up?

If you'd like us to set up Cloudflare for your site, audit an existing configuration, or bundle it into a wider hosting and cloud infrastructure review, get in touch. We manage Cloudflare configurations for every client site we build as part of ongoing delivery, and it's the kind of job that takes an afternoon rather than a week. We're software developers in Wigan serving Northwest UK and the wider UK, and this is exactly the sort of practical, unglamorous work that keeps a small business site healthy.

Why we put every client site behind Cloudflare