Website Security Basics Every Business Owner Should Know

Nobody Is Targeting You — and That’s Exactly the Problem

The most useful thing a business owner can understand about website security is that almost nobody gets hacked by a person. Small-business sites get hacked by software: automated scanners that sweep the internet around the clock, probing every domain they find for the same short list of known weaknesses — an outdated plugin, a login page with a guessable password, a form that doesn’t check what gets typed into it. The bot doesn’t know you’re a plumbing company in Etobicoke or a dental clinic in North Vancouver, and it doesn’t care.

This reframes the whole conversation. Owners often skip security because they reason, sensibly enough, that no hacker would bother with a twelve-page local-business site. They’re right — and it doesn’t protect them, because the bot bothers with everyone. The flip side is more encouraging: since attacks are automated and opportunistic, defence mostly means not being the easy target. You don’t need enterprise-grade security architecture — you need the basics done consistently, because small-site compromises overwhelmingly exploit problems that were boring, known, and fixable. The digital equivalent of an unlocked back door.

What follows is the checklist we walk through with clients: what each item is, why it matters in plain language, and what to ask the person who maintains your site. None of it requires you to become technical. All of it requires you to know that someone, specifically, owns each job.

HTTPS Is the Floor, Not the Finish Line

Start with the padlock. HTTPS encrypts the connection between your visitor’s browser and your server, which means the contact form they fill out, the password they type, and the pages they browse can’t be read or tampered with in transit — on café Wi-Fi, on a hotel network, anywhere. The technology behind it is an SSL/TLS certificate; a decade ago this was a paid, fiddly annoyance, but today certificates are free through services like Let’s Encrypt and every reputable host issues and renews them automatically. There is no remaining excuse for a business site served over plain HTTP.

The stakes are partly about trust signalling. Modern browsers actively warn visitors away from non-HTTPS pages — Chrome labels them “Not secure” right in the address bar — and a security warning on a page with your phone number and contact form is a conversion killer of the most direct kind. Google has also used HTTPS as a lightweight ranking signal for years, so the SEO cost of skipping it is real, if modest.

Two details separate done from done properly. First, the entire site should redirect to HTTPS — every page, automatically — not just the homepage, and not a setup where both versions of the site quietly coexist. Second, the certificate has to renew without human intervention. Expired certificates are one of the most common self-inflicted wounds online: the site suddenly greets every visitor with a full-screen browser warning because a renewal email went to an inbox nobody checks. Ask your developer to confirm both, in writing, once. Then this item stays solved.

The Update Treadmill — and the WordPress Plugin Reality

If your site runs on WordPress — and statistically, it probably does — the single most important security habit is keeping it updated. Not because WordPress core is insecure; the core software is well-maintained and patched quickly. The real exposure is the plugin layer. A typical small-business WordPress site runs a dozen or more plugins — forms, SEO tooling, sliders, page builders, backups — each written by a different author with a different level of diligence, and each one is code running on your server with meaningful access to it.

Here’s the dynamic that catches owners off guard: when a plugin author fixes a security flaw, the fix itself becomes a public roadmap. The vulnerability gets disclosed, the patched version ships, and attackers immediately add the old version to their scanners — because they know most sites won’t update for weeks or months. From the moment a patch is released, every unpatched site is on a countdown. The plugins most likely to hurt you are the ones nobody thinks about: installed years ago by a previous developer, abandoned by their author, still active, still exposed.

The fix is a routine, not a heroic effort. Someone — you, your developer, or a maintenance plan you pay for — applies updates on a schedule, ideally weekly, and checks that nothing broke afterwards. Deactivated-but-installed plugins get deleted, not just switched off, because their code can still be reachable. Themes and plugins from unofficial “free” sources are forbidden outright; pirated premium plugins are a classic malware delivery vehicle. And once a year, do an inventory: if you can’t name what a plugin does, that’s the conversation to have. If nobody currently owns this routine for your site, that is the most important takeaway in this article.

Passwords, Logins, and the Case for Multi-Factor Authentication

The second-most-common way small sites fall is the front door: somebody logs in as you. Automated tools try thousands of username-and-password combinations against login pages, drawing on enormous lists of credentials leaked from breaches of other services. This is why password reuse is the cardinal sin — if the password protecting your website admin is the same one you used on a forum that got breached in 2019, your site’s security is whatever that forum’s security was.

The defence is unglamorous and extremely effective. Every account that touches the website — the CMS admin, the hosting control panel, the domain registrar, the email tied to all of them — gets a long, unique password stored in a password manager. Not a clever word with a number on the end; a generated string no human memorizes. The password manager does the remembering, and it removes the only real objection, which is convenience.

Then add multi-factor authentication wherever it’s offered — the one-time code from an app on your phone. MFA means a stolen password alone is no longer enough to get in, which neutralizes the bulk of credential-based attacks in one move. Prioritize it on the accounts that can do the most damage: your domain registrar (whoever controls the domain controls everything), your hosting account, and your CMS admin.

Finally, audit who has access. Sites accumulate accounts the way drawers accumulate keys: the developer from two redesigns ago, the intern who wrote three blog posts, the agency you stopped working with. Each dormant admin account is an unwatched entrance. Remove what isn’t needed, and give people the minimum role that lets them do their job — an editor who publishes posts doesn’t need administrator rights.

Backups Are Only Real If You’ve Tested a Restore

Everything above is about preventing a bad day. Backups are about surviving one — and they’re the item most likely to be quietly broken without anyone knowing. Plenty of businesses discover the state of their backups at the worst possible moment: after the hack, after the botched update, after the server failure, when someone finally asks “we have backups, right?” and the honest answer turns out to be “we had a plugin that said it was making them.”

A real backup setup has four properties. It’s automatic, because anything that depends on someone remembering will eventually be forgotten. It’s frequent enough to match how often your site changes — daily for most business sites, more often for stores. It’s stored somewhere other than the server it’s backing up, because a backup that lives next to the original disappears in the same fire; reputable setups copy to separate cloud storage. And it’s retained in multiple versions going back weeks, not just last night’s copy — critical, because hacks are often discovered days after they happen, and if your only backup is from last night, you’ve made a perfect backup of the hacked site.

Then there’s the step almost everyone skips: testing a restore. A backup is a theory until someone has actually used one to bring the site back. The test doesn’t need drama — your developer restores a backup to a staging copy and confirms it comes up intact, once or twice a year. The question to ask whoever maintains your site is precise and slightly unfair: “When did we last successfully restore from a backup, and how long did it take?” The quality of the answer tells you everything.

Forms, Spam, and Injection Attacks in Plain Language

Every form on your site — contact, quote request, newsletter signup, search box — is a place where strangers get to type things that your website then processes. That makes forms the classic attack surface, and two problems show up constantly.

The first is mundane: spam. Bots fill out unprotected forms relentlessly, burying real leads under junk and sometimes using your contact form to relay scam messages from your domain. Modern protections are nearly invisible to humans: tools like reCAPTCHA or hCaptcha, honeypot fields (hidden inputs only bots fill in), and basic rate limiting. If your inbox is full of gibberish submissions, that isn’t a fact of life; it’s an unconfigured form.

The second is more serious: injection. The idea, stripped of jargon, is that an attacker types something into a form that the site mistakenly treats as an instruction rather than as text. In SQL injection, malicious input gets passed to the database and executed — historically the route to wholesale data theft. In cross-site scripting, an attacker plants code in something the site later displays, like a comment, and that code runs in other visitors’ browsers. These are among the oldest tricks on the web, and the defences — validating and sanitizing every piece of user input — are well understood and built into every modern framework and reputable form plugin.

You will never personally configure input sanitization, and you shouldn’t try. Your job is one layer up: use well-maintained, mainstream form tools rather than abandoned ones, keep them updated, and don’t store data you don’t need. Every credit card number or password your site never stores is one you can never leak. Let your payment processor and booking platform carry that risk — it’s what they’re built for.

What a Hack Actually Costs: The SEO and Trust Bill

It’s worth being concrete about the downside, because “getting hacked” sounds abstract until you see what it does to a business that lives on search traffic and credibility.

The first cost is search visibility. Google scans the pages it indexes for malware and spam, and when it finds a compromised site it acts to protect searchers: warnings like “This site may be hacked” appear under your listings, browsers may interpose a full-screen red warning before anyone reaches your homepage, and rankings can drop sharply or pages can fall out of the index entirely. A common variety of compromise — spam injection — quietly stuffs your site with hidden pages for pharmaceuticals, knock-off goods, or gambling, and you find out when Search Console starts reporting that you rank for products you’ve never sold. Cleaning that up means removing the malicious content, closing the hole it came through, and requesting a review from Google — and while the warnings stand, your organic traffic is effectively switched off. If you’re also running paid traffic, it gets worse: ad platforms suspend destinations flagged for malware, so the hack pauses your ad account too.

The second cost is trust, and it’s less recoverable. Visitors who hit a browser security warning don’t investigate; they leave, and a meaningful share of them remember. If customer data was exposed, you may have legal notification obligations — in Canada, PIPEDA requires reporting breaches that create a real risk of significant harm — and the awkward emails that follow do more damage than the breach itself.

Against that bill, the cost of prevention — a maintenance routine, a backup service, an hour of configuration — is a rounding error. Security spending is unsatisfying because success looks like nothing happening. That’s the point.

What to Ask Your Developer and Your Host

You don’t need to verify any of this yourself — you need to ask questions specific enough that vague answers stand out. Here is the short interrogation, and what good answers sound like.

For whoever maintains the site: Who applies updates, and on what schedule? (A named person and a cadence, not “it’s mostly automatic.”) What plugins or dependencies are installed, and when were unused ones last removed? Where do backups go, how long are they kept, and when did we last test a restore? Is admin access protected by MFA, and who currently has accounts? What happens, step by step, if the site is hacked on a Saturday?

For your host, or your developer’s choice of host: Is the SSL certificate auto-renewing? Does the host provide a firewall and malware scanning at the server level? Are backups included independently of the ones the site makes for itself? What’s their support response time when something is actively wrong? Cheap hosting is often cheap precisely here — fine on a quiet Tuesday, invisible during an incident.

Two broader notes. First, if your site is a custom build on a modern framework rather than a plugin-based CMS, your risk profile is genuinely different — no public admin login, far less third-party code exposed to the internet — but it isn’t zero, and the questions about backups, access, and incident response apply unchanged. Second, if the honest answer to most of these questions is “nobody currently does that,” you haven’t discovered a crisis; you’ve found the gap before the bot does. A maintenance arrangement typically costs less per month than a single emergency cleanup.

When Something Goes Wrong Anyway

Good security reduces the odds; it doesn’t eliminate them. The difference between a bad afternoon and a bad month is usually whether anyone knew what to do in the first hour. You don’t need a formal incident-response plan with a binder and a logo. You need five decisions made in advance.

Know how you’ll find out. Many compromises are silent — the spam pages and malicious redirects are hidden from you and shown to Google. Free monitoring closes most of this gap: Google Search Console emails you when Google detects hacked content or security issues on your site, and an uptime monitor pings you when the site goes down. Both take minutes to set up and cost nothing.

Know who you’ll call. A name and a number — your developer, your agency, your host’s support line — written somewhere that isn’t on the website.

Contain first, investigate second. The immediate moves are changing every password connected to the site (CMS, hosting, domain, associated email), and if the site is actively serving malware to visitors, taking it offline temporarily — a maintenance page for a day costs you less than infecting your customers.

Clean properly, not cosmetically. Restoring a backup removes the damage but not the door it came through; if the vulnerable plugin or stolen password is still in place, you’ll be re-hacked within days. The hole has to be identified and closed, then the cleanup verified.

Then close the loop with Google: fix, then request a review through Search Console so the warnings come off your listings, and tell customers honestly if their data was involved.

None of this is exotic. Like most of website security, it’s a short list of unglamorous habits — owned by someone, done on schedule, tested occasionally. The businesses that get burned are rarely unlucky. They’re unassigned.