Short answer: To test if your CDN is working on WordPress, check HTTP response headers for a CDN-provider header, verify the IP address resolves to your CDN edge server, and confirm resources load from the CDN domain instead of your origin server. Use browser dev tools, curl commands, or online CDN checkers.
Key takeaways
- Check response headers for a CDN provider header.
- Use curl or browser tools to inspect resource URLs.
- Verify IP geolocation matches your CDN edge locations.
- Run performance tests to confirm speed improvements.
- Test cache purge and TTL behavior.
- Exclude admin pages from CDN to avoid conflicts.
What you will find here
You installed a CDN plugin, configured your DNS, and waited for propagation. But is it actually working? Many WordPress users assume their CDN is active when it isn’t. Maybe the DNS didn’t update, the plugin misconfigured, or something is cached on your end. Let me show you how to test your CDN setup with practical steps you can run right now.
What Should a Working CDN Look Like?
A properly working CDN serves your static assets — images, CSS, JavaScript — from edge servers near your visitors. Instead of every request hitting your origin server, the CDN intercepts them and delivers cached copies. When it works, your site loads faster, your server handles less traffic, and your visitors see lower latency.
The tricky part is that many things can break this chain. Misconfigured DNS, conflicting caching plugins, or incorrect CDN settings in WordPress can all prevent your CDN from doing its job.
Method 1: Check HTTP Response Headers
Every CDN adds custom headers to the responses it serves. These headers tell you which CDN handled the request. Here’s how to check them.
Using Browser Developer Tools
Open your site in Chrome or Firefox, right-click anywhere, and select Inspect. Go to the Network tab, refresh the page, and click on any resource (like a stylesheet or image). Look at the Response Headers section. You should see headers like x-cache: HIT, cf-cache-status: HIT, x-served-by, or server: cloudflare depending on your provider.
If you see x-cache: MISS on every request, that means the CDN is passing through but not caching. That’s a sign something is off with your cache configuration.
Using the curl Command
Open your terminal and run:
curl -I https://yoursite.com/wp-content/uploads/2024/01/image.jpgLook for a header like cf-ray (Cloudflare), x-amz-cf-id (CloudFront), x-cache: HIT from (StackPath, KeyCDN, etc.), or server: bunny (BunnyCDN). No CDN headers? Your content isn’t being served by the CDN.
Method 2: Verify Resource URLs
Open your site’s page source (right-click > View Page Source). Look for URLs of images, scripts, and stylesheets. If your CDN is set up correctly, these should point to your CDN domain (like cdn.yoursite.com or a provider-specific domain like yoursite.cloudfront.net). If they still point to your original domain, the CDN plugin isn’t rewriting URLs properly.
Check both the page source and actual loaded resources in Network tab. Sometimes the source URL looks correct but the server redirects it back to your origin. That’s a DNS or configuration issue.
Method 3: IP Address Geolocation
Your CDN should serve visitors from an edge server close to them. You can test this by checking the IP address your site resolves to from different locations. Use a tool like whatsmydns.net or run ping yoursite.com from different servers. If the IP matches your CDN provider’s range and changes based on your location, it’s working.
If you always get the same IP — and it’s your origin server’s IP — your DNS isn’t pointing to the CDN.
Method 4: Performance Testing
Run a speed test from multiple locations using services like GTmetrix or Pingdom. Look at the waterfall chart. You should see that static assets load from a different domain (the CDN) and have shorter download times. Also check the Time to First Byte (TTFB). A good CDN should reduce TTFB for static resources because the edge server can respond quickly.
If you notice that TTFB is still high for cached resources, the CDN might be proxying requests back to your origin instead of serving from cache. That’s often a sign of dynamic content being requested without proper cache rules.
Common Issues That Break CDN Delivery
Even if your CDN shows as active, several things can prevent proper delivery:
- Plugin conflicts: Some caching plugins override CDN headers. Ensure you’re using a compatible combination. Check our comparison of caching plugins to see which work best with CDNs.
- SSL mismatches: If your origin uses HTTPS but the CDN URL is HTTP (or vice versa), browsers may block mixed content, and the CDN might not cache properly.
- Cache bypass for logged-in users: Many CDN setups bypass cache for admin or logged-in users. Test from an incognito window or a different browser.
- Wrong DNS records: Double-check that your CNAME or A records point to your CDN provider, not your web host.
What to Do If Your CDN Isn’t Working
If your tests show the CDN isn’t delivering content, start with these steps:
- Purge your CDN cache from the provider’s dashboard. Sometimes old cached configurations cause issues.
- Disable other caching plugins temporarily to rule out conflicts. Re-enable one by one while testing.
- Verify DNS propagation using a global DNS checker. If records are still pointing to your host, wait or update your DNS.
- Check your CDN plugin settings. Ensure you’ve entered your CDN URL correctly and enabled rewriting for CSS, JS, and images.
- Review your origin server’s firewall or security rules. Some hosts block requests from CDN IPs. Whitelist your CDN provider’s IP ranges.
If you’re still stuck, revisit your caching fundamentals. Our beginner’s guide to WordPress caching explains the interplay between caching layers.
Testing your CDN doesn’t require advanced tools. A few minutes with your browser’s dev tools and a terminal can confirm whether your setup is actually working. Once you’ve verified it, you’ll enjoy faster load times and reduced server load. If you find problems, the troubleshooting steps above will help you fix them quickly.
Frequently asked questions
How do I test if my CDN is caching content?
Check the response headers of static files using browser dev tools. Look for headers like x-cache: HIT or cf-cache-status: HIT. If you see MISS or DYNAMIC, the CDN is not caching that resource. Also verify that the server header shows your CDN provider.
Can I test CDN performance from multiple locations?
Yes, use online tools like GTmetrix or Pingdom that have multiple test locations. Compare load times from different regions. If the CDN is working, content should load faster from locations closer to the edge server. Also check TTFB; it should be low for cached assets.
Why does my site still load slow even with a CDN?
A CDN only accelerates static assets. If your site is slow due to uncached dynamic content, large unoptimized images, or poor server performance, the CDN won’t help much. Check if the CDN is actually serving your assets by inspecting resource URLs and headers.
How do I know if my CDN plugin is rewriting URLs correctly?
View the page source and check URLs for images, CSS, and JS files. They should point to your CDN domain (e.g., cdn.yoursite.com). If they still use your original domain, the plugin isn’t rewriting. Also inspect the Network tab to confirm loaded resources come from the CDN domain.
Do I need to clear my local cache to test CDN?
Yes, because your browser may have cached old versions from before the CDN was set up. Test in incognito/private mode or clear your browser cache. Also use tools like curl from a different network to avoid local DNS and cache interference.