# WordPress Security Checklist: Practical Hardening for Site Owners and Developers > A prevention-focused WordPress security checklist covering updates, access control, backups, configuration hardening, monitoring, and the point at which a suspected compromise requires structured incident response. - Canonical: https://asgru.com/wordpress-security-checklist-hardening-guide/ - Language: en - Author: asgru - Published: 2026-09-15T22:51:25+02:00 - Updated: 2026-09-15T22:51:25+02:00 Most WordPress compromises do not start with an exotic zero-day flaw. More often, the cause is ordinary: an abandoned plugin, a reused password, an exposed hosting account, excessive permissions, or a backup that has never been tested. This WordPress security checklist focuses on prevention. It explains how to reduce the chance of compromise, limit the damage from a stolen account, and keep recovery possible if controls fail. If the site is already redirecting visitors, sending suspicious email, displaying unknown administrator accounts, or triggering browser or search-engine warnings, treat that as an active incident—not routine maintenance. Preserve evidence and investigate the cause before attempting a cleanup. ## Start with an accurate inventory You cannot secure a WordPress site if nobody has a reliable picture of what is running, who has access, and where critical credentials are held. An inventory often reveals the real risks: a forgotten staging copy, a plugin installed for a one-off campaign, an old contractor account, or a domain registrar account controlled by one employee. Record the following before changing settings: - WordPress core version, active theme, child theme, and installed plugins; - the purpose, owner, and update status of every plugin and theme; - WordPress administrator, hosting, domain registrar, DNS, SFTP/SSH, database, backup, email-service, and payment-provider accounts; - production, staging, development, and old migrated copies of the site; - backup location, frequency, retention period, and documented restoration procedure; - third-party integrations, API keys, webhooks, payment services, and form destinations. Delete inactive plugins and themes that are no longer needed. Inactive code is still code on the server: it can contain a vulnerability, be reactivated accidentally, or complicate incident investigation. Keeping one current default WordPress theme as an emergency fallback is reasonable; retaining years of old commercial themes usually is not. ## 1. Establish an update policy that does not create outages Updates are among the highest-value WordPress security controls. But “update everything immediately on production” is not a policy. On a site with custom templates, WooCommerce extensions, caching, or external integrations, an untested update can create a different kind of incident. A practical update process looks like this: - Confirm that a current backup is complete and restorable. - Review the scope: WordPress core, plugins, themes, PHP, and server software are separate layers. - For business-critical or customised sites, apply changes to staging first. - Test the important user journeys: login, forms, search, checkout, payment callbacks, customer accounts, and custom integrations. - Deploy to production and review application and server logs for new errors. WordPress minor releases are generally intended to be applied promptly, particularly where they contain security fixes. Major WordPress releases, plugin updates, and PHP upgrades deserve compatibility testing on complex sites. The exact cadence depends on the site, but leaving known updates untouched for months is rarely a defensible business decision. Review PHP support as part of the same process. WordPress may still run on an older PHP release, but that does not mean the release is supported by PHP maintainers or your host. Plan PHP upgrades as tested maintenance work rather than waiting for a forced hosting change. ## 2. Reduce access before adding security tools Access control matters more than hiding the login URL or installing several overlapping security plugins. Once an attacker has a valid administrator password—or access to the email account used for password resets—many cosmetic hardening measures provide little protection. ### Use individual accounts and least privilege Every person should have an individual WordPress account. Shared administrator accounts make offboarding, accountability, and incident investigation unnecessarily difficult. Assign the lowest role that allows someone to do their work: - Subscriber for users who only need an account; - Contributor or Author for restricted publishing workflows; - Editor for content management without site-wide configuration access; - Administrator only for people who need to manage users, settings, plugins, themes, or code. Review administrator accounts at least quarterly and immediately after staff, agency, or supplier changes. An unfamiliar administrator account is an incident signal, not an item to leave until the next review. ### Require unique passwords and multi-factor authentication Use long, unique passwords stored in a reputable password manager. Do not reuse WordPress credentials for hosting, the domain registrar, DNS, email, or other services. Email deserves particular attention because control of a password-reset mailbox can become control of the website. Enable multi-factor authentication for WordPress administrators and for hosting, domain, DNS, and email accounts wherever the provider supports it. Review recovery codes, recovery email addresses, and registered devices as part of offboarding. Multi-factor authentication tied to a former employee’s phone or an unattended mailbox is not a complete control. ### Protect server and deployment access Disable accounts that are no longer needed. Prefer SSH keys over password-based SSH access. Use separate accounts where the hosting platform allows it, and avoid granting unrestricted production access to every developer by default. Database credentials, deployment secrets, and API keys should not be committed to public repositories or sent in ordinary email. ## 3. Harden WordPress configuration and file permissions Hardening makes common attack paths less useful. The implementation depends on the host and deployment model, so test configuration changes on staging and retain a rollback route. ### Disable the dashboard file editor on production By default, WordPress administrators may edit theme and plugin files from the dashboard. On a production site, that convenience is a liability: a compromised administrator account can be used to alter PHP code directly. Add this line to wp-config.php, above the line that says “That’s all, stop editing”: define( 'DISALLOW_FILE_EDIT', true ); This disables the theme and plugin file editors in the WordPress dashboard. It does not prevent normal updates and does not replace server security. Make legitimate code changes through a controlled deployment process, SFTP, or SSH. ### Use permissions to enforce ownership, not to bypass errors Protect wp-config.php with ownership and permissions suitable for your server setup. Where the host supports it, keep sensitive configuration outside the public document root. Do not copy permission values blindly from a tutorial: Apache, PHP-FPM, containers, and managed WordPress platforms can have different requirements. The objective is simple: WordPress and the intended deployment process must be able to read or modify the files they need, while unrelated users and processes cannot. Do not make files or directories world-writable just to solve an update error. That usually hides a deployment or ownership problem while expanding the attack surface. ### Control who can introduce executable code For managed production sites, consider a workflow in which plugin and theme installation is performed only through an approved release process. This is not appropriate for every editorial team, but it is valuable where developers manage deployments and content users should not be able to introduce new executable code. The operating rule matters more than a single setting: decide who can add, update, and remove code in production, then make that responsibility explicit. ## 4. Protect login and application entry points Automated login attempts are routine on public WordPress sites. The useful response is layered control, not security theatre. - Require multi-factor authentication for privileged accounts. - Use rate limiting or login-attempt controls at the host, CDN, web application firewall, or an appropriate WordPress security layer. - Use a CDN or web application firewall where the site’s traffic and exposure justify it, especially if it receives repeated automated attacks. - Remove unused accounts and avoid predictable administrator usernames. - Review XML-RPC based on actual dependencies. If no required mobile app, publishing workflow, or integration uses it, restricting it can reduce unnecessary exposure. Changing the login URL may reduce low-quality automated noise, but it is not a primary security boundary. It should never substitute for multi-factor authentication, password hygiene, role control, and rate limiting. ## 5. Treat backups as a recovery control A backup is useful only if it is complete, isolated from the compromised environment, and restorable. A database-only backup may omit uploads and custom code. A backup held only in the same hosting account may be unavailable when the account is compromised. A backup that has never been restored is an assumption, not a recovery plan. Keep both database and file backups, store at least one copy separately from the production hosting account, and set retention based on business requirements. An e-commerce site processing orders daily has a very different tolerance for data loss than a brochure site updated once a month. Test restoration into a non-public environment. Confirm that the restored site loads, media is present, expected data exists, and critical functions such as forms or checkout work. Backup storage needs the same access discipline as production: named users, unique credentials, and multi-factor authentication where available. For larger sites, define two targets: - Recovery Point Objective (RPO): the maximum acceptable data loss. An RPO of 24 hours means the business can accept losing up to one day of changes. - Recovery Time Objective (RTO): the maximum acceptable time to restore service. These are business decisions, not technical labels. They determine backup frequency, retention, hosting architecture, and the level of recovery preparation required. ## 6. Monitor meaningful change, not only malware Malware scanning is useful, but a clean scan is not proof that a site is secure. Detection depends on what the scanner recognises, what it can inspect, and how the compromise behaves. New administrator accounts, changed DNS records, unexpected scheduled tasks, altered files, and unusual outbound email can be equally important signals. Build a monitoring routine around: - failed login patterns and successful administrator logins; - new, deleted, or privilege-changed WordPress users; - core, plugin, and theme changes; - unexpected modifications to critical files; - availability, TLS certificate expiry, and domain or DNS changes; - web-server and PHP error logs, particularly after releases; - outbound email volume and form submissions that suggest abuse. Choose tools based on the environment rather than installing multiple plugins that all scan files, run firewalls, and send alerts. Your host, CDN, monitoring provider, and existing WordPress tooling may already cover part of the stack. Duplicated controls can consume resources, create conflicting settings, and leave nobody clearly responsible for responding to alerts. ## 7. Include custom code and integrations in the security review WordPress security is not confined to the dashboard. A custom REST endpoint, form handler, webhook, payment integration, or bespoke plugin can introduce more risk than the standard WordPress installation. Review custom functionality after significant changes and before connecting sensitive systems. Pay particular attention to authorisation checks, input validation, output escaping, nonce use for administrative actions, file-upload handling, API key storage, and error messages that expose internal details. For a site with custom plugins or business-critical integrations, a focused [WordPress code security audit](https://asgru.com/wordpress-code-security-audit-what-it-covers-and-when-to-order-one/) provides answers that a configuration checklist cannot. A checklist reduces routine operational gaps; a code review examines application logic, permissions, and trust boundaries. Security requirements should also be part of acceptance criteria for rebuilds and integration work, not an afterthought once a feature is live. For the wider architectural and maintenance considerations, see [WordPress website enhancement and integration planning](https://asgru.com/wordpress-website-enhancement-custom-functionality-integrations-and-modernization/). ## 8. Define the incident threshold before you need it No control guarantees that a site will never be compromised. The practical difference between a manageable incident and a prolonged one is often whether the team recognises the warning signs early and avoids destroying useful evidence. Escalate immediately if you find unexplained administrator accounts, altered payment details, unfamiliar code in plugin or theme files, spam redirects, browser or search-engine warnings, unusual outbound email, or suspicious hosting-log activity. Record what was observed, preserve relevant logs and backups, restrict access carefully, and involve the host or a qualified incident-response provider. Do not assume that deleting one suspicious file or updating plugins has removed a compromise. After recovery, rotate credentials and secrets, identify the likely entry point, review the possible exposure period, and close the underlying gap. Restoring a backup without finding the cause can simply restore the same vulnerability. ## WordPress security checklist: a workable maintenance routine ### Weekly or when updates are released - Review and apply tested WordPress core, plugin, and theme updates. - Check backup completion and investigate failed backup alerts. - Review security, availability, and error alerts that require action. ### Monthly - Review administrator accounts, installed plugins, themes, and integration credentials. - Test critical site journeys, including login, forms, checkout, and account areas where relevant. - Review logs and investigate unexpected file or configuration changes. ### Quarterly - Test a restoration in a safe, non-public environment. - Review access to WordPress, hosting, DNS, domain registration, email, and backup storage. - Confirm that multi-factor authentication methods and recovery details belong to active staff. - Remove old staging copies, inactive services, and integrations that no longer have a business purpose. ### After any major change - Test functionality and review logs. - Verify that current backups completed successfully. - Document new accounts, API keys, permissions, and third-party dependencies. ## FAQ ### Is a security plugin enough to secure WordPress? No. A security plugin can provide useful monitoring, login protection, and alerts, but it cannot compensate for weak hosting access, reused passwords, unsupported server software, insecure custom code, or untested backups. WordPress security spans the application, server, DNS, email, backup storage, and the people who can access each layer. ### Should every WordPress plugin update automatically? Automatic updates can reduce the time that known issues remain exposed, especially on simpler sites. On complex or revenue-critical sites, updates should be combined with staging tests and a rollback plan. The right choice is a documented policy based on the consequence of downtime and the team’s capacity to monitor changes. ### Does hiding the WordPress login page make a site secure? No. It may reduce opportunistic automated traffic, but attackers can identify WordPress installations through other signals. Prioritise multi-factor authentication, strong unique passwords, least-privilege roles, and rate limiting. ### How often should a WordPress site be backed up? Set backup frequency according to the amount of data the business can afford to lose. A site that receives orders, registrations, or daily content changes needs more frequent recovery points than a static site. Include files and the database, keep an offsite copy, and test restoration regularly. ### What should I do if I think my WordPress site has been hacked? Do not treat the issue as a normal update task. Preserve evidence, record the symptoms, restrict access where appropriate, contact the host if needed, and use a structured remediation process. Once the site is verified as clean, use this checklist to address the conditions that allowed the compromise. ## The practical priority If you do only five things this month, remove unnecessary code and accounts; apply overdue updates through a tested process; enforce multi-factor authentication for privileged access; verify an offsite restore; and review who controls hosting, DNS, the domain, email, and backups. Those controls address a substantial share of preventable WordPress risk without creating a pile of plugins and false reassurance. Where custom functionality, sensitive integrations, or material business consequences are involved, add a code-focused security review to the maintenance plan.