Cloudflare for Small Business Sites: DNS, Caching, and Security
Why use Cloudflare on Nepali sites
Even when origin servers sit in Singapore or Europe, Cloudflare PoPs improve TTFB for Kathmandu users and add DDoS protection on free tier.
Most Gurkha Technology client sites — WordPress, static, or hybrid — sit behind Cloudflare within the first week of launch. Not because clients ask for it, but because Nepal’s connectivity profile makes edge caching and DNS resilience disproportionately valuable:
- International origin latency from Kathmandu is often 180–350ms uncached
- ISP routing varies by district; a stable anycast DNS layer reduces “site works on Ncell but not WorldLink” reports
- Small businesses cannot afford dedicated DDoS mitigation; Cloudflare absorbs volumetric noise on free tier
-
.com.npand international domains both work; nameserver change is the same process
Cloudflare is not a replacement for good hosting — it is a performance and security layer in front of whatever you already pay for. See web hosting in Nepal for origin server choices.
Setup checklist
- Add site, import DNS records
- Update nameservers at registrar (including register.com.np)
- SSL/TLS mode: Full (strict) with valid origin cert
- Enable Brotli + auto minify (HTML/CSS/JS cautiously)
- Page Rules or Cache Rules for static assets
- Firewall rule: block obvious bad bots
Step 1: Add site and scan DNS
Create a Cloudflare account, add your domain, let Cloudflare scan existing DNS records. Verify:
| Record type | Check |
|---|---|
| A / AAAA | Points to correct origin IP |
| CNAME | www → root or host alias |
| MX | Mail records preserved (do not proxy orange-cloud email) |
| TXT | SPF, DKIM, domain verification untouched |
Critical: Only proxy (orange cloud) web traffic records. Mail records must stay DNS-only (grey cloud) or email breaks silently.
Step 2: Nameserver cutover at register.com.np
For .com.np domains, log into register.com.np (or your registrar), replace default nameservers with Cloudflare’s assigned pair. Propagation typically takes 2–24 hours; some ISP caches stretch to 48.
During cutover:
- Lower TTL on old DNS records 24 hours before if your registrar allows
- Keep origin server running — you are changing DNS, not migrating files
- Test with
digor whatsmydns.net before announcing “site is live”
Step 3: SSL/TLS configuration
| Mode | When to use | Risk |
|---|---|---|
| Off | Never in 2026 | No encryption |
| Flexible | Legacy HTTP-only origin | Redirect loops if origin forces HTTPS |
| Full | Origin has cert (any) | Accepts self-signed |
| Full (strict) | Origin has valid cert | Recommended default |
Install Let’s Encrypt on cPanel, CyberPanel, or your VPS. Then set Cloudflare to Full (strict). Enable “Always Use HTTPS” and “Automatic HTTPS Rewrites” after confirming no loop.
Step 4: Speed optimizations
On free tier, enable:
- Brotli compression
- Auto Minify — enable CSS/JS; HTML minify can break inline scripts on older WordPress themes (test first)
- HTTP/2 and HTTP/3 — usually on by default
Do not enable Rocket Loader on WordPress without testing — it frequently breaks jQuery-dependent plugins and WooCommerce checkout.
Step 5: Caching rules
Modern Cloudflare uses Cache Rules (Page Rules are legacy-limited on free tier). Example patterns:
| URL pattern | Cache setting | Edge TTL |
|---|---|---|
*.css, *.js, images |
Cache everything | 1 month |
/wp-admin/* |
Bypass | — |
/wp-login.php |
Bypass | — |
WooCommerce /cart/*, /checkout/*
|
Bypass | — |
| Static HTML (brochure sites) | Cache | 1 hour–1 day |
Static sites like ours on GitHub Pages benefit from aggressive asset caching; HTML cache duration depends on deploy frequency — purge after each deploy.
Step 6: Basic security rules
Free tier firewall suggestions:
- Challenge or block countries you never serve (optional — tourism sites should not block)
- Block known bad user agents (
curlscrapers hitting/xmlrpc.php) - Rate-limit
/wp-login.phpif on Pro plan; on free tier use Cloudflare “Bot Fight Mode” cautiously
For WordPress hardening beyond Cloudflare, cross-reference WordPress security in Nepal.
Common mistakes
- Flexible SSL with HTTPS origin → redirect loops
- Caching HTML for dynamic WordPress admin paths
- Forgetting to purge cache after deploy
Expanded mistake list
| Mistake | What happens | Prevention |
|---|---|---|
| Orange-cloud on MX records | Email delivery fails | Grey-cloud all mail DNS |
| Caching WooCommerce cart | Empty cart, duplicate orders | Bypass checkout paths |
| No purge after deploy | Clients see old homepage for hours | Automate purge in CI or purge manually post-deploy |
| Development subdomain proxied | Staging indexed, wrong SSL | Separate Cloudflare zone or DNS-only staging |
| Trusting “Always Online” alone | Shows stale snapshot during long origin outage | Monitor origin uptime separately |
| Enabling all speed features at once | Broken JS, layout shift | Enable one feature, test, then next |
Redirect loops: diagnosis
Symptom: browser shows “too many redirects” after enabling Cloudflare.
Fix sequence:
- Check origin — does
http://originredirect to HTTPS? - If yes, Cloudflare Flexible mode causes double redirect — switch to Full (strict)
- Check WordPress
siteurl/home— must match live HTTPS domain - Review
.htaccessor nginx redirect rules for conflicting www/non-www logic
We document similar redirect limitations for GitHub Pages in GitHub Pages vs Netlify vs Cloudflare Pages — Cloudflare Workers or Page Rules can fix 301 gaps static hosts leave open.
Performance expectations in Nepal
Cloudflare improves repeat visits and static asset delivery most. First-byte time for uncached dynamic WordPress still depends on origin location.
Rough expectations from client projects (Kathmandu, mobile 4G):
| Metric | Without CF | With CF (cached assets) |
|---|---|---|
| Static CSS/JS TTFB | 200–400ms | 50–120ms |
| Uncached WP homepage | 800ms–2s | 700ms–1.8s (modest gain) |
| DDoS / traffic spike | Origin may throttle | Absorbed at edge |
For meaningful dynamic gains, pair Cloudflare with origin page cache (LiteSpeed, WP Rocket) or move static marketing pages to a static generator — see WordPress vs static TCO.
When to upgrade from free tier
Free tier suffices for most Nepali SMEs. Consider Pro ($20/month) when:
- Client needs image Polish or mobile-specific optimization at scale
- WAF custom rules for WooCommerce fraud patterns
- Priority support during festival-season traffic spikes (Dashain e-commerce surges)
Agencies can bundle Pro cost into website maintenance retainers rather than asking clients to manage Cloudflare billing separately.
Cloudflare Pages vs proxy-only
Some teams deploy static sites directly to Cloudflare Pages instead of proxying GitHub Pages. Benefits: native redirects, unlimited bandwidth, preview deployments. Trade-off: another build pipeline to maintain. Our site stays on GitHub Actions + Pages with Cloudflare DNS optional — choose based on redirect requirements and team familiarity.
Maintenance checklist (quarterly)
- Review DNS records after any hosting migration
- Confirm SSL cert expiry on origin (auto-renew via certbot)
- Audit cache rules after plugin/theme major updates
- Check firewall events for false positives blocking Nepal IP ranges
- Purge everything after structural URL changes
- Verify analytics still accurate (some ad blockers affect CF Web Analytics vs GA4)
