A private client page can become public with nothing more than a shared URL. Removing it from your navigation is not enough, because anyone with the link may still be able to open it.
To restrict page access to logged in users in WordPress, you must control what happens when someone requests the page.
This guide explains the simplest ways to protect a page, helps you choose the right method for your audience, and shows you how to test the protection before applying it to other content.
TL;DR: Use WordPress Private visibility for content intended for editors or administrators; use a maintained access-control plugin, such as Simple Page Access Restriction, when any logged-in user needs access or guests need a redirect, after verifying current compatibility.
Save the rule, then test the exact URL as a guest, an allowed user, and a user without the required role. Remember that restricting a page is only one part of a complete WordPress security strategy.
Choose the smallest rule for your audience
There are four common options:
- WordPress Private visibility: Use this for editorially private pages and posts that should be available to users with the required WordPress permissions, normally editors and administrators. It is not a general “all registered users” gate.
- A simple access-control plugin: Use this for one or a few pages that should be available to logged-in users, with a login page, message, or custom redirect for guests.
- A membership or role-based plugin: Use this when subscribers, customers, members, editors, or other groups need different content.
- Custom code: Use this only when the rule is specific enough to justify maintenance and testing. A small mistake can cause redirect loops, lockouts, permission errors, or conflicts with caching and login plugins.
Start by matching the rule to the audience. In practice, this is the first distinction I make: is the page for WordPress editors, or for anyone with an account? That distinction determines whether core WordPress is sufficient and keeps the page you started with on the simplest safe path.
Method 1: Use Private visibility
Use Private visibility when the page is for the site’s editorial users rather than ordinary members. It can also suit a distributed editorial team: a writer can prepare a post while an editor reviews it before publication.
- Open the page: In the WordPress dashboard, go to Pages and open the page. Use Posts instead if the content is a post.
- Set visibility: In the editor, find Visibility in the page settings or publishing panel.
- Save the change: Select Private, confirm the change, and select Update or Publish.
- Test the exact URL: Use the three-case test matrix in Test access before launch, adapting the required role to the page’s Private permission.
WordPress also supports Public and Password protected visibility. Password-protecting a WordPress page or site is useful when everyone who receives the password may see the same content, but it is not the same as checking each visitor’s account. Do not use it as a substitute for member- or role-specific permission checks.
📝 Note: Private does not mean “visible to every registered user.” Core WordPress private content is permission-based. An ordinary subscriber may still be denied even though that person can log in. If the page is intended for subscribers, customers, or all registered users, use an access rule that explicitly supports that audience.
Private visibility is a good fit when WordPress permissions define the audience; when the page is for any logged-in user or needs a guest redirect, the next method is the better match.
Method 2: Restrict one page
To restrict page access to logged-in users in WordPress, use a maintained WordPress access-control plugin when the requirement is simple: a visitor must be logged in before viewing a selected page or post. Choose a plugin that is actively maintained and compatible with the WordPress version used by the site. Its exact menu names may differ, but the setup normally follows this sequence.
Set up the access rule
- Backup the site: Back up the site, or work on staging if the page is important or the rule will affect many URLs.
- Install the plugin: In the dashboard, go to Plugins > Add New Plugin. Search for the selected access-control plugin, review its maintenance and compatibility information, then install and activate it.
- Choose a guest destination: Open the plugin’s settings if it has a global configuration page. Set the destination for visitors who are not logged in. This may be the standard WordPress login URL, a custom WordPress login URL, or an explanatory page.
- Enable the page rule: Go to Pages and edit the page to protect. Look for an access-control panel, restriction box, or similar setting in the editor. Enable the option that requires a user to be logged in.
- Choose roles carefully: If the plugin offers a role selector (a control for choosing account groups), use the broad logged-in-user setting only for content intended for every logged-in account. Choose specific roles or permissions when the content is not for all users.
- Add guidance and save: If the plugin allows a custom message or redirect, explain why the visitor needs to log in and provide a clear route to the login page. Save or update the page.
📝 Note: The key setting is the rule on the content itself; the mistake I see most often is stopping after the plugin is installed. Installing a plugin or hiding the page from navigation does not protect a page unless the plugin checks the request and applies the rule to that page.
Redirect logged-out visitors
A login redirect is useful when the page is part of a member or client area. Configure the plugin to send a visitor who is not logged in to the login page and, when supported, preserve the original destination so the visitor returns to the requested page after signing in. Check these details before enabling the redirect:
- Keep the login page public: Do not apply the same restriction to the login route.
- Choose a separate destination: The redirect destination must not be the protected page itself unless the plugin specifically handles that flow.
- Validate the return URL: The return URL, the address of the page the visitor originally requested, should be valid on the site and should not send a user to an unrelated administrative screen.
- Use the canonical test: Use the three-case test matrix in Test access before launch, including both a direct visit to the protected page and a visit after clicking a link to it.
If a custom message is better than an automatic redirect, use a page that explains the access requirement and links to login or registration.
Restrict access by role or membership
Use role-aware settings when a subscriber should see member resources but another logged-in account should not. A membership plugin is usually the better fit when access depends on a plan, purchase, subscription state, expiration date, or related pages. It adds setup and maintenance, but provides a model for managing protected resources.
Being logged in proves identity, not permission to view every protected page. “Logged in” is an authentication check: it confirms that WordPress recognizes an account. Role- or membership-based access is an authorization check: it decides whether that account has permission to view a specific item.
Page-level restrictions are also different from restricting access to the WordPress admin area, which controls who can reach backend screens and perform administrative actions.
Define membership levels that match those audiences, then apply the appropriate level to each page or post. When configuring a role rule:
- Define the audience: Define the audience in plain terms before choosing a WordPress role or specific permission.
- Start with one page: Apply the rule to one test page first.
- Use the canonical test: Follow the three-case test matrix in Test access before launch rather than recreating it here.
- Retest after changes: Repeat the test after changing the role or membership state, because access can change with that setting.
Avoid broad rules that happen to work for administrators but have never been checked with an account that has fewer permissions. An administrator test alone can hide a permission mistake.
Secure the accounts that can access the page
A page restriction is only as strong as the accounts allowed through it. Require strong, unique WordPress passwords and two-factor authentication for privileged accounts, especially for administrators, editors, and anyone who can change access rules.
Review the wider WordPress login-security setup as well. Monitor failed WordPress login attempts for unusual patterns, remove accounts that are no longer needed, and keep each user at the lowest role required for their work.
Protect files and other content
A page rule may protect the HTML page while leaving another version of the content available. Apply the same access question to every protected item:
- Check other content types: For posts or custom post types (other kinds of content), confirm that the rule covers that content type, not only Pages.
- Test direct downloads: For downloads, copy the file’s direct URL and open it while logged out. A visitor who knows the file URL may be able to request the file even when the download page is restricted.
- Test original media URLs: For media, test the attachment URL and the original upload URL, not just the image or link embedded in the protected page.
- Check feeds: For feeds, confirm whether the protected title or content appears in RSS or another feed generated by the site.
- Check REST responses: For REST API responses (data returned to connected tools and apps), check whether the content is returned to a request from a visitor who is not logged in. API authentication is a separate control surface from the page’s front-end rule.
If a download is genuinely private, use a delivery method that checks permission for the file request itself. Do not assume that placing a public file URL inside a protected page makes the file private. The correct implementation depends on the hosting, storage, membership, and access-control tools used by the site.
Search engines and caches need separate attention too. An old search result, cached HTML response, or copied file can still exist after the normal public request is protected. Decide whether the content should be indexed, check the page’s search behavior, and purge stale caches after changing the rule. Do not promise a particular result without checking the actual site stack.
Custom code is not the beginner default
Custom code can be appropriate for a narrowly defined rule, but it should be reviewed and tested like a security-sensitive change. WordPress provides an is_user_logged_in() check for the current visitor. It also provides auth_redirect(), which checks login status, sends a visitor who is not logged in to the login URL with the requested destination, and returns the visitor after login.
Those functions do not by themselves define who is authorized to view a page, protect a file, or handle every cache and API path. A custom implementation must also account for the login route, permissions, redirects, REST and feed responses, and cache behavior. Do not paste an unreviewed snippet into a live site. If a rule is important enough to need custom code, test it on staging and keep a recovery path through a backup or hosting access.
If you do not need a highly specific rule, using a well-maintained WordPress security plugin alongside a dedicated access-control tool is safer than relying on unreviewed custom code.
Test access before launch
Use the exact URL, not only the navigation link, and run the canonical three-case test. A useful test matrix has at least three cases:
- Logged out in a private browser window: Login page, custom message, or approved alternative; not the protected content.
- Logged in with the required role or membership: The protected page and any intentionally available assets load.
- Logged in without the required role: Access is denied or redirected according to the rule.
Repeat the test after clearing or bypassing page and content delivery network (CDN) caches. Test a direct download URL, attachment URL, feed, and relevant REST response when those outputs matter. If the site uses a login, caching, security, or membership plugin, test their interaction rather than assuming the page rule wins.
At minimum, back up the site and keep an administrator recovery account. I always include the user-without-role case: an administrator test alone can hide a permission mistake. A global rule that accidentally covers the login page can lock out every user, including the administrator.
Troubleshoot access problems
Logged-out visitors can still see the page
Open the exact URL in a private window and confirm that the browser has no active WordPress session. Check that the rule is enabled on the correct page and content type, then purge the page and CDN caches. Also check for a second plugin or theme template that creates a public copy of the content.
Cached private content appears publicly
Exclude protected paths, login paths, and user-specific responses from the page or CDN cache according to the site’s caching system. Purge old entries after changing the rule. A cache can serve a previously public response after restriction, or one user’s private response to another visitor if configured incorrectly.
A redirect loop blocks access
Make sure the login page, logout route, and any required registration page are not restricted. Check that the destination is not the protected URL, that the site uses one consistent HTTPS address and hostname, and that the return URL is valid. Temporarily disable one redirect source at a time if several plugins manage redirects.
Users land on the wrong page
Review the plugin’s global redirect and the individual page’s override. Confirm that the login form preserves the original destination and that it still exists. A stale redirect, changed permalink, or cached response can send users to an old page.
A restricted download still works
Request the direct file URL while logged out. If the file loads, the page restriction does not cover the file request. Move the file to an access-controlled delivery path or use a download system that checks the visitor’s authorization before serving it. Test old URLs and alternate attachment URLs after making the change.
The login page is inaccessible
Remove the login route from the restriction and from any private-page cache. If a site-wide rule caused the lockout, use the backup, hosting access, or another documented recovery method before changing more settings. This is why a staging test and recovery account matter before applying global access rules.
FAQs
How do I restrict a WordPress page to logged-in users?
Edit the page, choose the access rule that matches your audience, save it, and test the exact URL while logged out. Use Private for authorized editors or administrators, or use an access-control rule when any logged-in user should be allowed.
Can I restrict a page without a plugin?
Yes, but WordPress Private visibility is permission-based. It is suitable for editors and administrators, not automatically for every registered user. Use a plugin or membership system when ordinary members or customers need access.
How do I restrict access by user role?
Choose a role- or permission-aware access rule, then use the three-case test matrix in Test access before launch. Use a membership system when access depends on plans, purchases, subscriptions, or expiration dates.
How do I redirect logged-out visitors?
Configure the access-control tool to send visitors who are not logged in to the public login page or to an explanatory page. Keep the login route unrestricted, preserve a valid return URL when supported, and test a direct visit to the protected page.
How can I confirm that the restriction works?
Use the three-case test matrix in Test access before launch. Also test direct files, feeds, API responses, and caches when they could expose the same information.
Conclusion
Use Private visibility when the content is for WordPress editors or administrators. Use a maintained access-control plugin for a small number of pages that should be available to logged-in users, and choose membership or role-based controls when different groups need different content. Use custom code only for a reviewed, narrowly scoped requirement.
Whatever method you choose, test the direct page URL with each relevant account, then test files, caches, feeds, and API responses that could expose the same information. Page access rules solve page authorization; they do not replace account security or whole-site protection.
