Login Manager
WooCommerce Login and My Account Page Problems
Treat WooCommerce My Account as a private routed application. Verify page assignment, endpoints, cookies, redirects, templates, and cache isolation with a test customer.
Main Menu
wp-login.php is the most attacked URL on any WordPress site. Not because it is weak, but because it is at a known address on millions of sites, which makes it worth attacking automatically and continuously. Most owners discover this from a log file rather than a breach.
These guides cover the defences, roughly in order of how much they help. Moving the login URL removes you from the easiest scans. Limiting attempts stops the patient ones. Allowlisting your own addresses and blocking the worst offenders narrows it further. A captcha stops most automated submissions, and two-factor authentication is the one that still protects you when a password has already leaked.
Each of those has a failure mode, and they are covered too. A custom login URL that a cache serves to the wrong person or that returns 404 after a permalink change. A URL you moved and then forgot. Attempts that continue after the move because something is still reaching the old file directly.
One group is about being locked out, which is the risk you take on when you harden a login. Losing the phone with the authenticator on it, a redirect loop after a correct password, sessions that end after minutes, cookies the browser will not set.
If you are hardening a site today, read the recovery articles before the hardening ones. Knowing the way back in is what makes the rest safe to do.
Treat WooCommerce My Account as a private routed application. Verify page assignment, endpoints, cookies, redirects, templates, and cache isolation with a test customer.
Keep custom login, logout, and recovery routes private and dynamic at the CDN. Compare edge and origin responses, add exact bypasses, and purge only stale entries.
Changing the WordPress login URL hides one form; it does not remove authentication routes or stop credential attacks. Classify fresh events by endpoint and layer.
Trace one WordPress session across its authentication cookie, next request, server node, cache, and expiry. Align hosts, HTTPS, keys, clocks, and session policy.
Trace the WordPress test cookie from Set-Cookie to the next request. Fix the first domain, path, scheme, SameSite, header, or cache rule that breaks the round trip.
Trace a fresh WordPress password-reset link through every redirect. Align the host, scheme, custom login route, and cache rules without exposing or dropping the key.
A custom login 404 may come from the CDN, server, WordPress rewrites, a disabled route, or a slug collision. Locate the layer, repair the mapping, and purge narrowly.
Interpret WordPress login logs as a timeline: define recorded events, normalize time, verify client attribution, correlate account changes, and preserve evidence.
Use a temporary WordPress login IP block only with reliable client-address evidence, narrow scope, monitoring, expiry, and account controls that survive a network change.
Allowlist a WordPress login IP only after verifying client-address handling, stable network ownership, narrow scope, expiry, and an untrusted-path control.