How to Set Up a CDN for Your WordPress Website?

Sajjad
WordPress
29 Aug, 2026

A Content Delivery Network (CDN) serves your site's static assets, images, CSS, JavaScript, fonts, from a network of servers physically distributed around the world, so a visitor in Singapore downloads them from a server in Singapore instead of making a round trip to your single origin server in, say, Virginia. For a global audience, this single change can cut load times more than almost any other individual optimization, because it attacks latency directly rather than trying to make the same round trip faster.

This guide covers two real setup paths: a full-site CDN through Cloudflare (the most common choice, since it proxies your entire domain, not just static files), and a dedicated static-asset CDN like BunnyCDN using a CNAME subdomain, which some sites prefer to keep dynamic PHP requests going straight to origin. Both are covered end to end, including the WordPress-side plugin configuration that actually rewrites your asset URLs to point at the CDN.

How a CDN Actually Speeds Up Your Site

Two separate mechanisms are at work, and it's worth understanding both:

Reduced latency from geographic distance. Every request has to travel from the visitor's device to a server and back, and that round trip takes longer the farther apart they physically are. A CDN's global network of edge locations (often called "points of presence" or PoPs) means a visitor's request travels a much shorter physical distance.
Edge caching. Once an edge server has served a file (an image, a CSS bundle) to one visitor, it typically keeps a cached copy so the next visitor in that same region gets it served directly from the edge, without the request ever reaching your origin server at all.

The combined effect is fewer requests hitting your actual WordPress server, and the ones that do arrive from farther away travel a shorter final distance, which is also why a CDN often measurably reduces server load, not just visitor-perceived speed.

Option 1: Cloudflare (Full-Site CDN)

Cloudflare proxies your entire domain, including dynamic PHP requests to your WordPress server, and caches whatever's cacheable at the edge automatically. It's free at the entry tier and the most common starting point for WordPress sites.

Step 1: Create a Cloudflare Account and Add Your Site

Sign up at cloudflare.com and click Add a Site.
Enter your domain name and choose the Free plan.
Cloudflare scans your existing DNS records and imports them automatically. Review the imported records for accuracy before continuing.

Step 2: Update Your Nameservers

Cloudflare gives you two nameserver addresses (something like aria.ns.cloudflare.com and theo.ns.cloudflare.com). Log into your domain registrar (GoDaddy, Namecheap, or wherever you registered the domain, which is not necessarily the same company as your host) and replace the existing nameservers with these two.

This step is what actually routes your traffic through Cloudflare; DNS propagation can take anywhere from a few minutes to 24 hours, though it's usually much faster in practice.

Step 3: Confirm Proxy Status Is Enabled

Once Cloudflare is active, go to DNS → Records and check that your main A record (and www CNAME, if you use one) has the orange cloud icon enabled, not the gray "DNS only" one:

Orange cloud (Proxied) — traffic routes through Cloudflare's network, gets cached and protected. This is what you want for your main site.
Gray cloud (DNS only) — Cloudflare just answers DNS queries; traffic goes directly to your server, bypassing the CDN entirely.

Step 4: Configure Caching Rules

Go to Caching → Configuration, and set a Browser Cache TTL (4 hours is a reasonable default). Then, under Rules → Page Rules or the newer Cache Rules, create a rule to cache static assets aggressively:

Match: *yourdomain.com/wp-content/uploads/*
Setting: Cache Level: Cache Everything, Edge Cache TTL: 1 month

This tells Cloudflare's edge to hold onto your media library files for a full month before re-checking with your origin, since uploaded images rarely change once published.

Step 5: Install the Cloudflare WordPress Plugin

Install the official Cloudflare plugin from the WordPress Plugin Directory, connect it with an API token (generated under My Profile → API Tokens in your Cloudflare dashboard), and enable Automatic Platform Optimization if you're on a paid plan, or at minimum use the plugin's Purge Cache button whenever you publish new content that needs to bypass the edge cache immediately.

Option 2: A Dedicated Static Asset CDN (BunnyCDN Example)

Some sites prefer to leave dynamic requests (anything that touches PHP and the database) going straight to origin, and only route static files, images, CSS, JS, through a CDN via a separate subdomain. This avoids any risk of a full-site proxy interfering with dynamic behavior like logged-in sessions or WooCommerce carts.

Step 1: Create a Pull Zone

Sign up at bunny.net and create a new Pull Zone.
Set the Origin URL to your main domain, https://yourdomain.com. BunnyCDN will "pull" files from your origin the first time they're requested through the CDN, then cache them at the edge for subsequent requests.
Note the generated CDN hostname, something like yoursite.b-cdn.net.

Step 2: Point a Subdomain at the CDN

In your DNS provider, add a CNAME record pointing a subdomain at your Pull Zone's hostname:

Type:  CNAME
Name:  cdn
Value: yoursite.b-cdn.net
TTL:   Auto

This makes cdn.yourdomain.com resolve to BunnyCDN's edge network, while yourdomain.com itself continues to resolve directly to your WordPress server unaffected.

Step 3: Rewrite Asset URLs in WordPress

Install a CDN-rewriting plugin like CDN Enabler (a free, single-purpose plugin built exactly for this), and configure it:

Go to Settings → CDN Enabler.
Set the CDN URL to https://cdn.yourdomain.com.
Under Included Directories, list the folders that should be rewritten to the CDN, typically wp-content,wp-includes, which covers uploads, theme assets, and plugin assets.

From that point on, WordPress outputs asset URLs pointing at your CDN subdomain instead of your main domain, for example rewriting:

<img src="https://yourdomain.com/wp-content/uploads/2026/09/photo.jpg" />

into:

<img src="https://cdn.yourdomain.com/wp-content/uploads/2026/09/photo.jpg" />

If you're using a full performance plugin like WP Rocket instead, the same setting lives under Settings → WP Rocket → CDN, where you enable Enable Content Delivery Network and enter the same cdn.yourdomain.com hostname directly, without needing CDN Enabler as a separate plugin.

Verifying the CDN Is Actually Working

Don't trust the dashboard alone; confirm it with real requests.

Check response headers with curl:

curl -I https://cdn.yourdomain.com/wp-content/uploads/2026/09/photo.jpg

Look for a header indicating the CDN handled the request, which varies by provider:

Cloudflare adds cf-cache-status: HIT (or MISS on the first request, before it's cached) and a server: cloudflare header.
BunnyCDN adds a CDN-PullZone header and reports cache status in a similar way.

If neither header appears, the request is still going straight to your origin server, meaning either DNS hasn't propagated yet, or the rewriting plugin isn't actually replacing the URLs in your page's HTML. View your page source directly and search for your domain in <img> and <link> tags to confirm they now point at the CDN hostname.

Frequently Asked Questions (FAQ) About Setting Up a CDN for WordPress

The benefit is smaller but not zero. Even within one country, a CDN's edge caching reduces load on your origin server and can improve consistency during traffic spikes, since cached content is served without touching WordPress or the database at all. The latency improvement is most dramatic for a genuinely global audience, though.

By default, no. Cloudflare's standard caching rules only cache static file types (images, CSS, JS, fonts) automatically. HTML pages require an explicit Cache Everything rule or a feature like Automatic Platform Optimization (a paid add-on) to be cached at the edge as well.

Yes, this is normal and how most WordPress sites use Cloudflare. Just make sure your caching rules exclude wp-admin and any logged-in-user pages from aggressive caching, which Cloudflare's defaults already handle correctly out of the box.

Yes, and you should. A caching plugin speeds up how WordPress generates a page on your origin server; a CDN speeds up how that already-generated page (and its assets) reaches the visitor. They solve different parts of the problem and are meant to be used together.

Check that the relevant DNS record has the orange "Proxied" cloud enabled, not the gray "DNS only" one. A gray-cloud record bypasses Cloudflare's network entirely, so no caching headers will appear no matter how your Page Rules are configured.

Yes, primarily by reducing Time to First Byte (TTFB) and speeding up delivery of the images and scripts that affect Largest Contentful Paint (LCP), since the browser fetches them from a much closer edge server rather than a single distant origin.

For a Pull Zone-based CDN like BunnyCDN, requests generally fail for the CDN subdomain specifically, but your main domain (still pointing directly at your server) continues to work. For a full proxy like Cloudflare, an outage is broader, though these are extremely rare given the scale of Cloudflare's network.

Yes, they address different bottlenecks. Page caching avoids regenerating a page on your server for every visitor; a CDN avoids the geographic latency of delivering that page (and its assets) once it's ready. Combining both gets you the fastest result either could achieve alone.

Conclusion

Setting up a CDN for WordPress comes down to one of two shapes: a full-site proxy like Cloudflare that sits in front of every request to your domain, or a dedicated static-asset CDN on its own subdomain that only handles images, CSS, and JS while dynamic requests go straight to origin. Cloudflare is the simpler starting point for most sites and comes with a genuinely useful free tier; a Pull Zone setup with CDN Enabler is worth considering if you want to keep dynamic traffic entirely separate from cached static delivery.

Whichever you choose, don't take the setup on faith: check response headers with curl -I and confirm your page source is actually pointing at the CDN hostname before assuming it's working. A misconfigured DNS record or a rewriting plugin that isn't active will leave your site looking unchanged, with no error message telling you why.

Here are a few additional resources if you want to go deeper:

Cloudflare Learning Center: What Is a CDN? — a plain-language explanation of CDN mechanics.
Cloudflare Page Rules Documentation — configuring caching behavior for specific URL patterns.
BunnyCDN Documentation: Pull Zones — setting up and configuring a Pull Zone from scratch.