Claude/ChatGPT Prompt to Secure a Live WordPress Site in 30 Minutes

What this prompt does

This prompt casts the model as a senior WordPress security engineer and asks for a time-boxed, 30-minute hardening runbook made of real commands and config snippets, not generic advice. It tailors that runbook with four placeholders: [hosting_env] (so file-permission and shell steps match your stack), [wp_version] (the target to update core, plugins, and themes to), [waf_provider] (which firewall or CDN to configure), and [risk_priority] (the threat the final checklist verifies against first).

The structure works because security under time pressure is about ordering, not completeness. By forcing a runbook ordered into 30 minutes, the prompt makes the model triage — updates, 2FA, login limits, and locked-down file editing come before anything exotic. Tying the permission steps to [hosting_env] matters because the right chmod and wp-config.php changes on shared cPanel differ from a VPS, and getting them wrong either locks out editors or leaves wp-config world-readable. Naming [wp_version] keeps the update step concrete, and pinning [waf_provider] means the firewall rules match the tool actually sitting in front of the site rather than describing a setup you do not have.

When to use it

• You have just been pulled into a client site after a security scare and need to triage fast.
• You want a repeatable first-30-minutes checklist instead of improvising under pressure.
• You need copy-paste commands and wp-config.php snippets tuned to a specific [hosting_env].
• You are standing up a new site and want baseline hardening locked in on day one.
• You need to configure a WAF on [waf_provider] with sensible starter rules.
• You want a verification checklist focused on a specific [risk_priority] like brute-force logins.

Example output

Expect an ordered, time-boxed runbook: numbered steps with estimated minutes, each carrying the exact shell commands or wp-config.php snippet to paste. It covers updating to [wp_version] and removing unused plugins/themes, enforcing 2FA and login lockouts, disabling file editing with correct permissions for [hosting_env], enabling HTTPS/HSTS and security headers, configuring [waf_provider], and a closing verification checklist aimed at [risk_priority].

Pro tips

• Be specific with [hosting_env] (e.g. shared cPanel on Hostinger vs. a managed VPS) — the permission and shell commands depend on it entirely.
• Treat deliverable three carefully: wrong file/directory permissions either lock out editors or expose wp-config, so review those values before running them.
• Set [risk_priority] to your actual top threat so the final checklist verifies the thing you care about, not a generic list.
• Match [waf_provider] to what is already in front of the site; configuring Cloudflare rules is different from a Wordfence plugin setup.
• Take a full backup before you start — a 30-minute hardening pass changes a lot quickly, and you want a rollback point.
• After updating to [wp_version], log in as a normal editor to confirm 2FA and the file-editing lockdown did not break their workflow.
• Treat the closing checklist as a real gate: run each verification against [risk_priority] rather than assuming a step worked because the command ran without error.