WordPress Security Hardening Checklist: Protect a Site After Every New Plugin or User

Overview

WordPress security hardening is the process of reducing avoidable risks while preserving the access that legitimate editors, developers, customers, and administrators need. The safest approach is layered: keep software maintained, limit privileges, protect authentication, maintain recoverable backups, monitor changes, and test important controls.

Before changing a security setting, record the current configuration and test the site on a staging copy when practical. Security tools can conflict with caching, forms, ecommerce checkouts, REST API integrations, scheduled tasks, and editorial workflows. A change that blocks every request is not necessarily a useful change if it also prevents customers from checking out or editors from publishing.

Use this checklist as a review record rather than a one-time installation guide. For a safer update process, pair it with a WordPress staging site update checklist. If a custom plugin is involved, document its permissions, settings, and release process using the maintainable custom WordPress plugin checklist.

What to track

1. Core, PHP, theme, and plugin updates

• Record the WordPress version, PHP version, active theme, and installed plugins.
• Remove unused plugins and themes instead of leaving inactive software in place indefinitely.
• Review update notices and changelogs before applying significant changes to a production site.
• Test login, publishing, forms, search, media uploads, ecommerce functions, and important integrations after updates.
• Keep a rollback path through a tested backup or staging workflow. Do not assume that an untested backup can restore the exact working state you need.

Security maintenance and performance maintenance overlap. Outdated extensions can create both security exposure and debugging problems, while excessive security scanning or poorly configured plugins can add server load. Use the WordPress performance optimization checklist when a hardening change is followed by slower responses.

2. Administrator accounts and user roles

• Review every administrator and confirm that each account has a current business reason to exist.
• Disable or remove former staff, contractors, test accounts, and duplicate accounts according to your access policy.
• Use the least-privilege role that allows a person to complete their work. An author or editor should not automatically receive administrator access.
• Use individual accounts rather than shared administrator credentials so activity can be attributed and access can be revoked separately.
• Check newly created users, unexpected role changes, unfamiliar email addresses, and password-reset activity.

When adding a developer or support user, create temporary access with a defined review date where possible. After the work is complete, remove the account or reduce its role. This is more reliable than relying on memory months later.

3. Login and authentication protection

• Require strong, unique passwords for every account, especially administrators.
• Enable multi-factor authentication if it is supported by your chosen identity or security workflow.
• Use login protection that can rate-limit or challenge repeated failed attempts without locking out legitimate users permanently.
• Review password-reset email settings, administrator email addresses, and recovery contacts.
• Test login protection in a private browser session and confirm that administrators still have a documented recovery method.

Avoid making assumptions about a security plugin's default settings. Confirm which login URL, REST API routes, XML-RPC requests, application passwords, and automated tasks your site actually uses before blocking them.

4. HTTPS, files, and hosting controls

HTTPS should cover the front end, administration area, login process, and any connected service that exchanges credentials or customer data. Check for mixed content after changing certificates, domains, caching, or CDN settings. At the hosting level, review the following:

• Use a supported PHP release offered by the host and verify compatibility with the site before changing it.
• Restrict hosting-panel access to authorized users and protect the hosting account with strong authentication where available.
• Keep file and directory permissions as restrictive as the site requires, while allowing WordPress and legitimate deployment processes to function.
• Protect configuration files and avoid placing secrets, database exports, logs, or backups in publicly accessible directories.
• Confirm that server, CDN, firewall, and hosting backups are separate from the WordPress installation when possible.

5. XML-RPC, APIs, and integrations

Do not disable XML-RPC or the WordPress REST API automatically. First identify whether the site uses mobile publishing, external tools, ecommerce integrations, scheduled services, headless features, or another connection that depends on them. If a service is not needed, restrict or disable the relevant interface through a tested method. If it is needed, protect it with authentication, rate limiting, least privilege, and monitoring rather than applying a blanket block.

6. Backups, scanning, and activity logging

• Maintain backups of both the database and uploaded files, with retention that matches the site's recovery needs.
• Store at least one recovery copy separately from the production hosting account.
• Perform a restore test on a staging location or other controlled environment instead of treating backup completion as proof of recoverability.
• Use malware scanning as one layer of detection, not as a substitute for updates, access control, and clean deployment practices.
• Review activity logs for logins, plugin installations, theme changes, user creation, role changes, file edits, and unexpected settings changes.

Keep enough context in the log to investigate an event: timestamp, account, action, affected object, source information when available, and whether the action was expected. Logs should be protected from unauthorized editing and retained according to your operational needs.

Control ownership comparison

Cadence and checkpoints

After installing a plugin or theme

Record the extension name, version, source, purpose, required permissions, and installation date. Confirm its developer account or license details where relevant, then test the public site, administration area, forms, and integrations. Check whether the new extension adds an administrator, scheduled task, external connection, upload path, or custom endpoint. Remove it if it is not needed rather than leaving an unmaintained feature active.

After adding or changing a user

Record the user's role, reason for access, approving person, authentication method, and review date. Confirm that the account can perform only the required tasks. When access is no longer needed, deactivate or remove it and review tokens, application passwords, API keys, and connected services associated with the account.

Monthly review

• Review administrator accounts, recent user changes, failed logins, and suspicious activity.
• Check pending core, theme, plugin, and PHP maintenance work.
• Confirm that backups completed and that the most recent restore test is documented.
• Review malware scan results, server alerts, uptime notices, and unusual performance changes.
• Check HTTPS certificate status, domain settings, and critical third-party integrations.

Quarterly review

Repeat the monthly review, then test a recovery procedure, audit all installed software, remove abandoned accounts and extensions, and reassess XML-RPC, REST API, file access, hosting, and logging decisions. Review the incident-response record and update contact details, recovery credentials, and escalation instructions.

How to interpret changes

A single failed login is not enough to diagnose a compromise, and a clean scan does not prove that every part of a site is safe. Interpret changes in context and compare them with the site's normal activity.

• Expected change: A named user installed an approved plugin during a recorded maintenance window. Verify the version and test the site.
• Investigate: An unfamiliar login, new user, role change, modified setting, or file change has no matching ticket or owner. Preserve logs and confirm with the account owner before deleting evidence.
• Urgent response: The site redirects visitors, displays unauthorized content, sends unexpected mail, exposes credentials, or shows unexplained administrator activity. Restrict access carefully, contact the host or security provider, preserve a copy for investigation, rotate affected credentials, and restore only from a known-good source.

Use this incident-response template:

Incident ID:
Date and time detected:
Person recording the event:
Symptoms and affected URLs:
Recent plugins, themes, users, or hosting changes:
Suspicious accounts, IPs, files, or settings:
Actions taken to contain access:
Backups and scans reviewed:
Credentials or keys rotated:
Restore or cleanup steps:
Tests completed after recovery:
Follow-up controls and owner:
Next review date:

Do not overwrite the only copy of relevant logs while cleaning a site. If credentials may be exposed, change them from a trusted device and review connected services, hosting accounts, database access, deployment keys, and email accounts as well as WordPress users.

When to revisit

Revisit this WordPress security hardening checklist monthly for active sites and at least quarterly for lower-change sites. Run an additional review immediately after installing or removing a plugin, adding an administrator, changing hosting, changing domains, restoring a backup, modifying login or API settings, or completing a major WordPress, PHP, theme, or integration update.

Before each review, record the current software versions, user list, backup status, scan results, and important configuration changes. After the review, record what changed, what was tested, who approved it, and when the next check is due. Security guidance, plugin interfaces, hosting terminology, and supported software requirements can change after major releases, so verify settings in the current environment rather than copying an old configuration blindly.

Start with the highest-value actions today: remove unnecessary administrator access, confirm a recoverable backup, update through a tested process, enable stronger authentication, and document the site's recovery path. Then schedule the monthly and quarterly checkpoints so hardening remains part of normal WordPress maintenance instead of an emergency reaction.