17 items

Website Security & Backup

Most sites are compromised not by sophisticated hackers but by automated bots exploiting predictable gaps — outdated plugins, reused passwords, and backups that have never been tested. This checklist covers every defensive layer, from access control through verified disaster recovery. For more background and examples, see the guidance below; for built-in tools and options, use the quick tools guide.

Author

Checklistify Editorial Team

Last Updated

Checklist Items

0 done•17 left•3 of 4 sections collapsed

Use unique, strong passwords for all admin accounts — CMS, hosting control panel, and database.

Credential attacks (brute force and credential stuffing using breached password lists) are among the most common ways sites are compromised. Password requirements that actually matter: unique (not reused from any other service — credential stuffing works by trying username/password combinations from other breaches), long (16+ characters is adequate; 20+ is better), and random (generated by a password manager, not a pattern). A password manager (Bitwarden, 1Password) generates and stores these without requiring you to remember them. The CMS admin password, hosting cPanel/Plesk password, and database password should each be distinct — a breach of one hosting account should not compromise all sites managed from it.

Enable two-factor authentication (2FA) on every admin account.

2FA makes credential theft insufficient to gain access — the attacker also needs the second factor (typically a time-based one-time code from an authenticator app). Enable on: WordPress admin (via plugin — WP 2FA, Two Factor, or Google Authenticator for WordPress), hosting control panel (Cloudflare, cPanel, SiteGround, etc. — all major hosts support 2FA), and domain registrar account (extremely important — a compromised registrar account allows the attacker to redirect your domain to a malicious site or transfer it away entirely). Authenticator apps (Google Authenticator, Authy, 1Password) are more secure than SMS 2FA — SMS is vulnerable to SIM swapping, where an attacker convinces your carrier to transfer your phone number to their SIM.

Implement login attempt limiting and, for WordPress, relocate or protect the admin login URL.

WordPress installs a publicly accessible admin login at /wp-admin and /wp-login.php — these endpoints are probed continuously by automated bots. Login limiting (via the Limit Login Attempts Reloaded or WP Cerber plugin) blocks an IP after N failed attempts, slowing brute force attacks significantly. Renaming or hiding the login URL (via WPS Hide Login or iThemes Security) reduces automated probe volume by removing the default URL predictability. These measures are friction-increasers for attackers, not absolute barriers — they must be combined with strong passwords and 2FA rather than used as substitutes for them.

Apply the principle of least privilege — assign each user only the permissions they actually need.

WordPress roles and appropriate use cases: Administrator (full site control — should be limited to 1–2 people who genuinely require it), Editor (manage and publish any content — appropriate for managing editors), Author (publish own content — appropriate for regular contributors), Contributor (submit content for review — for guest authors who should not publish directly), Subscriber (read and comment — for member-only content). Never assign the Administrator role to SEO consultants, developers doing limited tasks, or content-only editors. If an Editor account is compromised, the blast radius is significantly smaller than a compromised Administrator account.

Audit and remove unused admin accounts, API keys, and third-party service integrations.

Every active account and API key is a potential entry point. Former employees, contractors, and developers frequently retain admin access indefinitely after their work ends — audit the WordPress Users list and hosting control panel quarterly and deactivate any account that is no longer in use. Equally important: revoke API keys for abandoned plugin integrations, disconnected payment gateways, and unused email service connections at the source (not just by removing the plugin from WordPress, which may leave the API key sitting in the database). Keys stored in wp-config.php or theme options files deserve extra scrutiny — if an attacker ever gains read access to those files, every stored key must be considered compromised and regenerated immediately.

Keep the CMS and all plugins and themes updated — enable auto-updates where practical.

Outdated software is the primary attack vector for CMS-based sites. When a vulnerability is disclosed in WordPress core, a plugin, or a theme, the disclosure is public — attackers have the exploit details immediately and begin automated scans for sites running the vulnerable version. Update timing is the defense: sites updated within days of a security release are rarely compromised; sites running months-old versions are systematically targeted. WordPress enables automatic background updates for minor security and maintenance releases by default. For plugins: enable auto-updates for those with a strong support history, and manually review major version updates before applying them. Remove deactivated plugins and themes entirely — they remain scannable and exploitable even when switched off.

Disable the XML-RPC endpoint if your site does not use remote publishing or Jetpack.

WordPress's XML-RPC endpoint (/xmlrpc.php) was designed for remote publishing tools and is required by Jetpack for its WordPress.com connection. For sites that use neither, the endpoint should be disabled — it is a frequent target for credential brute force attacks that bypass standard login attempt limiters, because XML-RPC allows bundling hundreds of authentication attempts into a single HTTP request, which many rate limiters do not count correctly. Disable via a plugin (Disable XML-RPC, or the security section of Wordfence or iThemes Security) or by blocking the file in .htaccess: add <Files xmlrpc.php> deny from all </Files> inside the WordPress .htaccess block. If you use Jetpack, leave XML-RPC enabled and rely on Jetpack's built-in brute force protection instead.

Deploy a Web Application Firewall (WAF) — Cloudflare's free plan is adequate for most sites.

A WAF filters malicious requests before they reach the web server, blocking common attack patterns including SQL injection, cross-site scripting (XSS), path traversal, and known exploit signatures. Cloudflare's free tier provides: managed WAF rules that block common attack patterns automatically, volumetric DDoS mitigation that absorbs traffic floods capable of taking a shared server offline, a global CDN that also improves page load performance, and SSL certificate management. The free tier is sufficient for most informational sites, portfolios, and small business sites. Implementation: change your domain's nameservers to Cloudflare's — all inbound traffic then passes through Cloudflare before reaching your origin server. The full setup takes approximately 30 minutes.

Set correct file permissions on the server: 755 for directories, 644 for files, 600 for wp-config.php.

File permissions control who can read, write, and execute files on the server. Overly permissive settings — particularly 777, which grants write access to all users — are a significant vulnerability: if an attacker gains code execution anywhere on the server, write permissions elsewhere allow them to inject malicious code into additional files. The correct defaults: 755 for directories (owner can write; group and others can read and traverse), 644 for PHP and HTML files (owner can write; others can only read), 600 for wp-config.php (contains database credentials — should be readable only by the server process user, never web-accessible). Apply via SSH with chmod 600 wp-config.php, or via an FTP client like FileZilla. If you are uncertain, ask your hosting provider's support team to verify permissions.

Install an SSL certificate and force all traffic to HTTPS — verify no mixed content remains.

Most hosting providers now offer free SSL via Let's Encrypt — enable it directly in the hosting control panel. Forcing HTTPS: add a redirect rule in the .htaccess file (Apache servers) or nginx configuration, or use the Really Simple SSL plugin for WordPress, which handles the redirect and fixes most mixed content automatically. After enabling HTTPS, check for mixed content — HTTP resources (images, scripts, stylesheets) loaded on an HTTPS page — using the browser DevTools console (F12, look for 'Mixed Content' warnings) or the Why No Padlock tool. Mixed content strips the secure padlock indicator from the browser and can re-expose data. Verify that the SSL certificate is configured to auto-renew — Let's Encrypt certificates expire every 90 days, and an expired certificate causes an alarming browser error that drives visitors away.

#10

Implement HTTP security headers — at minimum, X-Content-Type-Options, X-Frame-Options, and HSTS.

Security headers instruct browsers on specific security behaviors. The most impactful: X-Content-Type-Options: nosniff (prevents browsers from MIME-sniffing responses, which reduces cross-site scripting risk), X-Frame-Options: SAMEORIGIN (prevents the page from being embedded in iframes on third-party sites, blocking clickjacking attacks), HTTP Strict Transport Security / HSTS (tells browsers to always request the domain over HTTPS, preventing protocol downgrade attacks), and Content-Security-Policy / CSP (a more complex but powerful header that restricts which scripts and resources the page may load). Cloudflare can inject most of these headers through its Transform Rules without touching server configuration. Without Cloudflare, add them to the .htaccess or nginx config. Verify the result at securityheaders.com.

#11

Schedule automated daily backups of both files and the database — stored in a separate, offsite location.

A backup stored on the same server as the site is lost if the server is compromised by ransomware or account hijacking, or suffers a hardware failure. Backup storage must be logically independent: Amazon S3, Backblaze B2, Google Drive, or Dropbox are all valid destinations. For WordPress: UpdraftPlus (free tier) supports scheduled backups directly to cloud storage destinations and is straightforward to configure. Essential settings: daily backup schedule and a retention window of at least 30 days — infections are often present for weeks before discovery, so a short retention window may contain only infected copies. Both files and the database must be backed up — the database holds all content; the files hold themes, plugins, and media.

#12

Test your backup by restoring it to a staging environment — an untested backup is effectively no backup.

The catastrophic failure mode: a site is compromised, a restore is initiated, the restore fails — due to file corruption, an incomplete transfer, or a PHP timeout during a large database export — and there is no clean copy to fall back to. Prevention requires at least quarterly restore testing: download a backup and restore it to a local development environment (Local by Flywheel, XAMPP) or a staging site. Verify that all pages load, database connections work, and content appears correctly. This is the only way to confirm that a backup is genuinely restorable. Backup corruption most commonly results from interrupted backup processes, files not fully transferred to the remote destination, or PHP memory limits timing out during large database exports.

#13

Run a security scanner monthly to check for malware and known vulnerabilities.

Security scanners check for: modified core files (comparing against known-good WordPress file checksums to detect tampering), backdoors hidden in theme or plugin files, malicious code injections in the database (such as eval() base64 patterns used to obfuscate malware), and plugin or theme versions with disclosed CVEs. For WordPress: Wordfence (free tier) provides both scheduled and on-demand file scans with real-time monitoring that flags modifications as they occur. Sucuri SiteCheck (sitecheck.sucuri.net) provides a free external scan from outside the server. Note that external scanners only see what is returned to the browser — a plugin-based scanner that reads server-side files directly provides more thorough detection. Monthly on-demand scans plus continuous Wordfence monitoring is the recommended baseline.

#14

Write and maintain a documented disaster recovery plan.

A disaster recovery plan is a written document — not a mental model — that defines: what events constitute a security incident requiring a formal response (malware detected, site defaced, unauthorized admin login, data breach), who owns the response and how they are reached, the specific investigation steps and how to assess the scope of damage, the restoration procedure (which backup, which environment, verification criteria before going live), communication requirements (notify hosting provider; notify affected users if personal data was accessed), and the post-incident review to close the entry point. The core value is that decisions made in writing during calm are more reliable than decisions improvised under the pressure of an active incident. Most sites have a backup; far fewer have a documented and practiced recovery process.

#15

Set up uptime monitoring with alert notifications to catch downtime or defacement quickly.

A site that has been taken offline, defaced, or is silently redirecting visitors to spam pages may go unnoticed by the site owner for hours or days — particularly for lower-traffic sites. Uptime monitoring services poll your site at short intervals and send an email or SMS when the site goes down or returns an unexpected status code. Free options: UptimeRobot monitors up to 50 sites at 5-minute intervals at no cost; Freshping offers 1-minute checks on its free tier. More advanced monitoring can also alert on SSL certificate expiration before the Let's Encrypt renewal window closes and on keyword disappearance from key pages — catching defacements or redirect injections that do not take the site fully offline.

#16

Review server access logs periodically for unusual request patterns and failed login volume.

Access logs record every HTTP request to the server: source IP, requested URL, HTTP status code, and user agent string. Periodic review reveals: repeated 404 errors targeting admin or config file paths (path traversal probing), high volumes of POST requests to wp-login.php or xmlrpc.php (brute force attempts), rapid sequential requests from a single IP (automated scanning), and unusual user agent strings associated with known attack frameworks. Most hosting control panels (cPanel, Plesk) provide log viewer access; SSH access enables more flexible analysis. Cloudflare's analytics dashboard — even on the free tier — shows blocked request counts and traffic anomalies without requiring raw log access. Weekly or monthly review is adequate for most sites; automated analysis tools like GoAccess or AWStats reduce the time investment significantly.

#17

🚨 What Actually Happens After Your Site Is Compromised

The visible damage — a defaced homepage or an unexpected visitor redirect — is rarely the full story. The cascade of consequences following a successful compromise can persist for months after the malware itself is cleaned, hitting rankings, deliverability, and customer trust simultaneously.

⚠️ Google Safe Browsing blacklist

When Google's crawlers detect malware distribution or phishing content on a domain, it is added to the Safe Browsing database. Chrome, Firefox, and Safari then display a full-screen "Deceptive site ahead" interstitial to every visitor. Organic traffic typically drops 90%+ within days. Removal requires submitting a manual review in Google Search Console after cleaning the site — a process taking 1–4 weeks with no guaranteed timeline, even when the site is fully remediated.

⚠️ Hosting suspension and IP reputation damage

Hosting providers automatically suspend accounts detected distributing malware or sending spam — usually without advance notice, and often at 3am when no one is watching. Beyond the site going offline, the server's IP address may be listed on email reputation blacklists (Spamhaus, Barracuda), disrupting outbound email deliverability for every site sharing that IP. IP reputation recovery is measured in weeks to months, independent of whether the malware has been removed.

🔍 How to Evaluate a Plugin Before You Install It

Installing a WordPress plugin is effectively granting that code full execution access to your database and file system. The plugin repository surfaces several signals that help you filter out risky options — most site owners simply do not check them.

Check the last updated date

A plugin untouched for 12+ months likely hasn't been reviewed against current WordPress versions or recent PHP releases. The repository displays a banner when a plugin has not been tested with the last three major WordPress versions — treat that warning as a stop sign, not a suggestion.

Review the support forum before installing

Active install counts signal popularity; support forum behavior signals reliability. A developer who consistently responds within a few days is far more likely to release security patches promptly when a CVE is discovered. Scan the most recent threads before installing — patterns of unresolved critical bugs are a clear warning sign.

Search the WPScan vulnerability database

WPScan (wpscan.com/plugins) maintains a searchable record of known WordPress plugin vulnerabilities with CVE details and patch timelines. A plugin with a history of slowly patched or unresolved CVEs is a liability regardless of its star rating or install count. This takes 30 seconds and is worth doing for every new plugin.

Prefer commercially supported plugins for high-stakes functions

For payment processing, membership gating, or complex form handling — where a vulnerability has the greatest real-world impact — commercially supported plugins (WooCommerce, Gravity Forms, MemberPress) with dedicated security teams and structured release processes are worth the cost over free alternatives maintained by solo developers with no SLA.

💰 Shared Hosting vs. Managed WordPress — What the Price Difference Actually Buys

Your hosting environment determines which security responsibilities are handled at the infrastructure level and which fall entirely to you. The practical difference is significant.

Shared Hosting (~$3–12/month)

You own: plugin and theme updates, backup configuration, WAF setup, SSL installation, file permission management, and security plugin selection. The host manages physical hardware, server OS patching, and network infrastructure — nothing at the application layer is touched.

⚠️ This checklist is most critical for shared hosting users. Account isolation quality varies significantly between providers; a compromised neighbor on the same physical server can occasionally affect shared resources.

Managed WordPress (~$25–100+/month)

Hosts like WP Engine, Kinsta, and Flywheel handle server-level WAF and DDoS protection, automatic daily backups with one-click restore, WordPress core auto-updates, staging environments, and malware cleanup guarantees — Kinsta and WP Engine will remediate infections at no additional cost if a compromise occurs.

✅ You still own plugin selection, user permissions, and application-level credentials. But for a business-critical site, the monthly managed hosting cost is typically less than a single hour of emergency developer billing during an incident.

📝 When Personal Data Is Exposed: Legal Obligations Most Site Owners Miss

If your site collects any personal data from visitors in the EU — contact form submissions, newsletter signups, customer accounts — a breach that exposes that data triggers GDPR notification requirements, regardless of where your business is physically located.

72-hour notification window: Under GDPR Article 33, you must notify your relevant supervisory authority within 72 hours of becoming aware of a personal data breach. The clock starts at the moment of discovery, not when the breach first occurred — and "becoming aware" has been interpreted broadly by regulators.

Direct user notification threshold: When a breach is likely to result in high risk to affected individuals — exposed passwords, financial information, health data — you must notify those users directly and individually, typically via email. A generic site-wide announcement or banner does not satisfy this requirement.

Internal breach log (mandatory regardless): Even breaches that fall below the formal notification threshold must be documented internally — what occurred, what categories of data were involved, the estimated number of affected individuals, and the remediation steps taken. This log must be made available to your supervisory authority on request at any time.

💡 Add a data breach response section to your disaster recovery plan before you need it. Who drafts the notification, what it says, and who approves it should be decided during calm, not during an active incident.

🧮 The 3-2-1 Backup Rule Applied to Websites

The 3-2-1 rule — 3 copies of data, on 2 different storage media, with 1 copy in a logically separate location — is the standard framework in enterprise data protection. Here is what each number means for a website specifically.

Copies

Live site + a recent backup + a significantly older backup — giving you a copy that predates any potential silent compromise that began weeks ago

Storage Types

Primary cloud storage + a second independent provider or physical copy — not two folders within the same cloud account, which shares identical credential risk

Offsite Copy

At least one copy is logically isolated — your hosting credentials must not be able to delete it, and a full account compromise should not be able to reach it

The nuance that matters most in practice: the second backup destination must use entirely separate credentials — a different email address and password from your hosting account. If both the hosting account and the backup destination share credentials, a single compromised login loses everything simultaneously. This is the most common backup architecture mistake for self-managed WordPress sites.

Master This Checklist Quickly

Every important button and option for this pre-made checklist, shown in a glance-friendly format.

Start Here

1
Click any item row to mark it complete.
2
Use the note row under each item for quick notes.
3
Use the tool row for undo, redo, reset, and check all.
4
Use Save Progress when you want to continue later.

Checklist Row Tools

UndoRedoResetCheck allCollapse/Expand sectionsShow/Hide detailsInline notes

Top Action Buttons

Open all sharing and export options in one menu.

Email DraftContinue on another devicePrint or Save as PDFPlain Text (.txt)Word (.docx)Excel (.xlsx)

Add & Ask

Open one menu for apps and AI guidance.

NotionTodoist CSVChatGPTClaude

Copy and customize

Create a new editable checklist pre-filled with your chosen content.

Save Progress

Adds this checklist to My Checklists and keeps your progress in this browser.

Most Natural Usage

Track over time

Check items -> Add notes where needed -> Save Progress

Send or export

Open Share -> Choose format -> Continue

Make your own version

Copy and customize -> Open create page -> Edit freely

Website Security & Backup

Checklist Items

Access Control — The First Line of Defense

Software and Server Hardening

Backup and Recovery

Monitoring and Visibility

🚨 What Actually Happens After Your Site Is Compromised

🔍 How to Evaluate a Plugin Before You Install It

💰 Shared Hosting vs. Managed WordPress — What the Price Difference Actually Buys

📝 When Personal Data Is Exposed: Legal Obligations Most Site Owners Miss

🧮 The 3-2-1 Backup Rule Applied to Websites

Master This Checklist Quickly

Start Here

Checklist Row Tools

Top Action Buttons

Share

Add & Ask

Copy and customize

Save Progress

Most Natural Usage

Track over time

Send or export

Make your own version

Gaming PC Build

Operating System Fresh Install

PC Setup: From Unboxing to First Boot

Phone Factory Reset & Secure Wipe

Smartphone Upgrade & Backup

Checklistify