Most agencies install Wordfence or Sucuri, tick a few checkboxes, and tell you your WordPress site is secure. It is not. WordPress security hardening starts at the server level, not with a plugin. The agencies that skip this leave you vulnerable to the attacks that actually matter: brute force attempts that bypass rate limiting, file injections that exploit weak permissions, and backdoors planted in legitimate-looking plugins.
Server-Level Access Controls
Your WordPress files should not be writable by the web server process. Most shared hosting setups give Apache or Nginx write access to everything, which means any compromised plugin can modify core files or inject code into your theme. Proper WordPress security hardening sets file permissions to 644 for files and 755 for directories, with wp-config.php at 440 or 400. The uploads directory gets special treatment because it needs write access but should never execute PHP.
Disable PHP execution in uploads and includes directories through server configuration, not through a plugin. This stops attackers from running malicious scripts even if they manage to upload them. A single .htaccess rule or nginx configuration block does this. Most agencies never touch it.
Authentication and Access Auditing
Two-factor authentication is table stakes. What most agencies miss is limiting login attempts at the server level before requests even reach WordPress. Fail2ban or similar tools should monitor auth logs and block IPs after repeated failures. This happens outside WordPress, which means attackers cannot exhaust your server resources with login attempts.
Remove unused user accounts. Audit user roles quarterly. An old contractor account with admin access is a liability. WordPress security hardening includes reviewing who has access and why. Database-level user enumeration protection matters more than hiding author pages.
Database Security and Backups
Change your database table prefix from wp_ to something unique. Not because it stops attacks, but because it slows down automated SQL injection attempts that assume default naming. More important: your database user should have minimal privileges. It needs SELECT, INSERT, UPDATE, and DELETE. It does not need FILE, PROCESS, or SUPER privileges. Most hosting setups give root-level database access to WordPress. This is wrong.
Backups belong off-server, encrypted, and tested. Not just scheduled. Tested. Restore a backup to a staging environment monthly to confirm it works. Tensai Design Studios runs restoration tests as part of maintenance because untested backups are not backups.
Monitoring and Response
File integrity monitoring alerts you when core files, plugins, or themes change unexpectedly. This catches compromises early. Set up monitoring for wp-config.php, .htaccess, and your theme functions.php file. These are the first targets after a breach.
Security logs should go somewhere you actually look at them. Centralized logging to an external service means you have evidence even if an attacker wipes your server. Most agencies set up logging and never check it until something breaks.
Plugin and Dependency Management
Every plugin is a liability. Audit your plugin list and remove anything you installed to test and forgot about. Keep the rest updated, but test updates in staging first. A security patch that breaks your checkout process is not better than the vulnerability it fixes.
Use a staging environment. This is not optional for WordPress security hardening. You need somewhere to test updates, configuration changes, and new plugins before they touch production. Tensai sets up staging as standard because we have seen too many sites broken by untested security updates.
What This Looks Like in Practice
A manufacturing client came to us after a security scare. Their previous agency had installed three security plugins, all configured differently, all logging to separate databases and slowing the site down. None of them caught the backdoor planted through an abandoned contact form plugin. We removed the plugins, hardened at the server level, implemented file integrity monitoring, and set up proper backup testing. The site got faster and more secure. That is what WordPress security hardening looks like when done properly.
Practical Takeaway
Ask your current agency or hosting provider about file permissions, PHP execution in uploads, database user privileges, and backup restoration testing. If they point you to a security plugin dashboard, find someone who works at the infrastructure level. Security plugins have their place, but they are not a substitute for proper server configuration and access controls. Real WordPress security hardening happens below the application layer.