The quickest correct way to put a WordPress site on a CDN is to choose Cloudflare for a proxy/DNS setup, or a pull-zone provider paired with the CDN Enabler plugin if you cannot change nameservers. Either route takes roughly 15 to 30 minutes and cuts origin load while speeding up static assets. Before anything else, set SSL to Full (Strict) and add cache exclusions for wp-admin and checkout pages, or you risk breaking your own site.

TL;DR:

Proper CDN setup for WordPress involves choosing between proxy/DNS and pull-zone methods based on DNS management, security needs, and budget.

Cache exclusions for admin, checkout, and logged-in sessions are critical; incorrect settings often cause broken carts or login loops.

Verify CDN activation by checking response headers, speed tests, and functional testing, ensuring most static assets are served from the edge.

Regularly review cache hit ratios, purge caches after updates, and monitor SSL status to prevent security and performance issues.

A CDN is only justified for sites with significant traffic or large static assets, not essential for small or low-traffic websites.

How to set up a CDN for WordPress: the step-by-step checklist
How do you choose the right CDN for WordPress?
Setting up a CDN for WordPress: proxy/DNS versus pull-zone routes
What security settings and cache exclusions do you need?
How do you verify the CDN is actually working?
Ongoing maintenance and when a CDN isn’t worth it
CDN terminology every WordPress site owner should understand
Comparing CDN providers built for WordPress
Security beyond the WAF: hotlink protection and token authentication
Does a CDN affect SEO, and how do you avoid indexing problems?
How do you handle dynamic content and logged-in visitors?
Advanced caching: headers, TTLs and invalidation
A publisher’s perspective on when a CDN earns its place
Want the setup done properly the first time?
Sources

How to set up a CDN for WordPress: the step-by-step checklist

A correct WordPress CDN setup follows a fixed order. Skipping steps is where most site owners run into trouble, usually with a broken checkout or a login loop that takes hours to diagnose.

Decide on integration style first. Proxy/DNS (Cloudflare) suits anyone happy to change nameservers and wants built-in security; pull-zone suits anyone who wants to keep DNS untouched.
Back up the site and note your current DNS records before touching anything, since a botched nameserver change is far easier to reverse with the originals to hand.
Activate the CDN. For proxy setups, sign up and update nameservers at your registrar. For pull-zone setups, create the zone and generate a CDN hostname.
Install the matching WordPress plugin — the official Cloudflare plugin for proxy setups, or CDN Enabler for pull-zone rewrites.
Set cache exclusions and SSL mode before you consider the job done.
Run verification and purge tests on a handful of pages, including one with a shopping cart.

Pro Tip: Test your checkout flow in a private browser window straight after activation. If a cached cart or stale price appears, your exclusions aren’t set correctly yet, and it’s far cheaper to catch that now than after a customer does.

How do you choose the right CDN for WordPress?

The right choice depends less on brand reputation and more on three practical factors: how your DNS is managed, how much security you want bundled in, and your budget.

Consider the following before committing to a provider:

Global edge footprint. Cloudflare operates from more than 300 cities across over 120 countries, which matters if your visitors are geographically spread.
Cache hit ratio. A CDN only earns its place if most requests are served from the edge rather than bouncing back to your origin server.
Pricing model. Free tiers exist for both proxy and pull-zone providers, but bandwidth and request limits vary, so check the small print before scaling traffic.
WordPress integration depth. A dedicated plugin (official Cloudflare plugin, CDN Enabler) saves manual URL rewriting and manual purging.
WAF and DDoS protection. Proxy CDNs typically bundle this by default; pull-zone CDNs like Bunny.net focus more narrowly on fast asset delivery and usually charge extra, or omit it, for security features.

Proxy setups suit anyone wanting a “set-and-forget” security layer. Pull-zone setups suit anyone who cannot touch nameservers, perhaps because DNS is managed by an agency or a corporate IT team elsewhere in the business.

Setting up a CDN for WordPress: proxy/DNS versus pull-zone routes

The two integration paths diverge early, so pick one before you start clicking through dashboards.

Proxy/DNS route (Cloudflare and similar):

Add your site to the CDN dashboard and update your domain’s nameservers at the registrar.
Install the official Cloudflare WordPress plugin, which handles Automatic Platform Optimisation, automatic cache purge on content updates, and WordPress-specific WAF rules out of the box.
Wait for DNS propagation, then confirm the orange cloud icon is active on your A record.

Pull-zone route (Bunny.net and similar):

Create a pull zone pointing at your origin server, then set a custom CDN hostname such as cdn.yoursite.co.uk.
Install CDN Enabler to rewrite asset URLs sitewide, or use your provider’s own plugin if one exists.
Pull-zone CDNs are typically cheaper and simpler to remove if you decide to revert, since your DNS never changed in the first place.

Cache plugin integration: WP Rocket, W3 Total Cache and LiteSpeed Cache all accept a CDN hostname field under their CDN settings tab, letting the plugin rewrite static asset URLs automatically without touching theme files. This pairs well with either integration route above.

Host-provided toggles: Some hosts, including Kinsta, offer a built-in CDN switch that removes almost all manual configuration. If your host offers this, it is usually the easiest starting point.

Pro Tip: If you’re managing several client sites, standardise on one integration method across all of them. Mixing proxy and pull-zone approaches across a portfolio makes troubleshooting far slower when something breaks at 5pm on a Friday.

What security settings and cache exclusions do you need?

Two mistakes account for most WordPress CDN failures: wrong SSL mode and missing cache exclusions.

Leaving SSL in “Flexible” mode is insecure for production sites because traffic between the CDN and your origin server travels unencrypted. Full (Strict) mode requires a valid certificate on your origin. If you don’t have one, generate the provider’s Origin CA certificate and install it on your host, then switch to Full (Strict) in the CDN panel.

Cache exclusions to set before going live:

/wp-admin and /wp-login.php, to avoid caching the dashboard or breaking login sessions.
/cart and /checkout, since caching these on a WooCommerce store risks showing customers stale prices or someone else’s cart contents.
Any request carrying a logged-in cookie, such as woocommerce_items_in_cart.

Setup guidance from Pantheon’s learning centre puts the basic configuration steps for a standard CDN at 15 to 30 minutes, but that estimate assumes exclusions are set correctly the first time. Get them wrong and diagnosing a broken cart can eat far more time than the setup itself.

Purge strategy: automatic purge via the plugin handles most content updates. Manual purge is still worth doing after a theme change, a plugin update, or any edit that doesn’t trigger WordPress’s normal save hooks.

How do you verify the CDN is actually working?

Confirming activation takes minutes and prevents you from assuming performance gains that never happened.

Check response headers. Look for cf-cache-status: HIT (Cloudflare) or an equivalent header from your provider, plus an age value showing how long the asset has been cached.
Run a before/after speed test using WebPageTest or Lighthouse, watching Time to First Byte and asset load timings specifically.
Confirm cache hit ratio in your provider’s dashboard across a sample of pages, not just the homepage.
Test functionally as a real user would. Log in, submit a contact form, and complete a checkout to confirm nothing broke behind the scenes.

Check	Tool or location	What “working” looks like
Cache status header	Browser dev tools, Network tab	`HIT` on repeat requests
TTFB improvement	WebPageTest or Lighthouse	Lower TTFB than pre-CDN baseline
Cache hit ratio	Provider dashboard	Majority of static requests served from edge
Checkout function	Manual test as a logged-in user	Correct cart contents, successful payment

Ongoing maintenance and when a CDN isn’t worth it

A CDN isn’t a one-off task. Review cache hit ratio and WAF logs periodically, confirm your SSL certificate hasn’t lapsed, and purge manually after any significant site change.

Check cache hit ratio monthly; a persistently low ratio suggests your exclusion rules are too broad.
Review WAF logs for false positives blocking legitimate visitors or checkout traffic.
Renew or verify origin certificates before they expire, particularly with Full (Strict) SSL.
Purge the cache immediately after major design or plugin updates.

Cost shapes vary: some providers charge pay-as-you-go by bandwidth, others offer flat-rate tiers with generous free allowances. A CDN adds little value for a purely local audience with negligible traffic, or for sites built almost entirely around real-time, personalised content that can’t be cached anyway.

CDN terminology every WordPress site owner should understand

CDN jargon puts people off before they’ve even opened a settings panel, which is a shame because the underlying ideas are simple once named properly.

A CDN node (or edge server) is a physical server positioned close to visitors geographically, storing a copy of your site’s static files so requests don’t have to travel back to your origin server every time. Your origin server is wherever WordPress itself actually lives, whether that’s shared hosting or a managed WordPress host.

Origin pull means the CDN fetches and caches content automatically the first time a visitor requests it, then serves that cached copy to everyone after. This is how pull-zone providers like Bunny.net typically work, and it requires no manual upload step. Origin push, by contrast, means you upload files to the CDN’s storage directly rather than waiting for a visitor to trigger the first fetch. Push setups suit large media libraries where you want everything cached in advance, but they add complexity most WordPress sites don’t need.

Edge caching is the general term for storing copies of content at these distributed nodes rather than solely at the origin. It’s what makes a CDN faster than serving every request from a single server, particularly for visitors far from your hosting location.

Cache purge (or invalidation) removes a stale cached copy so the next request pulls a fresh version from the origin. Understanding these four terms is enough to read almost any CDN provider’s documentation without translation.

Comparing CDN providers built for WordPress

No single CDN suits every WordPress site, and the right pick depends on how much control versus convenience you want.

Cloudflare is the most widely used free-tier option, with a footprint spanning over 300 cities in more than 120 countries and bundled DDoS protection plus a Web Application Firewall. Its strength is the “set-and-forget” security layer; its main drawback is that proxy mode requires changing nameservers, which not every site owner can do if DNS is managed elsewhere.

Bunny.net takes the pull-zone approach, focusing narrowly on fast, low-cost asset delivery without requiring a nameserver change. It’s a strong fit for anyone who wants speed gains without touching DNS, though security features like WAF rules typically cost extra or aren’t included by default, unlike Cloudflare’s bundled approach.

Host-provided CDNs, such as the built-in toggle some managed hosts offer, remove almost all configuration decisions. The trade-off is flexibility: you’re locked into whatever the host’s CDN partner offers, with little room to fine-tune caching rules.

For most small business sites, Cloudflare’s free tier paired with the official plugin covers both performance and security in one step. Sites that specifically cannot alter DNS, perhaps because it’s managed by a third-party IT provider, are better served by a pull-zone setup using CDN Enabler.

Security beyond the WAF: hotlink protection and token authentication

A Web Application Firewall stops obvious attacks, but it doesn’t stop someone else quietly draining your bandwidth by embedding your images on their own site.

Hotlink protection blocks other websites from linking directly to your images, videos, or other static files and serving them to their own visitors at your bandwidth’s expense. Most CDN providers let you restrict asset delivery to requests originating from your own domain, rejecting anything referred from elsewhere. This matters more than most site owners assume, particularly for image-heavy blogs or product photography that gets scraped and reused without permission.

Token authentication goes a step further, generating a time-limited, signed URL for sensitive or paid content so a link only works for a short window before it expires. This suits sites distributing downloadable files, gated resources, or video content where you don’t want a shared link circulating indefinitely on forums or social media.

Neither feature is essential for a typical brochure or small e-commerce site, but both become worth configuring once a site has valuable static assets worth protecting. Setting them up usually takes a few extra minutes inside the same CDN dashboard used for the main setup, well within the same session as your initial WordPress CDN configuration.

Does a CDN affect SEO, and how do you avoid indexing problems?

A correctly configured CDN improves SEO indirectly, through faster load times and better Core Web Vitals scores, both of which Google’s ranking systems factor in. Misconfigured, though, it can quietly cause duplicate content or crawl issues.

The main risk is serving your site under two different hostnames, your original domain and a CDN subdomain, without a canonical tag pointing search engines to the correct version. Most reputable CDN setups avoid this by proxying traffic under your existing domain rather than serving content from a separate CDN hostname, which is one advantage of the proxy/DNS approach over some pull-zone configurations.

If you do use a pull-zone with a visible CDN hostname for assets like images and scripts, that’s generally fine for SEO since search engines don’t typically index static asset URLs as separate pages. The real hazard is accidentally allowing your CDN hostname to serve full HTML pages that get crawled and indexed alongside your main domain, creating duplicate content. Check your robots.txt and canonical tags specifically cover any CDN-served HTML, and confirm your sitemap only references your primary domain.

Page speed improvements from CDN adoption feed directly into the Core Web Vitals metrics Google uses as ranking signals, so a correctly configured CDN is a net positive for search visibility rather than a risk, provided the indexing basics above are handled.

How do you handle dynamic content and logged-in visitors?

Static assets are the easy part of any CDN setup. Dynamic content, anything that changes per visitor, is where naive configurations fall apart.

WooCommerce carts, membership dashboards, personalised recommendations and logged-in admin sessions all need to bypass the cache entirely, or visitors risk seeing someone else’s data. Explicitly excluding paths like /cart and /checkout, along with cookies such as woocommerce_items_in_cart, is the standard fix, and it’s worth revisiting this list any time you install a new plugin that adds personalised functionality.

Some CDNs support cache bypass based on cookie presence, meaning any request carrying a session or login cookie skips the cache automatically rather than requiring you to list every dynamic URL by hand. This is more robust than maintaining a manual path list, since new dynamic endpoints from future plugins are covered automatically.

For sites with heavy personalisation, such as membership platforms or stores with logged-in pricing tiers, consider caching only the truly static elements, images, CSS, JavaScript, fonts, while leaving the HTML itself uncached or cached for a very short duration (measured in seconds rather than hours). This hybrid approach captures most of the performance benefit without the risk of serving stale personalised data.

Advanced caching: headers, TTLs and invalidation

Once the basic setup is stable, cache-control headers give you far more precision over what gets cached, for how long, and when it’s thrown away.

The Cache-Control header, sent by your origin server, tells the CDN how long an asset can be stored at the edge before it needs revalidating. A max-age=31536000 on a versioned CSS file (one with a hash in its filename) tells the CDN to cache it for a full year, since the filename itself will change if the file’s contents change. HTML pages typically use a much shorter max-age, often measured in minutes, since content updates more frequently.

Cache invalidation should follow a deliberate strategy rather than happening reactively. Automatic purge, triggered by the WordPress plugin on content save, handles the common case of publishing or editing a post. Manual purge remains necessary after theme changes, bulk data imports, or plugin updates that alter shared assets without triggering WordPress’s normal save hooks.

For WooCommerce sites specifically, caching plugins built for commerce often add product-specific purge rules, clearing only the affected product and category pages rather than flushing the entire cache on every stock update. That distinction matters at scale: a full purge on every inventory change can spike origin load right when a busy sale is driving traffic.

A publisher’s perspective on when a CDN earns its place

MedwayWebDesign only recommends a CDN once a project’s traffic patterns or asset weight actually justify it. A five-page brochure site rarely needs one; a WooCommerce store with international visitors almost always does. The deciding factor is whether static asset delivery is genuinely the bottleneck, not whether a CDN sounds impressive on a project brief. Anyone unsure where their own site falls should treat that uncertainty as reason enough to get a second opinion before touching DNS.

— Ian Rickard

Want the setup done properly the first time?

MedwayWebDesign is the alternative to trial-and-error DNS changes and guessed cache rules: rather than risking a broken checkout while you learn Cloudflare’s dashboard, our team handles the backup, correct SSL mode, and cache exclusions before anything goes live.

Our CDN implementation and audit service covers the full checklist this article walks through: a pre-change backup, Full (Strict) SSL configuration with the origin certificate installed correctly, cache exclusions mapped to your specific plugins and checkout flow, and a verification report confirming cache hit ratio and functional testing once it’s live. If your site already has performance issues beyond caching, our website speed optimisation checklist covers the wider picture. Get in touch for a free initial audit and quote, and find out whether a CDN is genuinely the right next step for your site before you touch a single DNS record.

Launch a WordPress CDN in 15–30 minutes for UK sites

Table of Contents