If you install a “Last Login” plugin and suddenly your WordPress Users screen looks organized, that neatness is lying to you. The dates appear authoritative. You can sort them. They look like hard facts. They are not. WordPress has never stored a native last-login date, and every value in that column is an artifact of selective memory.
The History That Never Was
WordPress keeps accounts in a straightforward users table. It stores names, emails, password hashes, and registration dates. Conspicuously missing is any field that records when someone last authenticated. This has always been the case.
When you install a plugin to fill the gap, it hooks into the login process and writes a timestamp to user metadata. That is the entire mechanism. It does not reach backward into your server logs or reconstruct prior sessions. It simply begins watching from the moment you activate it.
Imagine a site that has operated for five years. Hundreds of editors, subscribers, and contractors have logged in during that stretch. You install a tracking plugin on a Tuesday afternoon. On Wednesday morning, a senior editor logs in. The plugin records the time and date. But your own admin account shows nothing, because you have not logged in since the install. An old freelancer account from 2021 also shows nothing. The column makes it appear that neither of you has ever touched the site. In reality, the recording simply had no past. It treats absence of data as evidence of absence, which is a dangerous assumption when you are managing access.
Three Ways the Column Misleads You
Once the plugin is running, the illusion shifts from missing history to corrupted present-tense reporting. There are three specific traps.
It tracks authentication, not activity
When a user checks “Remember Me” on the WordPress login screen, the browser receives an authentication cookie that can remain valid for up to fourteen days. During that window, the user can open the dashboard, publish posts, moderate comments, and update settings without ever retyping a password. Their session is alive and active.
Most last-login plugins, however, listen for the wp_login action. That action fires only when credentials are submitted through the form, not when an existing session refreshes. So your editor could log in on a Monday morning, keep the browser session alive, and work inside the admin area every day for two weeks straight. The column would still read fourteen days old. A security review based on that timestamp would flag the account as dormant. It is not dormant at all. You are looking at when a password was typed, not when a human being was last inside your house.
It hides dormant accounts during audits
Most plugins implement the sortable column by joining the users table to the usermeta table. Structurally, this makes sense. Practically, it creates a visibility bug.
If a user has never authenticated since you activated the plugin, there is simply no row in usermeta for that key. When you sort the user list by “Last Login” to find your stalest accounts, the underlying query often excludes users who lack the metadata. They drop out of the sorted view entirely.
You run a cleanup audit. You sort descending and see forty users with increasingly old dates. You confidently identify a group to disable. But you never saw the ten contractor accounts that have been silent for eight months because they never once triggered the tracker. Those accounts do not appear in the sorted list, so they do not appear in your conclusions. Your audit literally deletes its own findings. On membership sites, e-learning platforms, or multisite networks, this is especially troubling because dormant accounts are often the ones attackers target first.
The data exists only when it is useless
There is a quiet irony here. WordPress core does know something about user sessions. When someone logs in, the system generates session tokens and stores them in the user metadata. An administrator can view active sessions and terminate them. But that knowledge is strictly live. The moment the user clicks logout, or the session expires on its own, WordPress deletes the token. The record evaporates.
You can see who is online right now. You cannot easily see who was online yesterday at ten in the morning. The architecture was built for real-time session management, not for historical