A page can be absent from navigation and still be discoverable through the REST API, feeds, sitemaps, author archives, search, revisions, oEmbed, or an old CDN object. WordPress 7.0.3 closes a Core post-slug enumeration issue, but the release does not replace a site-specific inventory of every public content surface.
Use this audit for membership sites, private campaigns, embargoed announcements, gated resources, client portals, and any WordPress site where knowing a slug or title can reveal sensitive business information.
Quick answer
Update WordPress to 7.0.3, then test a controlled private fixture as an anonymous visitor against REST, search, feeds, sitemaps, archives, oEmbed, and CDN cache. A private item should not disclose its slug, title, excerpt, author, or predictable URL through any public surface.
What to check first
- Create one controlled private fixture with a unique marker that cannot match existing content.
- Search the REST API, feeds, sitemaps, site search, date archives, author archives, and oEmbed output for the marker.
- Request the likely clean URL with no cookies and with a cold cache-busting query string.
- Inspect CDN logs and object listings for an older public response tied to the fixture slug.
- Record which layer returned each disclosure before changing privacy, cache, or indexing settings.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Patch WordPress Core to 7.0.3 or the supported backport for the branch. | Create one controlled private fixture with a unique marker that cannot match existing content. | Anonymous REST, feed, search, sitemap, archive, and oEmbed requests reveal no private marker. |
| Align post status, REST visibility, sitemap inclusion, archive behavior, and search behavior. | Search the REST API, feeds, sitemaps, site search, date archives, author archives, and oEmbed output for the marker. | The likely clean URL and its cached variants do not confirm a private slug. |
| Purge exact CDN and page-cache keys that ever served the fixture publicly. | Request the likely clean URL with no cookies and with a cold cache-busting query string. | Public controls remain discoverable so the test does not hide a broader outage. |
| Require authentication for genuinely private material instead of relying on an obscure slug. | Inspect CDN logs and object listings for an older public response tied to the fixture slug. | CDN and application logs show the retest reached both edge and origin. |
Why this usually happens
- Visibility rules can differ between the single post route, REST collections, feeds, sitemaps, search, and third-party indexing plugins.
- A CDN may retain a successful public response after WordPress changes the post status.
- Custom post types and plugins can register REST or archive behavior without matching Core privacy expectations.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
marker='PRIVATE-703-AUDIT'
for path in '/wp-json/wp/v2/posts?search=PRIVATE-703-AUDIT' '/feed/' '/sitemap.xml' '/?s=PRIVATE-703-AUDIT'; do
curl -sS -H 'Cookie:' "https://example.com$path" | grep -Fi "$marker"
done
curl -sSI -H 'Cookie:' 'https://example.com/private-fixture/?audit=703'
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Published control | Public post with marker PUBLIC-703 | Listed only on intended public surfaces |
| Private fixture | Private post with marker PRIVATE-703 | No anonymous slug, title, excerpt, or body disclosure |
| Draft fixture | Draft post with marker DRAFT-703 | No anonymous discovery through REST, feeds, search, or cache |
| Previously public fixture | Published, cached, then made private | Origin and edge both stop serving the old public body |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Patch WordPress Core to 7.0.3 or the supported backport for the branch.
- Align post status, REST visibility, sitemap inclusion, archive behavior, and search behavior.
- Purge exact CDN and page-cache keys that ever served the fixture publicly.
- Require authentication for genuinely private material instead of relying on an obscure slug.
- Repeat the anonymous matrix and retain response evidence for the change record.
Decision rule
If any anonymous surface reveals a private or draft marker, preserve the full response and identify the owner of that surface. Fix that layer before widening the test. If only an old edge location leaks the marker, purge and review cache invalidation on future status changes.
Production verification checklist
- Anonymous REST, feed, search, sitemap, archive, and oEmbed requests reveal no private marker.
- The likely clean URL and its cached variants do not confirm a private slug.
- Public controls remain discoverable so the test does not hide a broader outage.
- CDN and application logs show the retest reached both edge and origin.
Field notes
- Use an invented marker, not real confidential text, because logs and support exports may preserve the probe.
- A 404 response is not enough if the response title, redirect target, or JSON still confirms the slug.
- Treat robots.txt as crawl guidance, not access control. Private content needs authorization at the origin.
Questions teams ask during testing
Does noindex protect a private post?
No. Noindex asks search engines not to index a page, but anyone who can request the URL can still receive the content.
Should WordPress REST be disabled?
Usually not. Test the affected post type and permissions first because many editors, blocks, and integrations depend on REST.
Why test a previously public post?
It exposes stale cache and search-index behavior that a newly created private post cannot reveal.
Mistakes to avoid
- Do not put real confidential content into the test fixture.
- Do not interpret robots.txt blocking as protection from direct requests.
- Do not purge only the homepage when the leaked object has its own cache key.
- Do not disable every REST route when a narrow visibility rule can preserve public functionality.
What to tell the client or owner
Report the exact marker, affected surface, anonymous response code, cache status, and whether the disclosure came from origin or edge. Avoid sharing real private content in the ticket.
When HandL WP should help
HandL WP can trace a discovery leak across WordPress status logic, REST registration, SEO plugins, page cache, CloudFront, and public search surfaces, then verify that intended public content still works.
If this is active on a production site, run a WordPress content exposure audit.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references