Stop handing out usernames through the author archive URL
Hide Author Slug replaces the username in every author URL with a random, non-guessable token, closing off the REST API, the archive address and the ?author=N redirect as ways to harvest a valid login name — while the archive itself keeps working exactly as before.
- Every author gets a random 16-character token, generated automatically.
- The real username URL returns a clean 404, not the archive.
- The REST API reports the token instead of the login name.
- Fully reversible — the actual username in the database is never touched.
/author/lorenzo//author/x7k2p9qm3w8f5j1a/What does Hide Author Slug do?
When the hide_author_slug module is active, TOWP_Hide_Author_Slug gives every author a random, unique slug token, stored in user meta without ever touching the real user_nicename in the database. Author links generated anywhere on the site get rewritten to use the token instead of the username, visiting the token URL resolves back to that author normally, and visiting the real username URL directly returns a 404. Since a bare ?author=N request would otherwise get 301-redirected straight to the username URL by WordPress itself, the module intercepts that and sends it to the token URL instead, and the REST API's users endpoint reports the token as the slug rather than the login name.
WordPress hands out login names through more doors than one
Since the same username surfaces through several unrelated paths, closing just one of them still leaves the door open.
An author's archive address is the login name itself
By default, /author/{username}/ uses the actual login name as its URL, making it visible to anyone who clicks an author byline or guesses the address.
The REST API exposes the same name to anything automated
The /wp-json/wp/v2/users endpoint reports the same username as a machine-readable slug, which is exactly the kind of list a brute-force attempt starts from.
One random token, closing every leak point at once
Instead of changing how the author archive actually works, the module replaces the username with an unguessable token wherever WordPress would otherwise reveal it.
A random, unique token per author
Every author gets a 16-character token, generated automatically and guaranteed unique across every user on the site.
The real username URL stops resolving
Visiting the address built from the actual login name returns a clean 404 instead of the author archive.
Fully reversible, nothing touched in the database
The real user_nicename never changes, so disabling the module puts every address back exactly as it was.
Four leak points, one token system
Every capability below is present in the supplied PHP class and its settings registration.
The author_link filter, applied precisely
Every author URL generated by the theme gets its trailing username segment swapped for the token, matched carefully so nothing else in the link gets touched.
Not just hidden, actually blocked
Visiting /author/{username}/ directly resolves to no author at all, rather than quietly still showing the archive.
Intercepted before WordPress's own redirect fires
WordPress would normally 301-redirect a bare ?author=N request straight to the username URL; this module sends it to the token URL first instead.
The users endpoint reports the token too
/wp-json/wp/v2/users returns the token as both the slug and the link, closing off a machine-readable enumeration path a URL-only fix would miss.
No unnecessary substitution where there's nothing to hide
When permalinks are set to Plain, where the URL carries no username to begin with, the module leaves links untouched instead of processing them pointlessly.
New users get one immediately, existing users on first use
A new account receives its token the moment it's created; an existing account gets one generated the first time it's actually needed.
Where hiding the author slug helps most
The module supports any site where a username shouldn't be reachable through the author archive or the REST API.
Sites where usernames double as an attack surface
Close off the archive, the redirect and the REST API as ways an attacker collects valid login names before a brute-force attempt.
Sites with public REST API access enabled
Prevent the users endpoint from handing out login names to anything that queries it programmatically.
Pairing with Restrict Login Identifier
Make a username-only login restriction actually meaningful by closing off the places that username would otherwise be published.
Less exposure, nothing else disturbed
The module combines a real reduction in exposure with a design that leaves everything else exactly as it was.
One lookup, generated once and reused
The verified implementation keeps token handling lightweight in every configuration.
One token lookup per author link
Resolving or generating a token is a single indexed user-meta lookup, no heavier than any other per-user data WordPress already reads.
No processing when there's no username to hide
With Plain permalinks active, the link-rewriting filter returns immediately, adding no overhead in that configuration.
Tokens generated once, reused after
A token gets created a single time per user and then read directly on every subsequent request, rather than being recalculated.
Four leak points closed, no new exposure introduced
The code addresses every ordinary way a username surfaces publicly, without changing anything about access itself.
Closes four leak points, not just one
The archive URL, the real-slug direct visit, the ?author=N redirect and the REST API all get addressed by the same token system.
The real username never appears in a public response
Between the rewritten links, the blocked slug, the redirected query and the filtered REST output, no ordinary request surfaces the actual login name.
Tokens are cryptographically random and collision-checked
Each token comes from wp_generate_password() and gets verified unique against every other user's token before being saved.
No new capability or access path introduced
The module only changes what appears in a URL or API response; it doesn't add, remove, or alter any user's actual permissions.
Built directly around WordPress's own author and REST filters
The supplied code integrates through APIs present in WordPress core; this page makes no compatibility claim beyond the verified implementation.
author_link filter
The native WordPress filter used to modify any author URL wherever a theme or plugin calls get_author_posts_url().
request filter
The core filter used to translate the token back to the correct author, or force a 404 for anything else.
rest_prepare_user filter
The native WordPress REST API filter used to modify a user's response data before it's returned.
TheOneWP versus common alternatives
Compare the verified Hide Author Slug implementation with a typical URL-only obfuscation approach.
| Capability | TheOneWP Hide Author Slug | Other common solutions |
|---|---|---|
| Author archive URL | Random token, real username returns a 404 | Often only obfuscates the link without blocking direct access to the real slug |
| The ?author=N redirect | Intercepted before WordPress's own redirect reveals the username | Frequently overlooked, still leaking the username through the default redirect |
| REST API exposure | The users endpoint reports the token too | Usually addressed only by URL-based fixes, leaving the API untouched |
| Database changes | None; the real nicename is never modified | Some approaches rename the nicename directly, which can affect other functionality |
| Reversibility | Instant; disabling the module restores normal URLs | A renamed nicename can require manual cleanup to undo |
Hide every username in four steps
Since there's nothing to configure beyond enabling it, verification is the real workflow here.
Enable Hide Author Slug
Activate the module from the TheOneWP Components settings tab; there's nothing further to configure.
Confirm an author URL now uses a token
Visit any author archive link on the site and check that the address no longer shows the username.
Confirm the real username URL 404s
Try visiting the old /author/{username}/ address directly and confirm it no longer resolves.
Check the REST API if it's publicly accessible
Query /wp-json/wp/v2/users and confirm the slug and link fields show the token rather than the login name.
Pair it with the rest of a login hardening approach
Hiding the username matters most alongside the login protections that make guessing it harder to exploit.
Enable it alongside other login-hardening modules
Pairing this with a username-only login restriction closes the loop between exposure and guessability.
Don't rely on it as the only login protection
Hiding the username removes one attack surface; it's not a substitute for strong passwords or rate limiting.
Recheck after disabling and re-enabling
Since disabling the module reverts URLs immediately, confirm links look as expected again if the module gets toggled back off.
Verify third-party integrations that call the REST users endpoint
An integration expecting the real nicename as the slug should be checked against the token-based response.
Avoid assuming it covers every exposure point
A couple of details are worth keeping in mind about what this module does and doesn't reach.
Assuming the username is hidden everywhere on the site
This module addresses the author archive, its redirect and the REST API specifically; a username can still appear elsewhere, such as in login error messages.
Expecting the token to stay the same forever without checking
The token is stable once generated for a given user, but it's still worth confirming links after any change to the module's configuration.
Forgetting the REST API is a separate exposure point
A URL-only fix leaves the REST users endpoint untouched; this module's REST coverage is what closes that specific gap.
Hide Author Slug FAQ
These answers come directly from the verified class and its settings registration.
What does Hide Author Slug do?
It replaces the username in every author URL with a random token, so the author archive, the ?author=N redirect and the REST API all stop exposing the actual login name.
Does the author archive still work?
Yes. The archive functions exactly as before, just at an address built from the random token instead of the username.
What happens if someone visits the old /author/username/ address directly?
It returns a clean 404, since the module explicitly blocks the real username slug from resolving.
Does this change the username stored in the database?
No. The real user_nicename is never modified; the token is stored separately in user meta.
Is this reversible?
Yes. Disabling the module reverts every author URL to the normal, nicename-based address immediately.
Does this affect the REST API?
Yes. The /wp-json/wp/v2/users endpoint reports the token as both the slug and the link, instead of the real username.
How is the token generated?
Each author gets a random 16-character token, created with wp_generate_password() and checked for uniqueness against every other user.
Do existing users need any manual setup?
No. An existing user gets a token generated automatically the first time one is needed.
Does this work with Plain permalinks?
The module skips link rewriting when Plain permalinks are active, since that structure carries no username in the URL to begin with.
Is there anything to configure beyond enabling the module?
No. The module works automatically once enabled, with no additional settings.
Stop letting the author archive hand out login names.Replace every username with a random token.
Use Hide Author Slug to close off the archive URL, the ?author=N redirect and the REST API as ways to collect a valid username, with the real login name never touched in the database.