Around 97% of hacked CMS sites run WordPress. Not because WordPress has uniquely terrible security architecture — it doesn't — but because of raw market share combined with a very specific pattern that plays out constantly across India: a developer builds a site in 2021, hands it over to the client, and nobody touches the plugins again for three years. I've seen this repeatedly with Kerala businesses running WordPress 5.x with form plugins and slider plugins from 2019, some on BSNL-hosted shared servers where the control panel itself hasn't been updated. These sites aren't hacked because WordPress is broken. They're hacked because they're abandoned.
The good news is that most WordPress attacks are automated and unsophisticated. Bots scan IP ranges looking for known vulnerable plugin versions, default login URLs, and weak passwords. If your site isn't trivially exploitable, the bot moves on. These 21 tweaks are ordered by how much attack surface they remove — work through the tiers in sequence and you'll eliminate the overwhelming majority of real-world attack vectors.
Tier 1 — High Impact, Easy Wins (Do These First)
These seven changes take under an hour combined and handle the attack patterns that compromise most WordPress sites in the wild.
1. Keep WP Core, Plugins, and Themes Updated
This single item is responsible for more successful WordPress compromises than everything else on this list combined. A vulnerability discovered in a popular plugin gets weaponised within 24-72 hours of the disclosure. Sites still running the vulnerable version at the 72-hour mark are swept up in mass exploitation.
Enable automatic minor version updates in wp-config.php by adding define('WP_AUTO_UPDATE_CORE', true); — this handles security-only point releases without your input. For plugins, go to Dashboard > Updates > Auto-update and enable it per-plugin. Major version updates (WordPress 6.x to 7.x if it happens) require manual review before applying.
2. Delete Inactive Plugins and Themes
Every plugin installed on your WordPress site — even deactivated ones — is accessible on your server. If a deactivated plugin has a file-inclusion vulnerability, an attacker can still exploit it. The same applies to bundled themes like Twenty Twenty-One that you never activated but never deleted. Go to Plugins > Installed Plugins, filter by Inactive, and delete everything you're not actively using. Do the same under Appearance > Themes.
3. Change the Default Admin Username
Every brute-force script in existence tries "admin" as the first username. If your WordPress admin username is "admin," you've handed attackers half the credential pair they need — they only need to crack your password. There's no in-dashboard rename option, so either create a new admin account with a different username, migrate all content to it, then delete the old "admin" account; or use WP-CLI: wp user update 1 --user_login=yournewusername.
4. Enforce Strong Passwords and 2FA
WordPress enforces password strength on the registration screen but doesn't force it on existing accounts or prevent password reuse. Install the WP 2FA plugin or Wordfence's built-in 2FA (if you're running Wordfence already). Set it to require 2FA for Administrator and Editor roles. A 12-character random password plus TOTP 2FA makes brute-force attacks computationally infeasible against your login endpoint.
5. Install a Security Plugin — Honest Comparison
Three credible options for Indian WordPress sites:
- Wordfence Free: Firewall (learning mode then enforcement), malware scanner, login protection, 2FA. The free tier has a 30-day delay on new firewall rules — a real limitation for high-value targets, but adequate for most SME sites.
- Sucuri Free: Excellent external monitoring and SiteCheck scanner. The free plugin adds basic auditing but lacks the active firewall of Wordfence. Sucuri shines in its paid cleanup service.
- Solid Security (formerly iThemes Security): Good for non-technical site owners — the setup wizard covers most Tier 1 items in a guided flow. Less granular control than Wordfence for power users.
For most Kerala SME sites, Wordfence Free is the starting point. Add Sucuri's free SiteCheck scan monthly as an external sanity check.
6. Enable Automatic Malware Scanning
Wordfence's free scanner runs on a schedule — go to Wordfence > Scan > Manage Scan to set it to daily. Enable email alerts for new threats found. The scanner compares your WordPress core files against the official checksums from WordPress.org, flags any additions or modifications, and checks plugins and themes against known malware signatures. A daily scan means you catch a compromise within 24 hours rather than discovering it when Google blacklists your domain.
7. Limit Login Attempts
Install Limit Login Attempts Reloaded (free, 1M+ active installs). Set it to 3 attempts allowed before a 20-minute lockout, and 4 lockouts before a 24-hour ban. This stops credential-stuffing attacks that try thousands of password combinations. If you're on Cloudflare, their rate-limiting at the edge is more efficient — but the plugin works on any hosting setup without additional infrastructure.
Tier 2 — Medium Impact, Some Technical Work
These seven tweaks require editing configuration files. If you're uncomfortable with FTP or cPanel file manager, have your developer handle them — they take 30-60 minutes for someone familiar with WordPress file structure.
8. Disable XML-RPC If You're Not Using It
XML-RPC is a remote API that lets external apps post to WordPress. If you're not using the WordPress mobile app, Jetpack, or a third-party publishing tool, you almost certainly don't need it. Attackers use XML-RPC for amplified brute-force attacks (one request can attempt hundreds of password combinations) and DDoS amplification. Block it at the server level by adding this to your .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>If you need XML-RPC for Jetpack specifically, use the Disable XML-RPC plugin which blocks the problematic endpoints while keeping Jetpack's whitelisted calls functional.
9. Hide the WP Version Number
WordPress outputs its version in the HTML <head> as a <meta name="generator"> tag and in ?ver= query strings on enqueued scripts and styles. Attackers use this to target sites running versions with known vulnerabilities. Add this to your theme's functions.php:
remove_action('wp_head', 'wp_generator');
add_filter('style_loader_src', 'remove_ver_query_string', 9999);
add_filter('script_loader_src', 'remove_ver_query_string', 9999);
function remove_ver_query_string($src) {
return $src ? remove_query_arg('ver', $src) : $src;
}10. Disable File Editing in WP Admin
WordPress includes a built-in theme and plugin file editor under Appearance > Theme File Editor and Plugins > Plugin File Editor. If an attacker gains admin access, this editor lets them inject PHP backdoors directly into your theme without FTP access. One line in wp-config.php disables it entirely:
define('DISALLOW_FILE_EDIT', true);There's almost no legitimate reason for this editor to be active on a production site — your developer should be editing files locally and deploying, not editing live in the browser.
11. Move wp-config.php Up One Directory
WordPress automatically looks for wp-config.php one directory above the webroot (public_html/) if it's not found in the webroot itself. Moving it there means a misconfigured server that accidentally serves PHP files as text can't expose your database credentials — the file is outside the document root and unreachable by HTTP requests. Simply move it via FTP from /public_html/wp-config.php to /wp-config.php (one level up). WordPress finds it automatically.
12. Set Correct File Permissions
Overly permissive file permissions are a common finding on cPanel shared hosting where files were uploaded with 777 permissions. The correct settings:
- Directories: 755 (owner can write, group and others can read and execute)
- Files: 644 (owner can write, group and others can only read)
wp-config.php: 600 (only owner can read and write)
Run this via SSH if your host allows it: find /path/to/wordpress -type d -exec chmod 755 {} \; && find /path/to/wordpress -type f -exec chmod 644 {} \; then chmod 600 wp-config.php.
13. Disable PHP Execution in Uploads Folder
The wp-content/uploads/ directory should contain only images, PDFs, and media files — never PHP. Attackers often upload a PHP web shell disguised as an image to a vulnerable file upload endpoint, then execute it directly via URL. Block PHP execution in uploads by creating a .htaccess file inside wp-content/uploads/ with:
<FilesMatch "\.php$">
Require all denied
</FilesMatch>This doesn't prevent file uploads — it only prevents PHP files in that directory from executing, so legitimate uploads are unaffected.
14. Add Security Headers
Security headers tell browsers how to handle your content and protect against clickjacking, MIME-type sniffing, and cross-site scripting. If you're on Cloudflare, add these via Transform Rules. Otherwise, add to your root .htaccess:
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"For Content Security Policy (CSP), start in report-only mode (Content-Security-Policy-Report-Only) and tune it for your site before enforcing — a misconfigured CSP can break your site's scripts.
Tier 3 — High Impact for Targeted Sites
These seven tweaks matter most for sites that handle transactions, store user data, or belong to businesses that might be specifically targeted — WooCommerce stores, healthcare portals, government-adjacent services, and similar.
15. Change the WordPress Login URL
Install WPS Hide Login and change /wp-login.php to something non-obvious like /account-access or a random string. Automated bots almost universally target wp-login.php and wp-admin/ — a custom URL removes your site from the target list for these scripts. Brute-force attempts in Wordfence logs typically drop to near-zero after making this change. Document the new URL immediately in your password manager before saving settings.
16. Implement WAF via Cloudflare Free Plan
Cloudflare's free plan includes DDoS mitigation, bot detection, and basic WAF rules that block the most common automated WordPress attacks before they reach your server. Set up Cloudflare on your domain (change nameservers at your registrar), then in the Cloudflare dashboard enable the WordPress managed ruleset under Security > WAF. This alone blocks a significant volume of automated probes targeting common WordPress vulnerabilities — and it costs nothing.
17. Enforce HTTPS with HSTS
HTTPS encrypts traffic between your server and visitors, preventing credential theft on public Wi-Fi. If you don't have an SSL certificate, your hosting provider almost certainly offers Let's Encrypt at no cost — enable it via cPanel > SSL/TLS or your host's control panel. After enabling SSL, add to wp-config.php:
define('FORCE_SSL_ADMIN', true);Then add the HSTS header to tell browsers to always use HTTPS for your domain: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains". Start with a short max-age (86400 seconds = 1 day) and increase to 31536000 once you've confirmed SSL works correctly on all subdomains.
18. Change the Database Table Prefix
WordPress defaults to the wp_ prefix for all database tables. SQL injection attacks often target known table names — wp_users and wp_options are standard targets. Changing the prefix to something like xk7m_ breaks these pattern-matching attacks. This is easiest to do during initial setup. On an existing site, use the Brozzme DB Prefix & Tools plugin to rename tables safely — always take a full database backup before doing this manually.
19. Disable Directory Browsing
If Apache's directory indexing is enabled and a directory has no index file, the server lists all files in that directory — effectively giving attackers a roadmap of your file structure. Add Options -Indexes to your root .htaccess file to disable this. Verify by navigating to yourdomain.com/wp-content/ — you should see a 403 Forbidden response, not a file listing.
20. Monitor for Unexpected Admin User Creation
One of the first things malware does after establishing access is create a new admin user as a persistent backdoor — even if you clean the malware, the rogue admin account remains. Wordfence can alert you immediately when a new administrator account is created: go to Wordfence > All Options > Email Alert Preferences and enable "Alert me when there is a warning-level event." You'll get an email within minutes of any new admin user appearing in your WordPress install.
21. Regular Offsite Backups Following the 3-2-1 Rule
The 3-2-1 backup rule: 3 copies of your data, on 2 different media types, with 1 copy stored offsite. For WordPress, this means: one live copy on your server, one local copy, and one on cloud storage. Install UpdraftPlus free and configure it to back up files and database daily to Google Drive (free storage up to 15GB covers most SME sites). Schedule it to run at 2 AM when traffic is lowest. Set a retention policy of 7 daily backups so you can roll back up to a week.
For Kerala SMEs using Indian hosting: Hostgator India and BigRock's automated server snapshots are not a substitute for a proper backup strategy — they're infrastructure-level and may not include your WordPress database if the snapshot fails. Always run UpdraftPlus independently.
A Realistic Security Stack for Indian WordPress Sites
You don't need to spend money to be reasonably secure. Here's what a ₹0/month stack looks like in practice:
- Cloudflare Free: CDN, DDoS protection, basic WAF, SSL certificate
- Wordfence Free: Firewall, malware scanner, login protection, 2FA
- UpdraftPlus Free: Daily backups to Google Drive
- WPS Hide Login Free: Custom login URL
- Limit Login Attempts Reloaded Free: Brute-force protection
This stack handles 95% of the threats that compromise WordPress sites in the real world. It's what I recommend to every Kerala SME client who asks where to start.
For business-critical sites — WooCommerce stores processing transactions, healthcare portals, or sites where downtime costs serious money — a ₹2,000–3,000/month paid stack adds meaningful protection:
- Cloudflare Pro (₹1,500/month approximately): Advanced WAF rules, image optimisation, Argo smart routing
- Wordfence Premium (₹6,000/year, roughly ₹500/month): Real-time threat intelligence, IP reputation blocking, priority support
- UpdraftPlus Premium (₹2,500/year): Incremental backups, multisite support, more storage options
The real-time threat intelligence in Wordfence Premium is the most meaningful upgrade — if a plugin you're running gets exploited in the wild, the free tier leaves you exposed for 30 days while the paid tier blocks the attack on day one.
Frequently Asked Questions
Do I need a paid security plugin or is free enough for an Indian SME?
Wordfence free covers firewall, malware scanner, and login protection — that handles the vast majority of threats a typical Kerala SME site faces. The paid version adds real-time threat intelligence, meaning new threat signatures arrive the same day they're identified (vs a 30-day delay on the free tier). For most sites with under 10,000 monthly visitors, the free tier is sufficient. The paid version becomes worthwhile for WooCommerce stores processing payments, sites storing client data, or any site where a day of being blacklisted causes measurable business loss.
How do I know if my WordPress site has already been hacked?
Five signs to check right now: Google Search Console shows a "This site may be hacked" warning in the Security Issues report; visitors are silently redirected to spam or phishing pages; new admin users appear in your WordPress user list that you didn't create; your hosting provider suspended the account with a malware notification; or Wordfence scanner flags core files modified in the last 24 hours with unexpected code. If any of these apply, run a free Sucuri SiteCheck scan immediately — it checks your site externally against known malware signatures and blacklist databases without needing wp-admin access.
Should I change my WordPress login URL?
Yes, but pair it with 2FA and document the new URL first. WPS Hide Login effectively stops automated brute-force bots that hardcode wp-login.php in their attack scripts — most bots never adapt to custom login URLs. The real risk is locking yourself out: if you forget the URL or a plugin conflict reverts it, you'll need FTP or database access to recover. Save the custom URL in a password manager before activating. Then enable 2FA as an independent security layer — so even if someone discovers your custom login URL through server logs, they still can't access the dashboard without the second factor.