How to Set Up BunnyCDN for WordPress: Step by Step

There’s a specific moment most WordPress site owners discover their CDN isn’t optional anymore: a reader in another country emails you saying your site “feels slow,” while it loads just fine for you. That’s distance talking. Your server sits in one place; everyone far from it waits longer for every image, stylesheet, and font file.

BunnyCDN has become one of the most popular answers to that problem — not because it’s the cheapest (though it’s close), but because the setup is straightforward and the control panel doesn’t make you feel like you need a network engineering degree. This guide walks through the full setup on WordPress: creating a pull zone, connecting it to your site, getting SSL right, setting cache rules that actually matter, and verifying everything is working before you declare victory.

If you haven’t decided on a CDN provider yet, read our guide on how to choose a CDN for your WordPress site and our head-to-head Bunny CDN vs Cloudflare for WordPress first. Already decided? Let’s set it up.

What a pull zone actually is (the one concept worth learning)

When you create a “pull zone” in BunnyCDN, you’re telling their network: “Here’s my website’s address. When a visitor in Berlin requests an image, grab a copy from my server once, then serve that copy from your Berlin edge server to everyone after that.”

“Pull” means the CDN pulls from your origin server automatically — you don’t upload anything. This is different from a “push zone,” where you manually upload files to the CDN’s storage. For a standard WordPress site, pull zones are almost always what you want. They stay in sync with your site automatically: update an image in the media library, and the CDN picks up the new version (more on cache invalidation later).

Step 1: Create the BunnyCDN account and the pull zone

1. Sign up at bunny.net and complete the account verification. BunnyCDN’s panel is clean and fast — a good sign for a CDN company.
2. From the dashboard, go to CDN → Add Pull Zone. You’ll see three things to decide:

Name. This becomes part of your CDN hostname, like yoursite.b-cdn.net. Pick something short and recognizable. (You can attach a custom domain later — step 5.)

Origin URL. Your site’s full address, e.g. https://yoursite.com. The CDN pulls files from here. Double-check this is the canonical URL — http vs https and www vs non-www matter. If your site redirects, put the final destination URL here to avoid the CDN chasing redirects on every request.

Pricing tier. BunnyCDN charges per gigabyte, and you pick the regions you want to pay for. Standard covers the major regions at the lowest rate; Volume and Volume-gen2 are cheaper per GB for high-traffic sites; there’s also a premium tier with the full network. For most WordPress sites starting out, Standard is the sane default. You can change tiers later without recreating anything.

3. Create the zone. Your CDN hostname is now live, something like https://yoursite.b-cdn.net. Open it in a browser — you won’t see your homepage (it’s a CDN, not a mirror of your site), but it should resolve.

That’s the BunnyCDN side. The zone exists. Now we wire WordPress to actually use it.

Step 2: Connect WordPress with the CDN URL

The standard approach is to rewrite your static asset URLs so they point at the CDN hostname. Most caching plugins have a CDN field for exactly this.

With WP Rocket: Settings → CDN tab → enable CDN → paste your pull zone hostname (https://yoursite.b-cdn.net) as the CDN CNAME. WP Rocket rewrites URLs for images, CSS, JS, and fonts.

With LiteSpeed Cache: Page Optimization → CDN Settings → turn CDN on and enter the CDN URL.

With W3 Total Cache: Performance → General Settings → CDN → enable → configure with your pull zone hostname.

With the free CDN Enabler plugin: Settings → enter your CDN URL. That’s literally all it does, and it’s reliable for simple setups.

Which files get rewritten? By default, images, stylesheets, scripts, and fonts. Do not put your whole HTML through the pull zone at this stage — that means either serving full pages from the CDN (which needs cache-exclusion rules for logged-in users, cart, checkout) or leaving HTML on your origin, which is the standard and safe arrangement for a pull zone serving static assets.

After saving, view your site’s page source (right-click → View Page Source) and look for a few image URLs. They should now start with your CDN hostname. If they still show your own domain, the plugin’s CDN rewriting isn’t active — recheck the setting, clear any page cache, and look again.

Step 3: Get SSL right (the step people get wrong)

Your CDN hostname needs HTTPS, and BunnyCDN handles this better than most providers:

• The default b-cdn.net hostname comes with SSL automatically. Nothing to do.
• If you add a custom hostname like cdn.yoursite.com, go to your pull zone → Hostnames, add it, and let BunnyCDN issue a free Let’s Encrypt certificate. It takes a few minutes.

The common mistake here is mixed content: your site loads over HTTPS but some rewritten URLs come out as HTTP. Check your pull zone’s origin setting — the Origin URL should use https://. Then verify in the browser: open DevTools (F12) → Console, and look for mixed-content warnings. There shouldn’t be any. If your site historically served some assets over HTTP, run a search-replace or fix the source rather than papering over it.

Also confirm in BunnyCDN’s zone settings that Force SSL is on, so any stray HTTP request to the CDN gets redirected to HTTPS.

Step 4: Set cache rules that actually matter

Default CDN caching is conservative. A few targeted rules turn BunnyCDN from “a faster pipe” into “a genuinely fast cache”:

Long cache lifetimes for versioned assets. WordPress asset URLs usually contain version query strings (style.css?ver=6.8) or hashed filenames. These are safe to cache for a long time — when the file changes, the URL changes. In your pull zone → Caching, set a generous browser and edge cache time for static files. Our guide on fixing the “Serve Static Assets With an Efficient Cache Policy” warning (link: https://wpspeedaudits.site/fix-efficient-cache-policy-wordpress/) covers the right lifetimes per file type in detail — the same principles apply at the CDN layer.

Never cache dynamic pages. If your pull zone ever ends up in front of HTML (some setups route everything through it), exclude wp-admin, wp-login.php, the cart/checkout pages, and anything with cookies. For the standard static-assets-only setup, this is a non-issue — but it’s worth knowing the rule exists.

Query string handling. BunnyCDN can cache each unique query string separately or ignore query strings. For WordPress, the safe default is to respect the standard version query strings (?ver=) since that’s how cache-busting works. Don’t set it to ignore query strings globally — you’d serve stale files after updates.

Origin shield (optional, useful for busy sites). If your site gets meaningful traffic, enable an origin shield region. It adds one caching layer between the edge servers and your origin, so a traffic spike doesn’t turn into dozens of edge servers all requesting the same uncached file from your server at once.

Step 5: Use a custom CDN hostname (optional but professional)

Serving assets from yoursite.b-cdn.net works fine, but cdn.yoursite.com looks better and keeps everything under your own domain — which has a small side benefit for cookie handling and brand consistency.

1. In your DNS (wherever your domain’s DNS lives), add a CNAME record: cdn → yoursite.b-cdn.net.
2. In the BunnyCDN pull zone → Hostnames → add cdn.yoursite.com.
3. Wait for the Let’s Encrypt certificate to issue (a few minutes), then swap the CDN URL in your WordPress plugin from the b-cdn.net hostname to your custom one.
4. Purge everything once after the swap, and re-check page source to confirm the new hostname is in use.

Step 6: Purge correctly when you update things

CDN caching means your changes don’t appear instantly everywhere. Know your purge options before you need them:

• Purge URL — clears one specific file. Use this after replacing a single image or stylesheet.
• Purge all — clears the whole zone. The nuclear option; use it after theme changes or when something looks wrong and you can’t tell what.

BunnyCDN also offers a WordPress plugin (official, free) that can purge the zone automatically when you update posts or clear your caching plugin’s cache. If you’d rather not think about purging, install it and connect it with your zone’s API key. One caution: automatic full purges on every post update can be wasteful on a busy editorial site — purge URLs, not zones, when you can.

Step 7: Verify it’s actually working

Don’t trust the green checkmarks. Verify with your own eyes, the way we describe in our CDN testing guide (link: https://wpspeedaudits.site/test-cdn-working-wordpress/):

1. Page source check. View source on a post and a page. Static asset URLs should show the CDN hostname. Spot-check images, one CSS file, one JS file.
2. Response headers. In DevTools → Network, click any image served from the CDN and look at the response headers. You’re looking for a server header mentioning BunnyCDN (or cdn-bunny markers) and a cache status header (cdn-cache: HIT on repeat loads). A MISS on first load followed by HIT on reload is exactly correct behavior.
3. Geography sanity check. If you have access to a VPN or a friend in another country, have them load the site. Or use a free tool like WebPageTest with a distant test location and compare TTFB on static assets before and after. The improvement on images and fonts from far away is usually dramatic — that’s the whole point.
4. PageSpeed re-run. Run PageSpeed Insights again. You probably won’t see a transformed score from a CDN alone (scores are dominated by your own HTML/JS), but “Serve static assets” type diagnostics should improve and real-world load times for distant visitors drop.

Give it 24 hours, then check BunnyCDN’s analytics in the dashboard: bandwidth served, cache hit ratio, and top files. A healthy pull zone on a WordPress site typically shows a cache hit ratio well above 90% for static assets after the first day. If yours is much lower, something is busting the cache — usually query strings on every URL or a plugin appending random parameters.

Common problems and their fixes

Images still load from my domain. The CDN rewriting isn’t active or your page cache is serving stale HTML. Clear the page cache, check the plugin’s CDN setting is saved and enabled, and view source in an incognito window.

Mixed content warnings. The Origin URL uses HTTP, or some hardcoded URLs in your theme/widgets use HTTP. Fix the origin setting, then hunt down the hardcoded URLs — the console tells you exactly which files are affected.

Changes not showing up. CDN cache. Purge the specific URL, wait a minute, hard-refresh (Ctrl+Shift+R). If you’re developing actively, consider a staging setup or shorter cache times during redesigns.

Fonts look wrong or fail to load. Font files served from a CDN hostname need proper CORS headers. BunnyCDN sends Access-Control-Allow-Origin for fonts by default in most configurations — if your fonts break after the switch, check the zone’s settings and your browser console for CORS errors specifically.

Checkout or login acting strangely. Your pull zone shouldn’t be serving HTML at all in this setup. If it is (because of an over-eager “cache everything” style rule or a DNS-level setup), exclude the dynamic paths immediately. Static-assets-only is the safe configuration.

What BunnyCDN doesn’t do for you

A CDN makes static files load faster from far away. It does not fix a slow server (that’s TTFB work — link: https://wpspeedaudits.site/wordpress-ttfb-too-high-fix/), it doesn’t shrink your JavaScript bundles, and it won’t save a page builder loading half a megabyte of CSS. Think of it as the last mile of a speed strategy, not the whole strategy: get your caching, images, and scripts in order first, then let the CDN distribute the result worldwide.

Set up right — about half an hour following the steps above — BunnyCDN quietly does its job in the background: your images load fast in Berlin and Brisbane alike, your origin server breathes easier, and the “your site feels slow” emails from the other side of the planet stop.