WordPress Security Hardening Checklist for Cloud-Hosted Sites

Overview

This checklist is designed to be revisited. WordPress changes, plugins change, hosting environments change, and the way attacks show up also changes. A secure baseline on day one can drift within a few months if no one reviews updates, access controls, backups, firewall rules, DNS records, or logging.

For cloud-hosted WordPress security, it helps to think in layers:

• Hosting layer: account isolation, patching, SSL, CDN, firewall controls, backups, monitoring.
• Application layer: WordPress core, themes, plugins, admin access, file permissions, login protections.
• Domain and DNS layer: registrar security, DNS records, email authentication, subdomain hygiene.
• Operational layer: update process, restore testing, incident response, audit cadence.

If you only change one habit after reading this, make it this: every security control should answer one of three questions. What does it prevent? What does it detect? How do we recover if it fails?

Use the following checklist as a working document. Mark each item as done, not applicable, or needs review.

Checklist by scenario

This section groups the hardening work by the moment when people usually need it most.

1. Baseline checklist for every cloud-hosted WordPress site

• Use reputable cloud web hosting or managed hosting with WordPress-aware security features. Look for account isolation, SSL support, backup options, staging, server patching, and logs you can access.
• Enable HTTPS everywhere. Install SSL, force HTTPS redirects, and fix mixed content. If you need a walkthrough, see How to Set Up SSL on a Website.
• Keep WordPress core, themes, and plugins updated. Remove anything inactive that you do not need. Unused plugins are still part of your attack surface.
• Use strong unique passwords and require MFA where possible. Apply this to WordPress admins, hosting accounts, domain registrars, and connected email accounts.
• Rename or remove default admin patterns. Avoid predictable usernames and audit all admin-capable accounts.
• Apply least privilege. Editors should not be admins. Developers do not always need registrar access. Temporary contractors should have temporary access.
• Limit login abuse. Add rate limiting, bot protection, or a firewall rule for repeated failed logins.
• Install only necessary plugins from established sources. Fewer plugins generally means less risk and less maintenance.
• Disable file editing from the WordPress dashboard. This reduces the damage of an admin account compromise.
• Review file permissions. Keep permissions conservative and avoid world-writable files or directories.
• Block directory listing and protect sensitive paths. Confirm that backup archives, logs, and configuration files are not publicly exposed.
• Use automated backups with retention. Back up files and databases, and store copies off the production server when possible. Then test restore steps. Related reading: Website Backup Strategy Checklist.
• Turn on uptime and health monitoring. Security incidents often first appear as downtime, redirects, resource spikes, or certificate issues. See Website Uptime Monitoring Guide.
• Enable a CDN or edge protection layer if available. This can help absorb basic malicious traffic and reduce origin exposure.
• Hide origin details where practical. Reduce direct access to the server IP unless a valid operational reason exists.
• Audit XML-RPC exposure. If you do not use it, limit or disable it. If you do, monitor it closely.
• Protect wp-login.php and wp-admin. Consider IP allowlists for private sites, geofencing where appropriate, or additional authentication controls.
• Scan routinely for malware and file changes. Detection matters because no single prevention layer is perfect.
• Maintain a written recovery contact list. Include hosting, registrar, DNS provider, mail provider, and internal decision makers.

2. Checklist before launching a new WordPress site

• Start with a minimal theme and plugin set. Add only what the site truly needs.
• Change all temporary credentials before launch. This includes hosting control panel, SFTP, database users, staging URLs, and default admin accounts.
• Remove demo content and test users. Demo imports can expose endpoints, forms, media, or pages that should never be public.
• Confirm search visibility settings. A staging site should stay blocked; the live site should be indexable when ready.
• Check redirects and canonical behavior. Security and SEO overlap when duplicate environments are left exposed.
• Verify forms and transactional email setup. Lock down form spam and configure domain email authentication. Related reading: SPF, DKIM, and DMARC Setup Guide for Custom Domains.
• Review launch DNS records carefully. Remove stale subdomains, old verification records only if no longer needed, and test propagation. See DNS Propagation Checker Guide.
• Run a pre-launch checklist. Pair security review with SEO, forms, and analytics validation using Website Launch Checklist for SEO, Analytics, Forms, and Indexing.

3. Checklist after migrating to cloud hosting

• Rotate credentials after migration. Old SFTP, database, API, and admin credentials should not survive the move without review.
• Verify SSL, redirects, and HSTS behavior. Migrations often break HTTPS enforcement or create mixed content.
• Recheck file ownership and permissions. Migration tools can preserve insecure values from the old environment.
• Confirm backups are running in the new environment. Never assume the old backup job moved with the site.
• Review cron jobs and scheduled tasks. Broken cron behavior can affect security plugins, update checks, and email delivery.
• Audit DNS and registrar security. Make sure the domain still points where intended, registrar MFA is enabled, and no stale records remain. Helpful references: Domain Transfer Checklist and Best Domain Registrars Compared.
• Test WAF, CDN, and caching behavior. Security rules and edge caching can change after migration.
• Compare logs before and after cutover. Look for login spikes, 404 floods, blocked requests, and unusual admin activity.

4. Checklist after adding or changing plugins

• Review the plugin's exact purpose. If it overlaps with an existing plugin, remove duplication.
• Check permissions requested by the plugin. Anything that writes files, modifies roles, exposes APIs, or handles uploads deserves extra review.
• Test in staging first. New plugins can open endpoints, alter redirects, or break caching and security headers.
• Confirm update frequency and maintenance posture. A plugin that lags behind WordPress updates may need closer scrutiny.
• Monitor file changes and admin notices after activation. Unexpected rewrites, new users, or altered settings are warning signs.
• Take a backup before major plugin changes. Especially for page builders, security plugins, caching plugins, and e-commerce extensions.

5. Checklist for sites with multiple admins, editors, or developers

• Separate roles by responsibility. Content teams need editorial access, not server keys.
• Use named accounts only. Do not share one admin login across a team.
• Review access monthly. Remove inactive users and old contractor accounts promptly.
• Require secure offboarding. Reset passwords, revoke tokens, and rotate shared secrets after personnel changes.
• Log key actions. Changes to plugins, themes, users, and settings should be attributable.
• Document who can approve high-risk changes. For example, DNS edits, plugin installs, payment settings, or firewall exceptions.

6. Incident response checklist if compromise is suspected

• Do not start by deleting files blindly. Preserve evidence long enough to understand scope.
• Put the site into a controlled maintenance state if needed. Limit damage while keeping a path for investigation.
• Rotate all critical credentials. WordPress admins, hosting panel, SFTP, SSH, database, CDN, DNS, registrar, and transactional email accounts.
• Check for unexpected admins, scheduled tasks, redirects, and modified core files.
• Restore from a known-clean backup if necessary. Then patch the weakness that allowed the compromise.
• Review logs around the first known bad event. Determine whether the entry point was a plugin, weak password, exposed endpoint, or reused credential.
• Verify the site after cleanup. Test forms, checkout, redirects, indexing controls, SSL, and sitemap responses.
• Write a short post-incident note. Record what happened, what changed, and what should be monitored next time.

What to double-check

These are the items that look finished on paper but often fail in real environments.

• Backups that have never been restored. A backup job is not the same as a recovery plan. Test restore time, file completeness, database integrity, and DNS cutover steps.
• SSL that exists but is not enforced. Some sites still serve mixed HTTP assets, non-canonical URLs, or inconsistent redirects.
• CDN or firewall rules that bypass the origin. If the origin remains exposed and unrestricted, edge protection is weaker than it appears.
• Staging environments indexed by search engines. Staging copies can expose outdated plugins, copied data, and duplicate content.
• Old subdomains and forgotten installs. A secure main site can still be undermined by an abandoned subdomain running outdated WordPress.
• Domain and hosting accounts secured differently. If WordPress has MFA but the registrar does not, domain hijack risk remains.
• Security plugins fighting cache plugins or server rules. Conflicts can break logins, APIs, or redirects in subtle ways.
• Email deliverability for security alerts. If your domain mail setup is broken, password resets and incident alerts may never arrive.
• Scheduled updates without review windows. Auto-updates can help, but critical plugins still need post-update validation.
• Admin access from unmanaged personal devices. The site may be hardened while endpoint hygiene remains loose.

A useful audit question is: If an attacker gained one low-privilege account today, what would stop lateral movement? The answer should include role separation, disabled file editing, credential rotation paths, file integrity checks, and backups.

Common mistakes

Many WordPress incidents are caused less by advanced exploits and more by predictable operational gaps.

• Treating hosting security as a complete substitute for WordPress hardening. Secure web hosting helps, but it does not replace access control, plugin hygiene, or routine audits.
• Keeping too many plugins for convenience. Every additional extension adds maintenance overhead and compatibility risk.
• Ignoring registrar and DNS security. Domain and hosting are part of the same security surface. Losing control of DNS can be as damaging as losing the server.
• Using one admin account for everything. Shared credentials reduce accountability and make incident review harder.
• Skipping staging tests for security-related changes. Firewall rules, login protection, and caching changes can lock out valid users or break APIs.
• Leaving old environments online after a migration. Attackers often find the forgotten copy first.
• Installing overlapping security plugins. More tools do not always mean more security. Overlap can create false confidence or operational conflicts.
• Not documenting exceptions. If you open XML-RPC, allow direct origin access, or keep a high-risk plugin for business reasons, write down why and how it is monitored.
• Waiting for visible symptoms. A compromised site may continue to load normally while spam pages, hidden redirects, or rogue users spread quietly.

If your team runs more than one site, standardize the checklist. The same baseline across projects makes audits faster and reduces configuration drift.

When to revisit

This checklist is most useful when tied to clear triggers. Revisit it on a schedule and whenever the site changes in a meaningful way.

• Monthly: review updates, user accounts, failed logins, uptime trends, SSL status, and backup success.
• Quarterly: audit plugins and themes, test restores, review firewall and CDN settings, inspect DNS records, and remove stale assets or subdomains.
• Before seasonal planning cycles: check capacity, monitoring, form protection, caching, and incident contacts before traffic or campaigns increase.
• When workflows or tools change: revisit the checklist after changing hosts, switching DNS providers, adding builders or e-commerce plugins, introducing AI content tools, or revising team access patterns.
• Before and after migrations: use the same list as a preflight and post-cutover review.
• After every security event: even small incidents should trigger a focused retrospective.

For a practical routine, create a short recurring task with four actions:

1. Update: patch core, plugins, themes, and hosting-level components under your control.
2. Audit: review users, logs, exposed endpoints, DNS records, and plugin inventory.
3. Verify: test backups, SSL, forms, login flow, and key pages.
4. Record: note what changed, what failed, and what needs follow-up.

That small habit turns a static wordpress hardening guide into an operating process. For most cloud-hosted WordPress sites, consistency matters more than complexity. A site with a modest, well-maintained security baseline is usually in a better position than one with many tools and no review discipline.

If you are launching a new site or rebuilding your stack, it may also help to step back and confirm that WordPress is the right fit for the project. See Website Builder vs CMS vs Static Site Generator and How to Launch a Website on a Custom Domain for broader planning context.

Use this checklist before plugin changes, before launch, after migration, and at the start of each review cycle. Security hardening works best when it becomes part of normal site operations rather than a one-off cleanup task.