WordPress CDN settings: what actually needs to be cached

Content delivery networks promise faster page loads and lower server bills. But most WordPress operators flip the switch and trust the defaults—only to find checkout pages breaking, comment forms failing, or member dashboards showing stale data.

The problem isn’t the CDN. It’s that most presets treat every WordPress site like a static blog. If you run anything interactive—memberships, WooCommerce, course platforms, paywalled content—you need to explicitly tell your CDN what not to cache.

What should always be cached

Start with the easy wins. These asset types are static, rarely change, and benefit most from edge caching:

• Images, CSS, JavaScript — anything in /wp-content/uploads/, /wp-content/themes/, and /wp-content/plugins/ with file extensions like .jpg, .png, .css, .js, .woff2.
• Publicly visible post and page content — the rendered HTML of non-logged-in pages. Cache for 1–4 hours if you publish frequently, 24 hours if you don’t.
• RSS and Atom feeds — most readers poll these hourly. Cache for 30–60 minutes.

Set a Cache-Control: public, max-age=3600 header for these. Most managed WordPress hosts and CDN plugins handle this automatically.

What should never be cached

These paths and query strings serve user-specific or time-sensitive data. Caching them breaks functionality or leaks private information:

• /wp-admin/ and /wp-login.php — the dashboard and login screen. Always bypass.
• Any URL with a query string containing ?add-to-cart=, ?edd_action=, ?nocache, or session tokens — these trigger actions or personalised views.
• Checkout, cart, account, and membership pages — if you’re using WooCommerce, Easy Digital Downloads, MemberPress, or similar, create explicit CDN rules to bypass these slugs.
• Comment forms and AJAX endpoints — /wp-comments-post.php and /wp-admin/admin-ajax.php must be dynamic.
• Any page that reads cookies for logged-in state — if a page checks wordpress_logged_in_* cookies to show different content, don’t cache it.

Most CDNs let you define cache bypass rules by URL path, query string, or cookie name. Use all three.

The logged-in user problem

WordPress sets a wordpress_logged_in_* cookie when someone signs in. If your CDN caches pages that check this cookie, logged-in users see cached, logged-out content—or worse, other users’ dashboards.

The fix: configure your CDN to bypass cache entirely when any wordpress_logged_in_ cookie is present. Most managed hosts (Kinsta, WP Engine, Flywheel) do this by default. If you’re on a VPS or using Cloudflare, you’ll need to add this rule manually.

If you run a membership site or paywalled newsletter archive, test this before launch. Log in, visit a member-only page, then open an incognito window and visit the same URL. If you see the same content, your CDN is leaking.

The one setting that fixes most problems

Most CDN misconfigurations come down to query strings. By default, many CDNs treat example.com/page and example.com/page?utm_source=twitter as different URLs—and cache both separately.

This fragments your cache, wastes memory, and reduces hit rates. The fix: strip query strings before caching, unless the query string affects content (like ?p=123 or ?s=search).

In Cloudflare, this is called “Query String Sort.” In Fastly, it’s “query string handling.” In WP Rocket or W3 Total Cache, it’s “ignore query strings.”

Whitelist the query strings that do matter—typically p, page_id, s, and preview_id—and strip everything else.

Testing your config

After you set cache rules, test three scenarios:

• Logged-out visitor — Pages should load from cache. Check response headers for X-Cache: HIT or CF-Cache-Status: HIT.
• Logged-in user — Pages should not cache. Look for X-Cache: BYPASS or CF-Cache-Status: DYNAMIC.
• Checkout or form submission — These must always be dynamic. If they cache, payments and signups will fail.

Use your browser’s network inspector or a tool like WebPageTest to inspect headers. If you see HIT on a logged-in page, tighten your cookie rules.

Most CDN problems aren’t speed problems—they’re config problems. Get these rules right once, and your site will be both faster and more reliable.

Want more infrastructure deep-dives like this? Subscribe to One Two Three Send and get one operator-focused article every day—no fluff, no filler.