WordPress Security Hardening: 15 Checks Before You Go Live
https://vulnify.app/blog/wordpress-security-hardening-15-checks-before-you-go-live

Launching WordPress without a hardening checklist is how small gaps turn into real exposure. This guide covers 15 practical checks to reduce attack surface, tighten access, and verify the site before it goes live.

WordPress sites rarely get compromised because of one dramatic mistake. More often, the trouble comes from a stack of smaller gaps left behind during the rush to launch: an unused plugin still installed, a weak admin account, a writable directory that never got tightened, or a staging shortcut that quietly made it into production. Attackers do not need every door open. They only need one. That is why wordpress security hardening should happen before launch, not after the first alert, strange redirect, or support ticket. A go-live checklist gives you a repeatable way to reduce obvious risk, cut down unnecessary exposure, and make sure the site that ships is the site you actually intended to expose to the internet. This guide is about prevention and configuration. It is not a step-by-step guide to scanning WordPress from the outside. If you want the detection-focused workflow, read Non-Intrusive WordPress Vulnerability Scanning . If you want a WordPress-aware public review after hardening, use the WordPress Security Scanner or the WordPress Stack Checker to validate what is still visible from the public edge. Table of Contents Why Pre-Launch Hardening Matters Before You Touch Production The 15 Checks Before Go-Live Master Checklist FAQ Related Articles Conclusion Why Pre-Launch Hardening Matters WordPress is flexible, popular, and heavily extended. That makes it productive for site owners and attractive to attackers at the same time. A typical compromise path is not especially glamorous: credential stuffing on wp-login.php, a forgotten plugin with a known issue, an exposed XML-RPC surface that is no longer needed, weak file permissions, or debug details left visible in production. Hardening reduces attack surface before anyone starts probing the site seriously. It also makes later scanning more useful. When the obvious operational mistakes are already handled, the findings that remain are easier to prioritize and less likely to be drowned out by noise. For launch teams, that means fewer last-minute surprises and better release decisions. Before You Touch Production Do not harden a live WordPress site by improvising changes directly on production. Use a staging copy, confirm backup and restore coverage, and make sure there is a repeatable path to deploy the approved changes. Security settings can break login flows, media paths, third-party integrations, and cache behavior when applied carelessly. Test first: Apply hardening in staging whenever possible. Back up before launch: Confirm file and database backups, and verify that restore actually works. Use a repeatable deploy path: Avoid one-off manual edits that cannot be reproduced later. The goal is not just a hardened site. The goal is a hardened site you can maintain without guessing what changed. The 15 Checks Before Go-Live 1. Freeze Scope, Staging, Backups, and a Repeatable Deploy Path Pick a short freeze window before launch and stop non-essential changes. Confirm that staging matches what will go live, that backups exist for both files and database, and that deployment is repeatable instead of manual and ad hoc. This matters because many WordPress security problems are introduced during chaotic release windows. Defenders lose track of what changed. Attackers benefit from confusion. How to verify: Restore a backup in a safe environment and compare the intended production build against staging. Common mistakes: Backing up only files, skipping database backups, or making “quick” live edits that never get documented. 2. Core, Themes, and Plugins: Updates, Removal, and Trusted Sources Update WordPress core, active themes, and active plugins before launch. Then delete anything unused. Deactivation is not enough if the code still sits on disk. Only use components from trusted sources, and avoid nulled or repackaged downloads entirely. Old and abandoned components are one of the easiest ways for attackers to get in. Even when the exploited issue is not publicized on your radar, the pattern is consistent: stale code extends exposure. How to verify: Review the installed plugin and theme lists and remove everything inactive that is not required. Common mistakes: Keeping the default theme “just in case,” leaving disabled plugins installed, or treating a marketplace download as trustworthy without checking provenance. 3. Accounts and Passwords: Least Privilege for Admins and Editors Review every user account before launch. Remove unused accounts, avoid shared logins, assign the lowest role needed, and make sure no one is still using the old “admin” habit for daily access if a named admin account can be used instead. Least privilege matters because compromised editor access is bad, but compromised administrator access is often game over. A smaller admin group means fewer high-value targets. How to verify: Review the user list and confirm every account has an owner, a purpose, and an appropriate role. Common mistakes: Sharing one administrator login across a team, keeping contractor accounts active, or giving plugin managers full admin when editor-level workflow would do. 4. Enforce Multi-Factor Authentication for Administrators Require MFA for all administrator accounts and strongly consider it for editors with sensitive workflow access. App-based authenticators are usually a better baseline than SMS because SMS is weaker against SIM-related attacks and account recovery abuse. Password theft still works when there is no second factor. MFA does not solve every access problem, but it makes simple credential reuse far less effective. How to verify: Test an admin login on a fresh browser session and confirm a second factor is required. Common mistakes: Enabling MFA for only one admin, relying on SMS as the only option, or forgetting to secure backup codes. 5. Protect wp-login.php and Limit Brute Force Protect wp-login.php with rate limiting, bot controls, WAF rules, or host-level protections. Renaming or obscuring login paths can reduce noise, but it is not a real substitute for access control and throttling. Attackers do not need a novel technique if your login endpoint allows endless guessing. Hardening here slows automated abuse and gives defenders better odds. Example pattern, adjusted for your host and stack: # Example only. Adjust for your host or edge service. # Rate limit requests to wp-login.php at the server or CDN layer. location = /wp-login.php { limit_req zone=login burst=10 nodelay; include fastcgi_params; } How to verify: Confirm repeated failed attempts trigger throttling, challenge, or block behavior. Common mistakes: Assuming a changed login URL is enough, leaving XML-RPC available as an alternate login path, or forgetting edge-layer protections. 6. Review XML-RPC and Automation Endpoints Decide whether XML-RPC is actually needed. Some workflows such as Jetpack or older mobile publishing paths may rely on it, but many modern sites do not. If you do not need it, disable it. If you do need it, monitor and protect it. This matters because XML-RPC has long been a useful target for brute-force and abuse patterns. It is not automatically unsafe, but it should not stay open by accident. How to verify: Test dependent services first, then disable XML-RPC in staging and confirm nothing business-critical breaks. Common mistakes: Turning it off blindly and breaking a needed integration, or leaving it on forever because “it came with WordPress.” 7. Harden wp-config.php: Salts, Keys, and Sensitive Settings Make sure your authentication salts and keys are unique, current, and not copied from an old build. Where hosting allows it, keep sensitive configuration outside the web root. Restrict access and avoid loose file permissions. wp-config.php is one of the most sensitive files in a WordPress deployment. If attackers can read or tamper with it, the damage usually extends well beyond a single page issue. Useful examples: define('FORCE_SSL_ADMIN', true); define('DISALLOW_FILE_EDIT', true); How to verify: Confirm salts are unique, production credentials are not reused in staging, and config is not web-accessible. Common mistakes: Reusing old salts across cloned environments, exposing backups that contain wp-config.php, or keeping production database credentials in development notes. 8. Disable Theme and Plugin File Editing in Production Disable the built-in theme and plugin editor in production. This removes an easy path for code changes through the dashboard if an administrator account is compromised. It is not a complete defense. It will not stop malicious plugin uploads or direct filesystem changes. But it does remove a common shortcut that attackers and rushed administrators both like to abuse. define('DISALLOW_FILE_EDIT', true); How to verify: Check that the dashboard no longer offers the theme and plugin editor screens. Common mistakes: Assuming this setting alone secures the admin area, or using the production dashboard as a code editor during emergencies. 9. Tighten File Permissions and Writable Directories Keep writable locations limited to what actually needs to be writable, usually uploads and a small set of cache or plugin-specific directories. Application code should not be broadly writable in production. Loose permissions make post-compromise persistence much easier. If an attacker gets any foothold, writable code paths help them turn a small problem into a durable one. How to verify: Review ownership and permission settings for wp-content, uploads, cache, and core files with your host or deployment tooling. Common mistakes: Setting everything to permissive values to “make uploads work,” or letting deployment scripts drift into overly broad write access. 10. HTTPS Everywhere: TLS, Redirects, and Mixed Content Force HTTPS, redirect HTTP cleanly, and remove mixed content before launch. A secure certificate is only part of the picture. You also need the site, assets, and canonical URLs to behave consistently over HTTPS. Attackers benefit when transport is weak or inconsistent. Users lose trust when browsers throw warnings or load insecure elements. Hardening transport protects sessions and improves basic site integrity. HSTS is useful once HTTPS is stable, but do not turn on long-duration HSTS until you are sure every path and subdomain that matters can stay on HTTPS reliably. How to verify: Load key pages over HTTP and confirm they redirect to HTTPS without loops, warnings, or mixed-content errors. Common mistakes: Enabling HSTS too early, forgetting media URLs, or leaving an old plugin or CDN path on HTTP. 11. Security Headers and Cookies at the Edge Review security headers and cookie flags at the server or CDN layer. For WordPress sites, browser-facing protections such as HSTS, CSP, X-Frame-Options or frame-ancestors policy, X-Content-Type-Options, and strong cookie flags can reduce common browser-side exposure. These controls are not a substitute for secure code, but they add meaningful resistance and improve overall web hygiene. They also help answer common launch and audit questions without pretending to guarantee compliance outcomes. How to verify: Inspect response headers and confirm session-related cookies use Secure, HttpOnly, and an appropriate SameSite setting where possible. Common mistakes: Copy-pasting a CSP that breaks scripts, setting HSTS on unstable environments, or forgetting cookie flags after reverse-proxy changes. 12. Reduce Information Disclosure Turn off debug mode in production, disable directory listing, and reduce visible version and environment clues where practical. You are not trying to become invisible. You are trying to avoid giving attackers easy context for free. Information disclosure usually does not compromise a site on its own. What it does is make follow-on targeting faster and cheaper. define('WP_DEBUG', false); define('WP_DEBUG_LOG', false); define('WP_DEBUG_DISPLAY', false); How to verify: Check public pages, error responses, and directory paths for debug output, indexes, or obvious version leakage. Common mistakes: Leaving debug enabled after a migration, assuming a hidden generator tag solves disclosure, or exposing logs through the web server. 13. REST API and User Enumeration: Know Your Exposure Review the WordPress REST API and common user enumeration behaviors with a practical mindset. Some exposure is normal and needed for real site functionality. The goal is to understand what is visible, which routes truly need to be public, and where you should tighten authentication, hosting rules, or plugin behavior. There is no single magic fix here. Overreacting can break features. Underreacting can leave unnecessary clues about users, content structure, or administrative paths. How to verify: Test public API responses and confirm only the intended routes and data are available anonymously. Common mistakes: Disabling routes that power the frontend, trusting one plugin toggle to solve everything, or ignoring public author exposure altogether. 14. Database and Table Prefix Hygiene Use strong database credentials, grant only the permissions WordPress needs, and avoid sharing one broad database user across unrelated applications. A custom table prefix can reduce predictability a little, but it is not a serious security control by itself. This matters because when attackers pivot into database access, over-privileged accounts increase blast radius quickly. Good hygiene here is about limiting damage, not chasing myths. How to verify: Confirm database users are unique per environment and not granted broader privileges than necessary. Common mistakes: Treating a custom prefix as meaningful protection, reusing the same credentials across staging and production, or using a database superuser for convenience. 15. Pre-Launch Verification: Scan, Review, Then Monitor Before go-live, run a non-destructive review of the public site, fix the critical and high-priority issues, and plan recurring re-checks after meaningful changes. Hardening without verification becomes guesswork. Verification without ongoing cadence becomes stale quickly. This is the point where Vulnify fits naturally. Use the WordPress Security Scanner for a public WordPress-oriented review, or use the WordPress Stack Checker when you want a lighter check after plugin changes, theme updates, migration, or pre-release hardening. If the site is already live and you need the detection-oriented workflow rather than this configuration guide, follow the non-intrusive WordPress scanning guide . How to verify: Review findings, assign owners, rerun after fixes, and repeat after major site, plugin, or hosting changes. Common mistakes: Scanning once and never rerunning, treating a clean-looking homepage as proof the whole site is ready, or skipping verification after “small” plugin updates. Master Checklist Use this as a final pre-launch review list for your wordpress security checklist. Freeze scope, staging, backups, and deploy path Risk reduced: release drift and unrecoverable change Verify: restore test completed and staging matches intended production Core, themes, and plugins updated and cleaned Risk reduced: stale component exposure Verify: no unused themes or plugins remain installed Accounts and roles reviewed Risk reduced: unnecessary privileged access Verify: every account has an owner and correct role MFA enforced for admins Risk reduced: credential reuse and simple takeover Verify: fresh admin login requires second factor wp-login.php protected Risk reduced: brute-force abuse Verify: repeated failures are throttled or challenged XML-RPC reviewed Risk reduced: unnecessary legacy exposure Verify: needed integrations still work or endpoint is disabled wp-config.php hardened Risk reduced: sensitive configuration exposure Verify: unique salts, strong credentials, restricted access File editing disabled in production Risk reduced: dashboard-based code tampering Verify: theme and plugin editors unavailable File permissions tightened Risk reduced: post-compromise persistence Verify: only required directories are writable HTTPS enforced Risk reduced: weak transport and session exposure Verify: HTTP redirects cleanly and no mixed content remains Headers and cookie flags reviewed Risk reduced: browser-side exposure and weak session posture Verify: expected headers and cookie flags are present Information disclosure reduced Risk reduced: attacker reconnaissance speed Verify: debug off, directory listing off, no obvious leakage REST API and enumeration exposure understood Risk reduced: unnecessary public clues and data exposure Verify: only intended anonymous routes remain public Database hygiene reviewed Risk reduced: over-privileged backend access Verify: unique least-privilege DB user for production Pre-launch verification completed Risk reduced: false confidence before go-live Verify: public scan reviewed, fixes applied, rerun scheduled FAQ What is the difference between hardening and a vulnerability scan? Hardening is the work you do to reduce exposure through configuration, access control, deployment discipline, and operational choices. A vulnerability scan checks what is still observable or testable. You need both. Hardening lowers risk. Scanning helps verify what remains. Should I rename the default wp-admin URL? It can reduce noise, but it should not be your main defense. Real protection comes from MFA, rate limiting, strong credentials, and access controls. Treat URL changes as a minor friction layer, not a primary control. Do security plugins replace good server configuration? No. A plugin can help, but it cannot fully replace strong hosting, clean TLS behavior, sound permissions, edge-layer headers, backup discipline, and careful account management. Good WordPress site hardening is layered. Is XML-RPC safe to disable on every site? No. Many sites can disable it safely, but some still rely on it for specific integrations or legacy workflows. Test first in staging, then decide based on actual need rather than assumption. What is the minimum I should do the night before launch? At minimum, update and remove unused plugins and themes, review admin accounts, enforce MFA, confirm backups, force HTTPS, turn off debug mode, check permissions, and run a public verification scan. That will not make the site perfect, but it will remove many of the easiest mistakes. How often should I re-check hardening after launch? Re-check after plugin or theme changes, hosting changes, major content or workflow changes, and on a recurring schedule for important sites. WordPress security is not a one-time launch task. It is ongoing maintenance. Related Articles Non-Intrusive WordPress Vulnerability Scanning: How to Check Public Plugin, Theme, and Core Risk Safely WordPress Security Workflows WordPress Security Scanner WordPress Stack Checker WordPress Security Troubleshooting Conclusion Secure WordPress before launch by treating hardening as part of release engineering, not an optional cleanup task. If you apply these 15 checks consistently, you reduce wordpress attack surface, make later findings easier to act on, and give your launch a stronger security baseline from day one.