How to hide your WordPress username from visitors

A WordPress login is two things: a username and a password. Everyone guards the second. Almost nobody notices that the first is public. Out of the box, WordPress will tell any visitor, and any bot, exactly what your usernames are, and it does so through four separate doors. Once a bot has the username, every login attempt it makes is a real attempt rather than a guess in the dark. If you want to hide your WordPress username, you have to close all four.

Check your own site first

Open a private browser window, so you are not logged in, and try these on your own domain.

1. /?author=1. WordPress redirects it to /author/<username>/. User 1 is almost always the account that set the site up, so this is the one bots ask for first. Change the number and it walks through every account.
2. /wp-json/wp/v2/users. The REST API lists every user who has published something: display name, the slug (which is the username for most accounts) and the author page link, as a tidy JSON array.
3. /wp-sitemap.xml. Since WordPress 5.5 the built-in sitemap has a users section that links every author page. Yoast SEO adds its own author-sitemap.xml.
4. Any post’s embed preview. The oEmbed response that other sites fetch when they embed your post names the author and links to the author page.

If your site is a shop, a company site, a portfolio or a one-person blog, none of these doors serve a reader. They exist for multi-author publications where the author archive is a real page people visit. On every other site they are pure leakage.

What people usually try

Renaming the admin account helps against bots that only try admin, and it is worth doing. It does nothing about the leak: the new name is published through the same four doors the moment you save it.

Setting a different display name hides the username in bylines, but the slug in the REST response and the author URL still carry the login. Bots read the slug, not the byline.

Blocking ?author= in .htaccess is the classic snippet. It closes one door, on Apache only, and leaves the REST API and the sitemaps open. Most guides that recommend it were written before the REST API existed.

Disabling the whole REST API works, but it breaks the block editor, most page builders, and any plugin that talks to your site, because they all use it while you are logged in.

Close the doors, keep the admin working

The right shape of fix is: close every door for visitors who are not logged in, and change nothing for anyone who is. Logged-in users need the users route for the editor and the admin, and they already know the usernames.

Adminkeep ships this as one switch, Username Privacy. With it on, a visitor gets “not found” from author pages and from ?author=1 (before WordPress has a chance to redirect it to the username), the REST users list is gone for visitors while posts and pages stay readable, authors are left out of the sitemap, WordPress’s own and Yoast’s, and out of embed previews, and author names in your theme stop linking to author pages. Anyone logged in, from subscriber to administrator, sees the site exactly as before.

Nothing is written to the database. It works entirely through WordPress filters, so switching it off reopens every page and route at once, with nothing to repair. The one site that should leave it off is a multi-author blog whose readers actually use the author pages.

Don’t want another plugin? The pieces are all filters: a template_redirect callback at priority 1 that calls set_404() when is_author() is true for a logged-out request, a rest_endpoints filter that unsets the /wp/v2/users routes for logged-out requests, wp_sitemaps_add_provider returning false for the users provider, wpseo_sitemap_exclude_author returning an empty array, and oembed_response_data unsetting the two author keys. Adminkeep is on wordpress.org if you would rather have the switch.

What this does not do

Hiding the username is one half of the login, kept private. It is not a login limiter, a firewall or a malware scanner. A bot that already knows a username from an old data breach can still try passwords against it, which is what a strong password and, later, a login-attempt limit are for. And it is enforced in PHP: anyone with database or file access can read the users table directly. This is about not handing the name to strangers for free.