A password prompt is not enough to prove that a WordPress page stays protected after caching. Test whether an unlocked response can be served to a second visitor who has never entered the password. Use harmless staging content, not a real confidential document.
Build a controlled two-session test
Create a staging password-protected page containing a unique, non-sensitive marker such as ACCESS-TEST-OCT08. Keep its password private. Match the production cache configuration closely enough to exercise the same page-cache and CDN rules, but do not copy private production content into the test.
Use two isolated browser profiles or cookie stores. Two tabs in one browser profile are not isolated. Label them Visitor A and Visitor B. Neither should be logged into WordPress because administrator sessions may bypass cache and produce a misleading pass.
The WordPress password-protection documentation explains that a password cookie can unlock matching protected content for that visitor. The test below asks whether another visitor incorrectly receives the resulting HTML.
Run both cache-warming orders
- Start with Visitor B, who has no password cookie. Confirm the page requires the password and does not expose the marker in its returned HTML.
- In Visitor A, enter the page password through the ordinary form. Confirm the marker becomes visible.
- Return to Visitor B and reload the identical public URL. Check both the displayed page and its response body for the marker.
- On staging, purge only the test path and repeat with Visitor A unlocking first, followed by Visitor B.
- Repeat after the cache's normal lifetime or revalidation path if those policies differ from the initial request.
Isolation: Separate cookie stores. Warm order: Both request orders tested. Response: Marker absent for visitor B. Media: Direct files checked separately. Explanatory checklist, not a customer test result.
Interpret the results carefully
| Result |
Meaning |
| B receives only the prompt after A unlocks |
This tested path preserves separation |
| B receives the marker without entering a password |
Treat as an access exposure and contain it |
| A keeps seeing a cached prompt |
Availability problem, not proof of a disclosure |
| Direct PDF opens for B |
Separate media-access problem |
Cache headers can help identify a responsible layer, but a cache-hit header alone does not establish whether content leaked. The decisive evidence is the protected marker appearing in an unauthorized response.
Contain a confirmed exposure
Stop serving sensitive content through the affected path while the owner reviews the incident. Remove cached exposed responses using the host and CDN's supported controls. Then configure the page cache to avoid sharing unlocked protected responses across visitors and retest before restoring sensitive material.
Do not solve this by hiding the marker with JavaScript, adding noindex or choosing a harder-to-guess URL. Those measures do not prevent an unauthorized visitor from receiving the response body. If the material needs individual access and revocation, choose an authenticated access design appropriate to that need.
Our protected-page media guide covers files that remain public independently of the page. HandL WP can audit the cache boundary across WordPress, hosting and CDN layers. A passing staging test is useful evidence, not a guarantee about every production route.
References reviewed October 8, 2026. Examples are explanatory, not customer test results.