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.

Define “logged in”

Choose the result you need before choosing a method:

• Current visitor: Is the browser making this request signed in? Use is_user_logged_in().
• Current account: What is the name or ID of the account making this request? Use wp_get_current_user() or get_current_user_id().
• Existing session: Does an account still have an unexpired sign-in session on a device? Use a maintained session-management or security tool.
• Past login: Was a successful login recorded? Use a log that was already collecting login events.
• Site change: Which account edited content, changed a user, installed a plugin, or changed a setting? Use an activity log.
• Online now: Is a person actively using the site at this exact moment? A session, last-seen value, or login record cannot prove that by itself.

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.

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

• Connect the security plugin before you need the history: Add MalCare to the site, connect it to the dashboard, and confirm that activity collection and the relevant login-protection features are enabled. A new log starts collecting from setup; it does not fill in earlier events.
• Start with the time window that matters: Open the activity or security log and filter around the suspected login, edit, or account change. Use date, user, or event filters when available.
• Compare the whole event: Check the account name, role, action, timestamp, and available location or IP details. One unfamiliar location is a reason to investigate, not proof of compromise; mobile networks, VPNs, and shared offices can make location data look unfamiliar.
• Trace nearby changes: Look for a new administrator, role change, plugin installation, settings change, file change, or edited post around the same time. Preserve the relevant records before deleting an account, revoking sessions, or clearing the log.
• Check current plan coverage: Product screens, retention periods, and plan options can change. Review the current MalCare pricing and plan information before promising a particular history length or feature.

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.';
}

Avoid common code mistakes

• Do not make the parent theme’s functions.php your default home for the snippet: A syntax error can break the site, and a theme update can remove the change. Use a small site-specific plugin, child theme, or trusted snippets tool instead.
• Back up before editing live code: Keep a backup plugin in place and verify that a restore works. A completed backup job is not useful if the backup cannot be recovered.
• Run the check after WordPress knows the user: init suits many general checks. A front-end redirect commonly belongs on template_redirect, and redirect code should stop after sending the redirect.
• Check caching when the result looks wrong: A full-page cache may serve HTML saved for an anonymous visitor. Exclude private or personalized output from that cache. A REST request also needs the correct signed-in context and nonce.
• Do not use the logged-in body class as security: It can help with presentation or client-side UI, but it is visible in the browser and cannot protect private content or a sensitive action.

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:

• Preserve evidence: Save timestamps, account names, changed items, and available location or device details before deleting users, revoking sessions, or clearing the activity log.
• Confirm the context: Ask the account owner whether the access was expected, then compare successful, failed, and blocked attempts around the same time. Look for new users, role changes, plugin installs, file changes, or edited content.
• Reduce access: Revoke unexpected sessions when the available tool supports it. Reset the affected password to a unique value and check other accounts that reused it.
• Strengthen the login: Enable two-factor authentication, consider changing the WordPress login URL, protect your WordPress login page, and remove permissions the account does not need.
• Check the site: Review plugins, themes, users, settings, files, and content. Scan when the event suggests unauthorized access, and investigate unknown administrator accounts or files.
• Recover carefully: If the site remains unsafe or damaged, follow a documented recovery plan and restore from a known-good backup that you have verified.

Keep login monitoring useful

Make the review routine small enough to maintain:

• Require unique passwords and two-factor authentication for appropriate accounts.
• Limit repeated login attempts with login-protection controls.
• Give each account only the access required for its work, then revisit permissions when responsibilities change.
• Review administrator accounts and recent activity after important site changes; remove unused accounts.
• Restrict access to login data, document retention, and disclose monitoring where privacy or employment rules require it.

FAQs

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.

Written by

Shivani M

Shivani enjoys crafting guides that make every aspect of using WordPress simple and easy to follow. When she's not glued to her laptop, you can find her buried in a good book or occasionally, painting.