This guide explains how to make your WordPress site easier to cache, faster to serve, and more stable under traffic.

A highly cacheable site allows Pressidium EDGE to serve more requests from EDGE instead of sending every request back to your origin server. This improves response times, reduces origin load, and helps your site handle more traffic with fewer bottlenecks.

It covers public and user-specific content, cookies, sessions, query strings, WooCommerce, membership sites, static assets, cache purging, and testing.

When to use this guide

Use this guide when you want to:

  • Improve cache efficiency on a WordPress site
  • Reduce origin load
  • Prepare a site before enabling or tuning Pressidium EDGE
  • Review WooCommerce, LMS, membership, or personalized pages for cache safety
  • Troubleshoot why public pages are not being cached as expected

What “highly cacheable” means

A highly cacheable WordPress site separates public content from user-specific content.

Public content can usually be cached and served safely to many visitors. User-specific content should usually bypass cache or vary by the right condition.

Examples of public content include:

  • Blog posts
  • Landing pages
  • Category pages
  • Static pages
  • Public product pages
  • Images, CSS, JavaScript, fonts, and other static assets

Examples of user-specific content include:

  • Cart pages
  • Checkout pages
  • Account pages
  • Logged-in dashboards
  • Personalized recommendations
  • Admin pages
  • Forms that use sessions, nonces, tokens, or user-specific state
  • Pages showing private user data

The goal is not to cache everything. The goal is to cache the right things safely.

Why cacheability matters

When a page is served from cache, the request can be handled closer to the visitor and does not need full WordPress processing at the origin.

This helps with:

  • Faster page responses
  • Lower Time to First Byte
  • Better Core Web Vitals
  • Reduced server load
  • Better stability during traffic spikes
  • Lower risk of origin overload
  • More predictable performance across regions

For WordPress sites, this matters because uncached requests often involve PHP execution, database queries, plugins, theme logic, and third-party integrations.

To understand how EDGE processes traffic before it reaches your origin, see How Pressidium EDGE works.

Start with a clean content model

Design your site so most visitors receive the same public version of a page.

Good examples:

  • A public blog post that looks the same for all logged-out visitors
  • A product page where price, images, and description are the same for all visitors
  • A landing page without session-based personalization
  • A documentation page with no user-specific modules

Less cacheable examples:

  • A page that changes based on every visitor’s cookie
  • A page that includes a unique greeting or user-specific block
  • A page that changes HTML based on every tracking parameter
  • A product page that mixes public product content with private cart data
  • A homepage that changes for each visitor based on session state

If a page is mostly public, avoid adding small personalized elements that make the whole page uncacheable.

Keep public pages public

For public marketing pages, blog posts, documentation, and product pages:

  • Avoid starting PHP sessions unnecessarily
  • Avoid setting visitor-specific cookies unless required
  • Avoid showing private user information in the HTML
  • Avoid embedding cart, account, or user-specific fragments directly into the page
  • Avoid changing the full HTML response for every visitor
  • Avoid using random values in the page output unless needed

If you need dynamic behavior, consider loading it separately with JavaScript after the public page has loaded.

Example:

Instead of rendering a user-specific banner into the cached HTML, serve the public page from cache and load the banner with a separate request that can bypass cache.

Separate dynamic actions from public pages

Forms, carts, search, filtering, and account actions often need dynamic handling.

Keep these actions separate from cacheable page views where possible.

Good pattern:

  • Public product page is cacheable.
  • Cart state is handled by a separate dynamic request.
  • Checkout and account pages bypass cache.
  • Form submissions use POST requests and are not cached.
  • Confirmation pages avoid exposing private data in cacheable HTML.

Avoid mixing session-specific content into otherwise public pages.

Use predictable URLs

Clean, stable URLs are easier to cache and easier to troubleshoot.

Use:

  • /about/
  • /services/
  • /blog/post-name/
  • /products/product-name/

Avoid unnecessary URL variations such as:

  • Multiple URLs showing the same page
  • Random query parameters
  • Session IDs in URLs
  • Tracking parameters that change the rendered HTML
  • Duplicate paths with inconsistent trailing slashes

If different URLs show the same content, they may create separate cache entries and reduce cache efficiency.

Be careful with query strings

Query strings can reduce cache efficiency because they create variations of the same page.

Common examples include:

  • ?utm_source=
  • ?utm_campaign=
  • ?fbclid=
  • ?gclid=
  • ?ref=

Tracking parameters should not change the page content. If they do not affect what the visitor sees, avoid using them to generate different HTML.

For functional query strings, make sure they are actually needed.

Examples:

  • Search results: ?s=keyword
  • Product filtering: ?color=blue
  • Pagination: ?page=2
  • Preview links: ?preview=true

Important: Do not cache preview, admin, cart, checkout, or account URLs as public pages.

Avoid unnecessary cookies

Cookies are one of the most common reasons public pages become less cacheable.

Some cookies are necessary. Others are added by plugins, popups, analytics tools, personalization systems, consent tools, or A/B testing scripts.

Review cookies used on public pages and ask:

  • Does this cookie change the HTML response?
  • Is this cookie required before the page loads?
  • Can this feature run after the cached page loads?
  • Can this cookie be limited to specific paths?
  • Can the page remain the same for visitors with and without this cookie?

A cookie that does not affect the page output should not force the whole page to bypass cache unless a plugin or cache rule uses that cookie as a bypass condition.

Avoid starting sessions for anonymous visitors

Some plugins start sessions for every visitor, even when the visitor is not logged in and has not added anything to a cart.

This can make pages harder to cache.

Check whether your theme or plugins start sessions on normal public pages. If they do, review whether that behavior is required.

For WooCommerce, session behavior is often needed for cart and checkout flows, but it should not make every public product or category page uncacheable unless necessary.

Keep logged-in and logged-out behavior separate

Logged-out visitors usually receive public content and are better candidates for caching.

Logged-in visitors may see:

  • Admin bars
  • Account information
  • Membership content
  • Personalized pricing
  • Private dashboards
  • Saved preferences
  • Restricted content

Do not assume logged-in and logged-out users can safely receive the same cached response.

Check both versions when testing cache behavior:

  1. Open the page while logged out.
  2. Open the page while logged in.
  3. Compare the content.
  4. Confirm private content is not present in the logged-out version.
  5. Confirm logged-in pages behave correctly.

Keep WooCommerce cache-safe

WooCommerce sites can still benefit from caching, but they need clear separation between public and transactional pages.

Usually cacheable:

  • Product pages
  • Product category pages
  • Brand or collection pages
  • Blog posts
  • Landing pages
  • Static content

Usually not cacheable as shared public pages:

  • Cart
  • Checkout
  • My Account
  • Order received pages
  • Payment pages
  • Customer-specific pricing pages
  • Pages showing cart count, cart contents, or account details in the HTML

Best practices:

  • Keep cart and checkout paths excluded from public caching.
  • Avoid rendering cart contents into the full page HTML.
  • Load cart fragments or user-specific elements separately.
  • Test add-to-cart, checkout, coupons, and payment flows after cache changes.
  • Avoid caching pages that include private order or customer data.

Important: Never cache checkout, account, or order pages as public content.

Keep membership and LMS sites cache-safe

Membership and LMS sites often combine public marketing pages with private course or member content.

Usually cacheable:

  • Public landing pages
  • Public course catalog pages
  • Public blog posts
  • Public documentation or help pages

Usually not cacheable as shared public pages:

  • Member dashboards
  • Course progress pages
  • Account pages
  • Paid lesson content
  • Quiz pages
  • Certificates
  • Private community pages

Best practices:

  • Separate public course marketing pages from private learning pages.
  • Keep member-only content behind clear logged-in checks.
  • Avoid mixing private progress data into public catalog pages.
  • Test as logged out, free member, paid member, and admin where relevant.

Optimize static assets

Static assets are usually excellent cache candidates.

Examples:

  • Images
  • CSS
  • JavaScript
  • Fonts
  • SVG files
  • PDFs
  • Downloadable public files

Best practices:

  • Use versioned filenames for CSS and JavaScript when files change.
  • Avoid constantly changing asset URLs.
  • Compress images before serving them.
  • Use modern formats where appropriate, such as WebP or AVIF.
  • Remove unused CSS and JavaScript where possible.
  • Avoid loading large assets on pages that do not need them.
  • Keep third-party scripts under control.

Versioned assets are easier to cache for longer periods because a new file URL can be generated when the asset changes.

Example:

theme.2.4.1.css or theme.css?ver=2.4.1

To review supported front-end optimization options, see Optimize CSS and JavaScript with the Performance Plugin and Automatic image optimization via the Performance Plugin.

Use cache purging intentionally

Cache purging should be targeted where possible.

Purge when:

  • A page is updated
  • A template changes
  • A menu changes
  • A product changes
  • A category archive changes
  • A global layout element changes
  • CSS or JavaScript changes
  • A plugin or theme update affects page output

Avoid purging everything for every small content edit unless necessary.

A full purge may be useful after major design, theme, or plugin changes. For normal publishing, targeted purges are usually better.

To manage cache purges from the Dashboard, see Manage cache in Pressidium EDGE.

Avoid plugin overlap

Multiple caching, optimization, CDN, firewall, and security tools can conflict.

Common problems include:

  • Different tools setting different cache headers
  • Multiple plugins minifying the same assets
  • Several tools rewriting URLs
  • Conflicting page cache rules
  • Firewall or bot rules blocking legitimate requests
  • Cache purges not reaching the correct layer
  • Stale content caused by unclear cache ownership

Best practice: Decide which tool controls each function.

For example:

  • EDGE handles edge caching, WAF, DDoS protection, CDN delivery, and routing.
  • The Performance Plugin handles WordPress-aware integration and supported front-end optimizations.
  • Avoid enabling duplicate page caching or conflicting CDN rewriting in other plugins unless you have tested the setup carefully.

Use cache rules only when needed

EDGE is designed to work with sensible defaults, but custom rules are useful when your site has specific requirements.

Use custom cache rules for cases such as:

  • Excluding a specific path from cache
  • Bypassing cache for a specific cookie
  • Applying different behavior to API routes
  • Handling mobile-specific content
  • Separating content by country or region
  • Adjusting cache duration for specific content types

Keep rules simple. A small number of clear rules is easier to maintain than a long rule set with overlapping conditions.

To exclude specific URLs or cookies from cache, see Manage cache URL and cookie exclusions.

Test after every important change

After changing cache, firewall, DNS, plugin, or theme settings, test the site as a real visitor.

Check:

  1. Homepage
  2. A blog post
  3. A key landing page
  4. A product or service page
  5. Search or filtering, if used
  6. Forms
  7. Login
  8. Cart and checkout, if used
  9. Account pages, if used
  10. Admin access

Test both logged-in and logged-out behavior where relevant.

Check cacheability during development

Cacheability is easier to preserve when it is considered during development.

When adding a new feature, ask:

  • Does this feature need to change the full HTML response?
  • Does it require a cookie?
  • Does it start a session?
  • Does it expose user-specific data?
  • Can it be loaded separately?
  • Can the public page remain cacheable?
  • Does it affect logged-in users only?
  • Does it need a cache bypass rule?

This is especially important for WooCommerce, LMS, membership, multilingual, and personalization features.

Common patterns that reduce cacheability

Review your site for these patterns:

  • Starting sessions for all visitors
  • Setting cookies on every page without need
  • Rendering cart contents into all pages
  • Showing personalized content in public HTML
  • Generating random page output on every request
  • Using many tracking query parameters as content variants
  • Running A/B tests that change server-rendered HTML for every visitor
  • Using plugins that bypass cache globally
  • Adding broad “do not cache” headers
  • Keeping many overlapping optimization plugins active
  • Using unversioned assets with long cache durations

These patterns do not always need to be removed, but they should be intentional.

If public pages are not being cached as expected, see Troubleshoot cache not working. If the issue may be caused by a plugin, see Troubleshoot WordPress plugin conflicts.

Use this checklist when reviewing a WordPress site for EDGE.

  • Public pages do not contain private user data
  • Logged-out pages are mostly identical for all visitors
  • Cart, checkout, account, and admin pages bypass public cache
  • WooCommerce sessions are limited to where they are needed
  • Membership or LMS private pages are separated from public pages
  • Unnecessary cookies are removed or limited
  • Public pages do not start sessions unnecessarily
  • Tracking parameters do not create unique HTML versions
  • Static assets use stable or versioned URLs
  • CSS, JavaScript, images, and fonts are optimized
  • Duplicate caching and optimization plugins are avoided
  • Custom cache rules are simple and specific
  • Cache purge behavior is tested after content updates
  • Logged-in and logged-out behavior is tested separately
  • Forms, search, filtering, and API requests are tested

Signs your site is highly cacheable

Your site is in good shape when:

  • Public pages load quickly for logged-out visitors
  • Repeat visits are faster
  • Origin load drops after EDGE activation
  • Cache purges update content predictably
  • Static assets are served efficiently
  • Cart, checkout, login, and account flows still work correctly
  • Logged-in users do not see stale or incorrect private content
  • Performance remains stable during traffic spikes

To review cache behavior and performance data, see Review cache analytics and Review performance analytics.

Need help?

Contact Support if you are unsure whether a page should be cached or bypassed.

Include:

  • The affected domain
  • The affected URL
  • What the page does
  • Whether it is public or user-specific
  • Whether users log in to access it
  • Any cookies or sessions involved
  • The expected cache behavior
  • Any related screenshots or test results

Support can help review cache behavior and recommend safe rule adjustments.

Where to go next