Securing WordPress is less about hiding that you use WordPress and more about controlling the ways a site can actually be compromised. Keep vulnerable software off the server, protect administrator access, reduce what PHP can execute, filter hostile traffic, watch for known vulnerabilities and malware, and make sure you can recover if something still goes wrong.

Quick answer: If you only do a few things, keep WordPress and every installed plugin and theme updated, remove software you do not use, require 2FA for administrators, use a firewall, keep tested off-site backups, monitor vulnerabilities, and scan for malware. Hardening settings are useful, but they should support those controls rather than replace them.

If you already see redirects, unknown administrators, spam pages, malware warnings, or suspicious files, secure the site after it has been cleaned. Hardening a compromised WordPress installation does not remove an existing backdoor. Start with our WordPress malware removal guide.

1. Start with secure WordPress hosting

Your WordPress security starts below WordPress itself. The host controls the operating system, web server, PHP environment, account isolation, networking, and part of your backup and recovery infrastructure.

A host suitable for a production WordPress site should provide:

  • supported PHP and server software;
  • timely security patching;
  • HTTPS support;
  • reliable backup and recovery options;
  • proper account isolation on shared hosting;
  • secure SFTP or SSH access;
  • firewall or abuse protection at the server or network layer;
  • clear support procedures when an account is compromised.

Cheap shared hosting is not automatically insecure, and a VPS is not automatically safer. What matters is how the environment is maintained and isolated. A poorly managed VPS can be much riskier than a properly maintained shared server.

Protect the hosting account itself as well. Use a unique password, enable 2FA with the hosting provider, remove old FTP accounts and SSH keys, and avoid plain FTP when SFTP or SSH is available.

Keep database access private unless there is a specific reason to expose it remotely. Use a dedicated database account for WordPress and avoid granting permissions beyond what the site actually requires.

2. Keep WordPress, plugins, themes, and PHP current

For most WordPress sites, reducing vulnerable code is one of the highest-value security steps you can take.

Keep current:

  • WordPress core;
  • active plugins;
  • active themes;
  • PHP and other server software you manage.

Do not stop at updating active software. Remove plugins and themes you no longer use. A deactivated plugin is still PHP code sitting on the server, and a vulnerability in that code does not become harmless just because the plugin is inactive.

Be equally careful about where software comes from. Avoid nulled, cracked, or repackaged commercial plugins and themes. In malware cleanup work, modified premium software is a recurring source of backdoors and reinfection because you cannot reliably know what was added to the package.

Automatic updates can be useful for low-risk components, but business-critical sites should still have a process for checking compatibility and responding quickly to important security releases.

SiteFort monitors WordPress core, plugins, and themes for known vulnerabilities so outdated or affected components are easier to identify before they become an incident.

3. Protect administrator accounts and reduce access

A secure server does not help much if someone can log in as an administrator.

Start with the accounts that can install plugins, change settings, edit users, or modify the site:

  • require two-factor authentication for administrators;
  • use unique, strong passwords;
  • check passwords against known breach data where possible;
  • limit repeated login attempts;
  • remove administrators who no longer need access;
  • give users the lowest role required for their work;
  • review old Application Passwords and revoke integrations that are no longer used.

Do not create an Administrator account for someone who only needs to edit pages. Least privilege matters because a compromised Editor account and a compromised Administrator account have very different consequences.

CAPTCHA and a custom login URL can reduce automated login noise, but neither should be treated as the main defense. Strong credentials, 2FA, rate limiting, and sensible account permissions matter more.

SiteFort includes 2FA, login attempt protection, CAPTCHA, safer login responses, breached-password checks, password policies, lockout controls, and optional custom login URLs.

4. Keep backups that survive a compromise

Backups are part of security, not just disaster recovery.

A useful WordPress backup should include both the database and the files needed to rebuild the site. More importantly, at least one copy should live somewhere other than the same hosting account.

If an attacker compromises the hosting account, deletes local backups, or damages files, a backup stored only inside that account may disappear with everything else.

For important sites:

  • keep automatic backups on a sensible schedule;
  • retain more than one restore point;
  • store a copy off-site;
  • protect the backup account with 2FA;
  • test that a backup can actually be restored;
  • take a fresh backup before major updates or remediation.

A backup is only useful when you know where it is, how old it is, and how to restore it.

5. Use a WordPress firewall and control automated traffic

Public WordPress sites are continuously scanned. Typical traffic includes login attempts, vulnerability probes, requests for exposed backup files, fake crawlers, XML-RPC abuse, repeated 404 scanning, and requests looking for common sensitive paths.

A firewall helps reject that traffic before vulnerable or expensive application code has a chance to handle it.

Useful WordPress firewall controls include:

  • IP and CIDR blocking;
  • rate limiting;
  • login and authentication abuse detection;
  • sensitive-file and backup probes;
  • 404 scanner detection;
  • bad bot and user-agent controls;
  • country rules where appropriate;
  • temporary blocking for repeat offenders.

If the site runs behind Cloudflare, some blocks can be enforced even earlier. SiteFort’s Cloudflare Sync can move supported firewall rules and temporary escalated blocks to Cloudflare so matching requests are stopped before reaching the WordPress server.

That does not replace the local firewall. Cloudflare and WordPress see different signals. WordPress has application context, while Cloudflare is better positioned to enforce supported decisions at the edge.

For a deeper explanation, see WordPress Firewall with Cloudflare: Stop Bots Before WordPress.

6. Harden the parts of WordPress that should not be exposed

Hardening is useful when it removes an unnecessary capability or stops a request at a safer layer. It is less useful when it simply hides cosmetic evidence that a site uses WordPress.

For most production sites, prioritize these controls:

  • disable the built-in plugin and theme file editor;
  • block PHP execution inside upload directories;
  • prevent public access to sensitive files and backup artifacts;
  • disable directory listing;
  • protect debug logs and development files;
  • block direct execution paths that the site does not require.

Disable the WordPress file editor

If an attacker gains access to a sufficiently privileged administrator account, the built-in theme and plugin editor gives them another way to modify PHP from the dashboard.

Add this to wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

This does not prevent normal deployment through Git, SFTP, SSH, or your hosting tools.

Block PHP execution in uploads

wp-content/uploads normally contains media and documents. WordPress does not need to execute arbitrary PHP files from this directory.

That makes upload-directory execution an important hardening boundary. If malicious PHP is somehow written into uploads, the web server should not make it directly executable.

The exact rule depends on Apache, Nginx, LiteSpeed, managed hosting, and the way PHP is configured. Apply the control at the server layer where possible and verify it after deployment rather than blindly copying a rule written for another environment.

SiteFort’s server hardening includes verified controls for PHP execution in uploads, sensitive-file access, directory listing, direct PHP access, XML-RPC policy, and other common WordPress exposure points.

7. Get file ownership and permissions right

File permissions matter, but the common advice to simply set every directory to 755 and every file to 644 leaves out the most important part: ownership and the way PHP runs on that server.

A common baseline is:

  • directories around 755;
  • files around 644;
  • wp-config.php more restrictive where the hosting setup supports it.

Those numbers are not universal. The correct setup depends on the owner, group, PHP handler, deployment process, and whether WordPress needs write access for uploads or updates.

The goal is simple: PHP and the web server should only be able to write where the application genuinely needs write access.

Avoid recursively changing permissions or ownership across a production account unless you understand the host’s security model. Incorrect ownership can break updates and uploads or, worse, make files writable by users or processes that should not be able to modify them.

8. Secure XML-RPC, the REST API, and Application Passwords based on actual use

Older hardening guides often recommend disabling entire WordPress interfaces. That can improve security on one site and break another.

XML-RPC

xmlrpc.php is still used by some publishing tools, integrations, and services. If nothing on your site requires it, disabling XML-RPC reduces an unnecessary public endpoint.

If it is required, keep it available and protect it with rate limiting and firewall controls. Disabling pingbacks while retaining required XML-RPC functionality is another useful middle ground.

REST API

Do not disable the WordPress REST API globally as a default hardening step. Modern WordPress, plugins, forms, WooCommerce, mobile applications, block-editor features, and headless integrations can depend on it.

Instead:

  • require authentication on private endpoints;
  • make sure custom endpoints have proper permission callbacks;
  • limit public user enumeration where it is not needed;
  • rate-limit abusive API traffic;
  • review unexpectedly public endpoints;
  • monitor repeated or suspicious API requests.

Application Passwords

Application Passwords are intended for API authentication and can be individually revoked. Review them periodically and remove credentials belonging to old integrations, departed users, or tools you no longer use.

The safest policy here is not “disable everything.” It is to leave only the interfaces and credentials the site actually needs.

9. Use HTTPS and sensible browser security headers

Every production WordPress site should use HTTPS throughout the site, including the login and administration areas.

Browser security headers can add another layer of protection. Common examples include:

  • Strict-Transport-Security;
  • X-Content-Type-Options;
  • frame restrictions through Content-Security-Policy or X-Frame-Options;
  • Referrer-Policy;
  • Permissions-Policy;
  • Content-Security-Policy.

Do not copy a strict Content Security Policy from another website and deploy it directly to production. WordPress sites often depend on inline scripts, payment providers, analytics, fonts, forms, embeds, CDNs, and other external resources. A CSP should be observed and tested before strict enforcement.

The same caution applies to HSTS preload. Only use it when HTTPS is permanent and every affected subdomain is ready for it.

10. Monitor vulnerabilities before they become incidents

Updating software and vulnerability monitoring solve related but different problems.

An update screen tells you that a new version exists. Vulnerability monitoring tells you whether a version you are currently running has a known security issue and how urgently it needs attention.

This matters when:

  • a vulnerable plugin is still active but no patched release exists yet;
  • a plugin has been abandoned;
  • an update fixes a security issue that should be prioritized over routine updates;
  • you manage enough sites that manually checking every component is unrealistic.

When a vulnerable component has no safe update, the right response may be to disable it, replace it, restrict access to the affected feature, or remove it entirely.

SiteFort checks WordPress core, plugins, and themes for known vulnerabilities and surfaces affected components alongside the other security findings for the site.

11. Scan for malware, unauthorized changes, and persistence

A site can be fully updated today and still contain malware installed before it was patched.

That is why vulnerability monitoring does not replace malware scanning.

A useful WordPress security scan should look beyond obvious filenames and check for things such as:

  • backdoors and web shells;
  • malicious or obfuscated PHP;
  • injected JavaScript;
  • SEO spam;
  • malicious redirects;
  • unexpected core, plugin, or theme changes;
  • suspicious files in writable directories;
  • database injections and suspicious options;
  • unexpected administrator accounts;
  • exposed sensitive files;
  • known vulnerable components.

If a suspicious file returns after you remove it, do not keep deleting the same file. Something else may be recreating it. Look for persistence through another backdoor, a compromised plugin, a scheduled task, an administrator account, a database entry, or an external deployment process.

SiteFort’s scanner checks files, database content, accounts, sensitive exposure, vulnerabilities, integrity changes, and other security indicators. It uses local analysis first and cloud-assisted analysis when deeper inspection is needed.

If you are not sure whether the site is already compromised, see 12 signs your WordPress site may be hacked.

If you already know the site is infected, see How to Remove Malware and Clean a Hacked WordPress Site.

12. Keep logs, monitor the site, and know how you will respond

Security logging is most valuable when it was enabled before the incident.

Useful events include:

  • successful and failed logins;
  • lockouts;
  • new users and administrator creation;
  • role and password changes;
  • plugin and theme installation, activation, deletion, and updates;
  • firewall blocks;
  • hardening changes;
  • important site-setting changes;
  • malware scan results;
  • vulnerability findings.

Logs let you answer questions that become important during cleanup: Which account logged in first? When was the malicious plugin installed? What changed immediately before the redirect started? Did the attacker create another administrator before the original account was removed?

Also monitor the site from outside WordPress where possible. Uptime checks, SSL expiry monitoring, reputation checks, and external scanning can still alert you when WordPress itself is unavailable or compromised.

SiteFort includes an audit log for WordPress security and administrative events, while Securewp Console provides centralized visibility across multiple connected sites.

Security measures that help, but should not be your main defense

Some common WordPress security tips are useful, but they are frequently given more importance than they deserve.

Hiding the WordPress version

Removing generator tags and visible version strings reduces easy fingerprinting. It does not make an outdated WordPress installation safe. Attackers can often identify versions and vulnerable components through other files and behavior.

Changing the WordPress login URL

A custom login URL can reduce generic bot traffic and log noise. It does not replace 2FA, strong credentials, and rate limiting.

Disabling directory browsing

Worth doing, but it only prevents directory listings. It does not stop access to a file when an attacker already knows its URL.

Blocking TRACE and TRACK

Reasonable server hygiene where those methods are enabled, but this is rarely one of the controls that decides whether a modern WordPress site gets compromised.

Spend your time in proportion to the risk. Patch vulnerable software, control privileged access, protect executable paths, monitor the site, and maintain recoverable backups before spending hours on cosmetic fingerprint reduction.

Using SiteFort to manage WordPress security

You can implement many of these controls manually. On sites you manage yourself, that may be exactly what you want.

The challenge is keeping the controls consistent and knowing whether they are actually working. Server configurations vary between Apache, Nginx, LiteSpeed, shared hosting, managed WordPress platforms, and Cloudflare-proxied sites.

SiteFort brings the main WordPress security layers into one plugin:

  • firewall and bot protection;
  • login security and 2FA;
  • WordPress and server hardening;
  • vulnerability monitoring;
  • malware and database scanning;
  • file integrity checks;
  • audit logging;
  • Cloudflare Sync;
  • security visibility through Securewp Console.

SiteFort does not replace good hosting, backups, updates, or careful administration. It handles the WordPress-specific security work that otherwise has to be configured and monitored across several separate tools.

SiteFort is available from the official WordPress.org plugin directory.

The WordPress security baseline

You do not need dozens of obscure hardening tricks to secure WordPress well. Keep unnecessary and vulnerable code off the site, protect privileged accounts, maintain recoverable backups, control hostile traffic, monitor for vulnerabilities and malware, and keep enough logging to understand what changed when something goes wrong.

Get those fundamentals right first. Smaller hardening controls are there to reduce the remaining attack surface, not compensate for missing basics.

Frequently asked questions

What is the most important way to secure a WordPress website?

Keep WordPress core, plugins, and themes current and remove software you do not use. Then protect administrator access with strong unique passwords and 2FA. These controls address two of the most important paths into a WordPress site: vulnerable code and compromised privileged accounts.

Do I need a WordPress security plugin?

Not necessarily. An experienced administrator can implement firewall rules, hardening, logging, vulnerability monitoring, authentication controls, and malware checks using separate server and application tools. A security plugin is useful when you want those controls managed and monitored from WordPress without maintaining several separate systems yourself.

Is Cloudflare enough to secure WordPress?

No. Cloudflare can stop a large amount of hostile traffic before it reaches your server, but it does not replace WordPress updates, 2FA, local hardening, vulnerability monitoring, malware scanning, or account security. Cloudflare and a WordPress security layer protect different parts of the request and application stack.

Should I disable XML-RPC in WordPress?

Disable it if your site does not use it. If Jetpack, a mobile application, publishing tool, or another integration depends on XML-RPC, keep the required functionality and protect the endpoint with firewall and rate-limiting controls. Disabling pingbacks while retaining other required XML-RPC methods is another option.

Should I disable the WordPress REST API?

Not as a general security measure. Modern WordPress and many plugins depend on the REST API. Secure sensitive endpoints with proper authentication and permissions, restrict unnecessary public data, and monitor abusive requests instead of disabling the entire API blindly.

What file permissions should WordPress use?

755 for directories and 644 for files are common starting points, but the correct permissions depend on ownership, PHP configuration, and the hosting environment. wp-config.php can often be made more restrictive. Avoid recursively changing a production site’s permissions without understanding how the host manages file ownership.

How often should I scan WordPress for malware?

Run a scan after initial setup, after a suspected compromise, after restoring or cleaning a hacked site, and whenever suspicious behavior appears. For active production sites, scheduled scanning provides better coverage than relying only on manual scans.

What should I do if my WordPress site is already hacked?

Do not start by randomly deleting suspicious files. Preserve a backup, identify the entry point and persistence mechanisms, remove malicious code and accounts, patch or replace the vulnerable component, and rotate any credentials that may have been exposed. That can include WordPress administrator passwords, hosting credentials, SFTP or SSH access, database credentials where necessary, API keys, and other secrets available to the compromised site.

Scan again after cleanup. If malware returns, assume the original persistence mechanism or entry point has not been fully removed.

For a full cleanup process, read How to Remove Malware and Clean a Hacked WordPress Site or run the free WordPress security checker for an external first look.