The first sign of a compromised WordPress site is rarely dramatic. It’s a customer who mentions their browser flagged your checkout page, or a spike in outbound email you never sent, or a login screen that suddenly refuses your own password. By the time any of those show up, the attacker has usually been inside for days. The uncomfortable truth is that most WordPress break-ins exploit settings the owner could have checked in an afternoon and simply never did.
This is a working checklist, not a lecture. Everything below is something you can verify or switch on yourself right now, starting at the file level and moving up through the protections your host provides. Read it with your hosting dashboard open in another tab.
Verify Your Server Permissions and File Access
Permissions decide who can read, change, or execute the files that make up your site, and loose permissions are one of the quietest ways in. Start with the two files that cause the most trouble. Your wp-config.php holds database credentials and secret keys, so it should be set to 640 or even 600 where your host allows it. Directories across your install should sit at 755 and individual files at 644. If you ever find a file or folder set to 777 because a tutorial told you to during troubleshooting, change it back immediately; that setting lets anyone with a foothold write whatever they like.
Next, look at who actually owns the files. On a correctly configured server, your WordPress files are owned by your user account, not by the web server process itself. When the server process owns everything, a single vulnerable plugin can rewrite your core files without resistance. If you can’t tell who owns what from your control panel, that’s a question worth asking your host directly.
Two more things belong on this pass. Disable file editing from inside the dashboard by adding define('DISALLOW_FILE_EDIT', true); to your config, so a stolen admin session can’t paste malicious code straight into your theme. And confirm that directory browsing is switched off, so a visitor typing a folder path into the address bar sees nothing instead of a tidy list of everything inside.
Turn On the Protections Your Host Already Offers
A surprising amount of hardening is already sitting in your hosting account, switched off by default or buried a menu deep. Before you install a single security plugin, find out what you’re paying for. Automatic daily backups, malware scanning, isolated account environments, and one-click staging sites are common inclusions that many owners never enable. A good managed platform will also keep PHP patched and quarantine suspicious files for you, which closes gaps long before you’d notice them manually.
This is where the quality of the host underneath you matters more than any plugin. Providers that specialise in WordPress Hosting tend to bake server-level firewalls, brute-force detection, and account isolation into every plan, so a breach on a neighbouring site can’t spill into yours. If you’re running a small business in Manchester or anywhere else where downtime costs you real customers, that shared responsibility is worth confirming line by line rather than assuming.
Walk through your account’s security tab and note what’s available but inactive. Enable automatic core and plugin updates for anything you’re not manually testing. Turn on whatever activity logging exists, because knowing when an admin account last changed a setting is often how you catch an intruder early. If two-factor authentication is offered at the hosting login itself, switch it on there too, not just inside WordPress.
Confirm Your Firewall, SSL, and Login Defenses Are Active
Finish at the front door. Check that a valid SSL certificate is installed and that your whole site is forced over HTTPS, not just the pages you remember to link that way. A quick way to test is to type the plain http:// version of a deep page and watch whether it redirects. Then confirm your firewall is genuinely filtering traffic rather than just installed; most dashboards show blocked requests, and a firewall seeing zero activity is often one that isn’t really on.
The login page deserves its own attention because it’s where most automated attacks land. Limit failed login attempts, enforce strong passwords for every account, and remove any unused administrator users left over from an old developer or theme demo. Rename the default “admin” username if it still exists, and add two-factor authentication for anyone with publishing rights.
Before you close the tab, make sure these four are done:
- File permissions tightened and dashboard file editing disabled.
- Host-side backups, scanning, and auto-updates switched on.
- SSL forced sitewide and the firewall confirmed active.
- Login attempts limited and two-factor enabled for every admin.