Connecting a CDN to WordPress and Verifying It's Actually Working

Cloudflare's default caching handles static file types reasonably well out of the box, but WordPress needs a couple of explicit rules to avoid two common failures: logged-in users seeing a cached page meant for logged-out visitors, and a cart or checkout page getting cached and showing stale contents. Under Caching > Cache Rules (or Page Rules on older accounts), set a rule that bypasses cache for paths like /wp-admin/*, /wp-login.php, and any cart or checkout URL your theme or e-commerce plugin uses.

For everything else — images, CSS, JS, fonts — a 'Cache Everything' rule with a browser cache TTL of several hours to a few days is typical, since these files rarely change and rarely need to be re-fetched from origin. If you're running WooCommerce, also exclude any cookie-based session paths from caching, since caching a response tied to one shopper's session and serving it to the next visitor is the single most common CDN misconfiguration on WordPress stores.

Don't assume the setup worked — check it. Open your site's browser developer tools, go to the Network tab, reload the page, and inspect the response headers on a static asset like an image or a CSS file. Look for a cf-cache-status header showing HIT (served from Cloudflare's edge cache) rather than MISS or DYNAMIC. The first load after a change often shows MISS while the edge cache populates; a reload a few seconds later should flip to HIT.

For a geographic check, use an online tool that tests load time from multiple regions, or ask someone in a different country to run a page speed test and compare their result to yours. If cf-cache-status never shows HIT on static assets, check that the DNS record's cloud icon is proxied (orange) and that no cache rule is unintentionally set to bypass everything.