Is Your WordPress Site Secure? 15-Point Checklist

Short answer: a secure WordPress site is not defined by one security plugin. It is a maintained system with current software, protected administrator accounts, least-privilege access, off-site backups, encrypted connections, sensible server configuration, monitoring, and a tested response plan.

This article originally discussed a single vulnerability disclosed in 2017. It is now a practical security checklist you can use for a business website in 2026. The companion guide to WordPress security updates covers the deployment workflow in more detail.

1. WordPress core, plugins, and themes are current

Known vulnerabilities become easier to exploit after fixes and technical details are public. Keep WordPress core and every active extension maintained. Review updates frequently and apply security releases promptly with a backup and verification plan.

Delete unused plugins and themes after confirming they are not required. Deactivated software can still contain vulnerable files. Replace abandoned components instead of accepting indefinite exposure because the site currently “looks fine.”

WordPress’s official security guidance identifies current core, plugins, and themes as the most important security foundation.

2. Every administrator has a unique account

Do not share one administrator login among employees, developers, and agencies. Individual accounts create accountability and can be revoked without changing credentials for everyone.

Give users only the capability required for their work. An editor does not normally need to install plugins; a support contractor does not necessarily need permanent administrator access. Review accounts regularly and remove users who no longer need access.

3. Strong unique passwords and a password manager are required

Use a long, unique password for WordPress, hosting, domain registrar, DNS, email, CDN, payment, backup, and analytics accounts. Reusing a password means one unrelated breach can expose the entire website stack.

Do not send primary passwords through ordinary email or chat. Use a password manager’s sharing feature or create a temporary account that can be removed after the work.

4. Two-factor authentication protects privileged users

Enable two-factor authentication for administrators and other high-impact accounts. Prefer authenticator apps, hardware keys, or passkeys where supported; preserve recovery codes somewhere secure and separate from the device.

WordPress core does not currently provide built-in 2FA, so use a reputable maintained plugin, single sign-on provider, or identity service. The official WordPress two-step authentication guide explains why a second factor strengthens password-based login.

5. Hosting, PHP, database, and server software are supported

A fully updated WordPress installation can still run on an insecure operating system, PHP version, database, or web server. Use a host that maintains the underlying platform, isolates accounts appropriately, provides logs, and has a documented incident process.

Confirm supported PHP and database versions before upgrading. Test compatibility on staging, then remove old environments and credentials that are no longer needed.

6. HTTPS protects the whole site and administration

Use a valid TLS certificate and redirect HTTP requests to HTTPS. Confirm that login, administration, forms, checkout, APIs, and embedded assets do not fall back to insecure URLs.

HTTPS protects data in transit; it does not remove malware or fix weak passwords. Treat it as a required layer, not a complete security solution.

7. Backups are off-site, monitored, and restorable

Back up the database and files on a schedule that matches how often the site changes. Keep copies outside the production hosting account and retain more than one version.

Test restoration periodically in an isolated environment. A successful backup notification does not prove the archive contains every upload and database table or that the credentials and encryption keys are available during an emergency.

For a practical setup, see our guide to WordPress backups in Dropbox and the official WordPress backup documentation.

8. Login abuse is rate-limited before it exhausts the server

Automated login attacks can consume resources even when no password is guessed. Use host, web-server, CDN, or WAF controls to rate-limit abusive requests. Protect administrator accounts with 2FA and monitor repeated failures.

Changing the login URL can reduce noise, but it is not a substitute for updates, strong authentication, or rate limiting. WordPress’s current brute-force guidance recommends layered login defenses.

9. XML-RPC and public APIs match actual requirements

Do not disable interfaces blindly because an old checklist says they are dangerous. Determine whether mobile apps, Jetpack, integrations, publishing tools, or APIs rely on them. If XML-RPC is unnecessary, restrict it; if it is required, rate-limit and monitor it.

For integrations using the REST API, prefer individually revocable WordPress Application Passwords over sharing a person’s main login. Review and revoke unused application credentials.

10. File editing and production changes are controlled

WordPress administrators can normally edit plugin and theme files from the dashboard. On managed production sites, consider disabling that editor with DISALLOW_FILE_EDIT and use a controlled deployment process instead.

Restrict SFTP/SSH access, use encrypted SFTP rather than plain FTP, and remove accounts and keys that are no longer required. Never paste unknown snippets into a live theme to solve a security warning.

11. File permissions and ownership are appropriate

The web server should not have broader write access than the application requires. Permissions depend on the hosting architecture, so avoid universal “chmod everything” commands from tutorials. Ask the host for the correct ownership model and investigate unexpected executable files or changes.

Protect configuration and secret files from public access. Do not store database exports, debug logs, or backup archives inside a publicly downloadable directory.

12. Logs and monitoring can reveal an incident

Monitor uptime, file changes, authentication failures, application errors, unexpected administrator creation, unusual outbound traffic, and changes to critical settings. Keep enough server and application logs to investigate what happened.

Alerts must reach a person who can respond. A dashboard full of unresolved warnings is not monitoring. Tune noisy alerts so important events are not ignored.

13. Production does not display sensitive errors

PHP and WordPress debugging messages can expose paths, queries, and implementation details. Log errors privately during diagnosis and keep on-screen error display disabled for visitors.

Temporary debugging settings can also affect performance. Remove them when investigation is finished and protect log files from public access.

14. Forms, payments, and personal data are minimized

Collect only data the business needs, protect it in transit and at rest, and define how long it is retained. Keep payment processing within the supported gateway flow instead of storing card data in WordPress.

Test form spam controls, file uploads, webhook signatures, account recovery, and transactional email. A security review should include privacy and operational failure, not only malware scanning.

15. There is a written incident and recovery plan

Know who can access the registrar, DNS, host, backups, WordPress, email, CDN, and payment systems if the primary administrator is unavailable. Record how to isolate the site, preserve evidence, rotate credentials, restore a known-good version, and communicate with affected parties.

Do not immediately delete every suspicious file before preserving logs and evidence. Restoring a backup without closing the original entry point can result in reinfection.

Use the practical WordPress incident response plan to turn this security checklist into roles, severity definitions, containment choices, recovery tests and a post-incident review.

Quick WordPress security self-check

• All installed software is current and maintained.
• Unused plugins, themes, users, keys, and applications are removed.
• Every privileged user has a unique account, strong password, and 2FA.
• Hosting and PHP versions are supported.
• The complete site uses HTTPS.
• Off-site backups run and a restore has been tested.
• Login and API abuse is rate-limited and monitored.
• SFTP/SSH and dashboard file editing are controlled.
• Production errors are logged privately, not displayed.
• Uptime, file changes, accounts, and critical workflows generate actionable alerts.
• An incident owner and recovery process are documented.

If several of these statements are false or unknown, the site is not ready for a security plugin shopping list—it needs an operational security plan.

What not to rely on

• Hiding the WordPress version while vulnerable software remains installed.
• Changing only the login URL.
• Installing several overlapping security plugins.
• Assuming the hosting backup can be restored without testing.
• Using “admin” avoidance as the primary login defense.
• Blocking every unfamiliar crawler without reviewing logs.
• Restoring a hacked site without identifying how access was gained.
• Keeping unused plugins deactivated instead of removing them.

Frequently asked questions

Is WordPress secure?

WordPress can be operated securely, but the complete system includes core, plugins, themes, hosting, administrator devices, credentials, integrations, and maintenance processes. Most incidents exploit weak credentials, outdated components, misconfiguration, or compromised accounts rather than the concept of WordPress itself.

Do I need a WordPress security plugin?

Not every site needs the same plugin. First identify which controls already exist at the host, CDN, identity provider, and application. Add a maintained plugin only for requirements that remain unmet, and avoid overlapping firewalls or scanners.

How often should WordPress security be checked?

Updates and alerts should be reviewed continuously or at least weekly for a business site. User access, backups, restore tests, integrations, and the broader security configuration should be reviewed on a documented recurring schedule.

What should I do if WordPress is hacked?

Preserve logs, restrict access, notify the responsible owner, rotate compromised credentials from a clean device, identify the entry point, remove malicious changes, restore known-good data if appropriate, patch the cause, and monitor for reinfection. Get professional incident help when customer or payment data may be involved.

Need ongoing WordPress security maintenance?

CodaStudio’s WordPress maintenance service combines updates, backups, monitoring, and human verification instead of relying on one plugin. If the site is already compromised or inaccessible, request help through our WordPress support service. For the deployment process, see our safe WordPress security-update workflow.