WordPress: exclude personalized pages from shared caching

Determine which pages must remain dynamic

Page caching can serve the same public HTML to several visitors. It must let WordPress generate the response when it depends on a session, role or personal selection. Inventory your site’s user journeys. An introductory page and public post may be candidates. A member area, order screen, profile page, preview or dashboard requires different handling. Add public pages that display a different block after login or according to a saved preference.

Record the address actually used, its functional owner and how personalization is determined. For example, a page may load the same public shell for everyone, then query an authenticated API to display the account. In that case, classify the HTML shell separately from the API response. If the shell already includes a name, form token or session state, treat it as a personalized response. Translated paths, secondary domains and parameters used by plugins also belong in the inventory.

If the problem is simply an old version of a public page, follow the guide to finding and clearing the correct cache. This process determines which responses may be shared, then checks the rule before launch. If exposure has been reported, stop delivery from the affected cache with the owner and handle the report through the designated channel. The checks proposed here take place exclusively on a fictional copy with protections in place.

Identify the layer deciding to reuse a page

Ask the hosting provider and maintainer which services can retain HTML. A WordPress plugin, hosting-integrated cache and CDN may act along the same path. The browser or an offline feature may also retain responses locally. An object cache stores data reused by the application, such as a query result, whereas a page cache can serve an entire HTTP response. Document who can modify and verify each layer.

On a WordPress.com copy or managed service, start with the functions actually offered by your plan. If you lack an HTML cache setting, prepare the inventory and ask the provider to confirm exclusions and available evidence. For a self-hosted installation, open the already active page cache’s panel and exclusions screen. Then check the server cache or CDN even when the plugin advertises automatic exclusions.

Keep a private copy of current settings with the date, rules and priority. Identify the person able to return to a known protective configuration. On the copy, follow requests from the browser to WordPress and record where the decision to serve an entry is made. If a layer can respond before WordPress starts, give it the exclusion rule too. An application instruction cannot correct a copy already returned earlier along the path.

Limit shared caching to identified public responses

Start with a short list of public pages returning the same content to anonymous visitors. For each layer, define eligible requests and responses the cache may retain. This test’s conservative framework permits only anonymous reads of explicitly designated routes. A recognized session, HTTP authorization, a method that can change state or a route with uncertain behavior must take the dynamic path. Also check parameters that change content or trigger an action.

For WooCommerce cart, account or checkout, record the pages actually assigned in store settings, then callback paths, endpoints and cookies listed in the installed version’s documentation. Translations and custom pages may have addresses differing from example values. On a membership or training site, make the same inventory for dashboards, messages, progress and protected downloads. An exemption on a single page does not cover requests completing its display.

Give exclusions priority over general HTML acceleration rules. Check the engine’s documentation to ensure the rule’s name, order and type produce that result. Preserve session cookies and normal permission checks. Cache variation based solely on a cookie can create many variants and does not itself authorize storing private responses. Ask each owner to validate route eligibility and the reasons it is public.

• Inventory stable public addresses and personalized routes.
• Apply exclusions in every active page cache.
• Confirm rule order with the layer’s owner.

Read cache directives and service decisions

For a sensitive response, ask the application for an appropriate policy, such as Cache-Control with private and no-store. The private directive forbids shared-cache storage when it applies to the entire response. The no-store directive asks caches not to store the response. It does not remove an already retained copy. The no-cache directive generally requires validation before reuse and still allows storage under certain conditions. Check each layer’s exact policy against its documentation.

The presence of a cookie or Set-Cookie header is not, by itself, a standard prohibition on caching. Retain eligibility exclusions and also check directives returned by the origin and the service in front of it. Ask which headers the service adds or replaces. A CDN may have its own lifetime rules and indicator. HIT, MISS and BYPASS are examples here; check their definitions in the service actually used.

In developer tools, open Network, then select the document or dynamic request of interest. Record HTTP status, Cache-Control and, if present, Age and the cache indicator. A MISS means an entry did not serve this request, with the possibility that the response will be cached afterward. Missing Age can also be explained by the service or chain. To confirm an exclusion, match the response to the relevant engine’s rule or log.

Prepare the copy and test profiles

Create an isolated local copy or test installation containing only invented pages and accounts. Exclude customer exports, tokens, orders, private media and histories. Disable external sending and test payments, or use the provider’s designated mode when these components are necessary. The two roles used here are editor and subscriber. Assign each to its test account with the copy’s normal permissions. The reader does not need a super administrator account to verify what they see.

Prepare a public page rendering exactly the same reference marker for all visitors. Also prepare a test account page displaying a fictional label matching the current role and requiring a logged-out visitor to sign in. The markers may be called “Éditeur fictif” and “Abonné fictif.” Accounts sign in through the ordinary flow. Use three independent profiles: one anonymous and one for each role. Maintain every exclusion from the first test.

Fill a grid with the route, profile, expected status, expected marker and expected cache decision. Also plan the result after reloading. If you can read a test cache’s log or inventory, specify how to check which routes are actually admitted. This preparation lets you verify a preventive policy with observable results without manipulating sessions.

• Create a public reference page, a personalized page and two fictional accounts.
• Open three separate profiles, including a logged-out one.
• Define expected results before making requests.

Check the public reference, then authorized sessions

Start with the anonymous profile on the public page. If you cleared its entry on the copy and the rule permits caching, expect the first response to come from the origin and a second request potentially to be served from cache. The public marker must remain identical. Record the observed decision even if your hosting provider uses words other than MISS and HIT. Keep the same URL and method for both requests.

Sign in the editor and subscriber from their respective profiles. On the copy’s personalized page, check each one’s own authorized result and the decision bypassing shared caching. Reload in the same profile and record headers again. In the logged-out profile, the journey must continue to request identification or deny access according to the page’s rule. Check dynamic responses associated with the page when it uses an API or separate service.

Look for independent evidence in the test layer. Under this protocol, only the public reference entry should be retained. Check that account responses carry private and no-store, stay outside the cache and follow WordPress permissions. The exact denial code depends on the application. A login form may produce a redirect, while a test page may return 401. Record the actual decision without modifying the URL to force a result.

• Confirm that the public reference can be served from cache when conditions are met.
• Validate each role and the anonymous profile against expected access.
• Check repeated decisions and, if possible, the cache inventory.

Check responses associated with the journey

An account page may load correctly and then request other data. On the copy, observe requests from the normal journey. Record documents, asynchronous calls and redirect responses carrying login state or role-related content. Check exclusion for each response and keep private parameters out of screenshots. For a form, also examine the result after submission with invented values and external services stopped.

If navigation moves from a public page to a restricted area, check what the application returns on entry, after login and after logout. Use the site’s intended controls. Requests changing state or responding to a form must retain their original processing and stay outside page caching. If the fictional test page accepts only reads, check that an unsupported method is denied and excluded from caching, without a real action.

An offline application or service worker can apply a browser policy independently of the CDN. If your site uses this feature, ask its maintainer to check what it retains after normal test navigation. The offline resource list must respect the same privacy decisions. A CDN’s labels do not describe browser caching. Record the result per layer to know where to intervene.

Apply exclusions before any invalidation

On the copy, save exclusions in the relevant layers and review their order. Have protected routes confirmed to take the dynamic path, then invalidate targeted entries according to the engine’s procedure. Purging alone has a temporary effect if the rule permits storing them again. Limit purging to the necessary scope when the service can identify the affected keys and variants. If that scope cannot be guaranteed, ask the maintainer for the designated way to remove every affected variant.

If you use WP Super Cache, open Settings → WP Super Cache → Advanced. In Accepted Filenames & Rejected URIs, find Rejected URL Strings. Add a fragment specific to the private page, for example /espace-membre/ if that is your test page’s path. Save the rule and remove the page’s old copy from the plugin cache. Reopen that page, then a public page whose address resembles the member area’s address. This checks both exclusion and scope.

If the hosting provider or CDN directly manages page caching, apply exclusions in that service’s panel or ask support to confirm them. Then use the same verification grid. The result depends on the layer responding to the request.

After invalidation, reuse the same profiles and grid. The public reference must continue working according to its rule. Private responses must have the correct headers, remain excluded even after reload and pass access checks. Compare observations with the policy defined before testing. Keep the date, routes and engine decisions without session identifiers or response bodies from a user.

If a step diverges, stop validation and retain the strictest known protection for affected routes. Restoring a configuration must preserve exclusions protecting these responses. A previous rule with uncertain protection must remain excluded. Correct the identified layer, then repeat reference checks before considering a change elsewhere. Test rollback ends when protective behavior is established again.

• Save and verify the exclusion rule before removing targeted copies.
• Repeat reference checks with the prepared profiles.
• If results differ, retain protection and resume checking the affected layer.

Keep a useful record for future updates

Keep the route list, rules, affected layers and owner of each setting. Also record changes requiring retesting, such as a new login journey, membership plugin, translated URL, CDN change or modified order screen. An old rule may remain correct for an old address while leaving the new one outside its scope. Include route verification in the update task.

The report must let the owner understand what was observed. Distinguish the saved rule, sent header, cache decision and evidence that a protected route does not enter the test system’s inventory. Record limitations, particularly when the provider supplies neither logs nor access to rules. An accelerated public page is insufficient to validate personalized pages. A local test with a fictional engine lets you check policy logic before verifying each target-environment layer.

For a store, the WordPress performance-tool comparison places page caching among other functions. If a login loop persists outside cache layers, follow the cookies and login guide. For the specific case of an independent domain mapped to a subsite, use the Multisite TLS, login and return flow.

Distinguish recovery after an error from a retained private response

Some caches can serve an old response when the origin encounters an error, under a policy such as stale-if-error. This possibility must remain limited to responses eligible for sharing. A personalized page does not become public because keeping the site accessible during an outage is useful.

In the layer inventory, ask whether a stale-content or service-continuity feature is active and on which routes. On the copy, its check must preserve the already defined exclusion of accounts and authenticated responses. If the provider does not allow reproducing this case, record the confirmed rule and that limitation. During a real incident, an old public page and a private response must therefore follow different decisions. Keep exclusions even if a fallback feature seems to hide the outage; it does not repair the service supplying personal data.

Related comparisons