Edge caching stores a cacheable WordPress response at CDN data centers close to visitors, so later requests can be served without reaching your origin server. Images, stylesheets, scripts and other static files are usually cacheable automatically. Public HTML pages require an explicit policy, because the same URL can produce either shareable content or private, logged-in, cart and checkout data.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
For WordPress, the safe pattern is simple: cache only anonymous, successful GET or HEAD responses; bypass every request that can contain user-specific or state-changing data; purge cached pages when content changes; then verify both anonymous and authenticated requests. Cloudflare APO automates much of this WordPress-aware behavior, while manual Cache Rules provide more control over paths, cookies, cache keys and time-to-live settings.
As an Amazon Associate I earn from qualifying purchases.
What edge caching means for a WordPress site
A normal page request travels from a visitor’s browser to your web server, PHP runtime, database and back again. Edge caching inserts a CDN between the visitor and the origin. When an eligible response is stored at an edge location, a later visitor near that location receives the stored response directly. The origin is contacted only when the object is missing, expired, purged or excluded from caching.
Cloudflare describes this model as caching content across globally distributed data centers. The practical result is fewer origin requests and shorter network distance for cacheable responses; it is not a guarantee that every WordPress request becomes faster, because uncached or personalized requests still execute at the origin.
#1 Best Overall
Static files and HTML follow different default rules
| Response type | Typical default | What you must decide |
|---|---|---|
| Images, CSS, JavaScript, fonts and other static assets | Usually eligible for CDN caching under provider defaults | How long they remain fresh, and how version changes are invalidated |
| Public WordPress HTML | Not cached by default by Cloudflare | Which pages are public, the edge TTL, cache key and purge behavior |
| Logged-in, account, cart, checkout and other personalized responses | Should bypass shared cache | Reliable path, cookie, header and method exclusions |
The distinction matters because a cached image can normally be reused by everyone, while cached HTML may contain a user’s name, permissions, cart contents or security token.
When WordPress HTML is safe to share
Shared HTML caching is appropriate for a response whose body is identical for anonymous visitors during its freshness period. Typical examples include published posts, pages, category archives and other public landing pages that do not vary by visitor, cookie, account state or request header.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Do not put a response in a shared cache when it is private, transactional or state-changing. That includes administration screens, login and authentication flows, previews, feeds, search results that vary by query, REST or other API endpoints, cron requests, account pages, carts, checkout and order confirmation pages.
Cloudflare’s eligibility model
Cloudflare’s documented APO behavior requires all of the following before an HTML response can be stored at the edge:
- The request uses GET or HEAD.
- The origin returns a successful 200 HTML response.
- The response permits edge caching through the
cf-edge-cacheheader. - No bypass cookie is present.
- No excluded path or risky request header matches.
- The query string is one Cloudflare supports for caching.
A response can therefore remain uncached even when a rule appears correct. Eligibility is checked for each request; a cache rule does not override a method, cookie, header or origin response that says the content must remain private.
Cloudflare APO or manual Cache Rules?
Both approaches can cache WordPress HTML, but they suit different operating models.
| Decision area | Cloudflare APO for WordPress | Manual Cache Rules |
|---|---|---|
| Setup effort | Lower: the WordPress plugin connects publishing events and applies WordPress-aware behavior | Higher: you define eligible responses, exclusions, TTLs and purge integration |
| WordPress awareness | Designed to bypass logged-in and administrator users and react when content is published | Depends on the rules and purge mechanism you create |
| Control over paths and cache keys | Less granular than a policy built specifically for your site | More explicit control over path matches, query strings, cookies, headers and cache keys |
| TTL control | Uses the product’s managed behavior and available CDN settings | You set an Edge TTL and can separately consider Browser Cache TTL |
| Debugging visibility | Convenient automation, but fewer decisions are exposed to you | Every match and bypass condition is inspectable in the rule set |
| Purge automation | The plugin can notify the edge when WordPress content changes | You must connect publishing events to purge, or accept the stale window |
APO is usually the safer starting point for a conventional WordPress publication that wants edge HTML caching without maintaining a large exclusion policy. Manual rules are preferable when the site has unusual URL patterns, several applications on one hostname, strict cache-key requirements or an operations team that needs explicit control.
Prepare the site before enabling HTML caching
- List every public URL pattern that can be identical for anonymous visitors.
- List every private or state-changing path, including custom account, membership, booking, store and form routes.
- Identify cookies that indicate a logged-in session, comment session, cart, checkout or other personalization.
- Record API, webhook, cron, preview and search endpoints that must always reach the application.
- Confirm that the origin remains reachable if the CDN is temporarily bypassed.
- Choose an initial Edge TTL that your editorial workflow can tolerate. A longer TTL reduces origin traffic but increases the time a missed purge can remain visible.
- Plan a purge method before publishing the first cached page.
Do not begin by caching the entire hostname. Start with a narrow, observable set of public HTML responses and expand only after testing.
Step-by-step: set up edge caching for WordPress
1. Put the WordPress hostname behind the CDN proxy
In your CDN dashboard, proxy the hostname that serves WordPress and verify that DNS, TLS and the origin still work through the proxy. Keep a way to reach the origin for diagnostics, but do not expose an alternate public hostname that bypasses the same security and access controls.
2. Keep the provider’s static caching defaults
Leave images, CSS, JavaScript and fonts eligible for caching unless your deployment process requires a special exception. Static files generally do not contain a visitor’s account data, so they are the lowest-risk place to begin. Use versioned filenames or an explicit purge process when replacing an asset.
3. Choose APO or a manual HTML policy
For APO, install and connect the provider’s WordPress plugin, then allow it to manage cache updates when content is published. Cloudflare states that APO lets you manage WordPress normally while its integration handles edge behavior. Confirm that the plugin is connected to the same zone and hostname that serves the site.
For manual configuration, open the zone’s Caching area and create a Cache Rule for selected public HTML responses. Do not use a blanket “cache everything” rule until the bypass policy is complete and tested.
4. Define the eligible response
Your allow condition should require the request and response characteristics that make sharing safe:
- Request method is GET or HEAD.
- Response status is 200.
- Response is HTML, normally identified by its content type.
- Request path is within your public-page scope.
- No exclusion cookie, authorization signal or no-cache instruction is present.
Set an Edge TTL. This is the maximum period an object remains fresh or available from the edge according to the provider’s cache policy. Treat it as a staleness budget, not as a performance score.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors5. Add bypass conditions before activating the rule
Put exclusions ahead of the broad public-page rule. The exact names of custom cookies vary, but the categories below should be covered.
| Condition | Examples to bypass | Reason |
|---|---|---|
| Administrative paths | /wp-admin/, login and authentication routes |
These responses contain controls, nonces or account state |
| Commerce and account paths | Cart, checkout, account, order and payment URLs | Content changes with the visitor’s session or transaction |
| Editorial and automation paths | Preview URLs, feeds, cron and webhook endpoints | They are temporary, machine-facing or must reflect immediate changes |
| Application endpoints | REST, GraphQL and other API routes | Responses may be personalized or used for state-changing operations |
| Visitor-specific cookies | Logged-in, session, comment, cart or commerce cookies | A shared object could disclose one visitor’s data to another |
| Request headers | Authorization and headers requesting no-cache | The caller or origin is explicitly asking for private or fresh content |
| Methods | POST, PUT, PATCH, DELETE and other non-GET/HEAD methods | These methods can change state and should not be served from a read cache |
| Query strings | Search, tracking or application parameters that change the body | Combining different responses under one cache key creates incorrect content |
Also inspect the origin’s Set-Cookie and Cache-Control headers. Cloudflare’s default behavior does not cache responses that include Set-Cookie; a rule that ignores those signals can create privacy and freshness defects.
6. Connect publishing to purge
A purge removes matching objects from the edge. The next request at each data center fetches the current response from the origin, returns MISS, and repopulates that location. Subsequent eligible requests can then return HIT. Purge after publishing, updating navigation, changing templates or modifying content that appears on many pages.
APO can receive WordPress publishing events through its plugin. With manual rules, use the CDN’s purge mechanism or an equivalent deployment hook. Purging everything is easy but expensive in cache efficiency; where practical, purge the changed URL and related archive or home-page objects.
Free tools Windows power users keep installed
One-click scans. No signup required.
7. Test before production rollout
- Open a public page in a private browser window and record the response headers, status code, cookies and body.
- Request the same URL again from the same region. An eligible page should move from an initial
MISStoHITafter the edge is populated. - Sign in and request that URL with the logged-in session. Confirm that the response is bypassed or dynamic and that no private markup from another user appears.
- Exercise cart, checkout, account, preview, search, feed and API URLs. They should never become shared HTML cache hits.
- Publish a small content change, purge through the configured path and request the page again. Verify that the first request retrieves the new content.
- Repeat from more than one network or geographic location if your audience is distributed. Different data centers populate independently.
Understand Edge TTL, Browser TTL and staleness
Edge TTL controls how long the CDN can consider an object fresh or retain it at an edge location. Browser Cache TTL controls how long a visitor’s browser can reuse its local copy. They are separate decisions: purging the edge does not necessarily erase a copy already stored in a browser.
Set the Edge TTL according to publishing frequency and the reliability of your purge process. A news page that changes several times per hour needs a shorter freshness window or dependable URL purges. A rarely changing documentation page can tolerate a longer TTL if templates and navigation are purged when they change.
Tiered caching can reduce repeated origin fetches by allowing one cache layer to fill another, but it does not make personalized responses safe to share. Cache keys deserve the same care: include only query-string or header variations that genuinely change the public response, and bypass the rest.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What HIT, MISS, BYPASS and DYNAMIC mean
| Status | Meaning | What to do |
|---|---|---|
HIT |
The edge served an eligible stored object without fetching the origin for that request | Confirm the body is public and current; a HIT on personalized HTML is a configuration defect |
MISS |
No usable object was present at that edge, so the request fetched the origin and may populate cache | After a purge or first visit, this is expected; check the next eligible request |
BYPASS |
The request or response instructed the CDN not to serve shared content | Inspect cookies, Set-Cookie, cache-control headers and matching rules |
DYNAMIC |
The request was ineligible before a cache lookup | Check method, path, bypass conditions and whether Development Mode is enabled |
These labels describe cache handling, not a ranking of page speed. A MISS can be the correct result immediately after a purge, and a HIT can be dangerous if the policy failed to exclude private content.
Troubleshoot common edge-caching failures
Every public page remains DYNAMIC
- Confirm the hostname is actually proxied through the CDN.
- Check that the request is GET or HEAD and the origin returns status 200.
- Look for an active Development Mode setting, a broad bypass rule or a response header that disallows caching.
- Verify that the response is HTML and that the manual rule matches the exact hostname and path.
Pages always show BYPASS
- Inspect the request for logged-in, session, comment, cart or other bypass cookies.
- Inspect the response for
Set-Cookie. - Review
Cache-Control: private,no-cacheor equivalent directives. - Check whether an earlier rule or an application security layer matches first.
A page is stale after publishing
- Confirm the purge event ran against the correct zone and hostname.
- Remember that each data center repopulates independently; the first request in a location can be a MISS.
- Check browser caching separately from edge caching.
- Purge related archive, home-page and navigation URLs when the changed content is embedded there.
A logged-in visitor receives a cached public response
Seeing a public page while logged in is not automatically wrong, but a shared response must never include another user’s private markup or state. If authenticated requests show a HIT when they should be bypassed, immediately tighten cookie and authorization exclusions, purge affected objects and retest with a fresh session before increasing any TTL.
Security and privacy checks for production
- Use separate tests for anonymous, logged-in, administrator, commenter and commerce sessions.
- Verify that authentication cookies never enter a shared cache key.
- Exclude all state-changing methods and endpoints, not only the default WordPress paths.
- Do not cache responses that set private cookies or contain account, payment or order data.
- Review custom plugins: membership, learning, booking, personalization and shop plugins often add their own cookies and AJAX or API routes.
- After changing rules, purge old objects before retesting so an earlier cache entry cannot mask the new behavior.
Using Amazon CloudFront instead
Amazon CloudFront is another global edge distribution service. AWS documentation notes that WordPress plugins can add CloudFront support, which makes it a practical alternative for teams already operating their infrastructure on AWS.
| Consideration | CloudFront approach | Operational implication |
|---|---|---|
| WordPress integration | Use a compatible WordPress plugin or deployment integration | You remain responsible for mapping WordPress publishing events to invalidations |
| HTML caching | Define behaviors and cache policies for public paths | Private, transactional and cookie-varying routes need explicit exclusions |
| Existing platform | Fits organizations already using AWS networking and identity tools | Centralizes operations but may require more infrastructure configuration |
| Diagnostics | Inspect CloudFront response headers and distribution behavior | Use the same anonymous-versus-authenticated test matrix |
The provider name changes, but the safety rule does not: only share HTML that is identical for every eligible visitor, and make bypass and purge behavior observable.
A practical operating checklist
- Document public, private, transactional and API URL patterns.
- Proxy the WordPress hostname and confirm origin reachability.
- Leave static assets cacheable under safe defaults.
- Choose APO for managed WordPress behavior or manual Cache Rules for explicit control.
- Require GET or HEAD, status 200 and HTML for shared page caching.
- Bypass administration, authentication, previews, feeds, cron, search, APIs, commerce and custom private routes.
- Bypass logged-in, session, comment, cart and authorization cookies and no-cache requests.
- Set an Edge TTL that matches your publishing and purge capability.
- Connect publishing events to URL or tag-based purge where available.
- Test anonymous, logged-in, administrator, commerce and API requests before rollout.
- Record expected
HIT,MISS,BYPASSandDYNAMICresults for future troubleshooting.
Bottom line
Edge caching can make public WordPress pages available from nearby CDN locations instead of rebuilding them at the origin for every visitor. The safe implementation is not “cache everything”: it is a narrowly defined public-HTML policy surrounded by reliable cookie, path, method, header and query-string bypasses. APO reduces the amount of WordPress-specific policy you maintain; manual Cache Rules give you finer control. Whichever route you choose, purge on publishing and verify both anonymous and authenticated behavior before treating a cache HIT as success.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
