CDN for Small Business Websites: What Cloudflare Really Fixes

Picture a bakery in Chiang Mai with its kitchen and its only warehouse in the same building. Every order, whether the customer lives in Hat Yai, Khon Kaen or Bang Na, is packed there and then travels all the way to them. On a normal day that works fine. On a big promotion day, when a thousand people order at once, the warehouse door jams and the packers can't keep up.

One day someone suggests to the owner: why not open small stockrooms in the big provincial cities? Put the best-sellers, the boxes that look identical every time, close to customers first. Whoever orders gets served from the nearest stockroom. And at each stockroom door there's a staff member who waves away people who are only queuing for fun, so they don't crowd out real buyers.

Sounds good, right? Websites have exactly this, and it's called a CDN. The name Thai business owners hear most often is Cloudflare. The day your web team walks in and says "let's move the DNS to Cloudflare" or "we should turn on a CDN", this article will help you understand what it really does, what it doesn't, and what to ask before you say yes.

Check your own website first, in under two minutes

Open a browser, type your website address and add /cdn-cgi/trace at the end, for example www.yourshop.com/cdn-cgi/trace, then press Enter.

If you see a few short lines of text, including one that says colo= followed by three letters, your site already runs through Cloudflare. Those three letters are the airport code of the city where the Cloudflare data center answering you sits. Open it from Thailand and see BKK, and your request was answered from a data center in Bangkok. If you get a 404 or a "page not found", your site isn't behind Cloudflare yet.

Then ask your web team two things. Whose email was used to open the Cloudflare account for our site? And who holds the password for the account where our domain is registered (what the industry calls the registrar)? If the answer is "the personal email of someone who left last year" or "not sure", write that down. We'll come back to it.

How a CDN works, told the shopkeeper's way

Every website has its own "central kitchen". The technical name is the origin server, which is simply the hosting that stores your site. Normally, when a customer opens your website, their browser goes straight to that kitchen every single time, however near or far they are.

A CDN (Content Delivery Network) is a network of servers spread across many cities around the world. Once it's switched on, customers no longer talk to your kitchen directly. They talk to the CDN server nearest to them first. If that server already has the item they asked for, it hands it over immediately. If not, it fetches it from your kitchen and keeps a copy for the next person. Keeping that copy is called caching.

What can sit in a branch stockroom, and what still has to be made in the kitchen

This is where most people get it slightly wrong. What a CDN keeps close to customers really well are the things that look the same in every box: images, the CSS files that control how your site looks, JavaScript files, fonts, or a PDF catalogue. Everyone who opens them gets the same file, so they can happily sit in a branch stockroom.

The page itself (the HTML file) is different. Cloudflare's own documentation says it does not cache HTML by default. That makes sense. Some pages hold information specific to one person, such as a shopping cart, a member's name, or a price that changes with stock. Cache the wrong page and one customer could end up seeing another customer's cart. So your web team has to decide which pages are safe for the CDN to copy and which must go back to the kitchen every time.

Put simply, ready-made items ship from the branch, but made-to-order items still come from the central kitchen.

The staff member at the door

Another job a CDN like Cloudflare does very well is standing at the door in front of your kitchen. Every request to your website passes through Cloudflare first. Bots scanning for weak spots, or huge floods of traffic meant to knock your site over (known as a DDoS attack), get filtered at the door and never reach your hosting. Cloudflare's plans page lists unmetered DDoS protection even on the free plan, meaning it isn't charged by the size of the attack.

The side benefit shows up on big promotion days. When most images and page files are served from branch stockrooms, your kitchen has much less to do, and keeps its strength for the work that actually needs thinking, like deducting stock or taking orders.

What a CDN can't fix, even with every switch turned on

I want to be clear here, because I've often seen owners expect that switching on Cloudflare will make a slow website fast overnight.

If the central kitchen cooks slowly, the branch stockroom can't help. Cloudflare's own guide to troubleshooting a slow website explains that uncached content still has to travel from the visitor to Cloudflare, on to your origin server, and back again. If your hosting processes pages slowly, the database is heavy, or there are so many plugins that each page waits, that part stays exactly as slow as before.

Heavy images are another story. A photo several megabytes in size sent from a stockroom near the customer is still a heavy box. It arrives a little sooner, but the customer's phone still has to download all of it. And badly written code, such as a script that stops the page from showing until it finishes loading, still blocks the page no matter where it's delivered from.

If you'd like to understand how site speed affects sales and Google rankings, I've covered it in our article on how website speed impacts SEO and online sales. Reading a PageSpeed Insights report section by section deserves its own article. For now, just remember that a CDN moves your goods closer to customers. It doesn't make the goods lighter or the kitchen faster.

Is Cloudflare's free plan enough for a small business website?

For a typical company site, online shop or clinic website, I'd say the free plan is enough in almost every case.

According to Cloudflare's plans page, which I checked on 29 September 2026, the Free plan includes the CDN, a Universal SSL Certificate (what makes your site show https), unmetered DDoS protection and a Web Application Firewall (WAF). The next tier up, Pro, is listed at 20 US dollars a month billed annually or 25 dollars billed monthly. That's the price on Cloudflare's own page, and I don't know whether it includes Thai tax, so check the final amount on the checkout page if you decide to subscribe.

Sites that should start thinking about a paid plan are usually ones that are targeted by attacks again and again, or that need traffic-filtering rules more detailed than the free plan offers. If your web team suggests upgrading, ask them: "Which feature are we missing on the free plan, and which real problem that we're having does it solve?" A good answer points clearly at a problem that has already happened.

"All our customers are in Thailand. Why would we need a CDN?"

That's a fair question, and I agree with it.

If your hosting is in Thailand or Singapore and almost all your customers open the site from inside the country, the distance between them and your kitchen was never large. The speed gained from branch stockrooms is much smaller than for a site selling to customers abroad. I'd never want anyone to switch on Cloudflare expecting their site to become twice as fast.

The reason so many Thai SMEs use Cloudflare usually has little to do with distance. It's about the staff member at the door. Scanning bots don't care where your customers live; they arrive from all over the world anyway. Filtering them before they reach your hosting leaves your kitchen with more strength for real customers. The other reason is having DNS and SSL tools in one place, which makes the site easier for your web team to look after.

Whether your hosting can cope when a lot of people arrive at once is a separate question from the CDN, and one to take up with your hosting provider directly. I've written about that in our article on reading a hosting quote before you sign.

Three settings that stop your website or your email when they're wrong

Putting a website behind Cloudflare usually starts with moving your DNS. DNS works like your domain's address book. It tells the world where your website lives and where your email should be delivered. When you move it, you're moving the whole address book, and that is where the three risks I see most often come from.

The shop's email goes quiet after the DNS move

When you add a domain to Cloudflare, it scans for your existing DNS records automatically. But Cloudflare's setup guide says plainly that the quick scan is not guaranteed to find every record, and asks you to review them yourself, paying special attention to email records. If the MX record (the line that says where this domain's email should go) or the email authentication records get lost along the way, info@yourshop stops receiving mail or starts landing in spam. Often nobody notices until a customer phones to ask.

Another common case is an email subdomain such as mail.yourshop.com being switched to proxied (the orange cloud icon) along with everything else. Cloudflare's email troubleshooting documentation explains that mail protocols like SMTP, IMAP and POP3 don't work through its standard HTTP proxy, so hostnames used for email must be set to DNS only (the grey cloud).

The page loops forever with "too many redirects"

Cloudflare offers several SSL/TLS encryption modes, and three are worth knowing. Flexible encrypts only the part between the customer and Cloudflare, while the part from Cloudflare to your hosting stays unencrypted. Full encrypts both parts but doesn't check the certificate on your hosting. Full (strict) encrypts both parts and checks that certificate too.

Trouble starts when Flexible is chosen but your hosting is already set to push every request to https. Cloudflare's page on ERR_TOO_MANY_REDIRECTS explains the loop: Cloudflare sends the request to your hosting over http, your hosting redirects it to https, and round it goes without end. Customers see a page that won't open even though nothing on the site is actually broken. Cloudflare's recommended fix is switching to Full or Full (strict), which needs a certificate on your hosting.

DNSSEC that has to be turned off before changing nameservers

If your domain has DNSSEC switched on (a system that signs your DNS data), the same Cloudflare guide says you must turn it off at your registrar before replacing the nameservers, because changing them while it's active can make your domain unreachable. Once the domain is active on Cloudflare, you can switch DNSSEC back on there. It happens less often than the email and SSL problems, but it's harder to fix when it does, because someone who can log in to the registrar has to sort it out.

Who should hold the keys to the Cloudflare account

Once your site sits behind Cloudflare, that account becomes one of the most important keys your business has. Whoever can log in can change where your website points and where your email goes.

Our recommendation is to open the Cloudflare account with a company email that the owner or a manager can access, then add your web team or agency as members. Don't let the whole account live in one person's personal email. The day that person changes jobs or the contract ends, you won't have to ask for the keys to your own house back. The same principle applies to the registrar account where your domain lives, which I've covered in the section on who should hold the account in our article on where to register a domain.

We've been through this ourselves with a different tool. When TumWebSME rebuilt its website, we found our old GA4 property was one nobody on the current team could access. In the end we had to create our own property under the company's own Analytics account and let the old data go. A Cloudflare account carries the same risk. The difference is that losing access means losing control of your website and email, which is far heavier than losing a report.

Why getting it right on day one pays off

The first DNS move is the moment everything is written into a new address book. If someone sits down then and compares the records line by line, picks the SSL mode that matches the hosting and opens the account in the company's name, there's very little left to touch afterwards.

If that first move is rushed, the mistakes don't show up right away. Missing email might only be noticed days later. An account sitting in someone's personal inbox may cause no trouble for years, right up to the day you really need it. Small day-one mistakes quietly compound until they become a big job on the day you have the least time.

The minimum a small business website needs

If I had to sum up what's right for a small to mid-sized business site, I wouldn't go further than this. Use the free plan. Proxy (orange cloud) only the records that serve your website. Set every email record to DNS only. Use Full (strict) SSL if your hosting already has a certificate. Keep the account under a company email with at least two people on the team able to get in. And note down the date of the move, in case you ever need to trace what changed and when.

That already gives you the main benefits of a CDN. Turn on the other features when you have a real problem to solve.

Real examples you can look up yourself

If you sell on Shopify, you already have a CDN without doing anything. Shopify's Help Center says every online store has a content delivery network run by Cloudflare. And Shopify's page on troubleshooting domains warns that putting your own Cloudflare proxy in front of a Shopify store can interfere with Shopify's network, causing problems with SSL certificates and connectivity, and Shopify states it doesn't support this setup. The lesson: before switching on a CDN, find out whether your platform already provides one. Two layers aren't always better than one.

The other example answers the question people usually ask next: what if Cloudflare itself goes down? It has happened. Cloudflare's own blog published a report on it. On 18 November 2025, at 11:20 UTC (18:20 Thai time), Cloudflare's network began failing to deliver traffic on a wide scale, and core traffic was largely flowing as normal again by around 14:30 UTC (21:30 Thai time). The cause was a bot-management configuration file that grew far larger than expected after a database permissions change, and Cloudflare stated it was not caused by any cyber attack. Many websites behind Cloudflare were affected at the same time.

I'm not telling you this to scare you. Every system can go down, whether it's hosting, a CDN or even the biggest cloud providers. What actually helps is knowing what your website depends on, and knowing who on your team has the access to switch the proxy off temporarily if it ever comes to that, with your web team making that call. For the bigger picture of why business websites are moving to the cloud, our article on why your business website needs the cloud is a good companion read.

Our own website runs behind Cloudflare too

The tumwebsme.com site you're reading runs through Cloudflare. On 29 September 2026 I checked it from a machine on our team. The server replied with server: cloudflare, and the /cdn-cgi/trace page showed colo=BKK, meaning the request was answered from a data center in Bangkok.

The interesting part came when I requested the CSS file that controls how the site looks. The first time, the cf-cache-status value said MISS: the branch stockroom didn't have it yet and had to fetch it from the kitchen. When I asked again straight away, the same value changed to HIT, served straight from the branch. The home page showed REVALIDATED, which Cloudflare's documentation describes as the origin confirming the cached copy was unchanged, so the stored copy could be served. It's the bakery's branch stockroom, exactly.

Beyond caching, we also use Cloudflare to serve the Google tag through our own domain's path (Google tag gateway), together with Consent Mode v2. That's a topic about measuring ads, though, so let's save it for another day.

A five-step plan when your web team suggests Cloudflare

1. Ask what problem it's meant to solve. Why is the site slow? Are we being hit by bots? Does our platform already include a CDN?

2. Have the web team list every existing DNS record before the move, especially MX and the email authentication records, then compare them line by line with what Cloudflare's scan found.

3. Open the Cloudflare account with a company email and add the web team as members. Also check that you can log in to the registrar yourself and that DNSSEC is off before changing nameservers.

4. Pick the SSL mode that matches your hosting (Full or Full (strict)) and schedule the move for a quiet time, well away from the day before a promotion.

5. After the move, send test emails in and out, open the site on both phone and computer, and open /cdn-cgi/trace to confirm a colo value appears.

How to measure the results

In the first week after the move, what matters most is whether everything still works the way it did. Speed can wait. Emails arrive and send, the contact form submits, the LINE chat button works, payments go through. Once all that is fine, look at the numbers.

Cloudflare's dashboard shows what share of requests were answered from cache and how much traffic was filtered out. A monthly screenshot summary from your web team is plenty. For the speed customers actually feel, use the same tool you used before the move, such as PageSpeed Insights, testing the same page at a similar time of day, so you know how much really changed.

And on your next big promotion day, open the dashboard during the day. You'll see for yourself how much of the crowd the branch stockrooms took off your hands.

Let's go back to that bakery in Chiang Mai. Opening branch stockrooms gets the best-sellers to customers faster, and puts someone at the door on the busiest days. But if the central kitchen bakes slowly, or each box is simply too heavy, the branches can only help so much. And most important of all, the keys to every stockroom and the shop's address book must always stay in the owner's hands.

If you're about to build a new website and would like hosting, setup and the handover of every account to sit with one team from day one, take a look at the details of TumWebSME's website packages. Or if your current site is about to move its DNS and you'd like someone to go through the record list with you before you switch, tell us about it. I'd be glad to look at it together with you.

Follow TumWebSME

Follow us for insights on website development and online marketing:

• Facebook: TumWebSME Business Website Development

• Instagram: @tumwebsme

• TikTok: @tumwebsme

• YouTube: TumWebSME

Contact Us and Inquire About Services

• 088-983-9386 (Ploy)

• 099-856-3198 (Saennan)