Website Security Checklist for Small Business Owners

Most small business website compromises aren't targeted attacks. They're automated — bots scanning the internet for known vulnerabilities in outdated WordPress plugins, weak admin passwords, or misconfigured servers. The attacker doesn't care that you run a small landscaping business in Ohio. They care that your site is running WooCommerce 3.2 with a known SQL injection vulnerability.

The consequences range from embarrassing to catastrophic: your site injected with malware that infects your visitors, your Google ranking destroyed when Google's Safe Browsing flags you, your customer data stolen, or your site turned into a spam relay that lands your email domain on blacklists. Small businesses are disproportionately targeted because they're less likely to notice quickly and more likely to pay a ransom to recover.

The good news is that the security measures that prevent 95% of attacks are not expensive or technically complex. Most of them take under an hour to implement and require no ongoing attention once configured. This checklist covers them in order of impact.

If your website still runs on HTTP rather than HTTPS, stop reading this and fix that first. Browsers now label HTTP sites as 'Not Secure' in the address bar, Google penalizes HTTP sites in search rankings, and HTTP connections transmit all data including form submissions in plain text — visible to anyone monitoring the network connection.

HTTPS requires an SSL/TLS certificate. Free certificates from Let's Encrypt are issued automatically by most hosting providers, cloud platforms, and CDNs. There is no longer any cost justification for running HTTP. Enable HTTPS, redirect all HTTP traffic to HTTPS with a 301 redirect, and add the HSTS (HTTP Strict Transport Security) header to tell browsers to always use HTTPS for your domain.

Check your certificate expiry date. Expired certificates cause browsers to block your site with a full-screen warning page, driving away every visitor. Set up automated certificate renewal (Let's Encrypt certificates auto-renew when properly configured) and a calendar reminder to verify renewal 30 days before expiry.

Weak or default admin credentials are involved in a significant percentage of WordPress and CMS compromises. Automated bots run credential-stuffing attacks — trying thousands of username/password combinations against your login page — continuously. If your admin username is 'admin' and your password is in any dictionary, it's only a matter of time.

Enable two-factor authentication (2FA) on every admin account. This single step stops credential-stuffing attacks almost entirely, because even a correct password isn't sufficient without the second factor. For WordPress, plugins like WP 2FA or Two Factor make this straightforward. For other platforms, use your platform's built-in 2FA settings.

Use strong, unique passwords for all accounts with any site access: CMS admin, hosting panel, FTP/SFTP, database, DNS. A password manager makes this manageable. Never use the same password across multiple accounts — credential leaks from unrelated services are routinely tested against CMS login pages.

Outdated software is the most common attack vector for website compromises. WordPress core, plugins, themes, your CMS platform, PHP version, and server software all receive security patches regularly. Running old versions means running with known vulnerabilities that attackers explicitly target.

Enable automatic updates for WordPress core security releases. For plugins and themes, set a weekly reminder to check for updates and apply them — ideally on a staging environment first for any update that might affect functionality. Delete deactivated plugins and themes entirely; they can still be exploited even when inactive.

Check your PHP version through your hosting control panel. PHP 7.4 reached end-of-life in November 2022. PHP 8.0 reached end-of-life in November 2023. If you're running either of these, you're running software with unpatched vulnerabilities. PHP 8.2 or 8.3 is recommended for 2026.

Security headers are HTTP response headers that tell browsers how to behave when displaying your site. They protect against common attacks like cross-site scripting (XSS), clickjacking, and MIME-type confusion with a single line of server configuration each. Many hosting providers and CDNs let you set these without touching server configuration files.

The five headers every site should have: Content-Security-Policy (controls which scripts can run), X-Frame-Options (prevents your site from being embedded in iframes on other sites, blocking clickjacking), X-Content-Type-Options: nosniff (prevents MIME type confusion attacks), Referrer-Policy (controls what URL information is sent to third parties), and Permissions-Policy (restricts browser API access like camera and microphone).

You can check your current security headers for free using securityheaders.com or WebEnture's Security Headers Agent. A grade of A or above means you have the important headers in place. These headers don't require ongoing maintenance once set — configure them once and they protect your site indefinitely.

Backups are your recovery plan when everything else fails. Even sites with excellent security get compromised occasionally through zero-day vulnerabilities or supply chain attacks. Without current backups, recovery can take days or be impossible.

Back up your database daily and your full files weekly, stored off-server. 'Off-server' is critical — if your site and your backups are on the same server and that server gets compromised, your backups may also be affected. Use a backup service that sends copies to external storage like Amazon S3, Google Drive, or a dedicated backup service.

Know what to do if your site gets hacked: take the site offline immediately to stop infecting visitors, contact your hosting provider (many offer free malware removal), restore from a known-clean backup taken before the compromise, update all passwords and credentials after restoration, run a security audit to identify the entry point, and consider reporting the incident to Google Search Console to expedite removal of any Safe Browsing warnings.