The best privacy settings for WordPress sites start with restricting user access, controlling what data WordPress collects, limiting comment visibility, and encrypting sensitive information in transit and at rest. A WordPress site running the default configuration exposes more visitor and user data than most site owners realize—from IP addresses logged in comments to admin panel access available to anyone with a valid username. By implementing WordPress privacy settings correctly, site owners can prevent unauthorized data collection, reduce breach surface area, and comply with privacy regulations like GDPR and CCPA.
WordPress’s privacy tools are scattered across the admin dashboard, database level, and plugin ecosystem, making it easy to miss critical settings. A healthcare site running WordPress, for example, might store patient names in comments without realizing that those comments are indexed by search engines unless explicitly set to private. The privacy settings that matter most—user roles, data retention, comment moderation, and SSL—must be configured intentionally, not left on defaults.
Table of Contents
- What WordPress Privacy Settings Are and Why They Matter
- Controlling User Registration and Account Visibility
- Hiding WordPress Usernames and Blocking User Enumeration
- Comment Privacy and Visitor Data Retention
- Database and Backup Privacy
- SSL/TLS Certificate and Data Encryption
- Two-Factor Authentication and Login Security
- Frequently Asked Questions
What WordPress Privacy Settings Are and Why They Matter
WordPress privacy settings control who can register accounts, what data gets stored, who can see published content, and how long data persists. These settings exist in the General settings tab, Discussion settings, and within individual post and user configurations. Unlike privacy policies, which describe what a site does with data, privacy settings actually enforce those descriptions by limiting data collection, visibility, and access.
A WordPress multisite hosting five client sites might accidentally allow all users across all sites to see each other’s email addresses if user visibility settings are not configured per site. Similarly, a WordPress site with open user registration stores passwords hashed (which is secure), but stores user IP addresses, email addresses, and registration dates in plain text in the wp_users table. If that database is compromised, attackers gain access to usernames and email addresses that can be cross-referenced with breach databases to identify and target site administrators.
Controlling User Registration and Account Visibility
The first privacy risk on most WordPress sites is open user registration combined with user directory visibility. In the General settings tab, “Anyone can register” is often left enabled without realizing that registered users can view each other’s profiles by visiting site.com/author/username. This exposes email addresses, display names, and registered user counts to anyone visiting the site.
The solution is to disable user registration entirely if it is not needed, or to restrict registration to invite-only mode using a plugin like Invite Anyone or Formidable Forms that enforces approval workflows. If registration must remain open, change the “New User Default Role” from Subscriber to a custom role with no public-facing profile visibility. A downside of disabling registration is that legitimate users cannot create accounts without administrator intervention, which increases support burden for sites with frequent new users. For sites requiring open registration, consider configuring user profiles to be non-public by editing each user and setting the “Public Profile” option to “Show only my name,” which prevents email address exposure while still allowing profile links to exist.
Hiding WordPress Usernames and Blocking User Enumeration
WordPress exposes registered usernames through multiple vectors: the author archive pages (site.com/author/admin), the admin-ajax REST API endpoint (site.com/wp-json/wp/v2/users), and WordPress XML-RPC ping-back systems. An attacker can enumerate all usernames on a target WordPress site in seconds, then use those names to attempt password attacks or zero-day exploits. WordPress 4.7 introduced privacy settings to restrict the public REST API User endpoint. Navigate to Settings > Permalinks, scroll to “REST API” settings, and disable “Show REST API in the admin bar” if you are using an older WordPress version.
For complete protection, a plugin like iThemes Security or Wordfence can block REST API user enumeration entirely by adding ?rest_route=/wp/v2/users to the block list. Real-world example: a small business WordPress site was compromised when an attacker enumerated the “admin” username using the REST API, then used a publicly disclosed plugin vulnerability to escalate privileges. After disabling REST API user exposure and updating the vulnerable plugin, subsequent attacks targeting that same endpoint failed to enumerate users. The limitation is that legitimate applications and mobile apps using the REST API to fetch user data will break if you disable user endpoints, so this trade-off must be balanced against whether the site actually needs public user data.
Comment Privacy and Visitor Data Retention
Every comment on a WordPress site stores the commenter’s IP address, email address, name, website URL, and comment timestamp in the wp_comments table. This data persists indefinitely unless explicitly deleted, and it is visible to administrators in the wp-admin panel. By default, unapproved comments are also stored in the database, so spam comments containing malicious payloads or email address harvesting remain in the database even after deletion. Set up automatic comment moderation and spam filtering by enabling Akismet or a similar service (with privacy review of the Akismet privacy policy, as comments are sent to Akismet’s servers for analysis).
Then, configure comment retention: navigate to Settings > Discussion and enable “Comment moderation” with a 30-day or shorter retention period. Set the threshold for automatic spam deletion to move comments older than 30 days to trash, then delete trash weekly using a plugin like WP Control or a custom cron job. The trade-off is that legitimate commenters’ email addresses will not be retained for future responses if they comment only once, reducing personalization. For GDPR-compliant sites, install a plugin like GDPR Cookie Consent that automatically deletes comment data after 60 days (or a period you specify) to comply with data minimization principles.
Database and Backup Privacy
WordPress databases contain all user data, post content, comments, and metadata. If the database is backed up but backups are stored unencrypted in publicly accessible cloud buckets, a database breach is as damaging as a website compromise. The second risk is that database backups older than 30 days are sometimes left on live servers in readable directories. Best practice is to configure automated backups using a plugin like UpdraftPlus or VaultPress that encrypts backups with AES-256 before uploading to cloud storage.
Verify that backups are encrypted in transit and at rest by checking the plugin settings: ensure the backup destination is not your own web server, that remote backup storage uses HTTPS or a secure protocol, and that backups are set to delete older versions automatically after 90 days. A limitation of encrypted backups is that restoring a database requires the decryption key, so losing the backup key means losing access to backups. Store backup encryption keys in a password manager with offline copies. Additionally, configure database access to allow only the application server’s IP address to connect to the database, and change the default WordPress database prefix (wp_) to something random (e.g., a72x_) to slightly increase the effort required to exploit SQL injection vulnerabilities.
SSL/TLS Certificate and Data Encryption
All data transmitted between a visitor’s browser and your WordPress server should be encrypted using HTTPS (HTTP over TLS). WordPress privacy depends fundamentally on this encryption: without it, usernames, passwords, and session cookies are transmitted in plain text over the network where they can be intercepted by an attacker on the same WiFi network. Enable HTTPS by purchasing an SSL/TLS certificate (many hosting providers include free Let’s Encrypt certificates) and configure WordPress to enforce HTTPS in Settings > General by changing both the WordPress Address and Site Address to https://.
Then, enable “Force SSL for all pages” in security plugin settings (or add the WP_HOME and WP_SITEURL constants to wp-config.php to force HTTPS). Install a plugin like Better WordPress Security to set the HTTP Strict-Transport-Security (HSTS) header, which prevents browsers from allowing http:// connections to your site. A real-world risk: a WordPress site enabled HTTPS on the admin panel only, leaving the front-end site accessible over http://. An attacker intercepted login cookies when a user browsed the front-end site first (unencrypted), then logged in, allowing the attacker to hijack the session.
Two-Factor Authentication and Login Security
WordPress administrators with weak passwords are the most common vector for site compromise. Enable two-factor authentication (2FA) for all user accounts with admin or editor roles by installing a plugin like Duo Security, Google Authenticator, or Wordfence Two-Factor. Two-factor authentication requires a second verification step (a time-based code from a phone app, a hardware security key, or an SMS) when logging in, making stolen passwords useless without physical access to the admin’s phone.
Configure the 2FA plugin to enforce 2FA for all admins and editors, then set a grace period of 7 days for existing users to set up 2FA before they are locked out. Store the two-factor backup codes in a password manager separate from the login credentials. A limitation is that users must have access to their phone or security key to log in, which increases friction and can lock admins out if they lose their phone; mitigate this by keeping backup authentication methods enabled and backup codes accessible to account owners.
Frequently Asked Questions
Do I need to delete WordPress user registration if I don’t accept user signups?
Yes. Disabling the “Anyone can register” toggle prevents new signups but does not remove existing user accounts or the option for administrators to create new users manually. Disable registration, then periodically audit the wp_users table to remove inactive accounts older than one year using a plugin like User Role Editor.
How can I tell if WordPress is logging visitor IP addresses for all users?
IP addresses are logged in comment author IPs (wp_commentmeta table) and in many plugins’ activity logs. Check Settings > Discussion to see which comments are retained, and check each security plugin’s audit log settings to see whether it is archiving IPs beyond the 30-day retention needed for debugging.
Is the GDPR “right to be forgotten” (deletion request) supported by WordPress?
WordPress has a Tools > Export Personal Data feature that allows users to request their data be downloaded, and Tools > Erase Personal Data to anonymize comments and accounts. This feature does not cascade to backups or third-party logging services (e.g., Google Analytics), so you must separately configure data retention and deletion policies in those services.
What happens to passwords when a WordPress database is compromised?
WordPress hashes passwords using bcrypt (or a similar algorithm), so raw passwords are not stored. Compromised password hashes cannot be reversed to reveal the original password, but attackers can attempt to brute-force short or weak passwords offline. Enforce strong password requirements using a plugin like Password Policy Manager and require password resets every 90 days for admin accounts.
Are WordPress REST API permissions the same as database access permissions?
No. The REST API respects WordPress user roles (e.g., Subscribers cannot edit posts via REST), but the REST API also exposes data that would otherwise require database access, such as the full user list. You can disable REST API entirely, restrict it to authenticated users only, or use a plugin like Disable REST API to selectively block endpoints like /wp/v2/users without breaking other REST functionality.
Do I need to set up backup encryption if my hosting provider already encrypts storage?
Yes. Hosting provider encryption protects backups from physical theft of hard drives, but does not protect against a compromised hosting account where an attacker gains access to all files and databases in your account. End-to-end encrypted backups protect against this scenario because the decryption key is not stored on the hosting provider’s servers.