To restrict usernames in WordPress, first identify the registration flow. Standard WordPress registration can use the illegal_user_logins filter for a denylist and registration_errors or register_post for custom validation. Multisite uses wpmu_validate_user_signup() and its own signup filters. Plugin-based membership forms may bypass these checks, so verify the exact form your visitors use.
Restricting names is a naming policy, not a substitute for strong passwords, two-factor authentication, and login throttling. WordPress does not treat usernames or user IDs as secret security credentials.
Choose the method that matches your registration flow
| Situation | Best starting point | Important limitation |
|---|---|---|
| Single-site visitors register through the normal WordPress login page | illegal_user_logins for blocked names; registration_errors or register_post for rules such as patterns and length |
It affects the flow that runs WordPress core registration. |
| WordPress Multisite signup | wpmu_validate_user_signup() and its documented signup filters |
Multisite has separate validation and reserved-name behavior. |
| A membership or community plugin owns registration | Use that plugin’s validation settings or a compatible extension | Some plugins bypass the core checks and hooks. |
| An existing administrator has an obvious login name | Rename or replace that administrative account as a separate hardening task | Changing future-registration rules does not rename an existing account. |
Block specific names in standard WordPress registration
WordPress core validates a new user through register_new_user(). Before the account is created, you can supply prohibited names with the illegal_user_logins filter. Put this code in a site-specific plugin or a child theme’s functions file so it is not lost when a parent theme is updated:
<?php
add_filter( 'illegal_user_logins', function ( $illegal_user_logins ) {
$illegal_user_logins[] = 'admin';
$illegal_user_logins[] = 'administrator';
$illegal_user_logins[] = 'support';
$illegal_user_logins[] = 'security';
return array_values( array_unique( $illegal_user_logins ) );
} );The filter is a denylist: it is appropriate when only a finite set of names must be unavailable. Decide whether your policy should be case-insensitive and test the result with the actual registration form. A blocked name should produce a registration error and no account should be created.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteAdd pattern, character, or length rules
For rules that a denylist cannot express, use the registration validation hooks. The registration_errors filter receives the accumulated WP_Error; adding an error prevents registration. This example requires a lowercase-and-digit username between 6 and 20 characters:
<?php
add_filter( 'registration_errors', function ( $errors, $sanitized_user_login, $user_email ) {
if ( ! preg_match( '/^[a-z0-9]{6,20}$/', $sanitized_user_login ) ) {
$errors->add(
'username_policy',
'Choose a username containing 6–20 lowercase letters or numbers.'
);
}
return $errors;
}, 10, 3 );Use register_post when you need to customize processing at the registration stage. Keep validation aligned with the form’s own sanitization rules, and test duplicate names, blocked names, spaces, punctuation, very short values, and values at both length boundaries.
Handle WordPress Multisite separately
Multisite signup does not use the single-site path unchanged. wpmu_validate_user_signup() strips whitespace, checks the username against lowercase letters and digits, checks illegal names, and applies the multisite signup filters.
Rank #2
Default reserved names
The documented multisite defaults reserve www, web, root, admin, main, invite, and administrator. These are defaults in the documented multisite validation path, not a guarantee that every registration plugin or custom form enforces the same list.
Recommended Free Tools
Custom multisite validation
Use the illegal_user_logins and wpmu_validate_user_signup filters documented for the multisite path. Test both user signup and site signup, because a custom front end may submit data differently from the network’s standard signup screen.
When a plugin is the practical option
A plugin can expose settings for non-developers, but compatibility with the registration flow matters more than the settings screen.
Rank #3
Restrict Usernames
The WordPress.com listing describes controls for reserved prefixes and patterns, spaces, required substrings, and minimum or maximum length. It applies to visitor self-registration, not accounts created in wp-admin. The listing also warns that some membership plugins bypass the checks and hooks on which it depends. Its displayed tested version is WordPress 4.9.29, an old compatibility declaration, so check current maintenance, support activity, and compatibility with your installed WordPress and membership plugin before relying on it.
Restrict Usernames Emails Characters
The WordPress.org listing advertises configurable restrictions on usernames, email addresses, and symbols. Review its current release, changelog, and support activity before deployment; historical tested-version statements do not establish present compatibility.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Plugin verification checklist
- Submit a real test registration through the exact public form visitors use.
- Confirm that a prohibited value is rejected before an account is created.
- Test administrator-created accounts separately; a plugin may intentionally exclude them.
- Check whether a membership, social-login, or custom-registration plugin uses its own endpoint.
- Retest after WordPress, the registration plugin, or the restriction plugin is updated.
Restricting names is not username security
The WordPress Hosting Handbook states: “The WordPress project doesn’t consider usernames or user IDs to be private or secure information. A username is part of your online identity. It is meant to identify, not verify, who you are saying you are. Verification is the job of the password.”
Many sites expose account information through the REST API endpoint /wp-json/wp/v2/users. A unique or hidden username therefore does not reliably stop login attacks. Use a strong, unique password, enable two-factor authentication, and add sensible login throttling. Treat username restrictions as account-naming policy and reduction of predictable names, not as authentication.
Rename an existing administrator account
Blocking admin for future registrations does not change an administrator account that already uses that login. The WordPress hardening guidance recommends renaming an obvious administrative account and documents a database method.
- Make a verified database backup before changing account data.
- Keep a separate, tested recovery route so you cannot lock out every administrator.
- Follow the hardening guidance’s database example carefully, adapting the account identifier and new login to your installation.
- Sign out and confirm that the renamed account can log in and still has the required capabilities.
- Remove or disable the old administrative route only after recovery has been verified, and assign existing content correctly if an account is replaced rather than renamed.
Database edits are installation-specific. Do not run an unreviewed query on a production site, and do not assume that renaming an administrator hides the account from every WordPress interface or API response.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Troubleshoot a rule that appears not to work
The standard registration form accepts a blocked name
- Confirm the code is active and has no PHP syntax error.
- Check that the form is WordPress’s standard registration flow, not a plugin-specific form.
- Verify that the value being tested is the sanitized login, not a display name.
- Test in a private session after clearing caching layers that may serve an old form.
A membership form bypasses the rule
Check the membership plugin’s own validation API or settings. The core hooks may never run, so adding more conditions to the core filter will not fix that flow.
Multisite behavior differs from single-site behavior
Test through the network’s signup path and review the multisite filters. Do not infer multisite results from a single-site test.
An administrator can still create a restricted username
That may be expected. Visitor-registration restrictions and administrator-created accounts are separate scopes; enforce an administrative naming policy through your operational process or an administrative-account plugin that explicitly supports it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
