WordPress security is not a one-time configuration task. This practical checklist shows how to harden a site, monitor the controls that matter, maintain reliable backups, and respond methodically when something changes or goes wrong.
Overview
A secure WordPress website depends on several layers working together: protected administrator accounts, current software, controlled access, safe file permissions, encrypted connections, dependable backups, and a tested recovery process. Missing one layer does not automatically mean a site will be compromised, but it can make prevention, detection, or recovery more difficult.
Start with the highest-impact controls rather than trying to change everything at once. Create a complete backup, confirm that you can access the hosting account, and record the current WordPress, PHP, theme, and plugin versions. This gives you a recovery point and a baseline for future reviews.
Your hosting environment is part of the security model. Review how your provider handles account access, SSL, server isolation, software updates, backup retention, and support escalation. If a site regularly exceeds its available resources or suffers unexplained downtime, security maintenance can become harder to perform. The comparison of shared, VPS, managed, and cloud hosting can help frame those trade-offs.
What to track
Administrator accounts and authentication
Review every administrator account and remove accounts that are no longer needed. Each person should have an individual account with only the capabilities required for their role. Avoid sharing credentials, especially for administrator access, because shared accounts make it difficult to identify changes or revoke access for one person.
Use long, unique passwords and enable multi-factor authentication wherever it is supported by your WordPress setup, hosting account, domain registrar, and email provider. Protect the email accounts associated with administrators as carefully as the WordPress dashboard itself. If an administrator loses access, use a documented recovery route rather than creating an untracked emergency account.
Core, theme, and plugin changes
Track the versions and update status of WordPress core, active themes, and plugins. Remove inactive extensions that are not required, and avoid installing software solely because it offers a convenient feature. Before adding a plugin, check whether it is maintained, compatible with your site, necessary for a defined purpose, and available from a source you trust.
Test significant updates in a staging environment when possible. At minimum, create a fresh backup before updating and check the public site, login page, forms, checkout or membership flows, and important integrations afterward. Keep a simple change log with the date, component, reason for the change, and result.
Files, permissions, and configuration
Check that writable permissions are no broader than necessary and that sensitive configuration files are not publicly exposed. Do not place database passwords, API keys, or other secrets in content that can be downloaded or committed to a public repository. Review administrator access to hosting panels, SFTP, SSH, databases, DNS, and deployment tools separately from WordPress roles.
Use the hosting control panel or deployment process to limit access where practical. If you are unsure whether a permission or server setting is safe, ask your hosting provider to explain the available options before changing production files.
HTTPS, login protection, and monitoring
Confirm that the site loads over HTTPS and that important redirects do not create loops or mixed-content warnings. SSL protects data in transit, but it does not replace strong authentication, updates, or backups. For common certificate and mixed-content problems, use this SSL troubleshooting guide.
Monitor login failures, unexpected administrator creation, password-reset messages, unfamiliar changes, and sudden redirects. Website uptime monitoring can identify outages, but uptime alone does not prove that a site is secure. Pair availability checks with application-level checks, such as confirming that a key page returns the expected content. The uptime monitoring and incident-response guide provides a useful starting workflow.
Backups and recovery evidence
Maintain backups of both WordPress files and the database. A database-only backup may not restore uploaded media, themes, or plugins; a files-only backup may not restore posts, settings, orders, or user data. Keep more than one recovery point and, when appropriate, store a copy separately from the live hosting account.
Do not treat a successful backup message as proof that recovery will work. Periodically restore a copy to a staging site or isolated environment and verify that the site can load, administrators can sign in, media is present, and essential functions operate. Follow the detailed WordPress backup and restore checklist when documenting this process.
Cadence and checkpoints
Use a recurring schedule, but adjust it to the site’s risk and change rate. A small brochure site may need a lighter review than a store, membership site, or publication with multiple administrators.
- After every change: Record the update, back up the site, test key user journeys, and check for unexpected visual or functional changes.
- Weekly: Review security notifications, failed logins, backup completion, uptime alerts, and recent administrator activity. Confirm that critical forms and login pages still work.
- Monthly: Audit administrator accounts, remove unused plugins and themes, review hosting and domain access, confirm HTTPS behavior, and inspect available storage and resource usage.
- Quarterly: Perform a recovery test, review access for staff and contractors, rotate credentials or keys when appropriate, inspect DNS and email settings, and reassess whether the hosting plan still fits the site.
- After an incident: Preserve relevant logs, restrict access, identify the affected time range, restore only from a known-clean source, and document what changed before reopening normal access.
Keep the checklist in a shared but access-controlled location. Include the site URL, hosting and registrar contacts, backup locations, recovery owner, critical integrations, and the order in which services should be restored.
How to interpret changes
Not every alert indicates an attack. A spike in failed logins may reflect routine automated traffic, while a single unfamiliar administrator account deserves immediate investigation. Interpret events by comparing them with your change log, deployment records, uptime data, and hosting activity.
Unexpected redirects, new files, modified core files, unfamiliar users, changed DNS records, or unexplained outbound email should be treated as investigation triggers. Avoid repeatedly logging in, editing files, or deleting evidence if you suspect compromise. First record what you observed and when, then restrict affected accounts or services as safely as possible. Contact your host or security specialist if you cannot establish a trusted recovery path.
A useful incident note includes:
- What was observed and which URLs, accounts, or systems are affected.
- When the issue was first noticed and when the site was last known to be normal.
- Recent updates, deployments, password changes, DNS edits, or hosting migrations.
- Actions already taken, including account suspension, isolation, restoration, or password rotation.
- The clean backup selected for recovery and the tests completed afterward.
Do not assume that changing the WordPress administrator password alone resolves a compromise. Review hosting, database, SFTP or SSH, DNS, email, API, and third-party service credentials as well.
When to revisit
Return to this checklist monthly for routine controls and quarterly for a deeper review. Revisit it immediately after a major WordPress, theme, plugin, PHP, hosting, or domain change; after adding an administrator; after moving the site; after a failed backup; or after any suspicious activity.
Use the review to compare the current state with the previous baseline. Are there more administrator accounts? Did an update introduce errors? Has the backup restore test become overdue? Are uptime alerts increasing, or is the site using more storage and server resources? Trends often reveal maintenance problems before they become outages or security incidents.
Make the next review actionable: assign an owner, set a date, and record one or two priority fixes. If a hosting move is planned, use the WordPress migration guide and test the restored site before changing DNS. Security improves through repeatable checks, clear ownership, and recovery practice—not through a single plugin or a one-time hardening exercise.
