WordPress Security Hardening and Recovery Access

Step 1: Review Current Risk
Open Security and review HTTPS, headers, login protection, proxy trust, file permissions, user roles, update state, secrets, exposed routes, commerce data, and fresh logs. A warning is a starting point for verification, not permission to turn on every control at once.

Step 2: Confirm Dependencies
Record the WordPress, PHP, database, plugin, theme, web server, cache, proxy, CDN, and authentication path before changing enforcement. Trust only known proxy headers and addresses. Test the real administrator route and public origin so a header or redirect change does not create a loop or hide the actual client address.

Step 3: Keep Recovery Available
Maintain a verified database and file recovery point, the prior immutable package, and an out-of-band way to disable the affected module if administration fails. Builder page history can recover content structure, but it does not replace a complete site backup for plugin, database, user, or server changes.

Step 4: Apply and Regression Test
Make one bounded change, then test anonymous pages, login, logout, password reset, administrator access, REST routes, forms, uploads, cache behavior, checkout, webhooks, scheduled jobs, and fresh logs. Use I.G.O.R. to record the exact failure and evidence instead of weakening broad controls without knowing which rule caused the problem.
