WordPress Security Checklist: Best Practices in Priority Order

Most WordPress sites get hacked through a few predictable doors. The usual ones are outdated or pirated plugins and themes, weak passwords, and a compromised browser on the computer used to log in. So a WordPress security checklist should close those first: take a backup, update or delete plugins, and lock down logins. Hosting, server settings and monitoring come next.

I have fixed more than 20 hacked sites, and most of them ran WordPress. Below is the checklist in the order I recommend for a small business site, with my own site as the worked example. It ends with what a hack does to your Google rankings, and how to recover.

How WordPress sites actually get hacked

These are the four ways in that I have seen most often:

1. Outdated plugins and themes. A plugin with a known hole stays open until someone updates or removes it. Patchstack, a WordPress security vendor, counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025. Its State of WordPress Security in 2026 report says “91% of new vulnerabilities were found in plugins, and 9% were found in themes.”
2. Weak passwords and brute-force attacks. In a brute-force attack, WordPress.org explains, “an attacker repeatedly tries username/password combinations until one works.” It adds that “even unsuccessful attacks can overwhelm your site with requests.”
3. Bad browser extensions. The computer you log in from is part of your site’s security. Chrome can let an extension “read and change all your data on websites you visit”. That includes your dashboard while you are logged in.
4. Nulled plugins and themes. These are pirated copies of paid plugins and themes. Google warns that “It’s a common tactic for attackers to add malicious code to free versions of paid plugins or themes.” The license fee you save can cost you the whole site.

Is WordPress the most hacked platform?

It is the biggest target because it is the most used CMS. W3Techs says WordPress runs 39.5% of all websites, as of 2 November 2026. But the core software is rarely the weak point. Patchstack found only 6 vulnerabilities in WordPress core in 2025, and called them “low priority issues.” The risk sits in what you add on top.

The WordPress security checklist, in priority order

Work in this order: a backup first, then updates, then logins. Plugins carry most of the risk, so updates come early. The backup comes before them, because WordPress.org says to back up “always before an upgrade.”

If you do nothing else, do the first three rows. The full checklist for each area follows.

Updates, plugins and themes

• Update core, plugins and themes. WordPress.org’s Hardening WordPress guide is blunt: “Older versions of WordPress are not maintained with security updates.” Patchstack found that “approximately half of high impact vulnerabilities get exploited within 24 hours.” A monthly update round is too slow for those.
• Turn on auto-updates where you can. Since WordPress 5.5, you can switch on auto-updates plugin by plugin, from the “Automatic update” column on the Plugins screen. Keep recent backups, so a bad update is easy to undo.
• Delete what you don’t use. The hardening guide says “if you are not using a specific plugin, delete it from the system.” Google adds: “remove all its files from your server rather than just disabling it.” The same goes for spare themes.
• Install only from trusted sources. WordPress.org’s rule is “Do not get plugins/themes from untrusted sources.” Use its plugin directory or well-known developers, and replace any nulled copy with a licensed one.
• Replace abandoned plugins. An update only helps if the developer ships one. Patchstack found that “46% of vulnerabilities did not receive a fix from the developer in time for public disclosure.” If a plugin has stopped getting updates, replace it.
• Check Site Health. In the dashboard, Tools > Site Health flags outdated PHP and pending updates. Its Info tab lists inactive plugins and themes you can remove.

Logins and users

• Unique, long passwords. WordPress.org’s brute-force guide says: “Encourage unique, long passwords (or passphrases) and the use of password managers.” Never reuse your WordPress password anywhere else.
• Two-factor login for every admin. The same guide says to “Enable 2FA for all administrators and privileged users.” WordPress core does not include it, so add it with a reputable plugin.
• No “admin” username. The guide is plain: “Do not use the username admin.”
• Limit login attempts. If your host or CDN does not rate-limit logins, “a security plugin can throttle login attempts.” A CAPTCHA on the login form also slows bots down.
• Turn off XML-RPC if you don’t need it. WordPress.org says: “If you don’t use XML-RPC, disable it.” Check first that no app or service you rely on uses it.
• One account per person, with the lowest role that works. Google lists excessive admin access among the security policy holes attackers use. Remove accounts for former staff, freelancers and agencies as soon as the work ends.
• Keep login names private. If no author slug is set, WordPress builds it from the login name. Its source code says: “Otherwise build a nicename from the user_login.” Also open yoursite.com/wp-json/wp/v2/users and check what it lists.
• Clean up the browser you log in from. Remove extensions you don’t use or trust. Chrome’s help says: “Make sure you only approve extensions that you trust.” WordPress.org’s hardening guide agrees: “Make sure the computers you use are free of spyware, malware, and virus infections.”

Hosting, server and database

• A supported PHP version. WordPress recommends “PHP version 8.3 or greater.” PHP 8.2 gets security fixes only until 31 December 2026. Ask your host how to switch, and test the site after you do.
• HTTPS everywhere. The hardening guide recommends you “require an HTTPS SSL encrypted connection for administration.” If any page still loads over plain http, fix that first.
• Disable the dashboard file editor. Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php. WordPress.org is honest about its limits: it “will not prevent an attacker from uploading malicious files to your site, but might stop some attacks.”
• Tight file permissions. The hardening guide uses 755 for folders and 644 for files. For wp-config.php, restricting reads “generally means a 400 or 440 permission.”
• Security headers. OWASP says the right HTTP response headers “can help prevent security vulnerabilities like Cross-Site Scripting, Clickjacking, Information disclosure and more.” It also says: “Remove all X-Powered-By headers.”
• A firewall in front of the site. WordPress.org notes that a website firewall can sit between internet traffic and your hosting server. Your host, a CDN or a plugin can provide one.
• Ask your host the hard question. WordPress.org warns that on a shared server, one compromised site can expose yours “even if you follow everything in this guide.” So ask your host what precautions it takes. My guide to hosting and cloud providers in India covers what else to ask.

Database security. WordPress.org says the database user “only needs data read and data write privileges”: SELECT, INSERT, UPDATE and DELETE. Some plugins and major updates need more, so check with your developer before restricting them. Give each site its own database and user. On a new install, pick a table prefix other than wp_, which “can block at least some SQL injection attacks.”

Backups you can actually restore

• Back up both parts. WordPress.org’s backup guide says: “There are two parts to backing up your WordPress site: Database and Files.” One without the other will not bring the site back.
• Match the schedule to how often the site changes. “For smaller websites with fewer posts, backups should be made once a week.” Busy sites with many posts should back up daily.
• Keep three copies in three places. The guide says to keep at least three backups. Put one on the hosting server, one in cloud storage such as Google Drive or Dropbox, and one on your own computer.
• Keep older copies too. A hack is not always noticed the day it happens. The hardening guide’s example is a site “compromised on May 1st but the compromise is not detected until May 12th.” Older backups let you rebuild from a clean point.
• Test a restore. A backup you have never restored is a hope, not a plan. Restore to a staging copy now and then.

Monitoring: how you find out early

• Search Console. It is one of the free Google tools I use most. Verify your site so you can see the Security Issues report. If Google finds your site was hacked, or could harm visitors, its findings appear there.
• A monthly site: search. Search Google for site:yourdomain.com. Google’s guide to spotting a hacked site uses this search to find pages a hacker may have added. Look for pages in languages or on topics you never published.
• Uptime monitoring. WordPress.org’s monitoring guide says “A combination of internal and external uptime monitoring is ideal for users.” An outside check alerts you when the site stops responding.
• Logs, files and users. Check your server logs and watch for changed files. Once a month, look in Users for admins nobody recognizes.

Worked example: how I hardened this site in October 2026

This site runs WordPress with an Elementor-based theme, on Hostinger shared hosting with a LiteSpeed server. On 28 October 2026, I hardened it. Here is what changed, by area.

On unfiltered uploads, Elementor’s help page itself warns that “uploading any files, including SVG files, may present a potential security risk.” Three lessons from the day:

• PHP 8.2 was on a deadline. Its security support ends on 31 December 2026, so the move to 8.4 was due anyway. Moving PHP and turning on page caching that evening also lifted the homepage’s mobile PageSpeed lab score from 61 to 91. I cover that in my Core Web Vitals guide.
• Hiding version tags is the weakest item on the list. WordPress.org says “Security through obscurity is generally an unsound primary strategy.” Hidden tags are a small extra. The real protection is keeping the versions behind them current.
• Host backups were the gap. Weekly backups that I could not trigger by hand fall short of three copies in three places. Until the off-site daily backup is running, the site depends on the host’s weekly copy.

What SEO poisoning is, and how a hack hurts your Google rankings

SEO poisoning is when attackers use hacked sites to push their own pages up in search results. Trend Micro describes malware “making search engines display the threat actors’ lure pages as if these were placed on the compromised websites.” Your site’s reputation does the ranking work for them.

Google’s spam policies define hacked content as “any content placed on a site without permission, due to vulnerabilities in a site’s security.” They list four forms:

• Code injection: malicious code added to existing pages.
• Page injection: new spam or malicious pages added to your site.
• Content injection: existing pages quietly changed.
• Redirects: code that sends some visitors to harmful or spammy pages.

The best-known example is the Japanese keyword hack. It uses Japanese keywords on hacked sites to send searchers to fake Japanese shops. Trend Micro, citing Japan’s JC3, says “47,278 fake e-commerce sites were reported to JC3 in 2023.” Netcraft has documented a marketplace called Hacklink that sells access to compromised sites. Prices are “often starting at just $1 per listing,” and buyers use them for hidden links to phishing pages, fake pharmacies and casinos.

You may not see any of it. Google says “it’s not uncommon for the hacker to use cloaking to make the hack harder for the site owner to detect.” Cloaking shows search engines one thing and people another.

The damage to search comes in three forms:

• A warning on your search result. Google may label your result “This site may be hacked”. It does this when it believes “a hacker might have changed some of the existing pages on the site or added new spam pages.”
• Browser warnings. Search Console’s help says affected pages “can appear with a warning label in search results or an interstitial warning page in the browser.”
• Lower rankings. Google’s spam policies say “Sites that violate our policies may rank lower in results or not appear in results at all.”

Cleanup in search takes time, too. When you ask for a review after fixing the site, Google says it “can take from a few days to a few weeks.”

One distinction matters. Pages added without your permission are hacked content. If you let a third party publish pages to ride on your site’s rankings, Google’s site reputation policy applies instead.

If your site is already hacked

Work in this order, based on Google’s help for hacked sites:

1. Take the site offline. Google’s advice is to “Take your site offline so that it no longer serves content to users.” Tell your host what happened.
2. Change every password. That means hosting, FTP, database and WordPress logins, for every user.
3. Restore a clean backup, if you have one. Google’s cleanup guide says: “First, check that your backup was created before your site was hacked.” Without one, the site needs a manual clean.
4. Find the way in and close it. Start with the four doors at the top of this page. If the hole stays open, Google warns that the site can be reinfected.
5. Update everything and remove what you don’t use. Then check the user list for admin accounts you did not create.
6. Ask Google to review. Once every page is clean, request a review from the Security Issues report in Search Console.

If Google shows spam pages in Japanese or another language under your domain, follow my Japanese keyword hack cleanup checklist.

Where to start this week

Start with the first three rows: a backup off the server, updates with unused plugins deleted, and two-factor login for every admin. Then work down the list one row at a time, and check the Security Issues report every month.

If nobody owns updates, backups and security warnings on your site, that is what my website maintenance and support covers. Tell me what your site runs on, and we can start with an access check and a full backup.