WordPress Security Checklist for Small Business Websites

Small business WordPress sites are not invisible targets. Most automated attacks do not discriminate by site size or traffic. They scan for outdated plugins, weak login credentials, and misconfigured settings. If your site matches known vulnerability patterns, it gets flagged.

Most WordPress compromises are preventable. Outdated software and weak or reused passwords account for a disproportionate share of incidents. You do not need a full-time developer or a large security budget to address those gaps.

This checklist covers 11 security areas for small business WordPress sites. Work through it once as an initial audit, then revisit it quarterly, or after any major update, hosting change, or team member departure. Each item includes what to check and the most common red flag to watch for.

Quick Answer

1. Keep WordPress Core, Plugins, and Themes Updated

Why it matters: Plugin and theme vulnerabilities are disclosed publicly in databases like Patchstack and WPScan once a patch becomes available. Sites that delay updates remain exposed after that disclosure window opens. Outdated software is one of the most common entry points for WordPress attacks.

What to check:

• Log into WP Admin and open Dashboard > Updates.
• Install all available plugin, theme, and WordPress core updates.
• Before applying a major version bump (for example, a plugin going from 4.x to 5.0), read the changelog. Major versions can rename settings, change integrations, or require manual configuration steps.
• After updating, test your homepage, your most important form, and any checkout or booking flow. Confirm they load and behave correctly.
• Consider enabling automatic updates for security-only WordPress core releases. Many managed WordPress hosts configure this by default.
• For guidance on applying updates safely, see how to safely update WordPress plugins without breaking your website.

Red flag: Any plugin flagged as having a known, unpatched vulnerability in your security plugin's audit. Or a plugin that handles user data, payments, or forms and has not received an update in more than 12 months.

2. Set Up Automated Backups with Off-site Storage

Why it matters: Backups do not prevent attacks. They limit the damage after one. A clean, recent backup is the difference between a 30-minute restore and days of rebuilding from scratch.

What to check:

• Use a backup plugin with scheduled automation. UpdraftPlus, WPvivid, and BlogVault are commonly used options. Compare them in the best WordPress backup plugins roundup.
• Configure daily backups for active sites: WooCommerce stores, booking-heavy sites, or sites that publish frequently. Weekly backups may be enough for a static brochure site.
• Store backups off-site. A backup stored only on the same server as your WordPress install does not protect you if the server fails or the account is suspended. Use a cloud destination: Google Drive, Dropbox, Amazon S3, or Backblaze are supported by most backup plugins.
• Run a test restore at least once per quarter. A backup that has never been restored successfully is an assumption, not a safety net.

Red flag: The last successful backup is more than 48 hours old on an active site. Or the only backup copy sits on the same server as the live site.

3. Use Strong Passwords and Enable Two-Factor Authentication

Why it matters: Weak or reused passwords leave accounts vulnerable to brute-force attacks and credential stuffing, where attackers try username-password pairs leaked from other breaches. Two-factor authentication (2FA) adds a second verification step so a stolen password alone is not enough to log in.

What to check:

• Every WordPress account should use a unique password used nowhere else. This applies to the WordPress admin, hosting control panel, and FTP or SFTP credentials.
• Use a password manager (Bitwarden, 1Password) to generate and store long, random passwords. This removes the memory burden that leads to password reuse.
• If your site still uses "admin" as the username for the main administrator account, change it. It is not a security fix on its own, but it removes an easy starting point for brute-force scripts.
• Check whether any admin account email addresses appear in known breach databases. The free service at haveibeenpwned.com lets you check any email address against a database of known leaks.
• Enable 2FA on all Administrator and Editor accounts at a minimum. Install a 2FA plugin: WP 2FA, the Two Factor plugin (maintained by the WordPress security team), and Wordfence Login Security all have free tiers on WordPress.org.
• Use an authenticator app (Google Authenticator, Authy, Microsoft Authenticator) rather than SMS-based codes where possible. App-based codes are not vulnerable to SIM-swapping.

Red flag: Any Administrator or Editor account operating without 2FA, especially on a site that handles payments, bookings, or personal data.

4. Limit User Roles to the Minimum Required

Why it matters: WordPress has five default roles: Subscriber, Contributor, Author, Editor, and Administrator. Each step up adds more capability. A compromised Editor account causes less damage than a compromised Administrator account. Giving users more access than their job requires increases the impact of any credential problem.

What to check:

• Open Users > All Users in WP Admin. Review every account and confirm its role matches the person's actual responsibilities.
• A contractor who submits blog drafts only should be a Contributor, not an Editor or Administrator.
• Remove or deactivate accounts for former team members, freelancers, or agencies no longer active on the site.
• Disable public user registration (Settings > General) unless your site intentionally allows visitor-created accounts for membership or community purposes.
• Some plugins create their own user roles or add accounts automatically during setup. Confirm any plugin-added accounts are expected and scoped correctly.

For a breakdown of what each default role can do, see the WordPress user roles and permissions guide.

Red flag: Inactive accounts from past contractors or team members still active in the user list. Or accounts with Administrator access that do not need that level of capability.

5. Install and Configure a Security Plugin

Why it matters: A security plugin handles several tasks that would otherwise require manual monitoring: blocking repeated login attempts, scanning files for malware, flagging known plugin vulnerabilities, and logging suspicious activity. One well-configured plugin covers a lot of ground without requiring technical expertise.

What to check:

• Choose a plugin with a reliable free tier. Wordfence Security, Sucuri Security, and Solid Security (formerly iThemes Security) are widely used options. The best free WordPress security plugins roundup on FS Code compares them in detail.
• After installation, run the setup wizard if available. Most security plugins walk you through the basic configuration.
• Enable login protection: limit login attempts, block repeated failed logins, and set lockout thresholds.
• Enable file change monitoring if supported. Unexpected changes to core WordPress files or plugin files can indicate a compromise.
• Review vulnerability alerts. Many security plugins check your installed plugins and themes against public vulnerability databases and alert you when an unpatched issue is found.

Red flag: No security plugin installed. Or a plugin installed and activated but still running on default settings with no login protection configured.

6. Choose a Host with Security Features Built In

Why it matters: Hosting-level security sits below WordPress. Even a well-managed WordPress install can be affected if the server environment is poorly configured or shared without proper isolation. Managed WordPress hosts often include server-level firewall rules, malware scanning, and DDoS protection that a security plugin alone cannot provide.

What to check:

• Confirm your host provides server-level malware scanning, separate from the plugin you manage yourself.
• Look for a web application firewall (WAF) at the server or network level, not only inside WordPress.
• On shared hosting, confirm accounts are isolated. On poorly isolated shared servers, a compromised neighbor site can affect yours.
• Confirm the host supports modern PHP versions. PHP versions past their end-of-life do not receive security patches. Check your current PHP version at Tools > Site Health > Info > Server.
• Review whether the host provides a staging environment. This lets you test major updates before they go live.

Red flag: Hosting that offers no built-in security features beyond a basic control panel. Or a host running PHP versions listed as end-of-life on the official PHP website (php.net/supported-versions.php).

7. Force HTTPS and Check Your SSL Certificate

Why it matters: HTTPS encrypts data between a visitor's browser and your server. Without it, login credentials, form submissions, and payment details travel in plain text across the network. Most browsers also display a "Not Secure" warning on HTTP-only pages, which affects visitor trust and SEO.

What to check:

• Visit your site with https:// and confirm the padlock icon appears without warnings or certificate errors.
• In WordPress Settings > General, confirm both the WordPress Address and Site Address use https://.
• Confirm your SSL certificate is valid and not expiring soon. Your hosting control panel typically shows certificate expiry dates. Most managed WordPress hosts offer free Let's Encrypt certificates that auto-renew.
• Force all https:// traffic to redirect to https://. Your host may handle this in server config, or you can use a plugin such as Really Simple SSL.
• Check for mixed content errors. These appear when an HTTPS page loads embedded resources (images, scripts) over HTTP. Open your browser's developer tools (F12) and check the Console tab on key pages.

Red flag: Certificate expiry warnings in the browser. Any key page still loading over https:// without a redirect. Mixed content errors on checkout, booking, or login pages.

8. Review File Permissions

Why it matters: File permissions control which users and processes on the server can read, write, or execute files. Overly permissive settings allow malicious scripts or other server accounts to modify your WordPress files. The WordPress documentation provides standard recommended settings.

What to check:

• The generally recommended WordPress file permissions are 644 for files and 755 for directories.
• The wp-config.php file contains your database name, username, and password. It should have permissions of 600 (owner read-write only) or 640 at most.
• Do not use 777 permissions on any WordPress file or directory. This allows any process running on the server to write to those locations.
• If your host provides a file manager or FTP access, spot-check permissions on the WordPress root, /wp-content/, and /wp-content/uploads/.
• If you are unsure how to check or change permissions, ask your host's support team. Many managed WordPress hosts apply correct permission settings by default and can confirm your configuration.

Red flag: Any file or directory in your WordPress install with 777 permissions, especially in /wp-content/ or the site root.

9. Run Regular Malware Scans

Why it matters: Malware on a WordPress site often causes no visible symptoms for weeks. Code injected into theme or plugin files can silently redirect visitors, harvest contact form submissions, or send spam from your server. Regular scans catch these problems before they compound.

What to check:

• Use a security plugin with scheduled malware scanning. Wordfence, Sucuri, and MalCare all include automatic scanning in their free or base tiers.
• Schedule automatic scans rather than relying on manual ones. Most security plugins support daily or weekly scheduled scans.
• Review scan results after each run. Investigate anything flagged as unexpectedly modified or suspicious. False positives are possible, but confirm before dismissing an alert.
• If your host provides server-level malware scanning separately from your plugin, use both. Server-level scans and plugin-based scans detect different patterns.
• After resolving any malware finding, run a clean scan to confirm the issue is resolved.

Red flag: No scheduled scans running, or scan results that have not been reviewed in more than 30 days.

10. Enable Activity and Audit Logs

Why it matters: Activity logs record who did what on your WordPress site: logins, page edits, plugin activations, user account changes, and settings updates. Without a log, a compromise or an internal mistake can go unnoticed, or be undetectable after the fact. Logs also help you identify brute-force attempts before they succeed.

What to check:

• Install an activity log plugin. WP Activity Log is a widely used free option. Some security plugins (Wordfence, Sucuri) include a log as part of their broader feature set.
• Configure the log to capture: user logins and logouts, failed login attempts, plugin and theme activations, changes to WordPress settings, post/page edits by role, and user account changes.
• Review the log after any unexpected site behavior: a page that changed without an obvious reason, emails that stopped sending, or settings that reverted.
• On multi-user sites, the log tells you which account took a specific action. This is essential when access needs to be reviewed or disputed.
• Check whether your host logs access requests at the server level. Server access logs are a secondary source of evidence if a plugin-level log is tampered with.

Red flag: No activity logging configured on a site with multiple user accounts, or on any site that handles customer data, payments, or bookings.

11. Protect Your Forms and Payment Pages

Why it matters: Forms and payment pages are direct interfaces to sensitive data. Contact forms can attract spam and injection attempts. Checkout pages process financial data. Booking forms collect personal information. Each of these is a target if not properly secured.

What to check:

• Confirm HTTPS is enforced on every page with a form, especially checkout and booking pages. Never collect payment details over HTTP.
• Use a reputable, PCI-compliant payment processor (Stripe, PayPal, Square) rather than attempting to handle card data yourself. These processors accept payment information on their own secure infrastructure and are maintained by dedicated security teams.
• Add spam protection to contact and booking forms. CAPTCHA options (hCaptcha, Google reCAPTCHA, Cloudflare Turnstile) reduce automated form abuse without significant friction for real visitors.
• Limit what forms collect. If an inquiry form does not need a phone number or mailing address, remove those fields. Collecting less data means less to protect and less to expose.
• If you use WooCommerce, confirm the payment gateway plugin is up to date and sourced from the official WooCommerce Marketplace or the gateway provider's official WordPress.org listing.
• Check whether your form or booking plugin stores submission data indefinitely in the WordPress database. If it does, configure a data retention or deletion policy. Old records you no longer need are a liability.

Red flag: Any form or checkout page loading over HTTP. A payment plugin that is outdated or sourced from a third-party site rather than the official gateway provider.

Practical Scenarios

If you run a WooCommerce store

Prioritize HTTPS on all order and checkout pages, strong passwords with 2FA on every account that can view orders, and a PCI-compliant payment gateway from a recognized provider. WooCommerce stores also accumulate customer and order data over time. Backup frequency should match order volume. Consider whether you need to store all historical order data indefinitely or whether older records can be archived or deleted.

If you run a booking or service business website

Booking forms collect names, contact details, and sometimes payment information. Enforce HTTPS on all booking pages. Keep your booking plugin updated. Confirm that old booking records have a defined retention period rather than accumulating without limit. If your booking plugin sends confirmation emails, verify your domain uses SPF and DKIM records so confirmation emails reach the inbox reliably, since failed delivery of a booking confirmation often looks like a site problem to the client.

If you have team members accessing the site

User role hygiene matters most when multiple people have logins. Assign the minimum role each person actually needs. Remove access immediately when someone leaves. Require 2FA for all Editor and Administrator accounts, not just the site owner. If a freelancer or agency needs temporary access, create a dedicated account with the narrowest possible role, and remove it when the engagement ends.

If you have limited technical help

Focus first on the items that require no code and no server access: updates, passwords, 2FA on admin accounts, reviewing user roles, and installing a security plugin. These address the most common attack patterns and are manageable by a non-technical site owner. For hosting-level and file permission questions, contact your host's support team. Most managed WordPress hosts can confirm your server settings are correct and walk you through any adjustments.

Mistakes to Avoid

• Treating plugin updates as optional. Vulnerabilities are disclosed publicly after a patch ships. Every day of delay is a window of exposure after the fix is available.
• Storing the only backup on the same server as the site. A server failure or account suspension removes both the site and the backup at the same time.
• Sharing admin credentials between team members. Each person should have their own account. Shared logins make activity logs meaningless and complicate access removal when someone leaves.
• Installing a security plugin but skipping configuration. Default settings are not always hardened. Work through the setup wizard and review login protection settings after installation.
• Using a simple password because you log in infrequently. Infrequent logins do not reduce brute-force risk. Attackers do not wait for you to visit the site.
• Leaving inactive plugins installed. An inactive plugin still exists as code on the server. If it contains a vulnerability, it can be exploited even while deactivated. Remove plugins you no longer use.
• Assuming HTTPS means the site is secure. HTTPS protects data in transit. It does not prevent a compromised plugin, a stolen password, or a malware injection from causing damage.

Recommended Next Step

Pick three items from this checklist that you have not yet confirmed. Work through those first. For most small business sites, the starting gaps are backup configuration, 2FA on admin accounts, and a security plugin that has not been fully configured.

Security is one part of broader WordPress site health. Pair this checklist with a regular maintenance schedule covering updates, database cleanup, and form testing on a weekly and monthly cadence. The WordPress Website Maintenance Checklist for Small Businesses covers those recurring tasks in a structured format.