Wordpress Has NO Core Feature to Restrict Reading Certain Content to Only Signed In Users. Here is How to Do It.

To block an entire WordPress page so only signed-in users can view it (not just certain sections), use a combination of WordPress access control plugins or programmatic redirects. WordPress alone does not natively block whole pages for logged-in users, but WordPress plugins like Members or Paid Memberships Pro allow you to restrict full page access, while a simple code snippet can redirect non-logged-in users to the login page.

Plugin-Based Approach

Members (by MemberPress): Install the free Members plugin. Edit the page, scroll to “Content Permissions,” and select which user roles can access.
Paid Memberships Pro: Similar process — restrict the entire page based on login status, with options for membership levels. You can make the page unavailable entirely unless a user is logged in.

Code Approach (Recommended for Technical Users)

Add this to your child theme’s functions.php file to redirect non-logged-in visitors away from one or more pages:

phpadd_action('template_redirect', function() {
    if (is_page('your-page-slug') && !is_user_logged_in()) {
        wp_redirect(wp_login_url(get_permalink()));
        exit;
    }
});

Replace your-page-slug with the actual page slug. Non-logged-in users will be redirected to the login, with destination set to the protected page after login.

When to Use Each Method

For simple sites and pages, the code method is quick and doesn’t require extra plugins.
For member sites or role-based access, use Members or Paid Memberships Pro for more granular control and user management.
Both methods ensure the entire page, including all Divi content and modules, is hidden and inaccessible from guests.

This guarantees absolute protection for long pages or custom templates, regardless of the layout complexity.

The code approach for restricting page access in WordPress can be easily customized for specific pages, categories, posts, or any combination. You do not need a separate snippet for each page—simply adjust the conditions within the function to target what you want to secure.

Restricting Individual Pages

To restrict only certain pages, include multiple slugs or IDs in your condition:

phpadd_action('template_redirect', function() {
    $protected_pages = ['page-slug1', 'page-slug2'];
    if ((is_page($protected_pages)) && !is_user_logged_in()) {
        wp_redirect(wp_login_url(get_permalink()));
        exit;
    }
});

Replace page-slug1, page-slug2, etc. with your actual page slugs.

Restricting Categories

To restrict all posts in one or more categories:

phpadd_action('template_redirect', function() {
    $protected_cats = ['category-slug1', 'category-slug2'];
    if ((is_category($protected_cats) || (is_single() && has_category($protected_cats))) && !is_user_logged_in()) {
        wp_redirect(wp_login_url(get_permalink()));
        exit;
    }
});

Replace category slugs as needed. This will secure any post within those categories.

Restricting by Post Type or Custom Rule

You can restrict based on tags, post types, or combinations:

For all posts of a custom post type: is_singular('your_post_type')
For posts with a tag: has_tag('yourtag')

General Notes

The logic is flexible. You can combine conditions (is_page(), is_category(), is_single(), etc.) to match any group of content you want.
You only need to add or adjust the array of slugs/IDs/taxonomies within the code, not copy new blocks for each page.

This approach lets you efficiently manage private access without bloating your theme with repeated snippets.You do not need a separate code snippet for every page; you can modify the snippet to target multiple pages, whole categories, or even post types at once by using WordPress conditional functions.

Restricting Multiple Pages

Use the is_page() function with an array of page slugs or IDs:

phpadd_action('template_redirect', function() {
    $protected_pages = array('page-slug-1', 'page-slug-2', 42); // slugs or IDs
    if (is_page($protected_pages) && !is_user_logged_in()) {
        wp_redirect(wp_login_url(get_permalink()));
        exit;
    }
});

This restricts all specified pages—just add them to the array.

Restricting Entire Categories

Use the is_category() and/or has_category() functions:

phpadd_action('template_redirect', function() {
    $protected_categories = array('private-category', 'special-category');
    if ((is_category($protected_categories) || (is_single() && has_category($protected_categories))) && !is_user_logged_in()) {
        wp_redirect(wp_login_url(get_permalink()));
        exit;
    }
});

This restricts all posts within those categories—no need to edit for each post.

Combining Rules

You can mix page, category, or post-type rules inside a single snippet for flexible, site-wide access control.

This lets you protect many pages, posts, or categories with one small block of code—just update your arrays/slugs/taxonomies as needed

WordPress does offer basic features for restricting content to signed-in users, but the built-in “Private” setting only allows access for administrators and editors, not regular subscribers or custom user roles. For true member-only content visible to all logged-in users (not just admins and editors), a plugin or custom code is typically required.

WordPress Built-In Method

Setting a post or page to “Private” means only admins and editors (not typical users) can see it on the front end, even if they’re logged in.

Building a Fully Private Website

WordPress.com: If using WordPress.com hosting, you can set the entire site’s privacy to “Private”, so only invited/approved users with WordPress accounts can view it.
Plugin Solution (Recommended for most private sites):
- Use plugins like Members, Content Control, or Force Login to restrict either specific content or the entire site to logged-in users of any role. These plugins redirect guests to a login prompt and can allow broader access beyond just admins/editors.
Code Solution: Adding a simple function to your theme’s functions.php will redirect non-logged-in users from the whole site to the login page:

phpadd_action('template_redirect', function() {
    if (!is_user_logged_in() && !is_page('login')) {
        wp_redirect(wp_login_url());
        exit;
    }
});

This makes all content, including posts, pages, and archives, private for authenticated users only.

Summary Table

Method	Restricts To	Notes
Private visibility	Admins/Editors	Built-in, not for members/subscribers
WP.com Private	Invited users	Works only on WordPress.com hosting
Plugin	All logged-in users	Flexible, recommended for most “private sites”
Code	All logged-in users	Effective, simple, good for technical admins

For a fully private WordPress website accessible to all registered/authenticated users, use a plugin or a custom code snippet. This approach is standard, quick to implement, and works seamlessly with themes like Divi.WordPress does not provide a single-click built-in feature to make an individual post readable only by all signed-in users—its default “Private” setting limits access to administrators and editors, not typical users or subscribers. To build a truly private website, there are two main options: use a membership/access control plugin, or add a simple code snippet to enforce login for the entire site or specific content.

How to Build a Private WordPress Site

WordPress.com sites: The “Private” visibility option in Settings hides the entire site and allows access only to approved WordPress.com users; others see a login prompt.
Plugin (best for most self-hosted sites): Access control plugins such as Members, Force Login, or Content Control let you restrict posts, pages, or the whole site so only logged-in users—across any user role—can view content. These plugins auto-redirect guests to the login page, making your site private to registered users.
Custom code (simple for admin users): You can make the full site private by adding a function to the theme’s functions.php, which redirects all guests to the login page. Example:phpadd_action('template_redirect', function() { if (!is_user_logged_in()) { wp_redirect(wp_login_url()); exit; } });

Practical Table

Method	Who Can See	Setup Difficulty
Private Visibility	Admins, Editors	Very Easy
WP.com Private Site	Approved WP users	Easy
Plugin (recommended)	All logged-in users	Easy
Custom Code	All logged-in users	Moderate

With a plugin or code, building a private WordPress site—where only signed-in users can view content—is straightforward and supports all major themes, including Divi.

For restricting access to specific WordPress pages so only logged-in users can view them, the best plugins—both paid and free—are focused on efficient access control, flexibility, and reliability. The leading premium choices are:

1. MemberPress (Premium)

Best overall for access control: Highly regarded for its powerful page- and post-level restriction options, ability to manage memberships, and seamless user experience.
Features: You can restrict any post, page, category, or custom post type to logged-in users or specific membership levels. Supports content dripping, paywalls, advanced rules, and integrates with most payment gateways.
Pricing: Starts at $179/year for basic plans.
Recommended for: Sites that may want to grow from simple page restrictions to paid memberships or courses later.

2. Restrict Content Pro (Premium)

Strengths: Lightweight yet robust, Restrict Content Pro allows you to protect pages, posts, or even entire categories by login status or membership level with easy rule setup and a clean interface.
Pricing: Starts at $99/year.
Recommended for: Sites needing powerful protection, flexible membership tiers, but want a faster, less “heavy” plugin than a full membership suite.

3. Content Control (Free & Paid)

Best lightweight solution: Protects any page, post, category, or even individual Gutenberg blocks by login status or role. Paid upgrades add more granular rules and scheduling features.
Ease of use: Simple rules engine, allows for easy “logged-in only” setup for chosen pages.
Recommended for: Straightforward access control without membership management bloat.

Quick Comparison Table

Plugin	Access Levels	Granularity	Paid/Free	Best Fit For
MemberPress	Advanced, roles	Pages, posts, CPTs	Paid Only	Full-featured protection, future growth
Restrict Content Pro	Advanced, roles	Pages, posts, cats	Paid Only	Lightweight but powerful
Content Control	Simple to adv.	Pages, posts, blocks	Free & Paid	Simple, no-fuss restriction
User Access Manager	Roles/groups	Pages, posts	Free & Paid	Role-based access, lightweight

All of these plugins let you target specific pages for restriction, show custom messages or redirects, and scale to complex needs if required. For most professional use cases, MemberPress is the strongest choice—widest feature set, reliable support, and investment in updates. If your needs are simple, Content Control or User Access Manager are solid lighter-weight options.

You will be able to restrict chosen pages to logged-in users—no manual code required—with any of the above.plugins.

WordPress does not provide logged-in user content restriction as a standard feature mainly because its core philosophy is to remain flexible, lightweight, and extensible, relying on plugins to add advanced functionality as needed. The platform is designed so that the base install works for blogs, public sites, and simple use-cases, while third-party plugins can cater to membership, e-learning, or private content needs, which can vary greatly. This modular approach keeps WordPress broadly compatible and fast out of the box.

Why Is This Not Standard?

Most sites use WordPress for public-facing publishing, so the core team prioritizes these features to keep the system streamlined and avoid lock-in or feature bloat.
It avoids forcing extra database calls, session checks, and user management overhead for users who don’t need private content.
Many WordPress features are driven by community feedback; historically, access control for logged-in users was seen as niche and better solved with plugins so as not to complicate the main UI.

Are Users Complaining?

There are frequent complaints and requests for easier access control, especially from people creating private sites, clubs, or intranets.
However, many users are new, hobbyists, or businesses who don’t require advanced restrictions, so plugin solutions are widely accepted, and the most popular options have millions of active installs.
The WordPress ecosystem strongly encourages using plugins for all extra features, so custom solutions thrive and plugin authors benefit economically.

Is There Collusion?

No evidence suggests “collusion”; rather, it’s the norm for open-source platforms to delegate specialized features to third-party plugins, enabling a vibrant developer marketplace.
Top plugin providers compete aggressively—there is no monopoly, and many important plugins remain free and open-source.

WordPress could arguably add more core privacy features, and this remains a frequent topic for future releases, but the current architecture intentionally keeps such advanced features optional to retain broad appeal and extensibility.WordPress is intentionally designed to be lightweight and flexible, providing only essential public publishing and basic privacy features out-of-the-box, and encouraging users to extend functionality with plugins as needed. The philosophy behind this approach is to avoid adding performance overhead or complexity for the majority of sites, which remain entirely public or have minimal privacy requirements. As a result, many advanced features—including restricting content to logged-in users—are handled by third-party plugins rather than the WordPress core itself.

Why Is This Central Restriction Still Missing?

Historically, most WordPress sites are blogs or marketing sites needing maximum public reach, so restrictive features were deprioritized.
The WordPress developer ecosystem thrives on plugins, which let users add the features they need without bloating the base software, making it more efficient and easier to update for all.
The open-source model relies on distributed innovation, so demand for features like private content has led to many plugin options, but not core adoption unless a strong majority pushes for it.

User Reactions and Collusion Concerns

There are many posts on support forums asking why these restrictions aren’t easier and expressing frustration, particularly from intranet, membership, and private site creators.
WordPress directs most feature requests to plugins, partly to allow its marketplace to thrive—this appears like “collusion” to some, though there is no factual evidence of coordinated restriction, just market-driven extension.
The community does discuss and request more privacy controls periodically, and future core updates could include better user-level visibility tools.

While it can be frustrating for those needing private access, WordPress intentionally favors extensibility over feature bloat, letting users customize and control their experience through a vibrant plugin ecosystem

WordPress Has NO Core Feature to Restrict Reading Certain Content to Only Signed In Users. Here is How to Do It.