How to track user activity in WordPress

Start with security-relevant events rather than trying to record every page view. Common choices include successful and failed logins, logouts, new users, role changes, profile updates, password changes, post edits, publishing, deletions, plugin changes, theme changes, and important settings updates.

Keep privacy and storage in mind. Activity logs can contain usernames, IP addresses, browser details, and other sensitive information, so restrict access and define how long records should be kept.

WordPress provides hooks that tell custom code when some actions occur, but it does not give you a complete audit-log screen or a permanent searchable history out of the box. For example, wp_login records successful logins, wp_login_failed records failed attempts, wp_logout records logouts, and profile_update runs after an existing user is updated.

Content changes can be observed with hooks such as save_post, while user creation and option changes need their own handling. A normal WordPress installation will not reconstruct activity that happened before you added logging.

For a small, controlled site, create a custom plugin or must-use plugin that attaches callbacks to the events you selected. Each callback should record the event name, user ID, timestamp, affected object, and enough context to investigate it later. Store records in a dedicated table or another structure designed for querying rather than writing them into individual user profiles.

Check permissions before recording sensitive data, sanitise values, avoid storing passwords or complete form submissions, and prevent the logger from recording its own database writes. Test login failures, edits, deletions, role changes, and actions performed through the REST API or scheduled tasks.

Give log access only to trusted administrators, protect the log from public access, and include the site timezone or use UTC consistently. Add retention and deletion rules so the database does not grow without limit. Back up the log if it is needed for incident investigation, but keep those backups protected as well.

The common Friday failure is discovering that the logger only covered post edits and successful logins, while the important event was a failed login, a role change, a plugin update, or an action taken by a scheduled process. Test the exact events you care about before relying on the records.

For most sites, the fast way is to install WP Activity Log, activate it, and review its event and retention settings. It provides searchable audit logs for user actions, login attempts, profile and content changes, with alerts and scheduled reports for ongoing monitoring.

On multisite, install and activate it at network level so activity across the network can be monitored centrally. Limit who can view or manage the log, then create alerts for events such as administrator logins, role changes, new users, plugin changes, and content published by sensitive roles.

Use the log as part of a routine security check rather than waiting for an incident. Filter by user, role, event type, object, IP address, or date range, and investigate unfamiliar administrator activity, repeated failed logins, unexpected settings changes, and edits made outside normal working hours.

Generate a report for your chosen review period and confirm that alerts are delivered. A log that nobody reviews, or an alert mailbox that is not monitored, will not help when something goes wrong.