"Why Would Anyone Hack Us? We're Small"

Because it isn't personal. The overwhelming majority of attacks on small business websites come from automated bots scanning the entire internet for known weaknesses — outdated plugins, default passwords, unpatched servers. Your site isn't targeted because you're interesting. It's targeted because it's there.

And the consequences are disproportionate for small businesses: a defaced site, a Google "this site may be hacked" warning, customer data leaked, or your domain blacklisted for sending spam — any of these costs more than years of basic prevention.

You don't need to become technical. You need to know what good looks like, and what to ask.

The Non-Negotiables

1. HTTPS Everywhere

The padlock in the browser. It encrypts traffic between visitor and site, and browsers actively shame sites without it ("Not secure" next to your brand name). Certificates are free and auto-renewable in 2026 — there is no excuse. If any page of your site still loads over plain HTTP, that's a five-minute conversation with your developer today.

2. Backups That Actually Restore

Everyone says they have backups. The real questions:

• How often? Daily for the database, at minimum
• Stored where? Off the server itself — a server that dies takes its own backups with it
• Tested? A backup nobody has ever restored is a hope, not a plan. Ask when the last test restore happened.

3. Updates, Applied

Most successful attacks exploit vulnerabilities that were publicly known and patched — on sites that never applied the patch. Whoever maintains your site should apply updates on a schedule, not "when we remember." If your site is built on a plugin-heavy platform, this is doubly critical: every plugin is a door someone must keep locked.

4. Access Control

• Unique accounts per person — never one shared "admin" login on a sticky note
• Strong passwords in a manager, not a spreadsheet
• Two-factor authentication on the admin panel, hosting, and domain registrar
• Offboarding: when staff or an agency leaves, their access leaves the same day

The domain registrar deserves special paranoia: whoever controls the domain controls the email and the website both.

5. Least Privilege

The marketing intern updating blog posts doesn't need permission to delete the database. Good systems have roles — editor, admin, viewer — and people get the minimum that lets them work. One compromised account then does limited damage.

Five Questions to Ask Whoever Runs Your Site

1. When was the last backup, and when was one last restored successfully?
2. What's our update process and schedule?
3. Who has admin access right now? (Get the list. Be surprised.)
4. Do we have two-factor authentication on admin, hosting, and domain?
5. If the site was compromised this morning, what's the recovery plan and how long until we're back?

A competent developer answers these comfortably. Hesitation on multiple answers is itself an answer.

Security Is a Build Decision First

Bolting security onto a weak foundation is endless whack-a-mole. Building on a foundation with security defaults — encrypted sessions, hashed passwords, rate-limited logins, audit logs, role-based access — makes most attack classes simply not apply.

That's the standard we build to: security as architecture, not as a plugin. If you can't get straight answers about your current site's security posture, we'll audit it and give you the list in plain language — what's fine, what's risky, what's urgent.