A subscriber account registered three years ago, password never changed, mailbox no longer in use - that account is inactive but still exists. From a security angle it is an attack vector: its password may appear in another site's credential leak and through credential stuffing an attacker can log in to your site as a "legitimate" user.
Why this matters
Bots that scan WordPress sites en masse run automated logins against leaked password lists (rockyou.txt, COMB and others). If a subscriber on your system used password123 six years ago and that password is on the list, the bot logs in. A subscriber alone cannot do much, but: (1) certain privilege-escalation bugs let an authenticated subscriber elevate themselves through an insecure AJAX endpoint (known vulnerabilities and similar); (2) an authenticated session unlocks partial wp-admin, an authenticated REST API and ?author= enumeration; (3) suspicious behaviour from a subscriber account misleads incident response - it looks like "the user themselves" rather than an attack. Cleaning up dormant accounts shrinks the attack surface and reduces log noise.
How to detect
WordPress does not natively store last_login - you need a plugin. Options:
- Install WP Last Login or Simple History which begin recording from the day they are activated.
- Inspect
user_registeredinwp_usersand anyuser_activitymeta you have. - Via WP-CLI:
wp user list --role=subscriber --field=ID,user_login,user_registered --orderby=user_registered
RankPlus identifies users with a registration date older than 365 days, no comments, no posts and no related post_meta.
How to fix
- Install the free Inactive User Deleter or WP Inactive User Cleanup.
- Set safe criteria: 365 days without login, subscriber role only, no posts, comments or WooCommerce orders.
- Run dry-run / preview first - you get a list of accounts about to be deleted. Review it manually.
- When deleting through Bulk actions > Delete, the Attribute all content to option appears. Pick your main admin user - this matters because comments, posts and ACF fields tied to user_id break if the user simply vanishes.
- WP-CLI alternative:
This removes user 123 and reassigns their content to user 1.wp user delete 123 --reassign=1 - After cleanup close the door: Settings > General > Membership - uncheck "Anyone can register" if open registration is not required.
Common mistakes
- Bulk-deleting without review: a real customer who has not visited in a year gets deleted - and would have come back with money.
- Deleting an editor or author: they own posts. Without reassignment those posts break.
- Ignoring WooCommerce: an old customer with prior orders is not "dormant" - they have purchase history. Filter by orders.
- Skipping compliance checks: certain regulated sites must retain user records for a minimum period. In that case disable the account (Disable Users plugin) instead of deleting.
Verifying the fix
Run wp user list --role=subscriber --format=count and compare to the pre-cleanup count. RankPlus returns to green. Verify the site still works: log in as an existing subscriber, open a page, confirm a recent comment is still attributed correctly.