Protect WordPress Login and Customize the Admin URL

But

This guide explains how to secure access to the WordPress administration area: limit login attempts, automatically block malicious IP addresses, replace the standard login URL with a private URL and follow an anti‑lockout procedure to avoid losing access to the site.

Who it’s for and when to apply it

• WordPress sites and WooCommerce stores exposed to brute‑force attempts.
• When you want to reduce noise in logs and limit automatic blocks.

Prerequisites

• WordPress administrator access (manage_options capability).
• The Securantis plugin active and correctly installed in WordPress.
• Public IP address used for administration (useful for the anti‑lockout).

Overview of features

• Attempt limiting: counts failed login attempts over 24 h and applies blocks.
• IP blocking: automatic blocks and the ability to block/unblock manually.
• Private login URL: replaces access to /wp-login.php or /wp-admin with a custom URL (e.g. /my-login/).
• Refuse old URLs: commands to refuse or redirect accesses via the public URLs.
• Visible statistics: failures, blocks, refused URLs and number of blocked IPs.

Before you start — important precautions

• Do not remove protection without a fallback plan: note the chosen private URL and keep an alternative access method (e.g. SSH access or access via another administrator).
• Never send passwords by email or chat.
• File operations or quarantines are not automatic: any deletion or restoration requires a human decision.

Detailed steps

1. Check status and statistics

• Open the Connections & Access section of the Securantis dashboard. You will see four metrics: failed logins over 24 h, applied blocks, refused old URLs and blocked IPs. These figures give an immediate overview of activity.

2. Enable and configure attempt limiting

• Enable login protection if it is disabled. Once active, the module records failed attempts and enforces blocking rules.
• Set the failure threshold before blocking and the block duration if your interface allows it. Choose conservative values at first (e.g. 5 to 10 attempts over 24 h) to limit false positives.

3. Enable automatic IP blocking

• Enable the automatic blocking option. The system will block IP addresses that exceed the configured threshold.
• Monitor the list of blocked IPs to detect potential false positives (e.g. if you use IP ranges from an office or a shared cloud provider).

4. Deploy a private login URL (hide login)

• Enable the private URL feature if you want to hide wp-login.php and wp-admin.
• Choose a slug that is simple but not obvious (e.g. /securite-connexion/). Do not use obvious public slugs such as /login/ if your site is highly targeted.
• Decide whether you want to block direct access to /wp-login.php and /wp-admin. Typical options are: block one and/or the other. Blocking both is recommended but requires the anti‑lockout to be properly configured.

5. Anti‑lockout procedure (ensure you keep access)

• Before blocking wp-login.php/wp-admin, record the chosen private URL and test it in a private browsing window.
• Note your IP as shown by the dashboard (Securantis displays your current IP). If you work from a dynamic IP (e.g. mobile network), add a fallback method (another administrator or server access) before activation.
• If the interface allows specifying trusted IP addresses, add your current public IP (or your office range) to avoid being blocked.

6. Test and validate

• Test login using the new private URL. Verify that wp-login.php and/or wp-admin are blocked or redirected according to the configuration.
• Verify that logs correctly record failure/success/block events.

Expected result

• Login attempts are limited and counted.
• Malicious IP addresses are automatically blocked according to the defined threshold.
• The public login URL is disabled and your new private path functions.
• Dashboard metrics reflect activity and the number of blocked IPs.

Prudent settings and practical recommendations

• Start with permissive rules then harden progressively while monitoring logs.
• Always add your IP (or administrative IP ranges) to exceptions if possible.
• If you use a VPN/Cloud or have remote administrators, define an IP range rather than a single IP.
• Keep an active administrator session open until full validation is complete.

Common errors and causes

• Loss of access after changing the URL: generally caused by connecting from an unlisted IP and blocking public URLs without an anti‑lockout.
• Blocking a legitimate IP range: often caused by thresholds that are too strict or lack of exceptions for partner services.
• The new URL does not work: extension conflict, cache rule or server rewrite rule.

Step‑by‑step troubleshooting

1. I can’t access WP‑Admin anymore

• Stay calm: do not make repeated attempts from a different IP (risk of worsening the block).
• If you have another active admin session, use it to revert settings and temporarily disable protection.
• Server access (FTP/SSH): temporarily rename the Securantis plugin to disable its protections if you control server access.
• If you have a fallback IP (office, mobile), try from that.

2. The site redirects or blocks wp-login.php but the new URL returns an error

• Clear server cache and cache plugin, then test in a private browsing window.
• Temporarily disable competing security plugins that might interfere.

3. Legitimate IPs are blocked

• Check the event logs in the Logs & Access section.
• Unblock the concerned IP manually and add it to exceptions if you can.

Additional precautions

• Keep a documented recovery procedure (server access, host support account, another administrator).
• Limit access to the hosting account and enable all available protections on the host side (firewall, strong authentication).
• Never share passwords or keys through insecure channels.

When to contact Securantis support

Contact support when:

• You have lost access to the administration and do not have server access or another administrator.
• You observe a massive IP blocking that appears to be triggered by a module error.
• The private URL feature does not work despite cache and plugin checks.

Information on interventions and security

• Support will never ask for your passwords via email or chat. If a paid intervention is required, accesses are provided only after payment and via the secure client area.
• Quarantine, deletion or restoration actions on files are performed only after your explicit confirmation.

Quick summary

• Enable login protection, set reasonable thresholds, configure a private URL, add your trusted IPs and test before blocking public URLs. In case of lockout, use an open session, server access or contact support if you have no recovery options.