Our Location
304 North Cardinal St.
Dorchester Center, MA 02124
WordPress Security for Client Sites: The Agency Baseline That Scales
Securing client WordPress sites at scale requires a consistent, efficient baseline. Here's the login security and error monitoring setup every agency should standardise.
Managing WordPress security across multiple client sites is different from securing your own. When something goes wrong on a client site — a login attack, a compromised admin account, a locked-out user — it reflects on you, not just on the site. And when you’re responsible for 10, 20, or 50 sites, the configuration decisions you make need to be scalable: efficient to deploy, consistent across sites, and capable of being managed without a support ticket every time something needs adjusting.
This guide covers the login security setup that agencies and freelancers should be standardising across client WordPress sites, and how to make it both thorough and manageable.
The Most Common Failure Mode on Client Sites
The most common security incident on client WordPress sites is a successful login attack. Clients set weak passwords. They reuse credentials from other sites that have been breached. They never change the default admin username. And almost no WordPress site ships with any rate limiting on login attempts, meaning a bot can try credentials indefinitely without any pushback from WordPress.
The second most common source of client site compromises is outdated plugins and themes — vulnerabilities that get patched in updates that nobody installed. Both of these failure modes are preventable with discipline and the right baseline configuration.
The Login Security Baseline Every Client Site Should Have
Rate limiting with a sensible threshold
Install BruteFort on every client site as a baseline. Set the max allowed login attempts to 5 per 30 minutes and configure a clear custom error message using the {{locked_out_until}} variable so locked-out users know when they can retry. This stops brute force attacks and slows credential stuffing to the point of impracticality. Five minutes of setup per site, permanent protection.
Custom login URL on every site
Changing the login URL from the default /wp-login.php to an unpredictable slug removes the site from automated bot sweeps that target WordPress specifically. BruteFort’s Custom Login URL makes this a one-toggle setup. Use a slug that’s consistent enough for your workflow but unique enough per site that it’s not guessable. Keep a record of each client site’s slug in your project management or password manager.
Whitelist your own IP on every site you manage
Before enabling any aggressive lockout settings, add your own IP — and your team’s IPs — to the WordPress IP whitelist in BruteFort’s IP Settings. This is the most important operational step. It means no matter how strict the rate limiting is on a client site, you’ll never accidentally lock yourself out during maintenance. If you work from a static IP or use a business VPN with a fixed IP, this is a one-time setup per site.
Geo blocking where the client’s audience is geographically defined
For local businesses, regional membership sites, or any client whose users are concentrated in specific countries, BruteFort’s Geo Blocking whitelist mode is highly effective. If a plumbing company in Manchester has no users outside the UK, blocking login access from every country except the UK eliminates the vast majority of automated attack traffic with a single setting. Discuss with the client before enabling — some clients travel or have remote staff in unexpected locations.
What Agencies Often Get Wrong
Not whitelisting before locking down. Enabling aggressive rate limiting without first whitelisting your own IP is the most common self-inflicted problem. Always whitelist first, then configure restrictions.
Handing over login credentials without changing the custom URL. If a client’s login URL is still the default /wp-login.php when you hand over a site, that gap will exist indefinitely. Make the custom URL part of the handover checklist, and document the new URL in your client handover notes alongside the credentials.
Not having a recovery plan for lockout situations. Clients forget passwords and get themselves locked out. Make sure you or someone on the team can access the WordPress database via phpMyAdmin to retrieve the custom login URL or temporarily deactivate BruteFort via FTP if a genuine lockout occurs. Document this in your support runbook.
Error Visibility on Client Sites
Alongside login protection, install Logmate on client sites you maintain actively. Having PHP and JavaScript error logs accessible from the dashboard means you can check what’s happening on a client site remotely — without needing to ask the client to describe what they’re seeing or navigate your hosting account. When a client reports that “something isn’t working,” Logmate’s Logs screen often shows the exact PHP error or JavaScript failure causing the problem before you’ve even asked a follow-up question.
Frequently Asked Questions About WordPress Security for Client Sites
Should I use the same login slug on all client sites?
Using the same slug across all sites is operationally convenient but reduces the security benefit if that slug ever becomes known. A practical middle ground is a small set of slugs rotated across sites, or a site-specific slug derived from something unique to that client that’s easy for you to remember but not guessable from the domain name alone.
How do I handle a client who gets themselves locked out?
First, confirm whether it’s a rate limit lockout (temporary, clears after the window expires) or a permanent blacklist entry (requires manual removal). If it’s a rate limit lockout, advise the client to wait out the window or try from a different IP. If their IP has been manually blacklisted by mistake, remove it from the IP Settings table in BruteFort. If they’ve forgotten the custom login URL, you can retrieve it from BruteFort’s settings or the WordPress database options table.
Is BruteFort compatible with multisite WordPress installations?
Check BruteFort’s WordPress.org plugin page for current multisite compatibility information, as this can vary across plugin versions. For single-site client installations, BruteFort is fully compatible and covers the standard WordPress login endpoint used by all single-site setups.
What should be in my standard client site security setup checklist?
At minimum: install BruteFort and configure rate limiting, set a custom login URL and document it, whitelist your agency IP(s), install Logmate for error visibility, ensure all plugins and themes are updated, set strong unique admin passwords, and confirm the site has automated backups. This baseline addresses the vast majority of practical security risks on a typical client WordPress site.
Login security on client sites is an agency responsibility, not an optional extra. BruteFort and Logmate together cover the two most common client site failure modes — login attacks and undetected errors — for free, with minimal ongoing management overhead.
You might also like: