The Complete WordPress Security Checklist for 2027
A WordPress security checklist for 2027 comes down to four jobs: patch quickly, protect every login, shrink what you have installed, and prove you can restore the site. This guide turns those jobs into 30 checks. Each one tells you what to check, why it matters and how to verify it, and it says whether you, your host or both own the task.
The timing is not an accident. WordPress shipped four security releases in 41 days this autumn, from 7.1.1 on September 17 to 7.1.4 on October 28, according to the WordPress security team. Reports to its bug bounty program jumped from a usual 20 to 30 a month to 450 in July, and the team says AI research tools made much of that work faster. Faster discovery shortens the gap between a fix and an attack.
The 7.1.4 release closed a weakness in the upgrade process that could allow remote code execution during the upgrade window, as the official release notes describe it. Wordfence figures reported by Cybersecurity News counted more than 240,000 exploit attempts, starting the day the fix shipped. Nobody waited a week.
A checklist will not make a site unhackable. The official Hardening WordPress handbook says security is risk reduction, not risk elimination, and we agree. What a checklist can do is make you a harder target than the next site and make recovery dull instead of frightening.
Here is how to read the tags. Owner: You means whoever administers WordPress does the work. Owner: Host means your hosting provider controls it, so your job is to ask and verify. Owner: Both means each side has a part.
What Should You Check First When Securing a WordPress Website?
Check what is out of date, then check who has access. Core, plugins, themes and the PHP version come first because attackers scan for known flaws before they try anything clever. After that, review administrator accounts, remove dead plugins and run a first malware scan so you know your starting point.
Identifying outdated WordPress core, plugins and themes
Owner: You. Check: the Updates screen in the Dashboard, plus the Plugins and Themes lists, for anything pending. Note the exact WordPress version too. Only the most recent version is actively supported, and older branches get security backports as a courtesy.
Why it matters: once a fix ships, the information needed to exploit the flaw is effectively public, a point the official handbook makes plainly. The October 28 timeline above shows how fast that window closes.
How to verify: open Dashboard, then Updates, and confirm nothing is waiting. If your host gives you WP-CLI, wp core check-update and wp plugin list –update=available give the same answer in seconds. One caution: take a backup before a big batch of updates. A major plugin update can break a theme, and on a store you should try it on a staging copy first.
Checking PHP versions and hosting server configurations
Owner: Both. Check: the PHP version under Tools, Site Health, then the Info tab, in the Server section. According to the PHP release schedule, PHP 8.2 security support ends on December 31, 2026. From January 1, 2027, a site still on 8.2 gets no official fixes for new flaws.
PHP 8.3 stays covered until the end of 2027, and 8.4 and 8.5 run much longer. Pick 8.4 or 8.5 for anything you are moving this quarter. Most hosting control panels, including cPanel on shared web hosting, let you choose PHP per site. If you cannot find the setting, ask your host.
How to verify: Site Health shows the running version and warns when it is outdated. Also ask your host which web server and database versions they run. The handbook lists current stable server software as a sign of a trustworthy host. Friction to expect: an old plugin may throw a fatal error on a newer PHP, so switch off peak hours with the previous version one click away.
Reviewing administrator accounts and unused user permissions
Owner: You. Check: the Users screen, filtered to Administrator. Every admin should be a person you can name who needs that power today. Former staff, old agencies and accounts called test or temp need to be demoted or removed.
Why it matters: an attacker who gets one administrator login can install code that endangers the whole server. The handbook says so directly. A new admin you do not recognize is also one of the clearest signs of a hack in progress.
How to verify: run wp user list –role=administrator or read the screen line by line. Compare each name against a real person. When you delete a user, WordPress asks what to do with their posts. Reassign them. Deleting content because you were in a hurry is a mistake you cannot undo without a backup.
Identifying vulnerable, abandoned and unnecessary plugins
Owner: You. Check: every plugin for three things. When was it last updated, is it still needed, and does it have known vulnerabilities? A plugin with no update in a year or more deserves suspicion. That is our rule of thumb, not an official limit.
Why it matters: the handbook notes that hacked sites are rarely traced to the hosting infrastructure and most often to the application itself. Plugins are the biggest part of that application.
How to verify: open each plugin’s page on WordPress.org and read the last updated date and the support forum. Search the name in a vulnerability database such as Patchstack or WPScan. Then ask a harder question: would you notice if it vanished? If not, delete it. If a risky plugin runs something your site truly needs, build the replacement on staging first instead of ripping it out live.
Running an initial malware scan and website security assessment
Owner: Both. Check: run a scan now, before you change anything, so you have a baseline. A scanner that runs inside WordPress is useful but limited, because a compromised site can hide from its own tools. A scan at the server level sees files outside WordPress too, so ask your host what they run.
Why it matters: you cannot judge a change if you never saw the starting point. And if the scan finds something, you want to know before you spend a weekend hardening a site that is already infected.
How to verify: WP-CLI can compare your files against the official checksums.
wp core verify-checksums
wp plugin verify-checksums –all
find wp-content/uploads -name “*.php”
Any core file reported as modified needs an explanation. The last command lists PHP files inside uploads, where none should exist. If anything turns up, jump to the incident response check in the malware section below before you do anything else.
How Can You Protect WordPress Login Pages and Administrator Accounts?
Use long unique passwords, add two factor authentication for every privileged account, limit login attempts, give each person only the role they need, and force HTTPS on the admin area. The handbook says the most common attacks are crafted requests that hit known flaws and brute force password guessing. Your login page is half of that battlefield.
Enforcing strong passwords and unique administrator usernames
Owner: You. Check: every account has its own password from a password manager, and no administrator is called admin or webmaster. We suggest 16 characters or more. The handbook says to avoid names, dictionary words and anything built from your site or company name.
Why it matters: attackers do not guess so much as replay. Credential stuffing takes passwords leaked from other sites and tries them on yours, and a reused password falls in seconds.
How to verify: open the Users screen and look for the obvious usernames. Check that the password strength meter shows Strong when anyone changes theirs. To retire an account called admin, create a new administrator first, log in as that person, reassign the content, then delete the old one. Never delete your only working admin before you have tested the new one.
Enabling two-factor authentication for privileged accounts
Owner: You. Check: two factor authentication is on for every Administrator, Editor and shop manager account. WordPress does not enable it for you, so use a trusted plugin or login protection from your host. The official two step authentication guide recommends it alongside strong passwords.
Why it matters: a stolen password alone is no longer enough to get in. Prefer an authenticator app over text messages, since phone numbers can be hijacked.
How to verify: open a private browser window, log out, and sign in. You should be asked for the second step. Then test your recovery codes, because friction lives here. A lost phone with no recovery codes locks you out of your own site. Save the codes in your password manager and keep a second administrator with separate 2FA as a backup.
Limiting login attempts and suspicious authentication requests
Owner: Both. Check: something stops repeated failed logins. That can be a server rule, a firewall or a plugin. Server and firewall rules are better because they act before PHP loads, so ask your host what exists.
Why it matters: the official brute force guidance treats guessing attacks as routine. They are automated, constant and cheap for the attacker.
How to verify: try ten wrong passwords from a private window and confirm you get blocked or challenged. Then read your access log for the noisy sources.
grep “POST /wp-login.php” access.log | awk ‘{print $1}’ | sort | uniq -c | sort -rn | head
One trap: set the threshold sensibly, somewhere around five to ten tries. A strict limit locks out a whole office sharing one IP, and customers who mistype passwords at checkout.
Applying least-privilege user roles and permissions
Owner: You. Check: each person holds the lowest role that lets them do their job. Contributors and Authors write, Editors manage content, and Administrator is reserved for the few who install software and change settings. Agencies and freelancers get a temporary admin with an end date.
Why it matters: the handbook calls this containment. If one account is stolen, the damage should stop at what that account could do. A stolen Author login is an annoyance. A stolen Administrator login is a takeover.
How to verify: sort the Users screen by role and read down the list. On a WooCommerce store, include the shop manager role in your review. Before you demote anyone, ask what they actually do in the Dashboard. An editor who edits a plugin settings page may need a narrower fix than a blanket downgrade.
Securing administrator access with HTTPS and additional restrictions
Owner: Both. Check: the login and admin area only load over HTTPS. The official page on administration over SSL covers the setting, and the usual constant is define( ‘FORCE_SSL_ADMIN’, true ); in your configuration file. If your IP address is fixed, you can also restrict /wp-admin/ to it.
Why it matters: the handbook describes HTTPS for administration as the ultimate second layer, because passwords and session cookies never cross the network in the clear.
How to verify: visit the plain HTTP address of your login page. It should redirect to HTTPS. If you add a password prompt or IP rule to /wp-admin/, the handbook warns it can break admin-ajax.php, which many front end features use. Exempt that file, then test a contact form and a cart afterwards.
How Do You Secure WordPress Plugins, Themes and Core Files?
Turn on automatic security updates where you can, delete anything you do not use, install only from trusted sources, protect wp-config.php, lock down file permissions and watch for files that change without you. Attacks arrive mostly through software you installed, so this section deserves the most attention.
Enabling automatic security updates where appropriate
Owner: You. Check: core security releases update on their own, and plugins from reputable developers have auto updates switched on. WordPress has offered automatic updates since version 3.7, and the 7.1.4 announcement says sites that support background updates begin the update by themselves.
Why it matters: with four security releases in 41 days, manual patching on a weekly schedule is too slow. The gap between a release and an attack was a matter of hours on October 28.
How to verify: the Plugins screen shows whether auto updates are enabled for each one, and wp plugin list –fields=name,auto_update prints the same.
Here is the honest downside. An automatic update can break a site at 3 a.m. Daily backups and uptime monitoring turn that from a disaster into a ten minute fix. And do not set DISALLOW_FILE_MODS. It blocks updates and installs altogether.
Removing unused plugins, themes and abandoned extensions
Owner: You. Check: delete inactive plugins and themes, not just deactivate them. Keep one current default theme as a fallback in case your main theme fails. The handbook is blunt: if you are not using a plugin, delete it.
Why it matters: an inactive plugin is still code on your server, and its files can often be requested directly by URL. A flaw in dead code is still a flaw.
How to verify: run wp plugin list –status=inactive and wp theme list –status=inactive, or sort the Plugins screen by Inactive. Back up first, because deleting a plugin can remove its stored data. Some plugins also leave database tables behind after removal, so check for leftovers a month later and clean up with care.
Installing software only from trusted developers and sources
Owner: You. Check: where every plugin and theme came from. The handbook says to restrict yourself to the WordPress.org repository or well known companies, and to never download WordPress itself from any other site. Pirated copies of premium plugins are a favorite way to deliver malware.
Why it matters: a nulled plugin arrives with the backdoor already installed, and you will have installed it yourself, with admin rights.
How to verify: wp plugin verify-checksums –all checks plugins hosted on WordPress.org. Premium plugins will not appear there, so confirm those came straight from the vendor. An auto installer such as Softaculous gets you a clean WordPress to start from. After that, everything you add is your responsibility. Agencies should also check that shared licenses still receive updates, because a plugin that stops updating goes stale quietly.
Protecting wp-config.php and restricting file editing
Owner: You. Check: the configuration file is readable only by you and the web server, and the Dashboard code editor is switched off. The handbook says permissions of 400 or 440 are typical for this file. Some hosts need 600 or 640 for the site to load, so test after changing.
Add this line to turn off the theme and plugin editor.
define( ‘DISALLOW_FILE_EDIT’, true );
Why it matters: the built in editor is often the first tool an attacker uses after logging in, because it runs code. The handbook is clear that this will not stop uploads of malicious files, but it may stop some attacks. On Apache and LiteSpeed servers you can also deny web access to the file with a rule in .htaccess.
How to verify: the Theme File Editor should disappear from the Appearance menu. Then request your wp-config.php address in a browser. You should see a blank page or a denial, never source code. If you ever see code, treat it as an emergency and call your host.
Reviewing file permissions and monitoring unexpected file changes
Owner: Both. Check: the handbook’s example scheme sets directories to 755 and files to 644, with the WordPress root, wp-admin and wp-includes writable only by your user account. Only wp-content needs to be writable by the web server too.
find /path/to/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/wordpress/ -type f -exec chmod 644 {} \;
Why it matters: write access is how malware survives and spreads. If the web server cannot write to core files, a whole class of attack stops.
How to verify: list risky files with find . -perm 0777 and rerun wp core verify-checksums each week. Heavier tools such as OSSEC or inotify watch for changes in real time, but they need server access, so on shared hosting ask your host what they monitor. Friction alert: on some hosts the web server runs as a different user, and tight permissions break uploads and updates. After any change, upload an image and run a plugin update to test.
What Server-Level and Network Security Settings Should Every WordPress Website Have?
Every site needs a valid TLS certificate with HTTPS enforced, a firewall that filters bad traffic before WordPress loads, only the ports and services you actually use, a locked down database and a clear view of which endpoints are exposed. Most of this lives on the server. On shared hosting your host controls it, and your job is to ask and verify.
Configuring SSL/TLS certificates and enforcing HTTPS
Owner: Both. Check: the certificate is valid, covers both the www and non www names, renews on its own, and every HTTP request redirects to HTTPS. Confirm that the WordPress Address and Site Address in Settings use https. If you buy certificates separately, our SSL reseller program page covers one route.
Why it matters: the handbook warns that passwords and sensitive data cross untrusted networks in the clear when HTTPS is missing. It also protects visitors from page tampering on public WiFi.
How to verify: run curl -I http://example.com and look for a 301 redirect to the HTTPS address. Check for the padlock and scan a few pages for mixed content warnings. Add an HSTS header only after HTTPS works everywhere on the site. Start with a short lifetime, because browsers remember the rule and a mistake will lock visitors out until it expires.
Using a web application firewall and malicious traffic filtering
Owner: Both. Check: a firewall is active and in blocking mode, not just logging. The handbook describes three layers. Plugins work inside WordPress, a server level firewall such as ModSecurity filters before WordPress loads, and a DNS level service like CloudFlare sits in front of your server entirely.
Why it matters: a firewall can stop known attack patterns while you work on patching. The October 28 flaw is a useful lesson. Wordfence’s own timeline, as reported, shows paid customers got a rule about three hours after release while free users waited 30 days, and it noted a plugin firewall might not cover the extracted installer. A firewall buys time. It does not replace the update.
How to verify: read the firewall logs and confirm blocks are actually happening. Then watch for false positives. Some rules block legitimate editor saves or checkout steps. After you enable a firewall, test saving a post and placing a test order.
Restricting unnecessary ports, services and directory listing
Owner: Host on shared plans, You on your own server. Check: only ports 80 and 443 are public, SSH is restricted, FTP is replaced by SFTP, and the database port is not reachable from the internet. Turn off directory listing so nobody can browse your folders. The handbook recommends SFTP because it encrypts the password in transit.
Why it matters: every open service is one more thing to patch and attack. Visitors only ever need web ports.
How to verify: from a different network, scan your own server with a tool like nmap and read the list of open ports. Then open /wp-content/uploads/ in a browser. You should see a denial or a blank page, not a file list. If you manage a VPS or a dedicated server, these settings are yours. Before you close FTP, move any old deployment scripts to SFTP, or they will fail without warning.
Securing database access and server credentials
Owner: Both. Check: each site has its own database and its own database user, with a long unique password stored in wp-config.php. Remote database connections stay off unless something needs them. The handbook calls separate databases a containment strategy, since one cracked site cannot reach the others.
Why it matters: a shared database user turns one weak site into many compromised ones. The same logic applies to hosting panel, SFTP and SSH credentials. Rotate them when staff leave, and use SSH keys where possible.
How to verify: run SHOW GRANTS for the database user in phpMyAdmin and confirm it only touches that one database. One note on tempting advice. The handbook says normal operation needs only read and write privileges. It also warns that revoking structural privileges can make updates fail, so skip that step unless you hold tested backups. Changing your security salts logs everyone out, so do it after a compromise, not as routine.
Reviewing XML-RPC, REST API and other exposed endpoints
Owner: You. Check: what is publicly reachable. Test /xmlrpc.php, /wp-json/wp/v2/users, /?author=1, readme.html, wp-content/debug.log, and any .sql, .zip or .bak files sitting in the web root. A forgotten database dump in a public folder is worse than any plugin flaw.
Why it matters: attackers use XML-RPC to guess passwords in bulk and the user lists to find usernames. The WordPress hosting handbook notes the REST API lets anyone see many of a site’s users. But do not simply switch either one off. Jetpack, the mobile apps and some publishing tools rely on XML-RPC. The block editor, WooCommerce and countless plugins rely on the REST API.
How to verify: read your access log first. If nothing legitimate calls xmlrpc.php, block or rate limit it, then test your integrations. For REST, leave it running and restrict only the anonymous user listing if your theme does not need it. Check author pages and embeds afterwards. Also set WP_DEBUG to false in production, because the debug log can sit in a public folder and expose paths and errors.
How Can You Protect WordPress Websites From Malware, Data Loss and Cyberattacks?
Scan on a schedule, watch logs and login activity, run automated backups of files and database, store encrypted copies away from the server, and test a restore before you need one. Prevention fails sometimes. Detection and recovery decide whether a hack costs you an afternoon or a month.
Scheduling regular malware scans and vulnerability checks
Owner: Both. Check: a malware scan runs at least daily on the server side, and a vulnerability check of your plugins and themes runs weekly against a current database. Add an external scan of your public pages monthly to catch injected spam links.
Why it matters: new flaws are disclosed for software you already run. The WordPress project says it closed more than 50 Critical or High vulnerabilities in core since mid July. Plugins get disclosures at least as often.
How to verify: open the latest report and check the date.
Then ask a harder question. Where do the alerts go? An alert sent to a former employee’s inbox protects nobody. Send a test alert and confirm a living person reads it. A scan nobody reads is not a scan.
Monitoring suspicious login attempts and website activity
Owner: You. Check: an activity log records logins, new users, role changes, plugin installs and file edits. The handbook says logs show the IP, the time and the actions taken, which is exactly what you need after an incident.
Why it matters: attackers leave traces, and early detection shortens the damage. Watch for new administrators, plugin installs at strange hours and bursts of requests to the login page. Watch outbound email too. A sudden spike from your site is a classic sign of compromise, and sending through a dedicated service, such as the option on our MailChannels corporate email page, makes the spike easier to spot.
How to verify: trigger a harmless test event, like creating and deleting a test user, and confirm it appears in the log. Add an uptime monitor that checks every few minutes and also checks page content, so a defaced home page still raises an alarm.
Creating automated database and website file backups
Owner: Both. Check: backups run automatically, cover the database, wp-content and your configuration file, and keep several generations. The handbook offers a clear example. A site compromised on May 1 but noticed on May 12 needs backups from before May 1, which only exist if you kept more than a few days of history.
Why it matters: backups are the only fix that works against every attack, including the ones you never saw coming. On a busy WooCommerce store, orders arrive constantly, so match database backup frequency to order volume. Daily may lose a full day of sales.
How to verify: list the backup files and check their dates and sizes. A suspiciously tiny file usually means a failed job. You can export the database yourself with wp db export backup.sql. Ask your host how long they keep backups and how a restore works. One more trap: backup plugins on large sites can time out silently, so check that the last run actually finished.
Storing encrypted backups outside the production server
Owner: You, or Both if your host stores copies elsewhere. Check: at least one copy lives on a different provider or account, encrypted, and out of reach of the site’s own credentials. The handbook suggests encryption, independent hash records and read only media to prove backups were not tampered with.
Why it matters: a backup on the same server dies in the same disaster. Worse, if an attacker finds cloud storage keys in your configuration file, they can delete your remote copies too. Use write only credentials or versioned storage so a stolen key cannot erase history.
How to verify: log in to the offsite location from a different device and download one file. Compare its checksum with sha256sum. Encrypt before upload with a tool such as gpg –symmetric –cipher-algo AES256. Then store the passphrase in your password manager, away from the server. An encrypted backup whose key lives only on the hacked machine is a locked box with no key.
Testing website restoration and preparing an incident response plan
Owner: Both. Check: you have restored a full backup to a staging address and timed it, and you have a one page incident plan. A backup you have never restored is a hope, not a backup. The plan names who decides, who calls the host, and how to take the site offline fast.
Why it matters: during an attack nobody thinks clearly. A written order of steps saves hours. Ours runs like this: isolate the site, copy the logs and files for evidence, restore a clean backup from before the compromise, update everything, then rotate every secret. That means WordPress passwords, database password, salts, API keys, SFTP and hosting panel logins. Then find the entry point, or the attacker walks back in.
How to verify: after the staging restore, confirm that login works, media loads, forms send and plugin settings survived. Write down how long it took. If your site holds customer data, check your legal duties as well, because breach notice deadlines are short in many regions. If you host with us, our 24/7 support team can help with the server side of a recovery. The official site was hacked FAQ is a good companion.
How Often Should You Perform WordPress Security Maintenance in 2027?
Check alerts and backups daily, review updates, scans and logs weekly, audit accounts, permissions and server settings monthly, and run a vulnerability assessment plus a full restore test every quarter. Then write it all down so it survives staff changes. Small, steady habits beat a heroic annual cleanup.
Daily checks for security alerts, backups and suspicious activity
Daily work should take about five minutes. The goal is to spot trouble early, not to investigate every notification.
- Confirm last night’s backup finished and the file size looks normal.
- Read new security alerts from your scanner, firewall and host.
- Check uptime monitor history for outages or content changes.
- Glance at failed login counts for sudden spikes.
If you manage many sites, send all alerts to one shared inbox, and make sure a named person owns it. Daily checks only work when someone is clearly responsible. Skip them for a week and you will discover a failed backup on the one day you need it.
Weekly reviews of plugin updates, malware scans and website logs
Weekly work is where the real maintenance happens, and it takes 20 to 30 minutes per site. Set a fixed day so it does not drift.
- Apply plugin and theme updates that did not install automatically, after a backup.
- Read the latest malware and vulnerability scan results.
- Review the activity log for new users, role changes and plugin installs.
- Run wp core verify-checksums and look for modified files.
- Open Site Health and clear any critical warnings.
Security releases do not wait for your weekly slot. When WordPress announces one, apply it the same day. Weekly is the floor for routine updates, not the schedule for emergencies.
Monthly audits of user accounts, permissions and server settings
A monthly audit takes about an hour and catches slow drift. People leave, plugins pile up and settings change without anyone noticing.
- Review every administrator and every role against current staff and agencies.
- Delete unused plugins and themes, and check for abandoned ones.
- Check the PHP version and read your host’s announcements.
- Confirm the TLS certificate renews and has weeks left.
- Skim firewall blocks for false positives affecting real customers.
- Confirm two factor recovery codes are still saved.
Use the audit to ask what changed since last month. Anything you cannot explain is the place to dig. An unexplained admin, an unfamiliar plugin or a new open port is worth ten minutes of your attention.
Quarterly vulnerability assessments and backup restoration tests
Every three months, step back and test the whole system instead of its parts. This is where you find out whether your habits actually work.
- Run a full vulnerability assessment of core, plugins, themes and server software.
- Restore a backup to staging and time it.
- Review XML-RPC, REST and other exposed endpoints against your access logs.
- Rotate credentials for departed staff and shared accounts.
- Reread the incident plan and update the contact list.
Use this slot for lifecycle planning too. PHP 8.3 security support ends on December 31, 2027, so the move to 8.4 or 8.5 belongs on your 2027 calendar, not your December panic list. Test the move on staging in the third quarter.
Maintaining a documented WordPress security checklist for every website
Write one page per site and keep it somewhere the whole team can reach. It should list the site owner, hosting contacts, PHP and WordPress versions, every plugin and why it exists, who holds admin access, where backups live and how to restore them, and the date of the last audit.
Documentation turns knowledge from one person’s head into a process. When someone leaves, the checklist stays. When an incident hits at midnight, nobody has to guess where the backups are.
Agencies managing many sites benefit most. Use one template for every client and keep each client site in its own hosting account, so a breach in one cannot reach the rest. Our reseller hosting plans are built around separate accounts for exactly that reason. Whatever host you choose, tick every box on this list, and treat it as a living document.
You now have 30 checks, a clear split between your job and your host’s, and a routine that fits into a few hours a month. If you want a host that takes the server layer off your plate, compare the security, uptime and backup features on our reseller features page and see what comes with each plan.
