How to Secure a WordPress Website: Complete WordPress Security Guide

A secure WordPress website is not created by installing one security plugin and turning on a firewall. The strongest setup is layered: keep WordPress and extensions patched, protect administrator accounts, reduce unnecessary attack surface, use reliable backups, harden the hosting environment, monitor for suspicious changes, and know how you will recover if something still goes wrong.

WordPress itself has a mature security process, but the complete site also includes your hosting account, PHP, database, plugins, themes, administrator accounts, forms, integrations, CDN, DNS, and operational habits. A weakness in any of those layers can become the entry point.

This guide focuses on practical controls that materially reduce risk without relying on security-through-obscurity tricks.

Is WordPress Secure?

WordPress can be operated securely, but security depends on the whole environment rather than WordPress core alone. The WordPress Security Team develops and releases fixes for responsibly disclosed vulnerabilities, while the official WordPress hardening documentation recommends ongoing patching, secure credentials, careful file permissions, backups, logging, monitoring, and server hardening.

The practical lesson is simple: do not judge WordPress security by the CMS name alone. A fully patched WordPress site on a well-managed server with strong access controls can be substantially safer than an abandoned site running outdated plugins, reused administrator passwords, weak hosting credentials, and no tested backup.

For a platform-neutral version of these controls, see Tenfic’s website security checklist.

WordPress Security Checklist at a Glance

1. Keep WordPress Core Updated

Security patches lose most of their value if they are not deployed.

WordPress recommends staying current, and security releases can be distributed through automatic background updates. Review Dashboard → Updates regularly and make sure your hosting environment is not blocking automatic core security updates.

For business sites, use a simple update workflow:

1. keep reliable backups;
2. test significant updates on staging when the site is complex;
3. deploy promptly;
4. check the frontend, forms, checkout, login, and integrations afterward.

Do not remain on an old WordPress release simply because the site still appears to work. Public vulnerability information often becomes available after a patch is released, making delayed updates riskier.

2. Update Plugins and Themes Promptly

A WordPress installation is an ecosystem. Every active plugin and theme adds code that must be maintained.

WordPress provides plugin and theme auto-update controls, which can be useful for stable extensions, but your update strategy should match the importance and complexity of the site. Critical ecommerce or membership sites may need staging checks before major changes, while security fixes should not sit unpatched for weeks.

For each extension, verify:

• it is still maintained;
• its latest release is compatible with your environment;
• updates are being installed;
• you have a rollback or backup path if an update causes a problem.

3. Remove Unused Plugins and Themes

Deactivating unused software does not create business value, and abandoned code can still become a maintenance liability.

Delete plugins you no longer need. Keep only themes required for the active site and any deliberate fallback/testing workflow. Do not retain old ZIP uploads, abandoned premium plugins, duplicated features, or test extensions on production indefinitely.

The number of plugins is not the security metric by itself. Quality, maintenance, permissions, code paths, update status, and overlap matter more. Tenfic’s guide on how many WordPress plugins are too many explains that distinction in more detail.

4. Install WordPress Software Only From Trusted Sources

Avoid nulled, pirated, modified, or unofficial copies of premium themes and plugins. You cannot reliably know what additional code has been inserted, whether updates will remain available, or whether the package was altered after the legitimate release.

Prefer WordPress.org for repository plugins/themes or the official vendor for commercial software. Confirm the vendor domain before downloading an installer and protect license/account credentials with MFA where the vendor supports it.

5. Protect Administrator Accounts With Strong Authentication

Administrator access should receive stronger protection than an ordinary subscriber account because an administrator can install code, create users, change settings, and often reach sensitive business data.

Use:

• a unique account for each administrator;
• long, unique passwords generated and stored in a password manager;
• multi-factor authentication for administrators and other privileged users;
• secure password reset and email accounts;
• immediate credential rotation when compromise is suspected.

The OWASP Authentication Cheat Sheet describes MFA as one of the strongest defenses against password-based account compromise and also recommends protections against automated login attempts.

Avoid shared usernames such as a team-wide admin account. Shared credentials destroy accountability and make offboarding harder.

6. Apply Least Privilege to WordPress Roles

Not everyone who edits a page needs Administrator access.

WordPress roles exist so users can be given only the capabilities required for their job. For example, an author may need to publish content but should not normally install plugins. A customer-support user may need WooCommerce access without control over themes or site-wide configuration.

Audit users periodically and remove:

• former employees and contractors;
• duplicate accounts;
• temporary accounts that were never disabled;
• Administrator privileges that are no longer necessary.

Also review service accounts and application passwords used by integrations. Remove credentials for disconnected tools.

7. Secure the Hosting Account and Server Stack

A perfectly configured WordPress dashboard cannot compensate for a compromised hosting control panel.

Protect the hosting account with MFA and a unique password. Use current, supported PHP and database/server versions and keep the operating environment patched. Choose hosting that provides appropriate account isolation, backups, access logs, TLS management, and resource monitoring.

If a site suddenly becomes slow or unstable during attacks, security and performance can overlap. Tenfic’s guide to reducing TTFB and server response time explains how server capacity, PHP workers, database workload, and caching affect the request path.

8. Use HTTPS Everywhere

HTTPS protects credentials, cookies, form submissions, and page data while they travel between the visitor and your site.

Install a valid TLS certificate and redirect HTTP URLs consistently to HTTPS. Check that important resources are not still loaded over insecure HTTP and that admin/login pages are never intentionally served without TLS.

HTTPS does not prevent malware, vulnerable plugins, or stolen administrator credentials, but operating authentication over plain HTTP is unacceptable for a business website.

9. Build Backups for Recovery, Not Just Storage

A backup matters only if it is recent, protected, and restorable.

Maintain automated backups of both:

• WordPress files/uploads; and
• the database.

Store copies somewhere that is not dependent on the same production server. Protect the backup account itself with strong authentication. For important sites, use multiple retention points so a compromised or corrupted backup does not overwrite every clean recovery option.

Most importantly, test restoration. A backup job reporting “success” is not the same as a validated recovery process.

WordPress’s official backup guidance treats backups as a core part of hardening because recovery is part of security, not an afterthought.

10. Protect the Login Page Against Automated Abuse

Renaming /wp-admin/ or hiding a login URL is not a primary security control. Attackers can discover endpoints in many ways, and legitimate WordPress functionality still exposes recognizable platform behavior.

Use controls that actually reduce automated attack effectiveness:

• login rate limiting or throttling;
• WAF rules for abusive patterns;
• MFA;
• monitoring of repeated failed logins;
• CAPTCHA or challenge mechanisms when justified by attack volume;
• blocking obviously malicious networks when supported by evidence.

Avoid aggressive lockout settings that let an attacker deny service to legitimate administrators simply by triggering repeated failures on their usernames.

11. Use a Web Application Firewall and CDN Where Appropriate

A WAF can filter common malicious requests before they reach WordPress, while a CDN can absorb traffic and reduce origin exposure/load when configured correctly.

Useful protections can include bot filtering, rate limiting, managed vulnerability rules, geographic/network controls, and DDoS mitigation.

Do not assume a CDN automatically secures WordPress. Your origin, admin accounts, plugins, database, and backups still need protection. Likewise, firewall rules must be tested so they do not block WordPress REST requests, webhooks, payment callbacks, or authenticated API integrations.

See Tenfic’s CDN vs caching guide for the performance side of edge delivery and caching.

12. Protect wp-config.php, File Permissions, and Dashboard File Editing

wp-config.php contains sensitive configuration such as database credentials and authentication salts. It should not be publicly readable, and filesystem permissions should follow the principle that files are writable only by the accounts/processes that actually require write access.

Avoid broad permissions such as 777 as a routine “fix” for upload or update problems. Diagnose the correct ownership and permissions instead.

WordPress also supports disabling the built-in plugin/theme file editor by defining:

define( 'DISALLOW_FILE_EDIT', true );

This reduces one path an attacker could use to modify PHP through the dashboard after obtaining an administrator session. It does not make a compromised administrator account harmless, so keep authentication controls in place.

13. Harden Database and Secret Access

Use a dedicated WordPress database account rather than reusing a database superuser across applications. Keep database credentials out of publicly accessible files and do not expose the database directly to the internet unless there is a specific secured architecture requiring remote access.

Changing the default WordPress table prefix can reduce some automated assumptions, but it should be treated as minor obscurity—not a substitute for patching, secure queries, strong credentials, or least privilege.

If you rotate credentials or WordPress authentication salts during incident response, plan for the operational impact: changing salts logs active users out.

14. Reduce WordPress Attack Surface Carefully

Attack-surface reduction is useful when it removes functionality the site genuinely does not need. It becomes harmful when blanket blocking breaks legitimate WordPress behavior.

Examples:

• XML-RPC: If no mobile app, Jetpack feature, publishing client, or integration relies on it, you can consider restricting or disabling unnecessary XML-RPC functionality. If something uses it, apply rate limiting and monitoring instead of blindly blocking it.
• REST API: Do not disable the REST API globally simply because it is public. WordPress core, the block editor, plugins, and integrations can rely on REST endpoints. Restrict sensitive custom endpoints with proper authentication/authorization.
• Application passwords: Remove unused credentials and scope integrations to accounts with the minimum required capabilities.
• Directory/file exposure: Prevent accidental public access to backups, configuration exports, logs, staging archives, database dumps, .env files, and temporary ZIP files.

15. Secure Forms, Uploads, Ecommerce, and Integrations

Business websites often accept data through contact forms, file uploads, checkout, webhooks, membership registration, or APIs. These workflows deserve separate attention because they extend the attack surface beyond the WordPress login page.

Verify that:

• upload types and sizes are restricted appropriately;
• uploaded files cannot execute as server-side code in upload directories;
• forms have anti-spam/abuse controls;
• webhook endpoints validate authentication/signatures where the provider supports them;
• payment processing uses reputable gateways rather than storing card data unnecessarily;
• API keys and secrets are not embedded in public JavaScript or downloadable files;
• abandoned integrations are removed.

16. Add Appropriate Security Headers

HTTP security headers can reduce the impact of several browser-side attack classes when configured correctly.

Depending on the site, useful headers may include:

• Strict-Transport-Security after HTTPS is fully deployed;
• Content-Security-Policy when you can build and test a policy safely;
• X-Content-Type-Options: nosniff;
• Referrer-Policy;
• frame-embedding restrictions through CSP frame-ancestors or compatible controls.

Do not copy an aggressive Content Security Policy from another site without testing it. WordPress sites commonly load scripts, fonts, analytics, embeds, payment assets, and plugin resources from multiple origins; an incorrect policy can break production functionality.

17. Monitor WordPress for Suspicious Changes

Security is an ongoing process. You need visibility after deployment.

Monitor for:

• new administrator accounts;
• unusual login locations or repeated failures;
• unexpected plugin/theme installation or activation;
• modified core/plugin/theme files;
• malware indicators or injected JavaScript;
• unexplained redirects;
• spikes in outgoing email;
• unexpected cron jobs or scheduled tasks;
• abnormal traffic or server resource usage;
• changes to DNS, CDN, hosting, and domain accounts.

Keep logs long enough to investigate an incident and protect them from being modified by the same compromised account whenever practical.

18. Protect Staging, Development, and Backup Copies

A production site may be hardened while an old staging copy remains publicly reachable with the same users, database, or credentials.

Treat staging as part of the security boundary:

• require authentication or network restrictions;
• avoid using production secrets unnecessarily;
• keep staging software patched;
• prevent search indexing;
• remove abandoned staging environments;
• sanitize customer data when a full production database is not necessary.

Also delete migration archives and database exports after they have served their purpose.

19. Maintain an Incident-Response and Recovery Plan

Assume that prevention can fail.

A practical WordPress incident plan should define how to:

1. preserve evidence and logs;
2. contain the affected site/account;
3. identify the entry point;
4. rotate WordPress, hosting, database, email, CDN, DNS, API, and integration credentials as appropriate;
5. remove malicious code and persistence mechanisms;
6. patch the vulnerability;
7. restore from a verified clean backup when necessary;
8. validate users, plugins, themes, scheduled tasks, redirects, uploads, and server files;
9. monitor closely after recovery.

Do not restore a backup and immediately declare the incident resolved if the vulnerable plugin, stolen credential, or exposed server configuration that caused the breach is still present.

WordPress Security Mistakes to Avoid

A few common practices create false confidence:

• Relying only on a security plugin: Useful tools can add WAF, scanning, login controls, or monitoring, but they cannot compensate for an outdated stack or compromised hosting account.
• Changing the login URL and stopping there: It may reduce noise, but strong authentication and rate limiting matter more.
• Disabling every public endpoint: Blanket REST/XML-RPC blocking can break legitimate features without addressing the real vulnerability.
• Keeping inactive software “just in case”: Unneeded code still creates maintenance work.
• Using permissions like 777: This solves ownership problems by removing important restrictions.
• Assuming backups equal recovery: Untested backups may be incomplete, corrupted, inaccessible, or already compromised.
• Ignoring vendor and hosting accounts: Attackers do not have to enter through WordPress if they can take over DNS, hosting, email, or a plugin vendor account.

A Practical WordPress Security Maintenance Schedule

You do not need to perform every security task every day.

Continuously or automatically: backups, uptime monitoring, WAF/rate limiting, malware/file-change monitoring, and log collection.

Weekly: review pending updates, failed logins, security alerts, backup status, and major site changes.

Monthly: audit administrator accounts, unused plugins/themes, integrations/application passwords, staging sites, and restore readiness.

After every major change: verify backups, update status, forms, checkout, login, APIs/webhooks, security headers, and monitoring.

Immediately after a security advisory affecting your stack: assess exposure and patch according to risk rather than waiting for the next maintenance window.

Related guides: website security checklist and WordPress hacked recovery guide.

Conclusion

Securing WordPress is a lifecycle, not a one-time plugin installation.

The highest-value controls are consistent: keep the software stack patched, protect privileged accounts with MFA, minimize unnecessary code and permissions, use secure hosting and HTTPS, maintain tested backups, filter abusive traffic, protect configuration and secrets, and monitor for changes that should not be happening.

Then prepare for failure. If you know how to contain an incident, rotate credentials, restore clean data, patch the entry point, and validate the recovered system, a security event is far less likely to become a prolonged business outage.