To delete a WordPress user without deleting their posts, use the content-reassignment choice on the deletion confirmation screen. Do not select the option that deletes their content. But first decide whether deleting the account is necessary: removing a former employee’s access and changing the author of their published work are different decisions.
This guide covers an authorized staff or agency departure on a self-hosted WordPress site. If nobody can explain an administrator account, follow our unknown WordPress administrator guide instead. Preserve incident evidence before treating an unexplained account as routine housekeeping.
Decide what must stay before removing the user
Write down the outcome the business actually needs. Usually that means the former provider cannot administer the site, published pages remain available, the correct people receive enquiries, and the business controls the accounts that keep everything running. A missing username in the Users screen proves only one part of that outcome.
Check content and attribution separately. The account may be the author of posts, pages or uploaded media. Your theme or SEO plugin may use that relationship for a visible byline, author archive or Article schema. Reassigning content to the business owner can therefore change public credit, even when the article text stays exactly the same. Agree the credit before proceeding; do not present the replacement account as the original writer by accident.
If the writer’s attribution must remain, ask your maintainer to preserve that identity while removing editing privileges and securing authentication. A low-permission or no-role account is not automatically a blocked login. WordPress roles control capabilities, and custom plugins can add their own permissions. Review the official role definitions against the features on your site.
| Your actual goal | Safer direction | Check before continuing |
|---|---|---|
| Remove administration access but retain the writer’s credit | Keep the author identity and remove unnecessary privileges; secure its login routes separately | Byline, author archive, schema and custom permissions |
| Remove the account and transfer its standard content | Use WordPress’s reassignment choice with an agreed receiving user | Content inventory, recipient and attribution approval |
| Remove a customer, member, student or integration account | Review the owning plugin’s account and data workflow first | Orders, subscriptions, access rights and service connections |
| Remove access from one site in a multisite network | Ask the network owner to confirm site versus network scope | Other sites, network privileges and the intended content owner |
Prepare a recoverable handover
Confirm that a different, business-controlled administrator can sign in and recover its account. Do this before removing the person who originally built the site. Also verify access to hosting and the mailbox used for recovery. An administrator account is not a substitute for control of the domain or server.
Take a current database and file backup, then confirm how it would be restored. Save a private content inventory with the departing user’s ID, relevant URLs, content types, author assignments and important drafts. Keep secrets out of this record. For a store, agree how new orders would be protected if a recovery became necessary; a full database restore can overwrite newer business data.
Review custom post types and plugin-owned records before treating the standard content count as complete. WordPress exposes deletion hooks that plugins can use, and its user-deletion function distinguishes reassignment from deletion. That does not make the confirmation screen a complete inventory of every plugin’s customer, booking or membership data.
Use the native deletion and reassignment screen
Once deletion and attribution have been approved, use a different authorized administrator account on a normal single-site installation:
- Open Users > All Users and identify the exact departing account. Check the login and role rather than relying on a similar display name.
- Choose Delete for that user. This opens a confirmation step; it is not permission to delete every account left by an agency.
- Where WordPress detects owned content, select the option to attribute it to another user. Choose the agreed recipient and check the account shown in the dropdown.
- Read the complete confirmation screen before using Confirm Deletion. Stop if the expected reassignment choice is missing, the recipient is wrong, or the listed content does not match your inventory.
- Afterward, verify the affected URLs, editing access, author information and integrations. Keep the backup until those checks are accepted.
Labels vary with WordPress version and language. The current English screen can say Attribute all content to another user; older documentation may refer to posts and links. WordPress’s Users screen documentation explains the two outcomes. Never choose a destructive option just because the wording differs from a tutorial.
A worked example: an agency account owns the service pages
Imagine an agency is leaving a small business site. Its named account owns eight service pages, three unpublished drafts and some uploaded images. The site owner already has a separate administrator login. This is a hypothetical planning example, not a Webless client result.
The owner first records the eight page URLs and draft titles. They discover that two blog posts also use the agency account as a public byline. Instead of blindly transferring everything to the owner, they agree whether those posts should retain the original writer’s credit. If preserving that credit is important, the handover pauses deletion until an appropriate account and attribution plan exists.
Next, they find that a publishing integration uses a credential associated with the agency user. They arrange a business-controlled replacement and an authorized test before revoking the old connection. Deleting the user first could leave the pages online while quietly breaking the next scheduled publication.
Where reassignment is appropriate, the owner checks the eight service pages after removal, opens the three drafts in the editor, verifies representative images, and reviews the two article bylines and schema. The handover succeeds only when the agreed content and workflows remain available, not when the account count drops by one.
Close browser and integration access separately
If an account is retained, inspect its Sessions controls in Users > All Users > Edit. WordPress can show Log Out Everywhere when editing another user with active sessions. On your own profile, the control is Log Out Everywhere Else. Do not accidentally end the wrong person’s sessions or assume a missing button proves every external connection is closed.
Also review Application Passwords on the relevant profile. These are separate credentials for API clients, not ordinary wp-admin logins. Record the integration owner and revoke obsolete entries without copying their secret values. A retained account may still need an approved publishing or maintenance connection, so plan and test its replacement. The official application-password guidance describes individual revocation and usage information.
Plugin-specific keys, hosting single sign-on, SSH access, shared mailboxes and external service invitations need their own review. WordPress user deletion does not remove a person from the registrar, CDN, backup provider or analytics account. Our maintenance onboarding checklist helps map those separate owners without putting passwords in a handover document.
Multisite and customer accounts need a different decision
On multisite, removing someone from one site is not the same as deleting their network identity. They may have legitimate access elsewhere, and network-level privileges require a network administrator’s review. The site-removal API documents that separate operation and its optional reassignment. Do not apply a network-wide deletion to solve a one-site departure.
Likewise, do not use this staff-account procedure as a shortcut for deleting customers or complying with a personal-data request. Orders, invoices, subscriptions and memberships can follow different plugin rules and retention requirements. Identify the data owner and approved process first. If you cannot explain what an account powers, stop before deleting it.
Verify the result without restoring obsolete access
Compare your before inventory with the public site and dashboard. Open representative posts and pages while logged out. Check the byline, author archive and image files, then inspect a draft with the receiving editor. Have the authorized integration owner verify the next expected task or run a permitted test. Do not submit a real customer enquiry or chargeable order merely to finish an account review.
If content disappears or a business workflow fails, preserve the new evidence and pause further changes. Ask the maintainer to recover the affected records from the backup without overwriting newer orders or leads. Restoring an old database may also restore the former user’s access, so access controls must be rechecked as part of recovery.
Webless can help review an incomplete provider handover through WordPress maintenance. If custom permissions or integrations need repair, the work may require a separately agreed development task. Start with the missing ownership or broken workflow, not passwords in the first message.