WordPress remains a flexible and reliable platform for organizations of all sizes. But that flexibility comes with responsibility.

A WordPress site is not a finished product that can be launched and forgotten. It is an active software system made up of WordPress core, plugins, themes, hosting infrastructure, user accounts, third-party integrations, DNS, and other services. Every part of that system needs ongoing maintenance.

Website security is also not about making a site impossible to hack. No system can guarantee that. The goal is to reduce risk, limit the damage of a successful attack, detect problems quickly, and make recovery manageable. WordPress describes security as risk reduction rather than risk elimination.

Why WordPress Security Matters

It is easy to underestimate the damage caused by a compromised website, especially when the site does not process payments or store obviously sensitive information.

But attackers do not only target ecommerce websites or large organizations. Any compromised site can be useful.

An attacker may use a website to:

• Redirect visitors to scams or malicious downloads
• Add spam pages and links
• Steal customer, employee, donor, or member information
• Capture login credentials or form submissions
• Send spam or phishing emails
• Install malware
• Deface the website
• Gain access to connected systems
• Disrupt business operations
• Damage the organization’s search visibility and reputation

A security incident can also create significant recovery work. The team may need to take the site offline, investigate logs, remove malicious code, reset credentials, restore backups, contact vendors, notify affected users, and rebuild trust.

The cost is not limited to technical cleanup. A compromised website can affect sales, fundraising, recruitment, customer service, marketing campaigns, and public confidence.

What Has Changed in 2026?

The basic principles of website security have not changed, but the environment continues to become more complex.

WordPress sites increasingly depend on third-party plugins, external services, APIs, automated deployments, analytics platforms, form processors, and marketing tools. Every dependency adds another account, credential, integration, or piece of software that needs to be managed.

The current OWASP Top 10 specifically includes software supply-chain failures, security misconfiguration, broken access control, authentication failures, and inadequate logging among the most important web application risks.

Attackers also use automated tools to scan large numbers of websites. They do not need to know that your organization exists before attacking it. An outdated plugin, exposed login, reused password, or misconfigured server can be discovered automatically.

That means small and mid-sized websites need many of the same foundational controls as larger systems, even when the implementation is simpler.

1. Keep WordPress, Plugins, and Themes Updated

Updates are the most important part of WordPress security.

WordPress core, plugins, and themes should all be kept current. WordPress’s official security guidance identifies updates as the most important action site owners can take and recommends choosing plugins and themes that continue to receive active maintenance.

When developers release a security update, details about the vulnerability often become public. That information helps administrators fix the issue, but it also gives attackers more information about how to target sites that have not updated.

A good update process should include:

• Automatic installation of low-risk security updates where appropriate
• Regular review of available plugin and theme updates
• Testing major updates in a staging environment
• Visual and functional testing after updates
• A reliable backup before significant changes
• A defined person or vendor responsible for maintenance

Updates should not sit untouched for months because the team is concerned that something could break. That concern is valid, but the answer is a better testing process, not avoiding updates.

2. Reduce the Number of Plugins and Themes

Every installed plugin or theme adds code to the system. That does not automatically make it unsafe, but it does increase the amount of software that needs to be reviewed, updated, and monitored.

Delete plugins and themes that are no longer used. Deactivating a plugin is not the same as removing it. The files may still exist on the server and could still contain exploitable code.

WordPress’s hardening guidance specifically recommends keeping plugins updated and deleting plugins that are no longer needed.

Before adding a plugin, consider:

• Is the plugin actively maintained?
• Has it received recent updates?
• Does it have a clear support process?
• Does it duplicate functionality already available?
• Does it request more permissions than it needs?
• Is the developer or vendor reputable?
• What happens if the plugin is discontinued?

Avoid installing several security plugins that perform overlapping work. More software does not always create more security. It can introduce conflicts, performance problems, false alerts, and additional maintenance.

3. Protect Administrator Accounts

A secure website can still be compromised through a weak or stolen administrator account.

Every user should have their own account. Shared administrator credentials make it difficult to remove access, review activity, or determine who made a change.

Use:

• Long, unique passwords
• A password manager
• Two-factor authentication
• Passkeys or security keys where supported
• Individual accounts for each user
• Regular reviews of active users

WordPress core does not currently provide two-factor authentication by itself, so it must be added through a reputable plugin, single sign-on system, identity provider, or managed hosting service. WordPress also recommends login rate limiting and edge-level protection against brute-force attacks.

Avoid relying only on changing the WordPress login URL. That can reduce automated noise, but hiding the login page is not a substitute for strong authentication.

4. Give Users Only the Access They Need

Not everyone needs to be an administrator.

WordPress includes roles such as Administrator, Editor, Author, Contributor, and Subscriber. Use the lowest role that allows a person to complete their work.

A content editor usually does not need the ability to install plugins, modify themes, create administrators, or change site-wide settings.

Review user accounts regularly and remove access for:

• Former employees
• Previous vendors
• Temporary contractors
• Abandoned test accounts
• Accounts that no longer have a clear owner

Least-privilege access limits the damage caused by a compromised account and reduces the chance of accidental changes.

The same principle should apply outside WordPress. Review access to the hosting account, domain registrar, DNS provider, analytics platforms, code repository, deployment tools, email provider, CDN, and backup system.

5. Use Secure, Well-Maintained Hosting

Your hosting environment is part of your security system.

A reputable WordPress host should provide current versions of PHP and database software, HTTPS support, backups, malware monitoring, access controls, server updates, and technical support.

Managed hosting can reduce the amount of infrastructure your internal team needs to maintain, but it does not remove your responsibility. You still need to manage plugins, themes, accounts, integrations, and application-level configuration.

Ask your hosting provider:

• How often are backups created?
• How long are backups retained?
• Are backups stored separately from the live site?
• Can we restore the site ourselves?
• Does the provider monitor for malware?
• Is a web application firewall included?
• How are PHP and server updates handled?
• What logs are available?
• What support is provided during an incident?

Cheap hosting becomes expensive when the site is slow, unstable, difficult to restore, or poorly supported during an emergency.

6. Use HTTPS Everywhere

HTTPS encrypts information sent between a visitor’s browser and the website. This protects login credentials, form submissions, cookies, and other transmitted information from being read in transit.

HTTPS should cover the entire site, not only the checkout page or WordPress administration area.

The certificate should renew automatically, and the site should redirect all HTTP traffic to HTTPS. Administrators should also use encrypted connections such as SFTP or SSH instead of traditional unencrypted FTP when accessing server files.

HTTPS is essential, but it does not prove that a website itself is safe. It protects the connection. It does not fix vulnerable plugins, weak passwords, malicious code, or poor access controls.

7. Add Protection Before Traffic Reaches WordPress

A web application firewall, CDN, or hosting-level security service can block malicious requests before they reach the WordPress application.

Edge-level protection can help with:

• Brute-force login attempts
• Known malicious traffic
• Automated scanners
• Denial-of-service attacks
• Suspicious bots
• Rate limiting
• Geographic or network-based restrictions

WordPress recommends using edge or web-server protections where possible because they can stop harmful traffic before WordPress loads.

A firewall is not a replacement for updates or secure development. It is another layer.

8. Secure the WordPress Configuration

Several technical changes can reduce the potential impact of a compromised account or vulnerable plugin.

For example, production sites should generally disable the built-in theme and plugin file editor:

define( 'DISALLOW_FILE_EDIT', true );

This prevents administrators from editing executable theme and plugin files directly through the WordPress dashboard. It does not stop every form of malicious file upload, but it removes a tool attackers commonly use after gaining administrative access.

Other technical controls may include:

• Restricting access to wp-config.php
• Using secure WordPress authentication salts
• Preventing public access to sensitive files
• Disabling directory listing
• Restricting database permissions
• Blocking PHP execution in upload directories where practical
• Disabling XML-RPC when it is not required
• Removing development and debug output from production
• Setting appropriate file ownership and permissions

WordPress recommends limiting file write access as much as possible instead of making directories broadly writable.

These changes should be implemented by someone familiar with the hosting environment. Incorrect permissions or server rules can break updates, uploads, caching, or deployment workflows.

9. Use Reliable Backups—and Test Them

Backups are not only for server failure or accidental deletion. They are a core part of incident recovery.

A useful WordPress backup includes:

• The database
• Uploaded media
• Themes and plugins
• Custom code
• Configuration files
• Any other files required to rebuild the site

Backups should be stored somewhere separate from the live hosting environment. If an attacker compromises the server and can also modify or delete every backup, the backup system has failed.

Keep multiple restore points. A compromise may exist for days or weeks before anyone notices it, so the newest backup may already contain malicious code.

And test the restoration process. A backup is only valuable when the team can successfully restore it.

WordPress recommends regular snapshots of the complete installation and database, while CISA recommends testing backup procedures and maintaining protected backups for recovery.

10. Monitor the Website and Keep Logs

Prevention is only part of security. The team also needs to know when something goes wrong.

Monitoring should cover:

• Website uptime
• Unexpected file changes
• Failed login attempts
• New administrator accounts
• Plugin and theme installations
• Changes to critical settings
• Malware indicators
• Unusual traffic or resource usage
• Form and email behavior
• Security warnings from the host or firewall

Logs can help determine what changed, when it happened, which account or IP address was involved, and what the attacker attempted to do. WordPress’s hardening guidance describes logs as essential for understanding activity and investigating a compromise.

Alerts should go to a monitored address or ticketing system. A security plugin that sends hundreds of unread warnings does not provide meaningful protection.

11. Secure Custom Themes, Plugins, and Integrations

Custom code needs the same level of attention as third-party software.

Developers should follow WordPress APIs and current secure coding practices for:

• Data validation
• Output escaping
• Input sanitization
• Database queries
• File uploads
• Permissions and capability checks
• Nonces and request verification
• API authentication
• Secret management
• Error handling

Secrets such as API keys, passwords, and tokens should not be committed to public code repositories or exposed in frontend JavaScript unless they are specifically designed to be public.

Custom integrations should also be reviewed when vendors, APIs, or business requirements change. An integration that was safe when it launched can become outdated or unnecessary later.

The OWASP Top 10 provides a useful baseline for reviewing access control, authentication, configuration, dependencies, data integrity, logging, injection risks, and application design.

12. Create a Basic Incident Response Plan

Do not wait until a site is compromised to decide who should respond.

A simple incident response plan should identify:

• Who has authority to take the site offline
• Who can access hosting, DNS, backups, and WordPress
• Who will investigate the issue
• Who will contact the hosting provider
• Who will communicate with clients, users, or staff
• Who will handle legal, insurance, or compliance questions
• How credentials will be reset
• How a clean backup will be selected
• How the site will be tested before returning online

Keep essential account and vendor information somewhere secure and accessible outside the website itself.

During a real incident, the team will already be under pressure. A documented plan prevents avoidable delays and confusion.

A Practical WordPress Security Checklist

At a minimum, every maintained WordPress site should have:

• Current WordPress core, plugins, and themes
• No abandoned or unused plugins
• Two-factor authentication for administrators
• Unique user accounts
• Limited administrator access
• HTTPS across the entire site
• Secure hosting with a supported PHP version
• A firewall or edge-level traffic protection
• Automated backups stored separately from production
• Periodic restoration testing
• Uptime, security, and file-change monitoring
• Accessible server and application logs
• A staging environment for testing updates
• A documented maintenance owner
• A basic incident response plan

Security Is an Ongoing Process

WordPress security is not a plugin, a one-time configuration task, or a checklist completed at launch.

It is a maintenance process.

The strongest sites have clear ownership, a manageable number of dependencies, controlled access, regular updates, tested backups, useful monitoring, and a plan for responding when something goes wrong.

Taking security seriously does not mean reacting to every warning or buying every available security product. It means building a reasonable, repeatable process that reduces risk and keeps the website supportable over time.

That process is almost always less expensive than recovering from a preventable compromise.