Page Locks
Page Locks lets you restrict access to selected WordPress admin pages for users who match your Admin UX Cleaner (AUC) Audience configuration.
While Menu Cleaner controls what users see in the WordPress admin navigation, Page Locks controls whether selected admin pages can actually be accessed.
Use Page Locks when hiding a menu item is not enough and you need to prevent the selected audience from opening the page directly.
Page Locks lets you restrict access to selected WordPress admin pages for your configured audience.
Menu Cleaner vs. Page Locks
Menu Cleaner and Page Locks serve different purposes.
Menu Cleaner is designed to simplify the admin interface.
For example, hiding Plugins removes it from the admin menu for the affected audience. However, if the user still has the required WordPress capability, they may be able to access the Plugins page using its direct URL.
Page Locks adds an access restriction to the selected admin page.
A simple rule to remember is:
Hide it when users do not need to see it. Lock it when users should not be able to access it.
In many client setups, you may use both features together.
Lock an Admin Page
Open Page Locks in Admin UX Cleaner.
Select the admin page you want to restrict and enable the lock for that page.
Select the WordPress admin page that should be inaccessible to the affected audience.
Save your configuration when you are finished.
Users who match your Audience configuration will no longer be able to access the locked page normally.
Direct URL Access
One of the main reasons to use Page Locks is to handle direct access to WordPress admin pages.
For example, you may hide a menu item using Menu Cleaner, but a user could still attempt to open a URL such as:
/wp-admin/plugins.php
If the page is protected by a Page Lock for that user, AUC can prevent the user from accessing it even when the URL is entered directly.
This is the key difference between hiding navigation and restricting page access.
Redirecting Locked Pages
When a user attempts to open a locked admin page, AUC redirects them away from the restricted location.
Depending on your Page Locks configuration, you can define an appropriate destination for affected users.
Configure where affected users should be redirected when they attempt to access a locked admin page.
Choose a destination that remains accessible to the target audience.
Avoid redirecting a locked page to another page that is also restricted, as this may create an invalid or confusing navigation flow.
Audience Rules Still Apply
Page Locks follows your AUC Audience configuration.
A locked page is therefore not automatically locked for every WordPress user.
For example, if your Audience includes:
Editor
but does not include your Administrator account, the Page Lock can affect Editors while your Administrator account continues to access the page normally.
This allows you to restrict selected client or staff accounts without unnecessarily restricting the people responsible for maintaining the website.
For details about targeting roles and users, see Audience.
Page Locks Do Not Modify WordPress Capabilities
Page Locks does not rewrite the WordPress roles and capabilities system.
AUC applies its own page-level restriction for the configured audience while leaving the user's underlying WordPress role and capabilities unchanged.
This is useful when you want to control access to selected admin pages without permanently modifying the existing WordPress permission structure.
If your website requires a broader permission model, WordPress roles and capabilities should remain the primary authorization system.
What Should You Lock?
Page Locks should be used intentionally.
Good candidates are admin pages that a particular client or user group should not access as part of their normal workflow.
Depending on the website, examples may include:
- Plugin management pages.
- Theme management pages.
- Selected settings pages.
- Plugin configuration pages.
- Maintenance or administrative tools.
Do not lock pages simply because they look technical.
Some WordPress features depend on other admin pages internally, and third-party plugins may use admin URLs for background workflows, forms, redirects, or configuration screens.
Start with the pages you clearly need to restrict and test the affected workflows afterward.
Third-Party Plugin Pages
Page Locks can also be useful for admin pages registered by WordPress plugins.
However, third-party plugins do not all structure their admin pages in the same way.
A plugin may:
- Use several admin URLs for one feature.
- Redirect between admin pages.
- Process forms through a different admin endpoint.
- Load functionality through shared WordPress admin pages.
Because of this, always test Page Locks applied to third-party plugin pages before deploying the configuration to clients or production users.
Test Your Page Locks
After adding a Page Lock, verify the result before applying additional restrictions.
A good test is to:
- Confirm that the target page is locked for the intended audience.
- Try opening the page through its normal admin navigation.
- Try opening the page using its direct URL.
- Confirm that the redirect destination works correctly.
- Verify that your own administrative access remains available.
- Test any related workflow that may depend on the locked page.
Whenever possible, perform the final test using an actual WordPress account that represents the intended user.
Safety and Recovery
Page Locks can affect access to important WordPress admin areas, so configure them more carefully than simple menu visibility changes.
Before creating broad restrictions:
- Review your Audience configuration.
- Make sure your own account remains protected by the appropriate AUC safety mechanism.
- Keep your recovery information available.
- Test a small number of Page Locks first.
- Create a backup of a known working AUC configuration.
Review AUC safety and recovery options before applying significant Page Lock restrictions.
If an incorrect configuration causes an access problem, AUC provides recovery mechanisms designed to help you regain administrative access.
See Owner & Manager Access, Recovery URL, and Safe Mode for details.
Example: Protecting Plugin Management
Suppose a client uses an account that should manage website content but should not access plugin management.
You could configure:
Audience
└── Include: Client role or user
Menu Cleaner
└── Plugins: Hidden
Page Locks
└── Plugins page: Locked
For the affected client:
- Plugins is removed from the admin navigation.
- Opening the Plugins page directly is also restricted.
Meanwhile, an administrator who is not part of the configured Audience can continue using the Plugins page normally.
This combination creates a cleaner interface while also protecting the selected admin page from direct access.
Recommended Approach
When using Page Locks:
- Configure your Audience first.
- Use Menu Cleaner for visual cleanup.
- Add Page Locks only where access restriction is necessary.
- Choose a safe redirect destination.
- Add a small number of locks at a time.
- Test both normal navigation and direct URL access.
- Verify your administrative and recovery access.
- Back up a working configuration before making significant changes.
Page Locks are most effective when used selectively rather than as a replacement for the entire WordPress permission system.
Next Step
After configuring Page Locks, use Preview to review how the WordPress admin experience appears to your selected audience.
Before handing the website over to a client, also review the Safety & Recovery documentation and test important workflows with an appropriate user account.