A WordPress security checklist is a repeatable list of controls that keeps a business website patched, locked down, backed up and monitored. The 20 steps below cover what matters in 2026: update promptly, remove what you do not use, give every user the lowest role they need plus two-factor authentication, put a web application firewall in front of the site, keep backups off-site, and have a written incident plan.
Most WordPress hacks are not sophisticated: they exploit an outdated plugin, a reused password or a forgotten admin account. That means discipline removes most of the risk.
Why WordPress sites get hacked in 2026#
WordPress core is rarely the problem. According to Patchstack’s State of WordPress Security in 2026 report, researchers recorded 11,334 new vulnerabilities in the WordPress ecosystem in 2025, a 42% increase over 2024. Of those, 91% were in plugins and 9% in themes, while WordPress core received only six reports, all rated low priority.
Three more Patchstack findings explain why speed matters:
- 46% of vulnerabilities had no developer fix available when they were publicly disclosed.
- The weighted median time to mass exploitation for heavily exploited vulnerabilities was five hours, and about half of high-impact vulnerabilities were exploited within 24 hours.
- Premium and freemium components made up 29% of valid reports, so paid does not mean safe.
Patchstack names broken access control as the most exploited vulnerability type: plugins that let an anonymous visitor do what only an administrator should. Every plugin is code you trust with your business, and the gap between disclosure and attack is now measured in hours.
The 20-step WordPress security checklist#
Updates and code hygiene#
- Update core, plugins and themes promptly. Enable automatic updates for minor releases and well-maintained plugins. Test major upgrades on staging, then apply them within days, not months.
- Delete unused plugins and themes. A deactivated plugin still sits on the server and can still be attacked. Keep one default theme as a fallback.
- Vet every new plugin. Check its last update, the developer’s support record and public vulnerability databases. One well-built plugin is safer than three overlapping ones.
- Never use “nulled” premium plugins or themes. Pirated copies are a common malware route. Buy licences from the original vendor so you receive security updates.
- Run a supported PHP version. WordPress.org recommends PHP 8.3 or greater. According to PHP.net, PHP 8.2 receives security fixes only until 31 December 2026, and 8.0 and 8.1 are already end of life. Plan your move to 8.3 or 8.4 now.
Users and access#
- Apply least privilege. Give each person the lowest role that does the job: Editor or Author for content staff, Shop Manager for WooCommerce staff, Administrator only for the people who manage the site.
- Use one named account per person. No shared “admin” logins. Remove former staff, freelancers and agencies the day they leave.
- Enforce strong, unique passwords. Use a password manager and long passphrases; passwords reused from breached services are an easy way in.
- Turn on two-factor authentication (2FA) for every account that can publish or change settings. An authenticator app or hardware key beats SMS codes.
- Limit login attempts and disable XML-RPC if unused. Rate-limit the login page and block XML-RPC unless a service genuinely depends on it.
- Change the default login URL, as a minor measure. Moving /wp-login.php cuts bot noise in your logs, but it is not real protection; 2FA and rate limiting do the work.
Server and application hardening#
- Disable file editing in the dashboard. Add
define('DISALLOW_FILE_EDIT', true);to wp-config.php so a hijacked admin session cannot inject code through the theme and plugin editors. - Lock down files. Set correct permissions, protect wp-config.php, use unique salts and block PHP execution in the uploads folder.
- Force HTTPS everywhere. WordPress.org lists HTTPS support among its requirements. Redirect HTTP traffic and enable HSTS.
- Send security headers: Strict-Transport-Security, X-Content-Type-Options, frame-ancestors against clickjacking, Referrer-Policy, Permissions-Policy and, where practical, a Content-Security-Policy.
Perimeter, hosting and recovery#
- Put a WAF and CDN in front of the site. A web application firewall (WAF) filters malicious requests before they reach WordPress. Cloudflare’s documentation states that its Free Managed Ruleset is available on all plans, including Free; paid plans add the full Cloudflare Managed Ruleset and OWASP Core Ruleset. Add WordPress-aware virtual patching for plugin-specific exploits.
- Choose hosting built for WordPress security. Look for site isolation, current PHP, server-level malware scanning, daily backups, staging and fast support. Cheap shared hosting is a false economy.
- Keep automated backups off-site. The US Cybersecurity and Infrastructure Security Agency (CISA) recommends the 3-2-1 rule: three copies of important files, on two types of media, with one copy off-site. Keep one copy the server cannot overwrite, and test restores.
- Scan for malware. Schedule server and plugin scans, and watch the Security Issues report in Google Search Console for spam pages, rogue admins and redirects.
- Monitor and plan for incidents. Use uptime monitoring, an activity log, file-integrity alerts and vulnerability alerts for your exact plugin list, and agree who does what if the site is hacked.
WordPress security checklist table: step, why, how often#
| # | Step | Why it matters | How often |
|---|---|---|---|
| 1 | Update core, plugins, themes | Closes known holes before bots find them | Weekly check; security fixes same day |
| 2 | Delete unused plugins and themes | Inactive code can still be exploited | Monthly |
| 3 | Vet new plugins | Plugins are the main source of vulnerabilities | Before every install |
| 4 | Licensed premium plugins only | Nulled copies often carry malware | At purchase and renewal |
| 5 | Supported PHP version | End-of-life PHP gets no security fixes | Review twice a year |
| 6 | Least-privilege roles | Limits damage from a stolen login | Quarterly review |
| 7 | One account per person | Accountability and fast offboarding | On every joiner and leaver |
| 8 | Strong unique passwords | Stops credential-stuffing attacks | Ongoing; reset after any incident |
| 9 | Two-factor authentication | A stolen password alone is not enough | Once; verify quarterly |
| 10 | Login rate limiting, XML-RPC off | Blocks brute-force attempts | Once; check after updates |
| 11 | Custom login URL | Reduces bot noise (minor measure) | Once |
| 12 | Disable file editing | Prevents code injection from the dashboard | Once |
| 13 | File permissions, wp-config, uploads | Stops uploaded scripts from running | Once; recheck after migrations |
| 14 | HTTPS and HSTS | Encrypts logins and customer data | Once; certificates auto-renew |
| 15 | Security headers | Mitigates XSS and clickjacking | Once; test after theme changes |
| 16 | WAF and CDN | Filters attacks before they reach WordPress | Always on; review rules monthly |
| 17 | Security-focused hosting | Isolation, current PHP, server scanning | Review at renewal |
| 18 | Off-site backups | Fast recovery from hacks or mistakes | Daily backup; test restore quarterly |
| 19 | Malware scanning | Detects infections early | Daily automated; monthly manual review |
| 20 | Monitoring and incident plan | Shortens time to detect and respond | Continuous; rehearse yearly |
Incident response: what to do if your WordPress site is hacked#
An incident response plan is a short, pre-agreed list of actions that limits damage when a site is compromised. Keep it on one page, stored outside the website.
- Contain. Enable maintenance mode or block traffic at the firewall. Do not delete files yet.
- Preserve evidence. Snapshot files, database and server logs before cleaning.
- Reset every credential: WordPress users, hosting panel, SFTP/SSH, database, API keys and domain email. Regenerate the wp-config.php salts.
- Find the entry point. Restoring a backup without closing the hole usually leads to reinfection.
- Clean or restore from a known-clean backup or fresh official files, then remove backdoors and rogue users.
- Notify where required. Jordan’s Personal Data Protection Law No. 24 of 2023 came into force on 17 March 2024 and, according to law firm Clyde & Co, requires controllers to notify the regulator within 72 hours of discovering a serious breach. In Saudi Arabia, DLA Piper notes the PDPL requires notifying SDAIA within 72 hours of becoming aware of a breach.
- Review. Request a Google Search Console review if the site was flagged, and record what you changed.
Jordan and GCC considerations#
- Bilingual sites add code. Arabic/English sites add a multilingual plugin, RTL adjustments and Arabic fonts, all of which need updating.
- Forms and WhatsApp buttons collect personal data. Protect forms from spam and injection, and store only the names and phone numbers you need.
- WooCommerce stores carry extra risk. Use your gateway’s hosted or tokenised checkout so card data never touches your server.
- The website owner is accountable. Data protection laws in Jordan and Saudi Arabia place duties on whoever controls customer data, not only the host.
How Consult One can help#
Consult One has built and maintained websites from Amman for businesses in Jordan, the GCC and the USA since 2004. Our WordPress development team builds on a lean, vetted plugin stack with hardening from day one. Our IT infrastructure and security services cover firewalls and endpoint protection, and our mail and web hosting gives WordPress sites a managed home with backups and current PHP.
Not sure how your site measures up against this checklist? Send us your URL and we will show you where the gaps are and what it takes to close them. Get a free quote
FAQ#
Is WordPress secure enough for a business website?
Yes, when it is maintained properly. WordPress core has a strong security record: Patchstack counted only six core vulnerability reports in 2025, compared with thousands in plugins. Business risk comes mainly from outdated or poorly coded plugins, weak passwords and neglected hosting. A site with a lean plugin stack, prompt updates, two-factor authentication, a firewall and off-site backups is a solid platform for most companies.
How often should I update WordPress plugins?
Check for updates at least weekly and apply security releases as soon as they appear, ideally the same day. Patchstack found that heavily exploited WordPress vulnerabilities reached mass exploitation in a weighted median of five hours in 2025. Enable automatic updates for trusted, well-maintained plugins and test larger version upgrades on a staging copy before pushing them to the live site.
Do I still need a security plugin if I use Cloudflare?
Usually, yes. Cloudflare filters malicious traffic at the network edge, but it cannot see inside WordPress. A security plugin or host-level tool adds login protection, two-factor authentication, malware scanning, file-integrity checks and activity logs. Use the edge firewall to stop attacks early and the WordPress tool to catch anything that slips through.
Does changing the WordPress login URL stop hackers?
No. Hiding /wp-login.php reduces automated bot traffic and log noise, but it is security through obscurity. Attackers exploiting a vulnerable plugin do not need the login page at all. Treat a custom login URL as a small extra layer on top of strong passwords, two-factor authentication, login rate limiting and prompt updates.
How should I back up a WordPress website?
Back up both files and the database automatically, and store copies outside your hosting account. CISA recommends the 3-2-1 rule: three copies of important data, on two types of media, with one copy off-site. Keep enough history to roll back to a point before an infection started, since malware can go unnoticed for a while, and test a full restore on a regular schedule.
What PHP version should a WordPress site use in 2026?
WordPress.org recommends PHP 8.3 or greater. PHP.net lists versions 8.4 and 8.5 under active support, while PHP 8.2 receives security fixes only until 31 December 2026, and versions 8.0 and 8.1 are end of life. Ask your host to move your site to PHP 8.3 or 8.4 after testing your theme and plugins on a staging copy.
