Open the user list and identify administrators, custom roles with equivalent capabilities and, on Multisite, Super Admins. Record the account owner, purpose, recovery email and whether access is temporary.

Compare the list with your team, agency and integration records. Some service workflows create authorised management accounts, so confirm their purpose before removing them and breaking a legitimate process.

1. Confirm the owner and whether the account still needs administrative capabilities.
2. Check the email address and recovery route for accuracy.
3. Review available session and application-password information, and remove access that is no longer required.
4. Require unique strong passwords and suitable two-factor authentication through the site's supported setup.
5. Reduce unnecessary roles or remove obsolete users while preserving their content deliberately.

Use the correct installation and site URL to list ordinary administrators without printing password-related data. Review the resulting usernames privately and match each one to a current team member, agency, integration or documented management function.

wp --path='/home/ACCOUNT/sites/example.com' --url='https://example.com' \
  user list --role=administrator \
  --fields=ID,user_login,roles --format=table

An unfamiliar username is a reason to investigate its owner and activity. It is not sufficient evidence to delete it immediately. On Multisite, also review the network’s Super Admin list, because a site-specific role report is not the complete privileged-access inventory. Include custom roles with equivalent capabilities where plugins define them.

Expected result: Every privileged account has a documented purpose and recovery owner. Any removal or role reduction preserves required content and legitimate management access, then receives a separate functional check.

If an account is unknown, record its details and relevant timestamps or activity evidence before making changes. Check recent plugin installations, file modifications and other signs of compromise. Removing one account does not establish that the original entry point is closed.

Use a verified clean administrator account and protect the associated email and hosting credentials. If the site may be compromised, ask us to review the incident and avoid repeatedly restoring an unverified backup.

After reducing access, confirm that authorised editors, developers and integrations can still perform their intended tasks. Keep more than one carefully controlled recovery route where appropriate, without creating unnecessary permanent administrator accounts.

Document the final list and set a review point when staff or suppliers change. A role label alone may not capture permissions added by plugins, so include custom capabilities in deeper audits.

When requesting help, share the affected username or ID and observed behaviour through the approved support channel. Never include passwords, two-factor recovery codes or full authentication cookies in an access-review report.

• Changing a user's role without losing content ownership
• Removing a WordPress user and reassigning their content
• Creating and revoking WordPress application passwords
• Inviting contributors without sharing administrator credentials

• WordPress: Users Screen
• WordPress: Roles And Capabilities
• Hardening WordPress

• WP-CLI user inventory
• WP-CLI Super Admin inventory