WordPress Security Best Practices: A Complete Guide for Business Websites

WordPress powers 43% of the internet, which makes it the single most targeted content management system in the world. The attacks are automated, continuous, and indiscriminate. Bots scan every IP range on the internet looking for unpatched WordPress installations, exposed login pages, and outdated plugins. Your site’s traffic level and revenue are irrelevant to these scanners. What matters to attackers is whether your installation is exploitable.

The good news is that a secured WordPress site is genuinely difficult to compromise. The businesses that experience WordPress security incidents almost always share one of three vulnerabilities: they run outdated software, they use weak authentication, or they install plugins without vetting them. Eliminating those three exposure points addresses the vast majority of real-world WordPress attacks.

This guide covers every security layer a business WordPress website needs, from hosting environment hardening through active threat monitoring, ordered by the impact each measure delivers.

Why WordPress Security Requires Active Management

WordPress security is not a one-time configuration task. It is an ongoing operational discipline. Every plugin, theme, and WordPress core release introduces either new functionality or patches to discovered vulnerabilities. The window between a vulnerability being publicly disclosed and automated attacks targeting that vulnerability has shrunk to hours in many cases.

Business websites carry specific security stakes beyond the technical inconvenience of a compromise. A hacked site loses search ranking through Google’s manual action system, which flags hacked sites and suppresses them in search results. Visitor data exposure creates legal liability under GDPR, CCPA, and equivalent regulations. Pharma hacks, which inject hidden links to spam sites into your content, damage your domain authority in ways that take months to recover from, even after the malware is removed.

Understanding what you are protecting against shapes how you prioritize each security measure. The four most common WordPress attack types are brute force attacks against the login page, exploitation of known plugin and theme vulnerabilities, SQL injection through unvalidated form inputs, and cross-site scripting through user-generated content. The practices below address all four categories systematically.

Start With a Secure Hosting Environment

Your hosting environment is the foundation every other security measure builds on. A WordPress site hosted on a poorly configured shared server inherits the security vulnerabilities of every other site on that server. One compromised neighboring account can expose your file system if server isolation is inadequate.

Managed WordPress hosting providers like WP Engine, Kinsta, and Cloudways implement server-level security configurations that shared hosting cannot match: isolated containers per account, server-side malware scanning, automatic WordPress core updates, and Web Application Firewall rules at the network edge. These controls eliminate entire categories of attack before a request reaches your WordPress installation.

For businesses evaluating their hosting options, our guide to the best web hosting for small business websites covers the security capabilities of major providers alongside performance and pricing. The comparison between shared hosting and VPS hosting is particularly relevant for security considerations, since VPS environments provide the account isolation that shared hosting cannot.

Businesses with higher traffic or more complex infrastructure requirements should read the guide to managed VPS hosting, which covers the providers that combine root access flexibility with managed security services. At this tier, you gain firewall configuration control, intrusion detection systems, and dedicated IP addresses that shared hosting does not offer.

File permissions at the server level are a foundational security control regardless of your hosting tier. WordPress directories should be set to 755 permissions and WordPress files to 644. The wp-config.php file, which contains your database credentials and security keys, warrants tighter permissions at 600 or 640. Files set to 777 (full read, write, and execute for all users) are a critical vulnerability that attackers specifically look for.

Keep WordPress Core, Themes, and Plugins Updated

Outdated software is the leading cause of successful WordPress compromises. The WordPress security team releases patches promptly when vulnerabilities are discovered. Plugin developers issue security updates when researchers disclose issues in their code. The interval between a patch being released and automated scanning targeting unpatched installations is measured in hours, not days.

Enable automatic background updates for WordPress core minor releases (security and maintenance releases). Major version upgrades benefit from manual review on a staging environment first, but minor patches should apply automatically. The risk of running unpatched known vulnerabilities is substantially higher than the risk of a minor update introducing a conflict.

For plugins and themes, establish a weekly update review. The WordPress dashboard shows pending updates clearly. Before applying plugin updates on a production site, check the plugin’s changelog for breaking changes and verify the update was released within the past few weeks (very recent releases occasionally carry introduced bugs that a subsequent patch quickly fixes).

Deactivate and delete plugins you do not actively use. An inactive plugin’s files remain on your server and carry the same vulnerability exposure as an active one. Plugin authors do not send security alerts to sites with their plugin deactivated. If you do not need the functionality, remove the plugin entirely.

This same discipline applies to themes. Your active theme and one backup theme are the only themes your server needs. Every additional theme installed but unused represents unnecessary attack surface. Delete all unused themes from the WordPress dashboard, not just deactivate them.

Plugin selection based on update frequency and developer responsiveness is a security decision, not just a feature decision.

Implement Strong Authentication Across All User Accounts

Brute force attacks against the WordPress login page are the most common form of automated attack against WordPress installations. Bots systematically try username and password combinations until they find credentials that work. Two controls stop brute force attacks completely: strong, unique passwords and two-factor authentication.

Every WordPress administrator account needs a password generated by a password manager: at least 20 characters, mixing uppercase letters, lowercase letters, numbers, and symbols, unique to that account and not reused anywhere else. Browser-based password managers like Bitwarden (free and open source) or 1Password make generating and storing these credentials frictionless.

Two-factor authentication (2FA) makes a stolen password insufficient for account access. Even if an attacker obtains your administrator credentials through phishing or a data breach at another service, they cannot log in without the time-based one-time password generated by your authenticator application. Plugins like WP 2FA and Google Authenticator for WordPress implement this control cleanly without requiring developer involvement.

Change the default WordPress administrator username. The default “admin” username is the first value automated brute force tools try. If your administrator account still uses “admin” as its username, create a new administrator account with a different username, assign your content to the new account, and delete the original admin account.

Review your WordPress user roles critically. Contributors do not need editor access. Editors do not need administrator access. The principle of least privilege applies directly: every user account should have only the permissions its role requires. Administrator access should be limited to the minimum number of accounts that genuinely need it.

Protect the WordPress Login Page

The wp-login.php file is the default entry point for all WordPress administrator access. Because its location is known and predictable, it receives continuous automated attack traffic. Several controls reduce this exposure substantially.

Limiting login attempts is the foundational control. Plugins like Limit Login Attempts Reloaded or the login protection included in security suites like Wordfence and WP Cerber block IP addresses that exceed a configured number of failed login attempts within a time window. A setting of five failed attempts before a 30-minute lockout stops the vast majority of automated brute force campaigns.

Changing the login URL from the default /wp-login.php to a custom path eliminates a significant volume of automated traffic. Plugins like WPS Hide Login or the login URL customization in iThemes Security (now rebranded as SolidSecurity) make this change without touching theme or plugin files. Note that changing the login URL is a security-through-obscurity measure rather than a true technical control, so it works best combined with login attempt limiting and 2FA rather than as a standalone protection.

Adding HTTP authentication to the login page (a browser-level username and password prompt before the WordPress login form even loads) provides a strong additional layer for sites where all administrators access the backend from known IP addresses or are comfortable managing the additional credentials.

For administrator accounts that always log in from consistent IP addresses, IP allowlisting through your hosting control panel or a security plugin restricts login page access to those addresses entirely. This makes the login page inaccessible to any other IP, which stops brute force attacks at the network level rather than at the application level.

Install and Configure a WordPress Security Plugin

A dedicated WordPress security plugin provides automated malware scanning, file change detection, firewall rules, and login protection through a single interface. The three leading options each serve different user profiles.

Wordfence Security is the most widely deployed WordPress security plugin. Its free tier includes a Web Application Firewall (WAF), malware scanner, login security controls, and real-time threat intelligence from its network of protected sites. Wordfence Premium adds real-time firewall rule updates and access to its IP reputation database, which blocks known malicious addresses before they interact with your site.

Sucuri Security approaches protection differently. Its plugin handles WordPress-side security monitoring and post-compromise cleanup assistance, but its primary protection mechanism is a DNS-level Web Application Firewall that routes your traffic through Sucuri’s network before it reaches your server. This architecture blocks attacks before they reach WordPress entirely. Sucuri’s firewall is a paid service, but its plugin provides valuable monitoring capabilities at no cost.

WP Cerber Security has gained a strong reputation among developers for its granular control over login protection, user activity logging, and anti-spam measures. Its traffic inspection and bot protection capabilities complement its malware scanning to provide comprehensive coverage.

Install one security plugin and configure it thoroughly rather than running multiple competing products. Security plugins that both implement firewall rules can conflict and produce errors. Choose based on your hosting environment: sites on managed WordPress hosting often have server-level WAF already in place, which makes Wordfence’s firewall rules redundant; in this case, Sucuri’s monitoring plugin or WP Cerber’s login protection focuses better on what managed hosting does not already cover.

Secure Your wp-config.php File

The wp-config.php file contains your database name, database username, database password, and WordPress security keys. Compromising this file gives an attacker complete access to your database and the ability to generate valid authentication cookies for any user account.

Move wp-config.php one directory level above your WordPress root installation. WordPress automatically finds it at this location, but web servers do not serve files from above the web root, making the file inaccessible to direct HTTP requests.

Add the following rule to your .htaccess file to block all direct HTTP access to wp-config.php as an additional control:

<files wp-config.php>
order allow,deny
deny from all
</files>

Replace the default WordPress security keys and salts in wp-config.php with freshly generated values from the WordPress secret key generator at api.wordpress.org/secret-key/1.1/salt. These keys are used to encrypt authentication cookies. After any suspected compromise, regenerating these keys invalidates all existing sessions immediately, logging out every user, including any attacker maintaining persistent access through a stolen session cookie.

Disable XML-RPC When You Do Not Need It

WordPress’s XML-RPC interface was designed to allow remote publishing from desktop applications and mobile clients. Most business websites do not use it. In its default enabled state, XML-RPC allows brute force attacks to test thousands of username and password combinations in a single HTTP request, bypassing login attempt limiting controls that operate at the wp-login.php level.

Disable XML-RPC entirely if you do not use remote publishing applications or Jetpack. The Disable XML-RPC plugin handles this cleanly. Alternatively, the following .htaccess rule blocks all XML-RPC requests at the server level:

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

If you use Jetpack (which requires XML-RPC), configure your security plugin to block XML-RPC requests from all sources except Jetpack’s known IP ranges.

Implement SSL Across Your Entire Website

HTTPS encryption is both a security requirement and a Google ranking signal. An SSL certificate encrypts all data transmitted between your visitors’ browsers and your server, protecting form submissions, login credentials, and session data from interception.

Most hosting providers include free SSL certificates through Let’s Encrypt. Verify that your certificate is installed, that your WordPress site URL is configured to use HTTPS in Settings > General, and that HTTP requests are permanently redirected to HTTPS through an .htaccess rule or your hosting control panel. Mixed content warnings (secure pages loading insecure resources) undermine the protection SSL provides and create browser warning messages that damage visitor trust.

The best infrastructure tools for business websites guide covers SSL certificate management alongside the other technical foundations that business websites require for reliable, secure operation.

Monitor Your Website for Threats and Downtime

Active monitoring detects security incidents faster than manual checks. Your monitoring stack should cover three categories: uptime monitoring to detect when your site becomes unavailable (which can indicate a successful attack), file change monitoring to detect unauthorized modifications to theme and plugin files, and log monitoring to identify unusual traffic patterns or repeated attack attempts.

Our guide to website and server monitoring tools covers the monitoring platforms that provide real-time alerts for availability, performance, and security anomalies. Uptime Robot, Better Uptime, and StatusCake offer credible free tiers for availability monitoring. Wordfence’s file change detection and WP Activity Log for administrator activity tracking cover the WordPress-specific monitoring layer.

For businesses that publish status information for customers or stakeholders, our coverage of status page software for SaaS and online businesses identifies tools that communicate outages and maintenance windows professionally while your team resolves incidents.

Unusual traffic patterns sometimes indicate attack activity before a compromise occurs.  Detecting bot traffic in Google Analytics is the behavioral signals that distinguish malicious bot traffic from legitimate crawler activity and outlines the response steps for each traffic type.

Maintain Regular Off-Site Backups

Backups are your recovery mechanism when prevention fails. A recent, tested, off-site backup is the difference between recovering from a compromise in two hours and losing weeks of work. Backups stored on the same server as your WordPress installation are compromised alongside the site in a successful attack.

UpdraftPlus is the standard for WordPress backup management. Its free version covers scheduled backups to remote destinations, including Google Drive, Dropbox, Amazon S3, and Microsoft OneDrive. Configure daily backups for active business sites, keeping a minimum of 30 days of backup history. Before relying on your backup system, restore a backup to a staging environment to confirm the restoration process works correctly.

Test your backup restoration process quarterly. A backup you have never tested restoring is a backup you cannot rely on when you need it most.

Respond to a Compromise Correctly

If your WordPress site is compromised, the response sequence matters as much as the response speed. Acting without a clear process often results in incomplete cleanup that allows reinfection within days.

The correct response sequence: take the site offline or into maintenance mode immediately to prevent visitors from being exposed to malware. Contact your hosting provider to request a server-level malware scan and to understand the extent of the compromise. Use Sucuri’s free SiteCheck tool or Wordfence’s scanner to identify infected files. Restore from a clean backup if one predates the compromise and you can identify when the compromise occurred. If restoring from backup is not possible, use Sucuri’s or Wordfence’s malware cleanup service to remove injected code professionally.

After cleanup, regenerate your wp-config.php security keys, reset all administrator passwords, revoke and reissue all application passwords and API keys, and audit your plugin and theme versions to identify and update the vulnerability that enabled the compromise.

Submit a reconsideration request through Google Search Console if your site received a manual action notification for hacked content. Google removes manual actions within days of a verified clean site, but the request must be submitted with documentation of the cleanup steps taken.

Build Security Into Your WordPress Foundation

The most effective WordPress security posture is one built into the foundation of your site rather than added reactively after a problem occurs. The practices in this guide, applied at launch and maintained consistently, produce a site that resists the automated attacks that compromise less disciplined installations.

For businesses building or rebuilding their WordPress foundation, start with the theme and plugin selection process. Our complete guide to the best WordPress themes and plugins for business websites covers security-relevant selection criteria alongside design and functionality evaluation. Themes and plugins built by developers with strong security track records and active update histories reduce your ongoing security maintenance burden from the start.

Security and performance are complementary disciplines on WordPress. A fast site and a secure site share the same foundation: clean code, minimal plugin overhead, quality hosting, and active maintenance.

WordPress business websites that implement these practices consistently operate securely. The investment is real but modest: roughly two to four hours per month of update review, monitoring checks, and backup verification. That time commitment is trivially small compared to the cost of recovering from a preventable security incident.