Website security for small business: the basics that actually matter

Most owners treat website security for small business like a lock they hope someone else fitted at launch. Then a plugin sits unpatched for six months, a staff password is the same one used on a shopping site, or the only backup lives on the same cheap host as the live site. None of that looks dramatic until the homepage is serving spam, a browser shows a warning, or last week’s orders vanish. This is the non-technical version: what actually goes wrong, which basics (SSL, backups, updates, a bit of hardening) stop most of it, and what to ask the person who built the thing.

What actually goes wrong on a small-business website?

It is almost never a movie hacker in a hoodie. Government and industry guides for owners keep repeating the same boring list: stolen or reused logins, phishing, unpatched software, and no usable backup when something does fail [1] [2] [3]. Verizon’s long-running breach report still puts stolen credentials and social engineering near the centre of how real incidents start [7]. You do not need to be interesting to get hit. Automated scans look for known holes in popular plugins and leftover admin pages. A five-page brochure site is a perfectly acceptable target if it is easy.

• The site still loads, but it is not yours. Redirects, spam pages, or a hidden admin user you did not create. Customers see it before you do.
• You cannot get back in. Ransomware or a locked host panel, and the only copy of the files is the infected one.
• Trust evaporates in a screenshot. A browser interstitial or a “this site may be hacked” label in search. Recovery is slower than the original mistake [10].

Do I really need HTTPS, or is the padlock just for show?

You need it. HTTPS (the padlock) means the trip between the visitor’s browser and your site is encrypted, so a café Wi-Fi snoop cannot quietly read a form. That is what SSL/TLS is for [5]. Free certificates from Let’s Encrypt made this a configuration job, not a luxury line item [6]. Modern browsers treat a plain http page that asks for anything personal as a problem, and search consoles will tell you when Google has flagged a security issue on a property you control [10].

HTTPS is necessary and not sufficient. It does not patch a plugin, guess a weak password, or restore a deleted database. Think of it as the locked front door. You still need to know who has keys, and whether the spare is under the mat.

What does a real backup look like?

A download sitting next to the live site on the same disk is a copy, not a plan. Small-business cybersecurity programmes in the US and Australia all put backups in the “do this first” pile: something off the production server, recent enough to hurt if you lost a week, and actually restorable [2] [3] [4]. The test is the part people skip. If nobody has ever rebuilt the site from the backup, you have a hope, not a recovery path.

• Files and the database. A WordPress or custom site is not just a folder of images. Forms, orders, and pages live in a database. Back up both.
• Somewhere else. A second region, a different vendor, or an offline copy. One host outage should not take the only copy with it [2].
• A restore drill. Once or twice a year, rebuild on staging. That is also when you find out the backup user lost permission three months ago.

How often should plugins, themes, and apps get updated?

On a cadence, not “when the site looks weird.” Plugin and app ecosystems are where most of the holes show up because that is where most of the extra code lives. Patchstack’s WordPress security reporting is blunt about volume: thousands of new plugin issues in a year, and a large share still unpatched when they go public [15]. WordPress’s own hardening docs treat keeping core, themes, and plugins current as table stakes, not a nice-to-have [11]. Shopify apps and other platform add-ons follow the same shape: the platform vendor patches the platform; you (or your developer) still have to update what you bolted on [12].

If updates scare you because “something broke that one time,” the answer is a staging site and a maintenance window, not a freeze. Frozen software is how a two-year-old form plugin becomes the incident. This is the unglamorous half of why website maintenance matters — not new features, just not falling behind the people who write exploit kits.

What is basic hardening if I am not technical?

Hardening means turning off extra attack surface you are not using. You do not need to read OWASP cover to cover, but the Top Ten is still the industry’s plain list of how web apps actually get abused — injection, broken access, leftover components [9]. For an owner, the practical version is shorter.

• Fewer admin users, fewer plugins. Every extra login and every abandoned plugin is another door. Delete what you do not use [11].
• No “admin / admin.” Default usernames and reused passwords are still how a lot of small sites fall over [1] [7].
• Debug and directory listing off on production. Error messages that dump paths and plugin names are a gift to scanners. Your developer should already have this in a launch checklist [9] [11].
• Hosting that is not a forgotten shared account. Know who can log into the host panel, the domain registrar, and the CMS. CISA’s essentials start with knowing what you have and who holds the keys [2].

If you are briefing a studio on a new build, put those items in the handover. Good website development is not only how the homepage looks on a phone. It is whether the live site ships without leftover demo users and with a documented update path.

How do passwords and staff logins become the weak spot?

Because people share them in a group chat, reuse them, and never turn on a second factor. Multi-factor authentication (a code or prompt after the password) is the single cheapest control that still changes the outcome when a password leaks [13]. US and Australian small-business guidance both treat MFA on email, banking, and admin panels as non-optional, not “for big companies” [1] [4]. Verizon keeps finding that credential abuse is a workhorse of real breaches; phishing is how those credentials often move [7].

Practical rules that survive a busy week: unique passwords in a manager, MFA on the CMS, the host, Google or Microsoft 365, and the domain registrar; no shared “info@” inbox password used as the WordPress admin. When someone leaves, remove their access the same day — including the Shopify collaborator, the repo, and the backup tool. That last one is easy to forget and expensive later.

Should I worry about malware and Google warnings, or just data theft?

Worry about both, in that order of what customers see. A defaced page or injected spam is a trust problem even if nobody stole a card. Google’s Search Console security report is explicit that hacked sites can get a warning label, a browser interstitial, or come out of results until you clean up and request review [10]. Cleanup is not a refresh. You need a clean backup, rotated passwords, and a pass for leftover malware. That is days you are not quietly ranking for the thing you sell.

Data theft is the invoice you cannot screenshot. IBM’s Cost of a Data Breach research still puts the average incident in the millions of dollars for the organisations they survey — a figure that will not map one-to-one onto a ten-person shop, but the ingredients (investigation, downtime, customer notice, lost business) all exist at small scale [8]. The FTC’s small-business material is written for you, not for a bank: have a plan, know what personal data you collect, and do not wait until a lawyer is already on the call [1].

What extra risk do stores and payment forms add?

A brochure site leaking a contact form is bad. A store leaking orders is a different week. If you take cards, you want the heavy lifting on a specialist: Stripe, PayPal, or a platform checkout that keeps raw card numbers off your server [14]. Shopify publishes how they approach platform security; your job is still theme apps, staff permissions, and not pasting card data into a spreadsheet “just this once” [12]. A custom cart you invented on a Friday is how PCI scope explodes.

If you are comparing a marketing site with a real catalog, treat checkout as its own product. E-commerce development is not a brochure with a cart icon. Ask where cards are tokenised, who can export customer lists, and what the refund/fraud path looks like. Payment providers document this because the failure mode is public and ugly [14].

Who owns security if I am on Shopify, WordPress, or a custom site?

Shared responsibility, always. Shopify secures the platform; you secure staff accounts, apps, and what you put in the theme [12]. WordPress.org documents hardening; your host, your plugins, and whoever has admin are still on the hook for applying it [11]. A custom stack means your developer (or you) owns patching the language, the framework, and the server. There is no vendor who “does security” so you never think about it. There is only a clearer or foggier split.

Write the split down. Who applies CMS updates? Who watches uptime? Who holds the registrar? If the answer is “the intern who left,” you do not have a security posture. You have a lucky streak. Ongoing website maintenance services exist for owners who would rather pay for a cadence than volunteer as the night-shift sysadmin.

How can I tell if my current site is already exposed?

You cannot get a perfect answer from a homepage glance, but you can catch the loud failures. Search your brand plus “login” and make sure the admin URL you find is the one you know. Look at CMS users. Check Search Console for security issues [10]. Scan the live site for mixed-content warnings and an expired certificate. If emails from “your site” started bouncing or customers mention a weird redirect, treat it as an incident, not a quirk.

• Unexpected plugins or apps. Anything you did not install is a lead. So is a plugin you did install and then forgot.
• New admin users. One extra editor is how a lot of spam campaigns persist after a “cleanup.”
• Slow, random pop-ups, or pages you did not write. That is not “the internet being the internet.” That is a compromise until proven otherwise [1] [10].

A small business website checklist at launch should already include SSL, backups, and who owns updates. If yours never did, you are not late to a trend. You are doing the handover now.

What should I ask a developer or host before I sign?

Ask for the boring list in writing. If they wave it off as “we handle all that,” ask them to name the tools. You want: automated offsite backups with a tested restore, MFA on every admin surface, a stated update cadence, staging, monitoring, and a named human who gets the 2 a.m. email. NIST and CISA publish owner-level programmes so you do not have to invent the questions [2] [3]. Australian small-business guidance covers the same ground if that is your market [4].

• Where does the backup live, and when did you last restore it? If they cannot answer, you do not have a backup.
• What is patched, and how soon after a critical plugin advisory? Days, not “next time we redesign the hero.”
• Who can log in on day 90, and how do we revoke them? Host, CMS, analytics, payment dashboard, DNS.

If you already have a site and nobody can answer those, that is a maintenance conversation, not a redesign by default. A redesign will not save you if the new theme ships with the same leftover admin and no backup. Scope the security work first; then decide whether the design still earns a project.

What weekly habit is actually worth my time?

Fifteen minutes, same weekday. Confirm the site loads on your phone. Confirm the padlock is still there. Glance at one backup success log. Check that yesterday’s form test arrived. That is the owner loop. Updates, malware scans, and restore tests belong on a monthly calendar with whoever you hired — which is what a retainer is for if you will not actually do it in the month you are busy [2] [4].

Security for a small site is not a product you buy once. It is a short list you refuse to skip: encrypt the trip, keep software current, lock the logins, keep a backup that has been restored, and know who is on the hook. If you want a second pair of eyes on that list, contact us with the platform you are on and whether anyone has updated it in the last 90 days. We will tell you if you need a project, a cadence, or just a tighter handover.