Why WordPress author archives leak usernames

WordPress author archives can expose username-related information because author URLs are built around a public user slug called user_nicename.

A typical author archive looks like:

https://example.com/author/john/

If:

john

also happens to be the account’s WordPress login username, an attacker has learned a valid login identifier simply by browsing a public URL.

But there is an important technical distinction:

user_login
≠
user_nicename
≠
display_name

They are separate WordPress user properties.

The problem is that WordPress commonly derives user_nicename from user_login when an account is created unless another nicename is explicitly supplied.

That is why author archives can expose information that is useful for username enumeration.

This guide explains how WordPress author URLs work, why the public author slug can reveal login-related information, what user_login, user_nicename and display_name actually mean, how REST API output relates to the issue, and when you should hide the author slug or disable author archives completely.

What is a WordPress author archive?

WordPress can create archive pages that collect posts written by a particular author.

A typical URL is:

https://example.com/author/john/

The page may contain:

• the author’s name;
• biographical information;
• avatar;
• links;
• a list of posts written by that author.

The official WordPress Theme Handbook template hierarchy describes author archives as a dedicated archive type associated with WordPress users and their published posts.

WordPress has a dedicated author template hierarchy

For an author archive, WordPress can look for templates such as:

author-{user_nicename}.html
author-{user_id}.html
author.html
archive.html
index.html

in a block theme.

Classic themes use the corresponding PHP files:

author-{user_nicename}.php
author-{user_id}.php
author.php
archive.php
index.php

The official classic theme template hierarchy documentation confirms that WordPress specifically uses the author’s nicename in the author template hierarchy.

The author URL is based on user_nicename

WordPress generates author archive URLs through functionality such as:

get_author_posts_url()

The official get_author_posts_url() documentation shows that the function uses:

$user->user_nicename

when constructing the author URL.

Conceptually:

user_nicename:
john

author URL:
https://example.com/author/john/

user_nicename is not technically the login username

This distinction matters.

WordPress stores several separate values for a user.

The Core users table includes fields such as:

user_login
user_pass
user_nicename
user_email
user_url
display_name

The official WordPress Plugin Handbook user metadata documentation documents these fields as separate properties of the WordPress user record.

What is user_login?

user_login is the account’s login username.

For example:

user_login:
john.admin

It can be used as an authentication identifier depending on the site’s login configuration.

What is user_nicename?

user_nicename is the URL-friendly identifier associated with the user.

It is used in contexts including author URLs.

For example:

user_nicename:
john-admin

What is display_name?

display_name is the public-facing name WordPress can display for the user.

For example:

display_name:
John Smith

These three values could therefore be:

user_login:
john.admin

user_nicename:
john-admin

display_name:
John Smith

Why do author archives often expose something similar to the username?

Because of the way WordPress initializes new users.

The official wp_insert_user() documentation and Core source show that if a specific user_nicename is not supplied, WordPress builds it from the login name.

Conceptually:

user_login:
john.admin

↓ sanitize for URL

user_nicename:
john-admin

This creates the username-enumeration problem

An attacker sees:

/author/john-admin/

and may reasonably test:

john-admin
john.admin
johnadmin

as possible account identifiers.

On many WordPress installations, the nicename and actual login may be identical or trivially related.

Do not describe this as WordPress exposing passwords

Author archives do not expose:

• the password;
• password hash;
• 2FA secret;
• session cookies.

They expose a public account identifier or a value closely related to one.

Why does knowing a username matter?

Authentication normally involves at least:

identifier
+
secret

For example:

username
+
password

If the attacker already knows the username, they need to discover only the password.

This reduces the unknown information involved in an automated login attempt.

But usernames should not be treated as secrets

This is equally important.

A secure authentication system should remain resistant even if:

username = known

Usernames can become public through many different channels.

For the broader problem, see How Attackers Collect WordPress Usernames and Email Addresses.

The correct security model

Do not build security around:

attacker must never discover username

Build it around:

username may become known
+
password is unique and strong
+
2FA is enabled
+
login attempts are limited
+
privileged accounts are monitored

Author archives are reconnaissance, not account compromise

Finding an author slug does not mean an attacker has authenticated.

It means the attacker has potentially learned useful reconnaissance information.

The sequence might be:

discover author URL
↓
identify possible username
↓
attempt credential stuffing
↓
attempt password spraying
↓
attempt brute force

For the attack mechanics, see WordPress Brute-Force Attacks, Explained.

Strong passwords remain more important than username secrecy

Consider two accounts.

Account A

username:
secret-admin-8231

password:
Company2026

Account B

username:
john

password:
unique long random password
+
2FA

Account B has the stronger authentication design even though its identifier is obvious.

Author archive URLs can reveal the nicename even when display names are safe

Changing:

Display name publicly as:
John Smith

does not necessarily change:

/author/john-admin/

Display name and author slug are separate

You might have:

user_login:
adminjohn

user_nicename:
adminjohn

display_name:
John Smith

The visible article byline says:

John Smith

while the link behind it points to:

/author/adminjohn/

Changing the display name alone does not solve author-slug exposure

This is a common mistake.

The public author link can still disclose the nicename even though the human-readable name has changed.

How themes expose author archives

A theme may link the author’s name using WordPress functions that ultimately resolve the author’s archive URL.

For example, a post may display:

Written by John Smith

with:

John Smith
↓
/author/adminjohn/

Author archive support exists in both classic and block themes

Classic themes can use:

author.php

while block themes can use:

author.html

The official WordPress Theme Handbook templates documentation identifies author.html as the template used for author archives in block themes.

The template does not create the underlying identifier

Changing:

author.php

or:

author.html

changes presentation.

The underlying WordPress user still has:

user_login
user_nicename
display_name

Author archive template removal alone may not remove the archive

If a theme has no dedicated author template, WordPress can fall back through the template hierarchy to:

archive
↓
index

Deleting author.php therefore does not necessarily disable author archives.

WordPress considers author archives a normal archive type

The Theme Handbook explains that an author archive combines user profile information with a post archive.

This is useful for:

• news publications;
• magazines;
• multi-author blogs;
• editorial sites;
• expert-content platforms.

Author archives are not inherently a vulnerability

A public author page is legitimate WordPress functionality.

The security concern comes from unnecessary exposure of account-related identifiers.

This is better described as:

information exposure
or
reconnaissance surface

than:

critical WordPress vulnerability

The author slug can be intentionally different from the login

A more privacy-aware account structure might look like:

user_login:
jsmith-backend-91

user_nicename:
john-smith

display_name:
John Smith

The public URL becomes:

/author/john-smith/

while the login identifier remains different.

But WordPress does not provide a simple native profile field for changing user_nicename

This is where implementation becomes less convenient.

The normal WordPress profile screen lets users change their:

• nickname;
• display name;
• biographical information;
• website;
• other profile information.

It does not generally provide a simple built-in interface for editing the underlying user_nicename independently.

Do not edit the database casually

The value exists in:

wp_users.user_nicename

but directly modifying production user records in the database should not be the first-line workflow.

Changing author slugs can affect:

• existing author URLs;
• internal links;
• search-engine indexing;
• caches;
• custom integrations.

Changing a public author URL can create an SEO migration

Suppose the old archive is:

/author/adminjohn/

and the new archive becomes:

/author/john-smith/

If the old URL was indexed or linked externally, it may need appropriate redirect handling.

Do not treat URL hardening and URL migration as unrelated

Security changes can affect publicly visible URLs.

Review:

• redirects;
• canonical URLs;
• internal links;
• XML sitemap output;
• search-engine indexing.

Author IDs can also reveal account structure

WordPress author requests historically support user IDs as part of author query handling.

For example, requests involving:

?author=1

can interact with author archive resolution depending on the site’s routing and configuration.

The resulting canonical author URL can reveal the nicename

A visitor or automated client may request an author by ID and observe where WordPress resolves or redirects the request.

This can turn:

user ID
↓
author archive
↓
public nicename

into an enumeration path.

Do not rely on blocking only one enumeration technique

Even if you prevent:

?author=1

other public interfaces can expose author-related information.

The REST API is another user-enumeration surface

WordPress includes user endpoints under:

/wp-json/wp/v2/users

The official WordPress REST API Users endpoint documentation shows that public response contexts can include fields such as:

• user ID;
• display name;
• author URL;
• slug;
• avatar URLs.

The public REST slug is not the same field as username

The REST API documentation distinguishes:

username
→ login name
→ edit context

slug
→ public alphanumeric identifier
→ embed/view/edit context

This distinction is important.

WordPress Core does not simply expose the user’s login username as the public username REST field to arbitrary anonymous requests.

But the slug may still derive from the username

If:

user_nicename
derived from
user_login

then publicly exposing the slug still provides useful information to an attacker.

For the REST-specific behavior, see WordPress REST API User Enumeration, Explained.

Author URLs and REST output can reinforce each other

An attacker may discover:

REST user ID:
4

REST slug:
john-admin

REST link:
/author/john-admin/

That gives several signals describing the same user.

Do not disable the whole REST API solely to hide author slugs

The REST API is fundamental to modern WordPress functionality.

It is used by:

• the Block Editor;
• plugins;
• applications;
• custom integrations;
• frontend interfaces.

A targeted response is better than disabling an entire API without understanding the consequences.

Author archives and REST enumeration are separate controls

You can conceptually have:

author archive hidden
+
REST slug still visible

or:

REST user route restricted
+
author archive still public

Audit all relevant exposure surfaces

For the wider process, see How Attackers Collect WordPress Usernames and Email Addresses.

Should you disable author archives?

That depends on whether they provide genuine value.

Single-author business websites often do not need them

Consider a company blog where every article is published under:

Company Editorial Team

The author archive may simply reproduce:

• all blog posts;
• the same corporate identity;
• information already available elsewhere.

In that case, the archive may provide little editorial or SEO value.

Multi-author publications may benefit from author archives

A publication with journalists, experts or regular contributors may benefit from author pages containing:

• biographies;
• credentials;
• specialisms;
• social links;
• all articles from that author.

Removing such pages solely to obscure a username can damage useful site architecture.

Decide based on content architecture first

Ask:

Does this author archive
help visitors understand
who created the content?

If yes, keep the archive and manage its public identity appropriately.

If no, disabling it may be cleaner.

TheOneWP Disable Author Archive

TheOneWP Disable Author Archive can remove the public author archive workflow when the site does not need author pages.

This is appropriate when:

• the site is effectively single-author;
• authors should not have public archives;
• the archive adds no navigational value;
• the site uses a corporate editorial identity.

Disabling author archives and hiding author slugs are different

This distinction matters.

Disable Author Archive

public author archive
→ removed

Hide Author Slug

author functionality
→ retained

public identifier
→ changed / obscured

TheOneWP Hide Author Slug

TheOneWP Hide Author Slug replaces the username-derived public author slug with a separate randomized token while leaving the underlying WordPress login name unchanged.

That means the objective is not:

rename the login account

but:

stop exposing the login-derived
public author identifier directly

This can preserve useful author archives

A site can continue to have:

/author/random-public-token/

without exposing a slug that mirrors the underlying login identifier.

Hiding the slug is hardening, not authentication

Do not turn this into:

author slug hidden
=
account secured

The account still needs:

• a strong unique password;
• two-factor authentication where appropriate;
• login rate limiting;
• monitoring;
• least privilege.

See A WordPress Login Hardening Checklist.

Two-factor authentication is a much stronger control

Imagine an attacker successfully discovers:

user_login:
john-admin

If the account also requires:

strong password
+
TOTP second factor

the username alone provides very limited value.

TheOneWP Two-Factor Authentication

TheOneWP Two-Factor Authentication adds a second factor to supported WordPress authentication flows.

This protects a deeper layer than simply reducing public username exposure.

Limit repeated login attempts

Username discovery becomes more useful when an attacker can attempt an unlimited number of passwords.

Rate limiting changes:

known username
+
millions of password guesses

into a much less practical attack.

See How to Limit Login Attempts in WordPress.

Monitor targeted usernames

If logs repeatedly show attempts against:

john
admin
administrator
companyname

you can identify which account names attackers appear to know or guess.

See How to Monitor WordPress Login Attempts.

Do not create fake security by renaming only the visible author

Changing:

display_name

is useful for presentation.

It does not necessarily change:

user_login
user_nicename
REST slug
author archive URL

Do not assume the nickname field changes the login

WordPress has several account-related naming fields:

Username
Nickname
Display Name
Nicename

They have different purposes.

The official get_the_author_meta() documentation demonstrates that WordPress exposes separate author properties including:

• user_login;
• user_nicename;
• nickname;
• display_name.

Changing one does not automatically redefine the others

A site administrator should therefore understand exactly which property is being changed before assuming an exposure issue is fixed.

How to check whether your author archive exposes a login-derived slug

Start with a logged-out browser session.

1. Open a published article.
2. Find the author byline.
3. Inspect the author link.
4. Open the author archive.
5. Record the public slug.
6. Compare it with the account’s known internal identity if you administer the site.

Example

Suppose the public URL is:

https://example.com/author/jessica/

and the WordPress account username is:

jessica

Then the author archive directly exposes the login identifier.

A sanitized variation still provides information

Suppose:

user_login:
Jessica.Admin

and:

user_nicename:
jessica-admin

The values are technically different, but their relationship is obvious.

Audit the REST API too

Where publicly available, inspect:

/wp-json/wp/v2/users

and representative user responses.

Look for:

• id;
• name;
• slug;
• link.

Do not confuse the public slug with the REST username field

The official REST API schema specifically limits:

username

to:

edit context

while:

slug

is available in broader response contexts.

That technical difference should be preserved when auditing exposure.

Audit user IDs too

User IDs are not secrets either, but predictable IDs can help attackers map public accounts.

For example:

ID 1
→ original site administrator

ID 2
→ editor

ID 3
→ author

Do not build security around keeping IDs hidden.

Author archive exposure can help phishing too

Public author information may reveal:

• real names;
• job roles;
• writing topics;
• social profiles;
• organizational relationships.

This information can help attackers create more convincing targeted messages.

Public identity and private authentication identity should be designed separately

A useful model is:

Public identity
→ John Smith

Public URL identity
→ john-smith or random token

Authentication identity
→ independent account identifier

Password
→ unique secret

2FA
→ independent second factor

Do not publish unnecessary privileged-account metadata

A WordPress Administrator does not automatically need a public author archive.

If administrators never publish content, consider why their public user information should be exposed at all.

Use publishing accounts according to actual responsibilities

For example:

site owner
→ Administrator

editorial account
→ Editor / Author as appropriate

This also reduces the number of highly privileged accounts associated with public-facing content.

Least privilege still matters

If an account publishes articles but does not need to install plugins or manage users, Administrator may be unnecessarily powerful.

For permission architecture, see WordPress User Roles and Capabilities Explained.

Do not delete useful author pages solely for security theater

Author pages can contribute genuine value to:

• editorial transparency;
• author expertise;
• content discovery;
• trust;
• site navigation.

If author archives are valuable, preserve them and separate their public slugs from authentication identifiers.

When disabling author archives makes sense

Disabling them is more reasonable when:

• the site has only one effective author;
• all posts use a company identity;
• the archive duplicates the blog index;
• authors should not have public profile pages;
• the archive has no navigation or editorial purpose.

When hiding the slug makes more sense

Use slug hardening when:

• author pages are valuable;
• you want to preserve author navigation;
• the current nicename reveals the login identifier;
• you want public and authentication identities separated.

When neither is enough

If the account still uses:

password:
john123

then changing the author slug is barely relevant.

The most important controls remain:

unique password
+
2FA
+
rate limiting
+
monitoring
+
least privilege

WordPress author archive audit checklist

• Identify every user with published content.
• Open each author archive while logged out.
• Record each public author slug.
• Check whether the slug matches the login username.
• Check whether the slug is an obvious transformation of the username.
• Review each user’s display name.
• Do not assume display name changes the author slug.
• Inspect author links in post bylines.
• Check classic theme author templates.
• Check block theme author templates.
• Review whether author archives provide real visitor value.
• Review single-author sites carefully.
• Review corporate editorial accounts.
• Inspect REST API user responses where publicly available.
• Distinguish REST slug from REST username.
• Review public user IDs.
• Review ?author=ID-style enumeration behavior.
• Review author canonical redirects.
• Check whether custom plugins expose additional author information.
• Check whether themes expose author usernames in HTML or structured data.
• Review author schema output.
• Review public biographies for unnecessary sensitive information.
• Keep privileged accounts separate from publishing accounts where appropriate.
• Apply least privilege.
• Use strong unique passwords.
• Enable 2FA for privileged users.
• Limit repeated login attempts.
• Monitor failed authentication attempts.
• Use Hide Author Slug where author archives are useful but identifiers should be separated.
• Use Disable Author Archive where author pages provide no meaningful value.
• Re-test after changing author URLs.
• Add redirects where old author URLs have legitimately moved.
• Re-check REST output after slug changes.
• Do not rely on username secrecy as the primary security boundary.

TheOneWP controls for author identifier exposure

Hide Author Slug

Hide Author Slug separates the publicly exposed author slug from the original username-derived value.

Disable Author Archive

Disable Author Archive removes the archive workflow where author pages are unnecessary.

Two-Factor Authentication

Two-Factor Authentication protects a deeper layer by requiring an additional authentication factor even if an attacker learns a valid identifier and password.

Restrict Login Identifier

Restrict Login Identifier can control which identifier types are accepted in supported login workflows.

Use these controls for different purposes

Hide Author Slug
→ reduce public identifier exposure

Disable Author Archive
→ remove unnecessary author archive

Restrict Login Identifier
→ control accepted login identifiers

Two-Factor Authentication
→ strengthen actual authentication

Related guides

• How Attackers Collect WordPress Usernames and Email Addresses
• WordPress REST API User Enumeration, Explained
• A WordPress Login Hardening Checklist
• WordPress Brute-Force Attacks, Explained
• How to Limit Login Attempts in WordPress
• WordPress Login: Username vs. Email, Which Is More Secure?

Final recommendation

WordPress author archives can expose username-related information because their public URLs are based on:

user_nicename

rather than the human-readable:

display_name

WordPress treats user_login and user_nicename as separate fields, but the default user-creation process can derive the nicename from the login username.

That produces the common pattern:

user_login
→ john.admin

user_nicename
→ john-admin

author URL
→ /author/john-admin/

An attacker can use that public information for reconnaissance and username enumeration.

But the correct response is not to pretend usernames can remain secret forever.

The stronger model is:

reduce unnecessary identifier exposure
+
use unique strong passwords
+
enable 2FA
+
limit repeated attempts
+
monitor authentication
+
apply least privilege

If author archives provide useful editorial value, keep them and separate the public author identifier from the authentication identity.

If they provide no useful purpose, disabling them entirely may be cleaner.

Most importantly, treat author-slug hiding as hardening rather than authentication.

A discovered username should never be enough to compromise a properly protected WordPress account.