This page exists for the people who ask what do you really do in Cloudflare. It walks through the rules, traps, and alerts I use on real sites, in language a manager or trustee can follow.
If you just want the outcome, the summary is simple. Good visitors get through smoothly, junk traffic is filtered, suspicious visitors are logged and challenged.
Owners, trustees, digital leads, and the occasional curious tech who want to see how security work is done rather than just reading the words managed service.
I do not ask anyone to take security on trust. When I notice odd or repeat traffic on my own projects, I document it publicly so you can see the standard I work to.
Read the NPA traffic spike monitoring evidence
It shows that I watch ASNs, sources, and routes. It shows that I can separate normal interest from quiet monitoring. It shows that I keep a clear timeline.
If I can spot, log, and explain that behaviour on my own platform, I can set up your site so that you have similar visibility, just kept private and written for your context.
Cloudflare rules and Workers, honeypot routes, Discord alerts, and clean analytics that strip out obvious junk. No magic, just consistent attention and good notes.
You can share that article with a board or manager as an example of how Ki-Ki treats evidence and explanation.
These are simplified patterns based on real work. Values change per client. The idea stays the same. Each rule aims to protect something specific, not to look clever.
Tight control over sensitive routes like logins and admin tools.
(http.request.uri.path contains "/wp-login.php"
and ip.geoip.country ne "GB")Plain English: if someone tries to reach the WordPress login from outside the country you actually work in, they get challenged or blocked. Real staff use known locations or a VPN you trust.
Respect good crawlers, slow down the noise.
if (cf.bot_management.score <= 20)
action = ManagedChallengePlain English: if Cloudflare is very confident it is an automated tool rather than a person, we make it solve a challenge. Good bots pass, low quality scraping tools usually do not bother.
Hidden paths that only scanners find.
(http.request.uri.path eq "/.well-known/scan"
or http.request.uri.path eq "/old-admin")Plain English: if anything touches these routes, it is not a normal visitor. We log it, alert if needed, and can block that source earlier next time.
Let the edge deal with junk instead of your server.
if (country not in ["GB","IE"]) {
return new Response("Not available in your region", {
status: 403
});
}Plain English: if your service is meant only for people in certain areas, requests from elsewhere never reach your hosting. They are handled at the edge with a clear response.
I sit your site behind a smart front gate. Real visitors get in quickly. Suspicious requests are slowed, challenged, or blocked. You get a clear record of what happened.
Most small sites receive more junk than genuine traffic. Without filtering, your analytics lie to you, your hosting works harder than it should, and problems are harder to spot.
You can show a short monthly summary. For example: how many requests were blocked, where they came from, which rules did the work, and what changed as a result.
If we work together, I take this pattern and scale it to your size and risk. No generic preset. Just rules that make sense for who you are and who might take an interest in you.
Keeps sites and logins calm, removes a lot of junk from contact forms, and gives you reliable analytics for marketing spend.
Shows care with data, reassures trustees, and produces simple reports that can be attached to funding bids or internal risk registers.
Catches quiet monitoring from organisations you write about and gives you documented evidence if you ever decide to talk about that behaviour.
Tell me what you are seeing, even if it feels vague. Odd referrers, strange spikes, repeated visits from somewhere that does not make sense. I can usually tell you quickly whether it is noise or worth acting on.