How to Protect Custom Post Types in WordPress

Custom Post Types (CPTs) extend WordPress beyond its default post and page structures. A CPT might represent courses in an LMS, properties in a real estate platform, case studies in a portfolio site, or confidential reports in a client portal. Because CPTs can contain sensitive or premium content, controlling who can view, edit, and publish them is a core requirement for any serious WordPress application.

By default, when you register a new CPT with register_post_type(), it inherits capabilities from the built-in post capability structure. This means anyone who can edit posts can also edit your CPT, and depending on your visibility settings, the CPT’s archive and single pages may be publicly accessible without any authentication. That’s rarely what you want on a membership site or client portal.

The good news is that WordPress’s capability system is well-designed and gives you fine-grained control. With the right registration arguments, you can create CPT-specific capabilities, assign them to exactly the right roles, and build an access control layer that’s both secure and maintainable.

The key to native CPT protection is the capability_type and map_meta_cap arguments in register_post_type(). Setting capability_type to a custom string (like 'course') tells WordPress to generate a unique set of capabilities for this post type: edit_course, read_course, delete_course, edit_courses, edit_others_courses, and so on.

function wpdev_register_course_cpt() {
    $labels = array(
        'name'          => 'Courses',
        'singular_name' => 'Course',
        'menu_name'     => 'Courses',
    );

    $args = array(
        'labels'             => $labels,
        'public'             => false,   // Not publicly queryable.
        'publicly_queryable' => true,    // Allow front-end queries when user has caps.
        'show_ui'            => true,
        'show_in_menu'       => true,
        'query_var'          => true,
        'rewrite'            => array( 'slug' => 'courses' ),
        'capability_type'    => 'course', // Creates custom capabilities.
        'map_meta_cap'       => true,     // Let WordPress handle meta capabilities.
        'has_archive'        => true,
        'hierarchical'       => false,
        'supports'           => array( 'title', 'editor', 'thumbnail', 'excerpt' ),
    );

    register_post_type( 'course', $args );
}
add_action( 'init', 'wpdev_register_course_cpt' );


/**
 * Grant course capabilities to the 'instructor' role.
 * Run once on plugin/theme activation — not on every page load.
 */
function wpdev_add_course_caps() {
    $instructor = get_role( 'instructor' );
    if ( $instructor ) {
        $instructor->add_cap( 'edit_course' );
        $instructor->add_cap( 'read_course' );
        $instructor->add_cap( 'delete_course' );
        $instructor->add_cap( 'edit_courses' );
        $instructor->add_cap( 'publish_courses' );
    }

    // Grant read-only access to subscribers (enrolled students).
    $subscriber = get_role( 'subscriber' );
    if ( $subscriber ) {
        $subscriber->add_cap( 'read_course' );
    }
}
register_activation_hook( __FILE__, 'wpdev_add_course_caps' );

With this setup, only users with the read_course capability can view individual course posts. Everyone else gets a 404 or is redirected to your login page — whatever your theme handles for unauthorized access.

Role-based access control (RBAC) for CPTs works by assigning capabilities to roles, then letting WordPress’s native permission checks handle the rest. When a user attempts to view a CPT post, WordPress checks whether that user’s role has the appropriate capability. If not, the access is denied.

The critical distinction is between front-end visibility and back-end (admin) access. Setting 'public' => false on your CPT hides it from the front-end REST API and XML sitemaps by default, but setting 'publicly_queryable' => true still allows front-end templates to query and display the content for authorized users. This is the right combination for most protected content: not discoverable by search engines or unauthenticated API calls, but accessible to logged-in users with the right role.

For front-end access gates, add a check in your single CPT template using current_user_can('read_course', $post->ID). If it returns false, display your upsell or login prompt instead of the content. This is a belt-and-suspenders approach that works even if a direct URL is accessed.

WordPress’s built-in post password feature works with custom post types if your CPT is registered with 'public' => true or 'publicly_queryable' => true. In the post editor, set Visibility to “Password Protected” and enter a password. WordPress will show a password form on the front end before revealing the content.

This is a lightweight solution for occasional document protection or preview-before-purchase scenarios. It’s not suitable for full membership sites because passwords are shared and can’t be revoked per-user. For proper per-user access control, use the capability-based approach described above.

To redirect unauthenticated users away from protected CPT pages, hook into template_redirect and check both the post type and the user’s login status. This fires before any template output, so you can safely redirect without causing header conflicts.

You can also use the pre_get_posts filter to exclude your protected CPT from the main query entirely for non-logged-in users. This prevents protected content from appearing in search results, category pages, or any other archive that uses the main WordPress query — a particularly important consideration for sites with internal search functionality.

For complex multi-tier membership sites, combining the native capability approach with a plugin like MemberPress, Restrict Content Pro, or LearnDash gives you the best of both worlds. The plugin handles payment processing and subscription management; your native capability code handles the actual access control logic.

Use the plugin’s webhooks or action hooks (like MemberPress’s mepr-event-member-signup-completed) to call your wpdev_add_course_caps() function when a user upgrades to a paid tier. On cancellation or expiry, a corresponding function removes those capabilities. This approach keeps your access logic portable and independent of the membership plugin’s own content restriction UI, which gives you much more flexibility in your front-end design.