# How to secure a WordPress site: what to turn on, in order

A calm order for securing a WordPress site with BetterShield: your way back in, sign-in, the fixes, alerts, the log and file check, then assistants.

By M Asif Rahman, Oct 22, 2026. Updated Nov 8, 2026.

To secure a WordPress site with **BetterShield**, work in this order: keep a way back in, tighten how people sign in, apply the hardening fixes, set up alerts, read the activity log and file check, and leave assistant access off until you need it. Each step is a short section below, and each links to the post that goes deep on it.

The order matters more than the number of switches. A change to sign-in is only safe once you can get back in without it, so recovery comes first. If you want the full list of what the audit looks at, [the WordPress security checklist](/blog/wordpress-security-checklist/) walks through all 71 checks, and this post is the sequence we would follow on a new site.

## Quick summary

- Start with recovery: a recovery link and eight printed recovery codes, kept off the site.
- Then sign-in: two-factor for your own account first, then for the roles that need it.
- Then the hardening fixes, safest first, using **Monitor first** where a fix offers it.
- Then alerts, with a test message, so a problem reaches a person.
- The activity log and the file check run on their own; you read them. AI assistant access stays off until you use it.

## Why the order matters

Most security settings are easy to switch on and slightly harder to take back. A required second factor, a changed sign-in address or a stricter header can each get in the way of a person who has not been told. None of them is risky when you can get back in. That is why BetterShield checks for a working way back before it applies a change to how people sign in, and why this order puts recovery at the top.

The other half of the order is effort. The early steps cost minutes and protect the most. The later ones are optional, depend on your kind of site, and can wait.

## Before you start: install and run Quick Setup

BetterShield installs from WordPress.org under **Plugins › Add Plugin**. Activating it runs a read-only audit, emails a single-use recovery link to the site’s admin address and opens **Quick Setup**. Apart from refusing requests to cloud-metadata addresses, nothing else is hardened until you choose it. A few protections do start at activation: the sign-in limit, the hidden bot check, comment and password reset limits, a password policy and email alerts. The step-by-step reference is [Install BetterShield and run Quick Setup](/docs/install-and-set-up/). For what each wizard step saves and what to check once it finishes, see [WordPress security plugin setup: Quick Setup and what to check](/blog/wordpress-security-plugin-setup/).

Everything below is the plugin’s own [Recommended setup](/docs/recommended-setup/), laid out as a sequence.

## Step 1: Your way back in

On **BetterShield › Protection › Recovery**:

1. Save the recovery link from your activation email in a password manager. It works once and lasts 90 days. **Generate a new link** replaces it and shows the new one once.
2. Press **Issue recovery codes** and keep the eight codes off the site. They work when email does not.
3. Turn on **Send a weekly recovery email check** if mail from this site has ever gone missing. It is off by default.

If you want to know what getting back in looks like, [Locked out of WordPress?](/blog/locked-out-of-wordpress/) shows the route, and [Set up recovery](/docs/set-up-recovery/) covers every option.

## Step 2: Sign-in

Sign-in is where most of the day-to-day risk sits, so it gets the most attention. On **Protection › Login & Access** and **Protection › Two-Factor**:

| Setting | Default | What we recommend |
|---|---|---|
| **Sign-in attempt limits** | On: 5 failures in 15 minutes | Keep the defaults |
| **Refuse obviously automated submissions** | On | Keep it on |
| Proxy or Cloudflare | Not trusted | Behind Cloudflare, press **Yes, this site is behind Cloudflare**; behind another proxy, list it under **Trusted proxies** |
| Your own two-factor | Off | Press **Set up two-factor** for your own account first |
| **Require two-factor of a role** | No roles; **Grace period, in days** 14 | Tick Administrator, and Editor where editors publish |
| Passkeys | None | **Add a passkey** for yourself (needs HTTPS) |
| **Sign in with a passkey only** | No roles | Only for a role whose people all hold a passkey |

Name the proxy honestly. Behind a proxy every visitor can arrive from one address, and one lockout could block everybody. For the setup in full, see [Login & Access](/docs/login-and-access/) and [Require two-factor](/docs/require-two-factor/). For the reasoning, [WordPress two-factor authentication and passkeys](/blog/wordpress-two-factor-authentication/) and [limit login attempts without locking yourself out](/blog/limit-login-attempts-wordpress/) go further. [Two-factor authentication](https://en.wikipedia.org/wiki/Multi-factor_authentication) is the general idea if you want a definition.

## Step 3: The hardening fixes, safe ones first

On **Protection › Hardening**, in this order:

1. Apply the five fixes Quick Setup offers, if you skipped them: **File editor lock**, **WordPress version privacy**, **Folder listing protection**, **Username privacy** and **Browser protections**.
2. Add **Remote publishing block (XML-RPC)** if nothing on the site uses it. Its **Pingbacks only** choice keeps the WordPress mobile app and Jetpack working.
3. Add **Uploads code block** and **Private file protection** where your server reads .htaccess. Otherwise the row reads **Not available here**.
4. Once the whole site is on HTTPS, turn on **Strict HTTPS (HSTS)**, starting with **Five minutes, to prove it works**.
5. Under **Signing in** on **Protection › Login & Access**, turn on **Leaked password check**.

Where a fix offers **Monitor first**, use it before you enforce. **Custom sign-in address** is optional: it makes the logs quieter, not the door stronger. The [WordPress hardening guide](/blog/wordpress-hardening/) describes what each fix changes, and the WordPress project’s own [hardening documentation](https://developer.wordpress.org/advanced-administration/security/hardening/) is the platform’s view of the same ground.

## Step 4: Alerts

On **BetterShield › Settings › Alerts**, the weekly summary (Monday) and instant mail for high and critical events are on, going to the admin email until you name someone. Add the people who will act, up to five addresses, then press **Send a test alert**. It arrives as “Alert delivery test”.

For planned work, use **Planned maintenance** rather than **Mute all alerts**. [WordPress security email alerts](/blog/wordpress-security-email-alerts/) covers the choices, and [Email alerts](/docs/email-alerts/) is the reference.

## Step 5: The activity log and the file check

Both run from activation, with nothing to switch on. The [activity log](/docs/activity-log/) keeps 30 days; use **Export CSV** if you need a longer record. The file check compares WordPress core and directory plugins with the WordPress.org copies every hour. Read the weekly summary, and act on **Some WordPress or plugin files have been changed** when it appears.

A good habit is to open the log once after any change, so you know what a normal entry looks like. [What the WordPress activity log records](/blog/wordpress-activity-log/) and [the file integrity check](/blog/wordpress-file-integrity-check/) explain what to look for.

## Step 6: Assistants, off until needed

Reading, applying changes and issuing a connection are separate choices on **BetterShield › Agents › Connect**, and they start off. We recommend leaving them off until you use an assistant, then turning on **Let agents read this site** first, and **Let agents change this site** only when you want an assistant to apply fixes. [MCP security best practices for a WordPress site](/blog/wordpress-mcp-security-best-practices/) and [Connect an AI assistant](/docs/connect-an-ai-assistant/) cover it.

## Recommended settings by kind of site

| Site | What we recommend |
|---|---|
| Blog or brochure site | The five safe fixes, **Remote publishing block (XML-RPC)** (with **Pingbacks only** if you publish through the mobile app or Jetpack), **Leaked password check** and two-factor for your own account |
| Store (WooCommerce) | **Require two-factor of a role** for Administrator and Shop manager, and keep the bot check on: it adds nothing to the cart or checkout |
| Membership or course site | **Dashboard lock for customers and subscribers** for Subscriber, after **Monitor first** |
| Agency or many sites | **Me and a team** in Quick Setup, two-factor required for Administrators, and settings moved between sites under **Settings › General** |

## What can go wrong, and how to undo it

- **Remote publishing block (XML-RPC)** with **All of XML-RPC** stops the WordPress mobile app and Jetpack. **Pingbacks only** keeps both.
- **Browser protections** can affect another site that embeds your pages in a frame.
- **Custom sign-in address** locks out anyone who only knows the old address. The recovery link restores the standard page.
- **Sign everyone out on demand** signs everyone else out, so choose a quiet time.
- **Strict HTTPS (HSTS)** is remembered by a browser until its period ends, whatever you undo, which is why you start with five minutes.
- **Require two-factor of a role** waits until the grace period ends; signing in is never blocked.

To undo a fix, turn its switch off on the screen it is on. To restore an earlier settings save, use **Put a settings change back** on **Settings › General**.

## Check it is working

- **Overview** shows the score and grade, and **Findings** what is left. [What the WordPress security audit looks at](/blog/wordpress-security-audit/) explains how the score is worked out.
- **Nothing is limiting sign-in attempts** (High) means BetterShield’s limit is off and no plugin it recognizes is limiting sign-ins.
- **Failed sign-ins are not being counted, so password guessing is not stopped** (High) usually means a proxy is not named.
- **Your recovery options aren’t fully set up** (Low) means your way back needs a look.
- Your test alert arrives, and the weekly summary comes on Monday.

BetterShield does not run a firewall and does not scan for malware, so none of this replaces those jobs if you rely on them elsewhere.

## Frequently asked questions

### What is the first thing to do to secure a WordPress site?

Make sure you can get back in. Keep the recovery link and the eight printed recovery codes off the site, because every later change to sign-in assumes a way back exists.

### Do I need to turn everything on?

No. Some protection starts at activation, and the rest is your choice. The blog or brochure row above is a sound baseline, and the other rows add what a store or membership site needs.

### Will these changes slow my site down?

The steps here are settings and checks, not a front-end layer. The plugin’s own position is that it never slows your site, and nothing on the WooCommerce checkout path is touched.

### How often should I revisit these settings?

Read the weekly summary every Monday and press **Check readiness now** before you require two-factor or passkey-only sign-in of a role. Generate a new recovery link when someone who has seen it leaves.

### Can I undo a setting that causes trouble?

Yes. Turn the fix off on its own screen, or use **Put a settings change back** on **Settings › General**. If you are locked out, the recovery link is the way back.

## Conclusion

Securing a WordPress site is mostly a matter of order: a way back in, then sign-in, then the fixes, then alerts, then the log and the file check, with assistants last. Each step is small, and each can be taken back.

BetterShield is free on [WordPress.org](https://wordpress.org/plugins/bettershield/). The full reference for this sequence is [Recommended setup](/docs/recommended-setup/).