WordPress Who Is Logged In? How to Check Users and Activity

Managing a WordPress site with several contributors can feel like a juggling act. If you’re searching for “WordPress who is logged in,” you may want to know whether the current visitor is signed in, which accounts have active sessions, who logged in earlier, or who made an unexpected change. Each question requires a different approach.

This guide shows you exactly where to look. For a site-wide record of logins and changes, use an activity or security log. If you’re investigating suspicious activity, a WordPress security audit can help organize your review. For code that checks the current visitor, use WordPress’s is_user_logged_in() function.

Let’s start by identifying which type of login information you need and the best way to find it.

TL;DR: To check the current WordPress visitor, use is_user_logged_in(); to review recorded logins and site changes, use an activity log such as MalCare. Keep a backup plugin in place before adding code or changing security settings, and remember that a login record or open session does not prove someone is online right now.

Define “logged in”

Choose the result you need before choosing a method:

WordPress authentication uses cookies and session tokens. One person can have separate sessions on a laptop and phone, and closing a tab does not necessarily end either session. An unexpired session means access may still be valid; it does not mean the person is looking at the site now.

🧭 Note: Treat “logged in,” “has an active session,” and “online now” as separate labels in your reports. Combining them can make an ordinary idle session look like an active security incident.

1) Use an activity log

Use an activity log when you manage multiple administrators, editors, contributors, members, or customers and need accountability. It is also the right starting point when you are tracing an unexpected edit or login. The WordPress activity tracking guide explains the kinds of events an activity log can record. The log can show recorded events, but it cannot recreate activity from before logging was enabled.

MalCare’s activity log describes tracking user logins, login time and location information, user changes, and other site activity. Its login protection covers controls around the login surface and records blocked, failed, and successful login attempts. This makes it useful for reviewing an audit trail, not for displaying a guaranteed live roster of people browsing the site.

Set up the log and investigate a record

🔐 Note: Activity logs can contain IP addresses, device details, and user behavior. Limit access to people who need it, set a sensible retention period, and never put passwords, cookies, nonces, or session tokens into a custom log.

If your goal is to end access on one device, look for session-management controls rather than relying on the activity log. If your goal is to understand what happened, use the recorded events. They solve related problems, but they are not interchangeable.

2) Check the current visitor with PHP

Use code when a theme, plugin, or site-specific feature needs to show different content to the person making the current request. It is not a substitute for a site-wide activity log or a session dashboard.

The official WordPress reference for is_user_logged_in() defines it as a check for whether the current visitor is logged in. It returns a boolean:

if ( is_user_logged_in() ) {
    echo 'You are logged in.';
} else {
    echo 'Please log in to view this content.';
}

This checks one request. It does not enumerate other users, show previous logins, list active sessions, or identify who edited a post. For an anonymous request, the same check produces the opposite branch:

Show the current user safely

When the feature needs the account’s details, use wp_get_current_user() or use get_current_user_id() when the ID is enough. Check that the user exists before displaying account data:

$current_user = wp_get_current_user();

if ( $current_user->exists() ) {
    echo 'Welcome, ' . esc_html( $current_user->display_name ) . '.';
}

Being logged in does not grant every permission. If the feature performs an action, check the required capability with current_user_can() instead of trusting a role name or login status:

if ( current_user_can( 'edit_posts' ) ) {
    echo 'This user can edit posts.';
}

🛡️ Note: Authentication answers “which account is making this request?” Authorization answers “may that account perform this action?” Keep both checks in place when a feature changes data.

Avoid common code mistakes

For a narrow custom login report, a developer can attach a controlled recorder to WordPress’s wp_login action. It runs after a successful login and can record the account involved. It does not automatically track later edits, failed attempts, active browsing, or session expiry, so an activity log is usually safer for broader monitoring.

What about active sessions and old logins?

WordPress core does not give ordinary administrators a simple, complete view of active sessions or historical logins. Raw session-token records are not a clean live-user count: expired tokens need interpretation, and one person may have several sessions. Avoid hand-parsing serialized user metadata or running broad production queries unless you understand the performance and privacy risks.

If logging was not enabled when an event occurred, server logs or backups may provide partial evidence. A WordPress backup and restore guide from WP Remote can help you plan and verify the recovery side. WordPress cannot reliably reconstruct a complete history after the fact. That is why logging and backup routines belong in place before a problem appears, not during the first investigation.

Respond to a suspicious login or change

An unfamiliar record deserves investigation, but it is not proof of a compromise by itself. Work in this order:

🚨 Note: Do not erase the evidence while trying to clean up. Preserving the timeline first helps you distinguish a mistaken alert from a compromised account and shows what else needs review.

Keep login monitoring useful

Make the review routine small enough to maintain:

FAQs

Does is_user_logged_in() show the username?

No. It only reports whether the current visitor is logged in. Use wp_get_current_user() for the current account or get_current_user_id() when the feature only needs the ID.

How do I see who is logged in across the site?

Use a maintained session or activity tool. WordPress core does not provide a simple, complete dashboard, and an unexpired session does not prove that a person is using the site now.

How do I see who logged in before?

Open an activity log that was already collecting successful login events. If it was not enabled at the time, server logs or backups may offer only partial evidence.

Why does WordPress show a logged-out result for a logged-in user?

Check whether the code ran too early, a full-page cache served an anonymous page, or the request lacked the right signed-in context. Never use a browser-visible body class as a permission check.

Conclusion

The best answer to “who is logged in WordPress?” depends on the result you need. Use is_user_logged_in() for the current request. Use an activity log for recorded logins and changes. Use a session-management tool when you need to end access on a device, and never confuse an idle session with proof that someone is online.

MalCare can connect recorded activity monitoring with login protection. Pair it with two-factor authentication, least-privilege access, regular account reviews, and a restorable backup so you can investigate changes without making the situation worse.