WordPress Brute Force Protection Checklist

Symptoms

• wp-login.php receives repeated failed login attempts or credential-stuffing traffic.
• The issue is visible during routine WordPress, WooCommerce, or client review work.
• Owners need a clear next step before changing plugins, settings, payment flows, or content.

Most Common Causes

• Public login endpoints are routinely targeted with reused passwords, common usernames, and automated login attempts.
• Recent updates, configuration drift, cache/CDN behavior, plugin settings, or incomplete operational review can hide the owner of the issue.
• Teams may be relying on assumptions instead of order notes, logs, local diagnostics, public response checks, or documented handoff evidence.

How To Confirm The Cause

• Review failed-login patterns, admin usernames, password policy, 2FA/passkey status, and firewall/rate-limit rules.
• Record the affected URL, user role, workflow, plugin, order, product, or report section before changing settings.
• Compare the current result with the expected WordPress or WooCommerce behavior and preserve useful screenshots or exportable evidence.

Fixes

• Add 2FA or passkeys, remove weak accounts, rate-limit abusive attempts, and document recovery access.
• Apply the smallest reversible fix first, then clear only the relevant cache or retry only the affected workflow.
• Use a local report, CSV export, support-safe summary, or checklist when a developer, host, client, or payment provider needs evidence.

How To Verify The Fix

• Repeat the same workflow that exposed the issue.
• Confirm the visible status, report, order, product, page, or email path now matches the expected result.
• Document the final owner and next monitoring step so the issue does not quietly return.

When To Contact Support

Escalate when the issue involves hosting/network controls, payment-provider account state, private customer data, destructive restore work, or a code-level failure that cannot be safely confirmed from wp-admin.