Is a WordPress security plugin enough on its own, or do I still need this checklist?

A good security plugin handles the majority of the runtime defense: WAF, brute-force protection, malware scanning, 2FA, file integrity monitoring. But roughly a third of the items on a complete pre-launch security review sit outside the plugin's scope: your hosting provider's SSL/TLS setup, DNS records like SPF and DMARC, admin username choice, default file permissions, git-repo secrets scrubbing. This checklist covers all three layers explicitly.

How long does it take to run through a full pre-launch security review?

For a single site, about 30-45 minutes if you have all the credentials handy (host control panel, DNS panel, GuardPress admin). Multi-site agencies typically build this into a client-handoff runbook that runs in 15 minutes per site because the checks are scripted or pre-verified via templates.

Which of these items is most important if I only have time for one check?

2FA on every administrator account. It's the single defense that turns 'attacker got a valid credential' from 'compromise' into 'failed sign-in.' Every other item on this checklist reduces risk; 2FA eliminates one specific attack class entirely. Second-most-important: verify offsite backups are running and restorable (not just running).

Do I need to hide the WordPress admin URL or change the wp-login.php path?

It doesn't hurt, but it's not on the essentials list. Security-through-obscurity slows down automated brute-force scanners marginally, but doesn't prevent a determined attacker who knows the site runs WordPress. If you enable it, do so as an ergonomics improvement (fewer noisy blocked-request alerts) not as your primary defense. The primary defense against brute-force is still the rate-limit + 2FA combination.

Should I remove the readme.html and wp-config-sample.php files that ship with WordPress?

readme.html reveals the WordPress version to anyone who hits /readme.html directly, which lets attackers filter for sites running versions with known CVEs. Delete it after every WordPress update. wp-config-sample.php doesn't leak sensitive info but there's no reason to leave it in production either. Both are on the checklist under 'you verify manually.'

The Pre-Launch WordPress Security Checklist (2026)

Everything to verify before a new WordPress site goes live, or before you hand a site off to a client. 35 items, grouped by who owns each: 20 that a good security plugin (GuardPress or similar) automates, 5 that your host handles for you if you’re on a real host, and 10 that you still have to check manually because no plugin can see them.

What GuardPress automates (20 items)

These are handled automatically once GuardPress is installed, activated, and Quick Start is complete. Nothing to check per launch beyond confirming the dashboard shows green:

Item	What it covers
1. Web application firewall	Blocks SQL injection, XSS, path traversal, file inclusion, malicious-bot signatures before WordPress loads.
2. Brute-force login protection	IP lockouts on repeated failed sign-ins.
3. Two-factor authentication (TOTP)	Second-factor challenge on every sign-in surface.
4. Malware file scanner	Daily PHP-file scan against signature list + behavior heuristics.
5. File integrity monitor	Baseline hash of WordPress core files, alerts on any change.
6. Vulnerability scanner	Cross-checks every installed plugin against the CISA Known Exploited Vulnerabilities feed and other CVE data sources.
7. XML-RPC brute-force protection	Blocks the XML-RPC amplification attack vector.
8. WordPress version hiding	Strips the generator meta tag so attackers can’t filter for known-vulnerable versions.
9. File-editing lockdown	Disables the built-in theme/plugin file editor in wp-admin (`DISALLOW_FILE_EDIT`).
10. Emergency lockdown mode	Panic-button to reject all new sign-ins site-wide while an incident is being resolved.
11. Per-role 2FA enforcement	Require 2FA for Administrators / Editors / Shop Managers without forcing it on Subscribers.
12. Sign-in notifications	Email alert when an administrator signs in from a new device or location.
13. Database security checks	Scans for common WP DB attack surface: exposed `DB_USER`, weak admin passwords, tables from removed plugins.
14. IP whitelist / blacklist	Manual overrides for trust and block, plus auto-populated lockout table from brute-force.
15. Cloudflare / CDN real-IP resolver	Reads the correct source IP when the site sits behind a proxy.
16. Country blocking	Geographic access rules delivered by the Firewall module.
17. CAPTCHA on login forms	Cloudflare Turnstile / hCaptcha / reCAPTCHA on wp-login.php and every common integration surface.
18. Uploads PHP execution block	Prevents PHP from executing inside `wp-content/uploads/`, shutting down the “upload a shell via a bad file-type check” attack class.
19. Security event logging	Structured log of every block, lockout, malware finding, and file-integrity change.
20. Email alerts with throttling	Critical events emailed to you with per-attacker throttling so a scan wave doesn’t flood your inbox.

What your host should handle (5 items)

These are your hosting provider’s job. If you’re on a real WordPress-focused host (Kinsta, WP Engine, Pressable, Cloudways, Rocket.net, or similar), all five are default-on. If you’re on generic shared hosting, verify each one manually and consider moving providers if the answer is no.

Item	What to check
21. Automatic SSL certificate	Let’s Encrypt (or equivalent) auto-provisioned and auto-renewing. Test with SSL Checker.
22. HTTP/2 or HTTP/3 enabled	Modern protocol support. Not strictly security, but reduces attack surface for slowloris-style attacks.
23. Automatic offsite backups	Daily backups stored somewhere other than the origin server, retained for at least 30 days, and tested restorable. If your host doesn’t do this, run SiteVault to handle it independently.
24. PHP version currently supported	PHP 8.1 or newer. Older versions no longer receive security patches from the PHP core team.
25. DDoS mitigation at the network edge	Basic volumetric-attack absorption. Every major managed WP host provides this; on shared hosting you may need to front the site with Cloudflare’s free plan.

What you still have to check manually (10 items)

These sit outside both the plugin’s scope and the host’s scope. Every one is a common miss on client handoffs. Run through them before every launch:

Item	Why it matters, how to check
26. Admin username isn’t `admin`, `administrator`, or the site name	Half of all brute-force attempts try `admin` first. Rename the primary administrator account before launch. WP Users → create new administrator with a strong username → delete or demote the old one.
27. Every admin account has a strong, unique password	Password manager-generated, minimum 20 characters, not reused from any other service. Enforce for the admin account you’re handing off too.
28. `readme.html` is deleted from the site root	WordPress ships a `readme.html` that leaks the WordPress version. Delete after every WordPress update via SFTP or a small snippet in the theme’s `functions.php`.
29. `wp-config-sample.php` is deleted	Doesn’t leak sensitive info, but there’s no reason to leave it in production.
30. `wp-config.php` file permissions are 400 or 440	Read-only for the web-server user, unreadable for anyone else. Prevents a compromised process from exfiltrating DB credentials.
31. Database prefix is not `wp_`	Not a huge win, but reduces the effectiveness of generic SQL-injection payloads that assume the default prefix. Set during WordPress install, or migrate afterward with a plugin.
32. Unused plugins and themes are deleted, not just deactivated	Deactivated plugin code still sits on disk and can be executed via direct file access. Delete anything you’re not actively using.
33. Debug logging is off (or write-only)	Confirm `WP_DEBUG`, `WP_DEBUG_LOG`, and `WP_DEBUG_DISPLAY` are all false in production. Debug output on the frontend leaks file paths, PHP version, and sometimes credentials to any visitor.
34. DNS: SPF, DKIM, and DMARC records for transactional email	If the site sends email (contact forms, WooCommerce receipts, user notifications), these records make sure the mail actually delivers and can’t be spoofed. Set at your DNS provider based on your SMTP delivery service’s documentation.
35. Any secrets in a public git repo are scrubbed	If the site’s source is in git, run a secret scanner (gitleaks, trufflehog) over the whole history before making the repo public. Old commits with a `wp-config.php`, a stripe key, or an SMTP password are the most common leak class.

Bonus: the client handoff extras

If you’re an agency handing a finished site to a client, add these to the launch runbook. Not strictly security, but each one prevents a class of “the site broke and I don’t know how to fix it” support ticket:

Client owns the domain registrar account, not the agency
Client’s email is on the hosting account as at least a secondary contact
Client has an administrator account with 2FA configured
Backup restore procedure is documented in a place the client can find (not just in your internal wiki)
Support-contact information is visible in the WP admin dashboard (a small widget, an admin notice, or a shortcut in the GuardPress dashboard) so the client knows who to email when something breaks

Post-launch: what to watch in the first week

Launching secure is half the job. The other half is knowing when something changes. First-week watch list:

GuardPress dashboard, once a day. Skim for anything red. Amber can wait a few days.
Alert email inbox. Confirm alerts are actually arriving. If nothing has fired in a week, either your site is very quiet, or (more likely) your SMTP path is broken.
Google Search Console. Watch for “Security issues” and “Manual actions” sections lighting up.
Uptime monitor. UptimeRobot, Better Uptime, or similar. Ping the homepage plus wp-login.php every 5 minutes. This catches attacks that DoS the site before your host does.
Analytics for weird spikes. A 10x traffic spike from one country you don’t serve is probably not a marketing win; it’s probably a scanner wave.