A secure WordPress site depends on more than a security plugin. This practical WordPress hosting security checklist shows how to harden the hosting layer and WordPress itself while keeping updates, backups, permissions, and recovery manageable. Use it before major changes, during quarterly reviews, and after suspicious activity.
Overview
WordPress security is a shared responsibility between the hosting environment, the WordPress application, and the people who administer the site. A secure WordPress hosting plan may provide useful controls, but it does not remove the need for strong administrator accounts, careful plugin selection, updates, and tested backups.
Start with the controls that reduce the greatest risks and improve recovery if something goes wrong. In practice, that means protecting administrator access, enforcing HTTPS, maintaining reliable backups, limiting permissions, updating software, monitoring activity, and confirming that restoration works. Avoid changing several security settings at once on a production site. Make one controlled change, test the site, and record what changed.
Before using any hardening feature, confirm how it interacts with your hosting plan, caching layer, content delivery network, firewall, and plugins. A setting that is appropriate for one site can block legitimate traffic, interfere with scheduled tasks, or prevent an update on another.
What to track
1. Administrator access
- Use a separate administrator account for each person who needs administrative access. Do not share credentials.
- Remove inactive users promptly and review accounts with administrator-level permissions.
- Use strong, unique passwords and multi-factor authentication where it is supported by your hosting control panel, identity provider, or WordPress security setup.
- Keep an emergency recovery method documented, but store it securely and restrict access to it.
- Review hosting, domain, DNS, database, and WordPress accounts together. A compromised domain or hosting account can undermine otherwise strong WordPress settings.
2. HTTPS and transport security
Enable an SSL certificate and configure the site to use HTTPS consistently. Check the public site, login page, admin area, forms, images, scripts, and APIs for mixed-content warnings or redirect loops. Test both the preferred hostname and any alternate hostname that should redirect to it.
Review the provider's TLS defaults and certificate renewal process rather than assuming they are permanent. If HTTPS settings change, test checkout, login, embedded content, and external integrations. For troubleshooting, see SSL Certificate Errors Explained.
3. Backups and restoration
A backup is only useful if it contains what the site needs and can be restored within an acceptable time. Track whether backups include both the WordPress database and site files, where copies are stored, how long they are retained, and whether they can be accessed independently of the live site.
- Confirm the schedule for database and full-site backups.
- Check that backup jobs complete rather than merely being configured.
- Keep enough history to recover from a delayed discovery of unwanted changes.
- Test a restoration on a staging site or isolated environment before relying on it in an incident.
- Record the restoration steps, required credentials, DNS changes, and post-restore checks.
For a broader recovery workflow, use the Website Backup and Recovery Plan as a companion checklist.
4. Software, plugins, and PHP
Track the WordPress core version, PHP version, theme versions, plugins, and any server-side components that affect the site. Supported versions and hosting defaults change, so verify current compatibility with your host and with plugin and theme documentation during each review.
Remove unused plugins and themes instead of leaving them installed. Before updating a business-critical site, create a fresh backup, review plugin compatibility, and test the update in staging when possible. If an update changes PHP requirements or causes a fatal error, use the host's recovery tools or staging copy rather than repeatedly editing production files without a rollback plan.
5. Hosting-level and WordPress-level controls
| Control | Hosting level | WordPress level | What to verify |
|---|---|---|---|
| Access | Panel authentication, SSH or SFTP controls, account roles | User roles, strong passwords, multi-factor authentication | Inactive users and unnecessary access are removed |
| HTTPS | Certificate issuance, renewal, redirects, TLS configuration | Site URL, mixed-content handling, secure cookies where appropriate | Pages, forms, APIs, and admin screens load without warnings |
| Updates | Supported PHP version, server packages, managed update options | WordPress core, plugins, themes | Updates are tested and can be rolled back |
| Recovery | Snapshots, backup storage, retention, restore tools | Database and uploads are included | A test restore succeeds and is documented |
| Monitoring | Access logs, error logs, malware scanning if included | Login activity, file changes, plugin alerts | Alerts reach someone who can respond |
6. Logs, alerts, and permissions
Review hosting access logs, error logs, failed login activity, unexpected administrator accounts, and changes to plugins or themes. Logs are most useful when you know how long they are retained and where to find them. Confirm that alerts for backup failures, uptime problems, malware findings, or unusual activity are delivered to a monitored address.
Use the least privilege needed for each role. WordPress authors and editors generally should not receive administrator access merely for convenience. At the hosting level, restrict database, file, DNS, and server access to people who need it. If a migration or support task requires temporary access, set an expiration or remove it when the task ends.
Cadence and checkpoints
A recurring schedule makes security work less dependent on memory. Adapt the timing to the site's risk and change rate, but use the following as a practical baseline:
- After every significant change: Check the front end, login, forms, checkout, integrations, caching, and scheduled tasks after installing a plugin, changing PHP, modifying DNS, or changing HTTPS settings.
- Monthly: Review administrator and hosting accounts, failed backups, uptime alerts, error logs, available updates, and unexpected file or content changes.
- Quarterly: Perform a test restoration, review backup retention, confirm that contact details and escalation paths are current, remove unused software, and reassess hosting security features.
- Before major updates: Take a fresh backup, verify staging, check plugin compatibility, confirm access to the hosting panel, and define a rollback point.
- After suspicious activity: Preserve relevant logs, restrict or rotate credentials, inspect users and files, restore only from a trusted backup, and investigate the entry point before declaring the incident resolved.
Keep a short change log with the date, person responsible, software versions, backup reference, test results, and any follow-up action. This turns a collection of settings into an operational security process.
How to interpret changes
Not every warning indicates a compromise, and not every successful backup proves recoverability. Interpret signals in context and look for patterns.
- Repeated backup failures: Treat these as a recovery risk, even if the site remains online. Check storage limits, credentials, timeouts, and whether the backup is complete.
- A rise in failed logins: Confirm whether the activity is expected, then review authentication controls, usernames, passwords, and multi-factor authentication.
- New errors after an update: Compare the change log with server and WordPress logs. Test plugin and theme compatibility before disabling security controls broadly.
- Slower response or intermittent downtime: Review resource usage, PHP errors, database behavior, caching, and recent traffic changes. Security plugins and scans can also affect resources, so test configuration changes carefully.
- Certificate or redirect warnings: Check DNS, certificate coverage, canonical hostnames, proxy settings, and application URLs together. The issue may be outside WordPress.
Separate symptoms from causes. A firewall block, for example, may be a useful control rather than evidence that the application is failing. Record what was observed, what was changed, and how the result was verified.
When to revisit
Revisit this WordPress hosting security checklist at least monthly for operational checks and quarterly for a deeper review. Review it immediately after a major WordPress or PHP update, a hosting migration, a domain or DNS change, a new administrator, a new plugin, or any suspicious activity.
At each quarterly review, verify the current WordPress and PHP support position with the relevant provider or software documentation. Recheck TLS defaults, certificate renewal, backup retention, malware scanning availability, authentication recommendations, plugin compatibility, and the provider's security controls. These details can change as platforms and software evolve.
End each review with three actions: fix the highest-risk gap, test one recovery path, and record the next review date. If you are planning a hosting move, pair this checklist with the Website Migration Checklist or the Shared Hosting to Cloud or VPS Migration Playbook. For ongoing availability, see the Website Uptime Monitoring Guide. Security is strongest when access, updates, backups, and uptime response are reviewed as one connected process.
