- Article
- 3 minutes read
- Reviewed August 3, 2026
WordPress content can be visible to everyone, restricted to authorized users, hidden from normal public queries or used only inside an administration workflow.
These are architectural choices involving post type registration, post status, permissions, templates, search and API exposure. No single checkbox creates a complete internal-content system.
Public Content
Public content is intended to have visitor-facing URLs and appear in public queries according to its status and settings. Typical examples include articles, products, events and documentation.
A public post type may still exclude entries from search or omit an archive. Public behaviour should be configured explicitly rather than inferred from one broad setting.
Private WordPress Content
WordPress supports private posts that are visible to users with appropriate capabilities. This is useful for limited editorial content, but it does not automatically provide membership-level access rules or per-user authorization.
Themes, caches, feeds, APIs and integrations must respect the same permissions. Sensitive systems require testing beyond the normal browser view.
Password-Protected Content
Password protection places a shared password in front of rendered content. It is convenient for low-risk temporary sharing but provides no individual identity, audit trail or granular revocation.
Do not use it as the primary protection for confidential records.
Internal Content Types
An internal post type may appear in the administration area while being unavailable through public URLs. It can support workflows, configuration records, submissions or reusable objects used by other content.
Internal is an architectural description, not a universal core status. A type can be non-public, not publicly queryable and still exposed to selected REST users or administration screens.
Publicly Queryable, Searchable and Visible in Admin
Post type registration includes separate controls for public queries, user interfaces, menus, navigation and search exclusion. These controls allow more precise combinations than a simple public/private split.
For example, a type might have public single URLs but no archive, or be accessible through authenticated REST requests without public templates.
Access Control Requires Capabilities
Visibility settings do not replace capability checks. Every operation that reads, edits, publishes, deletes or exports protected content should verify the current user.
Custom front-end queries and REST endpoints are common places where developers accidentally expose records by checking only whether an ID exists.
Caching and External Services
A protected page can leak through full-page caching, search indexing, analytics payloads, email notifications or third-party integrations if those systems do not understand the permission model.
Define which systems may receive the data and ensure caches vary by authentication or avoid storing protected responses.
Privacy Is Not Security by Obscurity
Removing links or using an unguessable URL does not make content private. Search engines, logs, referrers and copied links can reveal the address.
Use authentication and authorization whenever access matters.
Planning Questions
- Who should be able to discover the record?
- Who should be able to read its full content?
- Who can create, edit, publish and delete it?
- Should it have public single URLs or archives?
- Should it appear in internal or external search?
- Should it be available through REST, feeds or exports?
- Which caches and external services can receive it?
Frequently Asked Questions
Is an unlisted WordPress page private?
No. A public page that is not linked remains accessible to anyone who knows or discovers its URL.
Is a non-public post type visible in wp-admin?
It can be. Administration visibility and public queryability can be configured separately.
Can private posts be used for a membership site?
They may form part of a solution, but membership rules commonly require more granular authorization, interfaces and testing.