WordPress Hardening: Eight Changes That Stop Most Attacks

WordPress powers websites ranging from personal blogs to business websites and online stores. Its popularity also makes it a frequent target for automated attacks, including attempts to exploit vulnerable plugins, guess passwords and upload malicious files.

The good news is that improving WordPress security does not always require expensive enterprise tools. Many important protections come from routine maintenance, careful access management and a reliable recovery plan.

This guide covers eight practical WordPress hardening measures that help reduce common security risks and make your website easier to maintain.

1. Keep WordPress Core, Themes and Plugins Updated

Outdated software can contain vulnerabilities that attackers exploit to gain unauthorised access, inject malicious code or disrupt a website.

WordPress core is only one part of the equation. Themes, plugins and server-side software also need attention.

What to do

• Enable automatic minor WordPress core updates where appropriate.

• Review available major updates and test important changes before deployment.

• Update actively maintained plugins and themes promptly, especially when security fixes are released.

• Remove plugins and themes that are no longer needed.

• Check compatibility before updating critical business websites.

• Maintain a recent backup before significant updates.

Pay particular attention to security advisories from plugin developers and reputable vulnerability databases. If a critical vulnerability affects an installed component, prioritise the recommended mitigation rather than waiting for your usual maintenance window.

Why it matters: Updating closes known security gaps that attackers may already understand and have tools to exploit.

2. Remove Unused and Abandoned Plugins

Every plugin adds code and may introduce dependencies, permissions or potential vulnerabilities. The more components you maintain, the more work is required to keep the website secure.

An inactive plugin can still pose a risk if its files remain accessible or its code contains an exploitable vulnerability.

Review your plugin list

For each plugin, ask:

• Is it still needed?

• Does it provide functionality that another component already covers?

• Is the developer maintaining it?

• Are security updates available?

• Is it compatible with your current WordPress version?

• Does it request more permissions or access than necessary?

Delete plugins you no longer use rather than simply deactivating them. Remove unused themes as well, while retaining any theme required by your active theme configuration.

If an essential plugin appears abandoned, investigate a maintained alternative and plan a controlled replacement. Do not leave a vulnerable component installed indefinitely because removing it might require additional work.

3. Strengthen Administrator Accounts and Passwords

Administrator accounts can make extensive changes to a WordPress website. If an attacker gains access to one, they may be able to install malicious plugins, create accounts, alter content or access sensitive information.

Apply these account security practices

• Give every administrator a separate user account.

• Use a long, unique password for every account.

• Enable multi-factor authentication (MFA) where supported.

• Remove unnecessary administrator privileges.

• Disable or remove accounts that no longer need access.

• Review administrator accounts regularly.

• Use a password manager instead of storing credentials in spreadsheets or chats.

Avoid relying on an unusual username as your main defence. Changing a default username can reduce some predictable account targeting, but it does not replace strong passwords, MFA and login protections.

For additional security guidance, read Password Hygiene for Small Teams Without Enterprise Tools.

4. Protect the WordPress Login Page

The standard WordPress login endpoint is well known, so automated tools frequently target it with password-guessing and credential-stuffing attempts.

Changing the login URL may reduce noise from basic automated scans, but it should not be treated as a primary security control. Attackers can discover alternative login paths, and hiding the URL does not fix weak credentials or vulnerable software.

Recommended login protections

• Enable rate limiting or another suitable control against repeated failed logins.

• Use MFA for privileged accounts.

• Consider a reputable security plugin or hosting-level protection that limits abusive requests.

• Monitor repeated failures and suspicious login patterns.

• Use individual administrator accounts rather than shared logins.

• Remove unnecessary remote access routes and integrations.

Avoid overly aggressive lockout settings that could prevent legitimate users or administrators from accessing the website. Test security controls before applying them to a business-critical site.

5. Prevent PHP Execution in the Uploads Directory

WordPress stores many uploaded images, documents and other media in the wp-content/uploads directory. If an attacker manages to place an executable PHP file there, a server that permits PHP execution in that location may run the malicious code.

Disabling PHP execution in uploads can reduce this risk. However, the correct configuration depends on your web server and hosting environment.

Before applying the change

• Confirm whether your server uses Apache, Nginx or another web server.

• Check the hosting provider's recommended method for restricting execution.

• Ensure the rule applies to the intended uploads directory.

• Test image uploads, media previews and any legitimate functionality that depends on files in that directory.

For Apache configurations, a suitable server rule may restrict PHP handling in the uploads directory. Nginx requires an appropriate server configuration rather than relying on .htaccess.

Do not copy a server rule blindly into a production environment. Incorrect rules can disrupt legitimate functionality or fail to provide the protection you expect.

Important: Disabling PHP execution in uploads is one layer of defence, not a complete malware-prevention strategy. Continue to protect upload functionality, validate file types and maintain access controls.

6. Maintain Off-Site Backups and Test Restoration

Backups are essential because preventive controls cannot eliminate every security risk. A compromised plugin, stolen administrator account or server failure may still require you to restore the website.

A backup is useful only if it contains the necessary data and can be restored successfully.

What a WordPress backup should include

• WordPress core files where needed for a complete recovery.

• Themes and plugins.

• Uploaded media and other website files.

• The WordPress database.

• Important configuration information.

• Any additional data stored outside the standard WordPress directories.

Keep backups separate from the production website where possible. An attacker who compromises the hosting account may otherwise be able to delete both the website and its backups.

Follow a backup routine

1. Choose a schedule based on how frequently the website changes.

2. Set a retention period that meets your recovery needs.

3. Store copies in a separate location or account.

4. Protect backups with appropriate access controls.

5. Test restoration in a staging environment.

6. Record the recovery steps and who is responsible for them.

An online shop with frequent orders may need more frequent backups than a static company website. Consider how much data you can afford to lose and how quickly the website must be restored.

You can review the SteboHost backup service to check the available backup options and retention arrangements.

7. Use a Web Application Firewall

A web application firewall (WAF) filters HTTP and HTTPS requests before they reach the application. Depending on its rules and configuration, it can block or challenge requests associated with known attack patterns.

A WAF may help reduce exposure to certain attacks, including malicious requests targeting vulnerable application components. However, it cannot prevent every compromise, particularly when attackers use stolen credentials or exploit weaknesses that the firewall does not recognise.

What to consider when choosing a WAF

• Protection against common web attack patterns.

• Compatibility with WordPress and its plugins.

• Rules that can be updated as new threats emerge.

• Useful security logs and alerts.

• Rate-limiting options.

• Protection for administrative endpoints where appropriate.

• A manageable process for investigating false positives.

Test the rules before enabling strict blocking on a live website. Overly broad rules may interfere with legitimate forms, checkout processes, API requests or administrative actions.

A WAF works best alongside software updates, strong authentication, restricted permissions and reliable backups.

If SteboHost provides a suitable WAF option for your plan, review the security services page for the current scope and availability.

8. Monitor the Website for Suspicious Changes

Preventive measures reduce risk, while monitoring helps you recognise problems that have already occurred or are developing.

You do not necessarily need an expensive security operations platform to start. A regular review of important accounts, files, logs and website behaviour can provide useful early warning signs.

Check these areas regularly

Use file-integrity monitoring or reputable security scanning tools where appropriate. An unfamiliar file is not automatically malicious, but unexpected changes to core directories should be investigated rather than ignored.

Create a response plan

If you suspect a compromise:

1. Preserve relevant logs and evidence.

2. Contact your hosting provider or security administrator.

3. Contain the incident using an approach appropriate to the risk.

4. Identify and remove the underlying cause, not just the visible symptoms.

5. Reset affected credentials and revoke compromised sessions or tokens.

6. Restore clean files and data if necessary.

7. Verify the website before returning it to normal operation.

For a step-by-step incident response, see The First 60 Minutes After a Malware Alert.

WordPress Hardening Checklist

Use this checklist to track the security measures you have implemented.

{@body const hardeningTasks = [
"Keep WordPress core, themes and plugins updated.",
"Remove unused and unsupported plugins and themes.",
"Use unique passwords and MFA for administrator accounts.",
"Apply login rate limiting and monitor suspicious attempts.",
"Restrict executable code in the uploads directory where supported.",
"Maintain off-site backups and test restoration.",
"Review WAF or other suitable web request protections.",
"Review administrator accounts, files, logs and security alerts."
]}
{@body const [hardeningChecked, setHardeningChecked] = DIL.useState([])}
<box border radius="xl" padding={4} gap={3}>
<row align="center" justify="between">
<title size="md">Website hardening progress</title>
<text color="secondary" size="sm">{hardeningChecked.length} of {hardeningTasks.length}</text>
</row>
<box background="surface-tertiary" radius="full" height="6px" clip>
<box background="surface-inverted" radius="full" height="6px" width={${hardeningChecked.length / hardeningTasks.length * 100}%} />
</box>
{#each hardeningTasks as task, i}
<checkbox key={task} checked={hardeningChecked.includes(i)} onChange={(value) => setHardeningChecked(prev => value ? [...prev, i] : prev.filter(n => n !== i))}>{task}</checkbox>
{/each}
<row gap={2}>
<button block variant="outline" color="secondary" onClick={() => setHardeningChecked([])}>Reset</button>
<button block onClick={() => GenUI.copy(hardeningTasks.map((task, i) => ${hardeningChecked.includes(i) ? "[x]" : "[ ]"} ${task}).join("\n"))}>Copy checklist</button>
</row>
</box>

Frequently Asked Questions

Is WordPress secure enough for a business website?

WordPress can be used securely when it is maintained properly. Security depends on the core software, themes, plugins, hosting configuration, account permissions and ongoing maintenance.

What is the biggest WordPress security risk?

There is no single cause behind every compromise. Common risk areas include vulnerable or outdated components, compromised credentials, insecure configurations and unsafe code. The most important priorities depend on the website's setup and current exposure.

Should I install several WordPress security plugins?

Not necessarily. Multiple plugins may duplicate features, create configuration conflicts or affect performance. Choose tools based on specific needs, maintain them and verify that their protections work as intended.

Does changing the WordPress login URL stop hackers?

It may reduce some automated login attempts, but it does not prevent targeted attacks or replace MFA, strong passwords and rate limiting. Treat it as an optional supplementary measure.

Are WordPress backups enough to protect my website?

Backups support recovery but do not prevent attacks. They should be stored securely, tested regularly and combined with preventive controls and an incident-response plan.

Does a web application firewall guarantee WordPress security?

No. A WAF can block certain malicious requests, but it may not stop stolen-account access, every new vulnerability or all malicious activity. It is one layer in a broader security strategy.

Conclusion

WordPress security is not achieved through a single plugin or configuration change. It comes from keeping software updated, reducing unnecessary components, protecting administrator accounts, restricting risky execution, maintaining recoverable backups and monitoring for suspicious activity.

Start with the measures that address your website's biggest risks, then make the checks part of a regular maintenance routine.

If your WordPress website is hosted with SteboHost, review the available hosting plans, backup options and security features to understand which protections are included and which need separate configuration.