A WordPress website can look perfectly normal while automated bots are already testing it for weak points. Some bots crawl useful pages for search engines. Others search for exposed login forms, outdated software, backup files and configuration mistakes.
When we build a website, we do not treat security as an optional plugin added at the end. We harden the WordPress installation and check the public site before launch. The goal is to reduce common attack paths and avoid exposing information that should never be available from the web.
Why WordPress websites are scanned constantly
A large share of internet traffic is automated. Search engines use crawlers to discover pages, but security scanners also request common paths and filenames. They may look for .env files, .zip archives, .sql database exports, debug logs and old copies of wp-config.php that were left on the server by accident.
The risk is not limited to a visible WordPress bug. A backup archive can contain the whole site. A database export can contain customer details, user accounts and password hashes. A copied configuration file may contain database credentials. We remove these files from the public web root and check that they cannot be downloaded directly.
Nulled plugins and hidden backdoors
Nulled plugins and themes are a serious risk because the code has been modified outside the normal vendor release. A backdoor can wait quietly and then run a trigger inside the hosting account. It may create a database copy, add an administrator, send mail, change files or forward information to another server.
This is why we do not install nulled software and why unused plugins, themes and test tools should be removed. A site that has already been exposed needs an investigation and clean-up, not just another security plugin.
What we check and harden before launch
- WordPress, Bricks, themes and plugins are updated
- Unused plugins, themes and test files are removed
- Public backup and configuration files are checked
- Administrator accounts and passwords are reviewed
- The login route and recovery access are tested
- Sitemap and public URLs are reviewed
- Forms, integrations and editor access are tested after hardening
Cloudflare as a reverse proxy
Cloudflare can sit between the visitor and the origin server as a reverse proxy. It can provide an additional layer for TLS, WAF rules, bot filtering and rate limiting before requests reach WordPress. The origin server must still be protected. If its IP address accepts traffic directly from anywhere, attackers may bypass Cloudflare.
Strict firewall and WAF rules
We use narrow rules to reduce repeated login abuse, suspicious requests and traffic aimed at known exploit paths. Rules should be introduced carefully. A broad block can stop a legitimate payment service, contact form, monitoring tool, crawler or administrator. Logging and testing come before aggressive blocking.
Changing the default login route
Changing the standard WordPress login URL can reduce automated noise, but it is not a complete security measure. It does not replace strong passwords, 2FA or access control. The new route must be documented and tested with caching, SSO, REST requests and recovery access because a mistake can lock out every administrator.
Disable XML-RPC when it is not required
If a website does not use Jetpack, the WordPress mobile app, remote publishing or another service that depends on XML-RPC, disabling it can remove an old remote interface that is often targeted. The trade-off is that mobile publishing, pingbacks and some integrations may stop working, so we check the requirements first.
Email Address Obfuscator
An Email Address Obfuscator can make visible email addresses harder for basic scraping tools to collect. It may reduce casual spam, but it does not secure the mailbox and it cannot stop every scraper. We also check mailto links, accessibility and contact forms after enabling it.
Limit Login Attempts
A login limiter can ban an IP after repeated failed attempts. A reasonable policy may start with a 15-minute ban, then increase the ban to 24 hours or longer after repeated abuse. This slows password guessing, but offices, VPNs and mobile networks may share one IP. The rule must not lock out every legitimate editor after one person mistypes a password.
2FA and Cloudflare Turnstile
Two-factor authentication protects an account even when its password has been exposed. Turnstile adds a bot check to the login form without using a traditional image CAPTCHA. We test administrator access, recovery codes, SSO, REST requests and the Bricks editing flow before treating the setup as finished.
Session length and Bricks editing
Short session or nonce lifetimes can reduce the useful life of stolen credentials, but they can also interrupt a long editing session and Bricks autosaves. If the editor logs out too quickly, keeping a second authenticated dashboard tab open and refreshing it periodically may help. The editor still needs to be saved and reloaded when a token has expired. This is a practical compromise, not a replacement for 2FA.
SSO and strong account protection
When hosting-panel SSO is available, it can reduce the number of WordPress passwords that staff need to use. The hosting panel then becomes the most important account. Protect it with a unique password, 2FA and recovery codes. Use a password manager and rotate access after staff changes, shared access or suspected compromise.
Author slugs are not the same as login names
Author archives can expose public author slugs, but an author slug is not always the WordPress login name. Obfuscating author slugs is not a complete defence against user enumeration and may create broken author links. We only keep that feature when the site needs it, while handling administrator usernames, author archives and enumeration separately.
Public pages, hidden URLs and sitemaps
A page missing from the menu is still public if somebody knows its URL. Before launch, we review the sitemap, search results, direct URLs and pages created during testing. Yoast may list indexable pages for crawlers, so unfinished, personal, staging and test pages must be removed, protected or excluded deliberately. Noindex reduces search visibility; it does not protect private information.
What security hardening does not guarantee
Hardening reduces common attack paths. It does not guarantee that a website can never be compromised. Updates, strong account security, safe hosting, tested backups and sensible user permissions still matter. If a site has already been infected, it needs a proper incident investigation and recovery plan rather than a quick cosmetic change.
Security is part of a responsible website launch
A website is not finished when the homepage looks good. Before launch, we check the public surface, remove unnecessary exposure and configure the practical protections that fit the project. The exact controls depend on the site, its integrations and the way the client needs to edit it after launch.
