How to restrict content by user role in WordPress

Decide whether you need to protect a whole page, a section inside a page, a custom post type, a taxonomy, or a downloadable file. These are different jobs. A membership or LMS site often needs several rules, such as lessons for enrolled users and resources for instructors.

Also decide what visitors should see instead: a login prompt, an upgrade message, a 404 response, or nothing. Do not rely on hiding a menu item as protection because users may still reach the URL directly.

Go to Users and confirm which roles your users actually have. WordPress includes roles such as Administrator, Editor, Author, Contributor, and Subscriber; each role receives a set of capabilities. Custom membership and LMS plugins may add their own roles.

Use a capability for the access decision rather than comparing role names wherever possible. WordPress documentation warns that checking a role directly can be unreliable, while current_user_can() is designed to test capabilities.

For a basic logged-in-only page, edit the page, open the Visibility setting, choose Private, and update it. This uses WordPress's private-content capability checks, so it can be suitable for small internal sites.

Private visibility is not a general role restriction. It does not give you a simple rule such as “Subscribers can see this lesson but Authors cannot”, and it is not a solution for hiding one section inside a public page. Test the result with a real account in each role before using it for paid or course content.

For a small custom implementation, add a capability such as view_members_content to each permitted role once. In site-specific code, retrieve a role with get_role() and call add_cap(); for example, $role = get_role( 'subscriber' ); if ( $role ) { $role->add_cap( 'view_members_content' ); }. Repeat this for every allowed role, and run it only during setup or activation because role changes are saved in the database.

In the template, custom block rendering code, or a shortcode callback, show the protected output only when current_user_can( 'view_members_content' ) returns true. Otherwise return your login or upgrade message. Shortcode callbacks must return their output rather than echoing it, and a custom shortcode is registered with add_shortcode().

This manual route is fine for one or two stable rules, but it becomes awkward when editors need to change access without editing code, when several roles overlap, or when you need to protect custom fields, taxonomies, lessons, or files.

Test while logged out, as a permitted user, and as a user in a role that should be blocked. Check the direct URL, archive pages, search results, feeds, menus, REST-powered blocks, and downloadable files. A hidden button is not enough if the original content or file URL remains public.

If a blocked user still sees the content, clear page and object caches and test with the active theme and other plugins in mind. Support cases commonly involve cached logged-in and logged-out versions, shortcode placement, or theme and plugin conflicts.

For complex access rules, use Toolset Access Addon. It provides a dashboard for role and user permissions across custom post types, taxonomies, and fields, with conditional content controls and support for multiple roles.

Install and activate it, then configure the roles and capabilities in its access settings. Choose this route when non-developers need to maintain the rules, or when your site has an LMS, custom content, or several membership levels. The manual capability check is genuinely fine for a small site; the plugin saves time once the rules become conditional or spread across different content types.