How to Secure a WordPress Website: The Complete Security Checklist

To keep your WordPress site safe in 2026, begin with the basics. Make sure you update regularly, use strong passwords, and back up your data. For extra protection, add hardening, firewalls, and monitoring. This checklist gives you a simple, practical plan based on expert advice that works for any site.

This guide will help you secure your WordPress site, whether you already have one or are building a new one. Follow each step and use the RoniPass – Security for WordPress plugin from Lab Tech to make sure you cover everything.

Core software hygiene

Keeping WordPress core, themes, and plugins up to date is the foundation for staying protected. Most hacks exploit known weaknesses in outdated software — vulnerabilities that are often publicly documented, making them easy targets for automated attack tools that scan thousands of sites at once. Enable automatic security updates for minor core releases, and schedule a weekly session to check for and apply plugin and theme updates. Treat this as a recurring calendar appointment rather than an ad hoc task so it doesn’t get overlooked during busy periods. Delete any themes or plugins you no longer use, as dormant code can still pose a security risk even when it isn’t actively running. Inactive plugins may still contain exploitable files on your server that attackers can access. If you installed a plugin solely to import data or products, disable and uninstall it once the task is complete. Remove unused themes, but keep the active theme, its parent theme if applicable, and one current default WordPress theme as an emergency fallback. Keeping your installation lean not only reduces your attack surface but also simplifies maintenance.

Accounts, passwords, and 2FA

Ensure that each account is protected by a strong, distinct password. Weak passwords remain one of the leading causes of CMS and WordPress security breaches. Avoid reusing passwords from other websites that may have been compromised. You can also verify your email address on the websites below:

• Have I Been Pwned
• Mozilla Monitor
• Malwarebytes Digital Footprint Scan

Use a password manager to generate and securely store long, complex, and entirely random passwords for all of your admin, editor, and hosting accounts. Relying on a password manager ensures that each account has a unique password, eliminating the dangerous habit of reusing credentials across multiple platforms. Passwords generated this way are far harder to crack than anything a human might create manually, since they typically combine random strings of letters, numbers, and special characters with no predictable pattern.

In addition to strong passwords, enable two-factor authentication (2FA) on all admin accounts using a dedicated security plugin. Tools like Google Authenticator add an essential second layer of protection, meaning that even if a password is somehow compromised, an attacker still cannot gain access without the secondary verification code. This single step dramatically reduces the risk of unauthorized logins.

Avoid using predictable or default usernames like “admin,” “administrator,” or your site’s name, as these are among the first guesses automated bots and brute-force attacks will try. Instead, choose a unique, non-obvious username that gives potential attackers no easy foothold.

Finally, make it a habit to regularly audit all user accounts associated with your site and hosting environment. Review who has access, what permission level they hold, and when they last logged in. Promptly remove or deactivate accounts belonging to former employees, freelancers, or contractors who no longer need access, and investigate any unfamiliar or suspicious accounts immediately. Keeping a clean and current user list is a simple but highly effective way to reduce your overall security exposure.

While you can’t dictate every user’s security practices, you do have control over their assigned roles. Implement the principle of least privilege by granting each user only the minimum permissions necessary — for example, assigning the editor role rather than the administrator role. The premium version of the RoniPass – Security for WordPress plugin allows you to verify whether a password has already been compromised in a data breach. It also provides options to activate 2FA, specify which user roles must use it, and either enforce it as a requirement for ongoing access or present it as an optional feature with a promotional incentive for customers.

Login page and brute‑force protection

Restricting the number of login attempts is one of the most effective and straightforward measures you can take to defend against brute-force and credential-stuffing attacks. By setting a threshold — typically between 3 and 5 unsuccessful login attempts per IP address — you can trigger a temporary lockout that prevents automated bots and malicious actors from repeatedly cycling through large lists of username-password combinations. Once the lockout period expires, legitimate users can try again, while persistent attackers will find their efforts significantly slowed or blocked entirely. You can also consider progressively increasing the lockout duration with each repeated violation, adding an additional layer of friction for bad actors.

Beyond limiting login attempts, consider replacing the default login URL (such as /wp-login.php or /wp-admin) with a custom, less predictable path via a trusted security plugin. Since these default URLs are widely known and among the first targets for automated attack scripts, changing them means the vast majority of bots will never even reach your login page. This security-through-obscurity approach works best as one layer within a broader security strategy rather than as a standalone solution.

Ideally, you should back all of this up with a robust edge service such as Cloudflare, which provides an additional layer of protection by filtering malicious traffic before it reaches your server. Cloudflare’s firewall rules, rate limiting, and bot management features complement your on-site login restrictions and help absorb large-scale attack traffic at the network level. For further information on how to configure this properly, refer to the article: What setup is needed for Cloudflare for a WordPress Website?

Implement CAPTCHA or reCAPTCHA on your login page and critical forms to hinder automated bot activity. Additionally, you can apply an extra HTTP authentication layer to the /wp-admin directory, preventing automated attacks from ever reaching the WordPress login screen. For pages that include forms, reCAPTCHA is the recommended option.

Hosting, server, and HTTPS

Choose a reliable managed WordPress host that offers server-level firewalls, malware scanning, and automatic patching. These features help make sure security updates are always applied, even if you miss them. Well-known hosts like Kinsta, WP Engine, and Pressable monitor their systems for threats and isolate each site to prevent problems from spreading if one account is compromised. Set up HTTPS everywhere by using a valid SSL/TLS certificate, such as Let’s Encrypt or a commercial option. Make sure all traffic goes over HTTPS by setting up a redirect from HTTP to HTTPS in your server settings or .htaccess file. This way, visitors never reach your site through an unencrypted connection, which keeps their data safe and helps your site look trustworthy.

Set up HSTS (HTTP Strict Transport Security) to instruct browsers to only ever connect to your site using HTTPS, even if a user types a plain HTTP address. This adds an important layer of protection against SSL-stripping attacks. Use modern TLS protocols such as TLS 1.3 if your host allows it, as older versions like TLS 1.0 and 1.1 contain known vulnerabilities and have been deprecated by major browsers. Additionally, fix any “mixed content” warnings, which occur when a page served over HTTPS still loads certain resources — such as images, scripts, or stylesheets — over HTTP. These warnings can undermine user trust and weaken your overall security posture. Tools like the browser developer console can help identify and resolve these issues.

Use SFTP or SSH instead of plain FTP when transferring files to your server. Standard FTP transmits credentials and data in plain text, making it trivially easy for an attacker on the same network to intercept your login details. SFTP and SSH encrypt the entire session, including authentication. Beyond that, harden your SSH configuration by disabling password-based authentication in favor of SSH key pairs, changing the default SSH port to reduce automated brute-force attempts, and restricting SSH access to specific trusted IP addresses where possible. Turn off any unnecessary services running on your server, as each open port or active service represents a potential attack surface that a threat actor could exploit.

File system hardening

Set file permissions to 644 for files and 755 for directories; this is widely recommended as a secure baseline for WordPress installs and strikes the right balance between accessibility and protection. These settings ensure that files are readable by the web server but not writable by unauthorized users, while directories remain traversable without being openly writable. RoniPass – Security for WordPress plugin checks the permissions of all pages and flags any files or directories that deviate from these recommended settings, making it easy to identify and correct potential vulnerabilities at a glance.

Set stricter permissions on wp-config.php (such as 440 or 400) and, if possible, move it one directory above the public web root. Since wp-config.php contains your database credentials, secret keys, and other sensitive configuration data, it is one of the most critical files to protect on your entire server. A permission of 400 makes the file readable only by the owner, while 440 allows both the owner and group to read it — neither setting permits any form of writing or public access.

Disable file editing in the WordPress admin by adding define('DISALLOW_FILE_EDIT', true); to wp-config.php. This removes the built-in theme and plugin editor from the WordPress dashboard entirely, which means that even if an attacker gains admin-level access to your site, they will be unable to inject malicious code directly into your theme or plugin files through the browser interface.

Disable directory browsing and listing in your web server configuration or via .htaccess to prevent attackers from enumerating files. When directory listing is enabled, anyone who visits a folder without an index file can see a full list of its contents — including sensitive scripts, backup files, or configuration data. Adding Options -Indexes to your .htaccess file is a simple and effective way to close this gap on Apache-based servers.

Block direct PHP execution in the uploads directory using .htaccess or server rules to reduce the impact of malicious file uploads. The uploads directory is intentionally writable, which makes it a common target for attackers who attempt to plant executable PHP scripts disguised as images or other media files. By denying direct PHP execution in this folder, you ensure that even if a malicious file is successfully uploaded, it cannot be run by simply accessing its URL — significantly limiting the damage an attacker can do.

Database and configuration security

Use a strong, randomly generated database password — ideally a long string of mixed characters, numbers, and symbols — and restrict the database user to only the WordPress database with the minimal privileges required (typically SELECT, INSERT, UPDATE, and DELETE). Avoid granting broad permissions like DROP or ALTER unless absolutely necessary for a specific maintenance task. Change the default table prefix (wp_) on new installs to a custom, unpredictable string, which helps reduce automated SQL injection attacks targeting common, well-known table names used by WordPress installations. A custom prefix provides minor obscurity but should not be treated as protection against SQL injection.

Use a dedicated database user restricted to the WordPress database. Advanced administrators may temporarily reduce schema-changing privileges between upgrades, but this can break updates and plugin installation.

Disable remote database access unless it is absolutely necessary for your setup, since exposing your database port to the internet significantly increases your attack surface. If remote access is required, restrict it to specific trusted IP addresses using firewall rules rather than leaving it open to all connections. Additionally, consider enabling encryption at rest for your database files if your hosting provider supports it, adding another layer of protection in the event of physical or lower-level server compromise.

Keep all sensitive secrets — including API keys, authentication salts, passwords, and third-party service credentials — entirely out of your plugins and themes. These files are far more likely to be inadvertently exposed through version control repositories, backups, or misconfigured file permissions. Where possible, store secrets in environment variables that are set at the server level, or confine them to wp-config.php only, ensuring that the file is placed outside the public web root and has appropriately restrictive file permissions (such as 400 or 440). Regularly rotate your salts and keys, especially after a suspected compromise or when team members with access leave your organization.

Plugins, themes, and third‑party code

Treat plugins and themes as your main attack surface, since plugin vulnerabilities account for the vast majority of WordPress security issues — some estimates put the figure at over 90% of all WordPress compromises. When selecting plugins or themes, install only well‑maintained, reputable options that have a strong track record of recent updates, responsive developers, and active community support. Before installing anything, check the last updated date, the number of active installations, and the support forum response rate in the WordPress repository; these signals can help you quickly identify projects that may be abandoned or poorly maintained.

Regularly audit your plugin list with a critical eye, removing any abandoned plugins that are no longer receiving security patches, as outdated code can become a liability even if the plugin is simply deactivated rather than fully deleted. Deactivated plugins still exist on your server and can still be exploited in certain scenarios, so removing them entirely is the safer approach. Beyond weeding out abandoned tools, aim to minimize the total number of active plugins across the board — every additional plugin introduces new code, potential conflicts, and additional entry points for attackers, so only keep what genuinely serves a clear purpose.

Keep a dedicated staging site that mirrors your production environment as closely as possible, and use it to thoroughly test plugin and theme updates, major configuration changes, and new installations before pushing anything live. This practice not only helps you catch compatibility issues and unexpected behavior before they affect real users, but also provides a controlled environment to observe how changes interact with your existing setup — reducing both security risks and unplanned downtime.

REST API, XML‑RPC, and API security

Disable XML-RPC unless you specifically need it for Jetpack, legacy third-party integrations, or the WordPress mobile app, as it is a common target for brute-force attacks and DDoS amplification attempts. Attackers routinely probe XML-RPC endpoints to test credential combinations at scale, often using the system.multicall method to submit hundreds of login attempts in a single request. If you do not actively use a mobile app or rely on any XML-RPC-dependent integrations, make absolutely sure it is disabled — there is no benefit to leaving it exposed. Numerous security plugins, such as Wordfence or iThemes Security, offer a simple toggle to disable it, or you can block access at the server level via your .htaccess file or Nginx configuration.

Limit REST API user enumeration by filtering or blocking unauthenticated access to the /wp-json/wp/v2/users endpoint. This endpoint, when left open, allows anyone to harvest a list of valid WordPress usernames, which can then be used as the first step in a targeted brute-force attack. Restricting this endpoint to authenticated users only significantly raises the barrier for attackers. If you expose custom REST API endpoints as part of your theme or plugin functionality, make sure to validate and sanitize all inputs rigorously to prevent injection attacks, use nonces for authenticated requests to guard against cross-site request forgery (CSRF), and implement rate-limiting on API calls to prevent abuse and resource exhaustion.

Secure external API keys and secrets — such as those used for payment gateways, analytics platforms, email services, or social media integrations — by keeping them entirely outside version control and any publicly accessible code. Never hardcode sensitive credentials directly into theme or plugin files that may end up committed to a Git repository. Instead, store them in environment variables or in the wp-config.php file, which should itself be properly protected and excluded from any public repository. Leaked API keys can lead to unauthorized charges, data breaches, and service abuse, so treating them with the same care as passwords is essential.

Backups and recovery

Configure automated daily backups of both your files and database, and establish multiple retention points — for example, keeping daily backups for the past week, weekly backups for the past month, and monthly backups for the past year. This layered approach ensures you always have a recent restore point without consuming excessive storage, and gives you flexibility to roll back to a specific moment in time depending on the nature of the problem.

Store all backups off‑site in a location that is completely separate from your primary server — such as a dedicated backup server, or cloud storage solutions like Amazon S3, Google Drive or Dropbox. This is a critical safeguard: if your primary server is compromised by a hack, ransomware, or a catastrophic hardware failure, having backups stored on the same machine could mean you lose everything simultaneously. Off‑site storage ensures your recovery data survives independently of whatever happens to your live environment.

Regularly test backup restoration on a staging server or local development environment — do not wait until a real emergency to discover that your backups are incomplete, corrupted, or incompatible with your current setup. Schedule periodic restoration drills, such as once a month or after any major site change, to verify that you can fully recover your site within an acceptable timeframe. A backup you have never tested is a backup you cannot truly rely on.

Use reputable, well‑maintained backup plugins or host‑provided solutions to handle the process. Popular options include UpdraftPlus, BackupBuddy, Duplicator Pro, RoniPass, and many managed hosting providers that offer built‑in snapshot tools that run automatically on a schedule. Whichever solution you choose, configure alerts or notifications so you are immediately informed of any failed backup jobs. A missed backup that goes unnoticed can leave you dangerously exposed, so active monitoring is just as important as the backup process itself.

Monitoring, logging, and alerts

Install a dedicated security plugin that offers comprehensive protection features, including malware scanning, login monitoring, and file integrity checks. Popular and well-regarded options include RoniPass, Wordfence, Sucuri, and Solid Security (formerly iThemes Security), each of which provides a robust suite of tools to help detect and respond to threats before they escalate into serious problems. Take time to configure these plugins properly rather than relying on default settings, as a well-tuned security plugin is significantly more effective than one left at its out-of-the-box configuration.

Enable detailed activity logging using a dedicated solution such as WP Activity Log, RoniPass, or a similar plugin. This gives you a comprehensive, timestamped record of everything happening on your site, including changes to plugins and themes, content edits, user login and logout events, and modifications to settings or user roles. This audit trail is invaluable not only for identifying malicious activity but also for diagnosing accidental changes made by legitimate users or contributors.

Set up real-time alerts so that you are immediately notified of high-priority security events rather than discovering them hours or days later. Key triggers to monitor and alert on include successful admin logins originating from new or unrecognized IP addresses, any installation, activation, deactivation, or deletion of plugins or themes, and suspected malware findings flagged during automated scans. Prompt notification allows you to investigate and respond quickly, dramatically reducing the potential damage from a compromised account or injected malicious code.

Finally, implement uptime monitoring and SSL certificate monitoring to ensure your site remains accessible and secure for visitors at all times. Uptime monitoring will alert you the moment your site goes offline, allowing you to address hosting issues, server errors, or the aftermath of an attack without delay. SSL monitoring ensures you are notified well in advance of certificate expiration, preventing the trust warnings and potential traffic loss that come with a lapsed certificate.

Security headers and content protection

Add HTTP security headers such as X-Frame-Options, X-Content-Type-Options, and Referrer-Policy via server config or a plugin. These headers act as a first line of defense by instructing browsers on how to handle your content — for example, X-Frame-Options prevents your site from being embedded in iframes on other domains (protecting against clickjacking attacks), while X-Content-Type-Options stops browsers from MIME-sniffing responses away from the declared content type. Most of these headers can be added directly in your web server configuration (such as Apache’s .htaccess or an Nginx server block), or through a dedicated security plugin if you’re working with a CMS like WordPress. Implement a Content Security Policy (CSP) to control which domains can serve scripts, styles, and media on your site. A well-crafted CSP is one of the most powerful tools available for mitigating cross-site scripting (XSS) attacks, as it explicitly whitelists trusted sources and blocks everything else — preventing malicious scripts from being injected and executed even if an attacker finds a vulnerability. Start CSP in “report‑only” mode to avoid breaking functionality, then gradually tighten to an enforcing policy. In report-only mode, violations are logged and sent to a designated reporting endpoint without actually blocking any resources, giving you a clear picture of what would be affected before you commit to enforcement. This phased approach allows you to identify legitimate third-party dependencies — such as analytics scripts, font providers, or ad networks — and add them to your allowlist before switching the header from Content-Security-Policy-Report-Only to the fully enforcing Content-Security-Policy.

Spam, bots, and abuse control

Use Akismet or similar anti-spam tools such as CleanTalk or Antispam Bee to significantly reduce comment spam before it ever reaches your moderation queue. You should also consider disabling comments entirely on older posts — anything beyond a certain age threshold, such as six months or a year — since these older entries tend to attract the most spam while generating very little legitimate discussion. This simple step alone can dramatically reduce your overall spam surface area.

On your forms, deploy honeypot fields — hidden input fields that real users will never fill in but that automated bots reliably trigger — alongside rate limiting to slow down or block repeated automated submissions from the same IP address or session. Adding CAPTCHA challenges as a secondary layer, particularly on high-value forms like registration or checkout, can provide additional friction against bot activity.

At the infrastructure level, maintain and regularly update a blocklist of known malicious user agents to reject suspicious requests before they even reach your application. For more robust and scalable protection, consider implementing dedicated bot management solutions at the CDN or WAF (Web Application Firewall) layer, such as those offered by Cloudflare, Fastly, or AWS. These services can identify and filter out malicious automated traffic in real time using behavioral analysis and threat intelligence feeds, reducing the load on your origin server while keeping your forms and comment sections cleaner and more secure.

Incident response basics

If you suspect your site has been compromised, the very first step is to take it offline or switch it into maintenance mode immediately. This prevents further damage, stops the spread of any malicious code to your visitors, and gives you a controlled environment in which to work. Once the site is safely offline, reapply all core, plugin, and theme updates, since outdated software is one of the most common entry points for attackers, and patching everything closes known vulnerabilities right away.

Next, run a full malware scan using a reputable security plugin or service — tools like Wordfence, Sucuri, or MalCare are well-regarded options that can detect injected code, backdoors, and suspicious file modifications. Alongside the scan, compare your current file integrity against a clean baseline or a freshly downloaded copy of WordPress core and your plugins. Any files that differ unexpectedly should be treated as potentially compromised and replaced.

Thoroughly audit all admin and editor accounts for unauthorized or unfamiliar users, as attackers frequently create hidden backdoor accounts to maintain persistent access even after a cleanup. Remove any accounts that shouldn’t be there. Rotate all passwords across the board — this includes your WordPress admin credentials, database passwords, FTP and hosting account passwords, and any connected third-party services. Don’t overlook regenerating your WordPress security keys and salts, which invalidates all existing sessions and forces everyone to log back in fresh.

Finally, dig into your server access logs for at least the previous 30 days to trace the attacker’s entry vector. Look for unusual POST requests, repeated login attempts, or requests targeting specific plugin or theme files. Once you’ve identified exactly how the breach occurred — whether it was a vulnerable plugin, a weak password, an exposed configuration file, or something else — take targeted action to close that specific hole so the same attack cannot be repeated.

In summary, make sure your website is protected in every area: server, CDN, firewall, and by keeping plugins, themes, and the core updated. Each of these layers plays a critical role in forming a comprehensive defense against potential threats. Your server should be properly configured and hardened to prevent unauthorized access, while a CDN helps distribute traffic and absorb malicious attacks such as DDoS attempts before they ever reach your origin server. A well-configured firewall acts as a gatekeeper, filtering out suspicious requests and blocking known malicious IP addresses from interacting with your site. Meanwhile, keeping your plugins, themes, and core software updated ensures that known vulnerabilities are patched promptly, closing off entry points that attackers commonly exploit. Outdated software is one of the most frequent causes of successful breaches, so establishing a regular update schedule is essential. Combining all of these steps creates a multi-layered security strategy that is far more effective than relying on any single measure, significantly increasing your website’s overall security and resilience against both common and sophisticated attacks.

WordPress Security Checklist (2026): 163 Steps to Secure Your Site

Based exclusively on the WPLabTech article.

FAQ