Website security checklist for small business

Most small business website breaches aren't sophisticated attacks. They're automated bots scanning the web for known, unpatched vulnerabilities, and they find sites that skipped basic maintenance rather than sites that were specifically targeted. That's actually good news: most of this checklist is about consistency, not expertise.

HTTPS and SSL: non-negotiable, not optional

Every site should run on HTTPS, shown by the padlock icon in the browser address bar, which encrypts data between the visitor's browser and your server. This has been standard practice for years now, browsers actively flag HTTP-only sites as "not secure," and it also factors into search rankings. If your site or your developer's quote treats an SSL certificate as a paid extra, that's a sign of an outdated setup: most modern hosting includes it free by default.

Keep everything updated, especially on WordPress

If your site runs on WordPress or a similar platform, the core software, theme, and every plugin need regular updates. The overwhelming majority of WordPress security incidents trace back to an outdated plugin or theme with a known, publicly documented vulnerability, not some novel attack. Set a recurring reminder to check for updates, or better, get someone to handle this on a schedule so it doesn't get missed for months at a time.

Use strong, unique passwords and limit login attempts

Reused or weak passwords on admin accounts remain one of the most common entry points for automated attacks. Use a password manager, enable two-factor authentication wherever it's offered, and limit or lock out repeated failed login attempts, which stops the automated bots that simply try thousands of common passwords in sequence.

Back up your site regularly, and check that the backups actually work

A backup you've never tested restoring is a hope, not a plan. Set up automatic backups on a schedule (daily is reasonable for an active site), store them somewhere separate from the live server, and actually test a restore occasionally so you know it works before you need it in an emergency.

Limit who has access, and to what

Every person with admin access to your site is a potential entry point, whether through a compromised password or simple human error. Give people only the access level they actually need, remove access immediately when someone leaves the business or a contractor's project ends, and review the list of who has access periodically rather than letting it accumulate silently.

Where custom-built sites have a structural advantage

A WordPress site's security is mostly determined by how many plugins it runs and how consistently they're updated, since each plugin is separate code from a separate source. A custom-built site, by contrast, only runs code someone actually wrote for that specific site, so there's no marketplace of third-party plugins to audit or patch. That doesn't make a custom site automatically secure, the code still needs to be written properly and the server still needs configuration, but it does remove an entire category of risk that comes from software you didn't write and don't fully understand.

This is part of what SolaLab builds in from the start rather than adding later: HTTPS by default, no unnecessary third-party code sitting on the server, and a codebase small enough that the developer who wrote it can actually account for every part of it. Security here isn't a separate add-on service, it's a byproduct of how the site gets built in the first place.

A short checklist to actually use

Confirm HTTPS is active and the certificate renews automatically. Confirm the platform, theme, and every plugin are current, and set a recurring check if you're on WordPress. Confirm strong, unique passwords and two-factor authentication on every admin account. Confirm backups run automatically and have actually been tested with a restore. Confirm the access list is current and reviewed periodically.

Most of this takes an afternoon to set up once and then runs on its own. The businesses that get hit are usually the ones that never did the afternoon.

If you want a site that's built lean and secure from day one, without a plugin stack to maintain later, describe your project and get a build scoped with security handled by default, not as an extra line item.

See SolaLab's services: what I build and what it costs