WordPress Security Checklist: Protect Your Site in 2026

Most WordPress sites are not hacked through clever, targeted attacks. They are hacked by bots running automated scans against millions of sites, looking for three things: a plugin or theme with a publicly disclosed vulnerability, a weak or reused admin password, and an exposed login endpoint. Almost every cleanup job traces back to one of those, not to a sophisticated zero-day.

That is good news, because all three are fixable with configuration you control. This checklist is ordered roughly by impact-per-minute: the items near the top stop the most attacks for the least effort. Where a step needs an exact file edit or plugin setting, the specific path is given so you can do it without guessing.

The few things that actually stop most attacks

If you only have an hour, do these four. They close the doors that automated bots walk through.

1. Update core, plugins, themes, and PHP, and reduce what you have to update

When a plugin vulnerability is disclosed publicly (for example in the WPScan or Wordfence vulnerability database), exploit code is usually circulating within days. Bots then scan for sites still running the old version. The fix is unglamorous: stay current, and run fewer plugins so there is less to keep current.

• WordPress core: Keep it on the latest stable release. Minor (security) releases auto-install by default; leave that on. You can force it explicitly in wp-config.php with define( 'WP_AUTO_UPDATE_CORE', 'minor' );.
• Plugins and themes: Update promptly, especially anything flagged as a security release. In Dashboard > Updates you can enable auto-updates per plugin; for a low-traffic brochure site, enabling auto-updates on everything is usually safer than letting updates pile up.
• PHP version: Run a version that still receives security patches. As of 2026, PHP 8.1 has reached end of life, so move to PHP 8.2 or 8.3. On most Indian shared hosts (Hostinger, A2 Hosting, cPanel-based providers) this is under cPanel > Select PHP Version or MultiPHP Manager. Test on staging first, because very old plugins may break.
• Delete what you do not use. An inactive plugin or an unused default theme still ships exploitable code on your server. Deactivated is not enough. Delete it.

If you manage several sites, a free service like the WordPress.org-hosted dashboard, ManageWP, or MainWP lets you see and push updates across all of them from one screen, which is far more reliable than remembering to log into each site.

2. Strong unique passwords plus two-factor on every admin account

Brute-force and credential-stuffing bots try common combinations and passwords leaked in past breaches. "admin / Password@123" or your business name with a year on the end falls almost immediately. Two defences make this a non-issue:

• Use a password manager (Bitwarden is free and open source; 1Password is a solid paid option) to generate a random 20+ character password for every account. You never type or remember it, so there is no reason for it to be weak or reused.
• Turn on two-factor authentication (2FA) for every Administrator and Editor account. The free 2FA plugins WP 2FA or the Two-Factor plugin add a TOTP code (Google Authenticator, Authy) on top of the password. Even a correctly guessed password is then useless without the phone. Prefer an authenticator app over SMS, since SIM-swap fraud is a real risk in India.

Also rename the default admin account. Create a new Administrator user with an unguessable username, log in as that user, and delete the old admin (assigning its content to the new user). Bots try admin first; not having it removes half their guess.

3. Lock down the login page and XML-RPC

By default anyone can hammer /wp-login.php and /xmlrpc.php endlessly. Close that off:

• Limit login attempts. Wordfence, Solid Security (formerly iThemes), or the lightweight Limit Login Attempts Reloaded plugin will lock out an IP after a handful of failures. This alone makes password-guessing impractical.
• Add a CAPTCHA or move the login URL. WPS Hide Login changes /wp-admin to a path only you know. It will not stop a targeted attacker, but it makes you invisible to the generic bots that only know the default URL.
• Disable XML-RPC if you do not use it. It is an old API abused for brute-force amplification and DDoS. The Jetpack app and some publishing tools still need it, but most sites do not. To block it, add to .htaccess (Apache):

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

On Nginx, the equivalent is location = /xmlrpc.php { deny all; }. Most security plugins also offer a one-click toggle for this.

4. Have working, off-site, restorable backups

No defence is perfect, so backups are what turn "we got hacked" into "we restored in twenty minutes." A backup you have never restored is a guess, not a safety net.

• Frequency: daily for a normal business site; for a WooCommerce store taking orders, real-time or hourly so you do not lose transactions.
• Scope: the full site: database, files, and the uploads/media library together.
• Off-site storage: never only on the same server as the site. UpdraftPlus (free) and WPvivid send backups to Google Drive, Dropbox, or AWS S3. BlogVault and Jetpack VaultPress are paid services that store backups independently and include one-click restore.
• Test it. Once a quarter, restore to a staging site and confirm it actually comes back. Keep at least 30 days of history, because a compromise can sit unnoticed for weeks.

Hardening that closes the remaining gaps

5. Choose hosting that does security work for you

On cheap shared hosting you share a server with hundreds of other sites, and a compromise next door can spill over. Better hosting bakes in protections you would otherwise bolt on. Look for a Web Application Firewall (WAF), server-side malware scanning, automatic off-site backups, easy PHP version switching, and SSH/SFTP access for safe file management.

For Indian businesses, realistic options range from budget shared plans (Hostinger India, A2 Hosting) to managed cloud and managed WordPress (Cloudways, Kinsta, WP Engine, SiteGround). Managed WordPress hosts typically cost more but handle core updates, server hardening, and backups for you. One India-specific note: hosting a server physically in or near India (or using a CDN with Indian edge locations) noticeably lowers latency for local visitors, a separate concern from security, but worth checking when you pick a host. Talk to us if you want help choosing.

6. Force HTTPS everywhere

SSL/TLS encrypts traffic between visitors and your server, prevents Chrome and other browsers from showing a "Not secure" warning, and is a confirmed (if small) Google ranking signal. Practically every host now issues a free Let's Encrypt certificate; if yours charges for basic SSL or makes it hard, treat that as a warning sign about the host.

After the certificate is active:

• Set both WordPress Address and Site Address in Settings > General to the https:// versions.
• Fix old http:// links and images already in your content (the free Better Search Replace plugin does a database-wide swap safely).
• Add a 301 redirect so every HTTP request lands on HTTPS. The free Really Simple SSL plugin handles this and the mixed-content cleanup automatically.
• Test the result at ssllabs.com/ssltest. Aim for an A or A+; a lower grade points to a real configuration weakness.

7. Protect wp-config.php and set sane file permissions

Your wp-config.php holds the database credentials and security keys; it is the most sensitive file on the site. The standard, safe permission scheme is:

• Directories: 755
• Most files: 644
• wp-config.php: 640 (or 440 on hosts that allow it)

Never set anything to 777: that makes a file world-writable and is a classic way malware persists. Two quick hardening steps that genuinely help:

Block direct web access to wp-config.php via .htaccess:

<Files wp-config.php>
  Order Allow,Deny
  Deny from all
</Files>

And stop PHP from executing inside the uploads folder, which is where injected backdoors love to hide. Create wp-content/uploads/.htaccess containing:

<Files *.php>
  Deny from all
</Files>

Also rotate your security keys: regenerate the salts from the api.wordpress.org/secret-key generator and paste them into wp-config.php. This logs everyone out and invalidates stolen session cookies, useful immediately after any suspected compromise.

8. Monitor so you find out before Google does

Security is continuous because new vulnerabilities surface constantly. Set up monitoring so a problem reaches you, not your customers:

• Uptime: UptimeRobot (free) or Pingdom alerts you when the site goes down, which is often the first symptom of an attack.
• Malware and file-integrity scanning: Wordfence or Sucuri compares your core files against the official versions and flags unauthorised changes. Run a full scan weekly and review what it finds.
• Failed-login logs: repeated failures from one IP or country mean you are being probed; your login-limiter plugin records these.
• Google Search Console: verify your property and enable email notifications. If Google flags your site for malware, you will usually hear it here first, and a flagged site can be dropped from search results or shown with a warning, directly costing traffic and trust.

Two myths worth correcting

"My site is too small to be a target"

Targeting is automated and indiscriminate. Bots do not check your traffic before attacking; they scan IP ranges and known WordPress paths and exploit whatever is vulnerable. A small bakery site in Indore is attacked by the same scanners as a large publisher. Often a compromised small site is not even the goal. It is quietly turned into a host for spam, phishing pages, or further scanning.

"Good hosting means I do not need to harden WordPress"

Host security and application security are different layers. The host protects the server and network; nothing it does can patch an outdated plugin running inside your WordPress install, because that is your application code. A site on premium hosting still gets compromised if it runs a vulnerable plugin. You need both layers.

A practical first-week plan

If this list feels like a lot, here is the order that buys you the most protection fastest. Most of it is doable in an afternoon:

1. Install Wordfence or Solid Security (free tier) and run a full scan.
2. Enable 2FA on every Administrator account and replace weak passwords with password-manager-generated ones.
3. Confirm core, plugins, themes, and PHP are current; delete anything inactive.
4. Verify a real, off-site backup exists and do one test restore.
5. Add the login limiter, disable XML-RPC if unused, and rename the admin account.

The .htaccess and file-permission steps are for when you are comfortable editing files, or when someone technical can do it for you. After the initial setup, the ongoing cost is roughly half an hour a month to check updates, scan, and confirm backups, far cheaper than recovering a hacked site. If you would rather hand this off, see our services.