Some links on this site are affiliate links. If you buy through them we may earn a commission at no extra cost to you.

← Back to Articles
Guides

How to Protect a One-Person Business From Getting Hacked

The habits and settings that stop most attacks on small sites, from account security and plugin hygiene to backups, monitoring, and a firewall.

How to Protect a One-Person Business From Getting Hacked

Most solo founders assume hackers are not interested in them. The site is small, the revenue is modest, and there is nothing worth stealing. The trouble is that almost nobody picks a target by hand anymore. Automated scripts scan millions of sites a day looking for an outdated plugin, a reused password, or an admin page with no second login step, and they do not care whose name is on the business. This guide walks through the habits and settings that close those doors, in the order that gives a one-person business the most protection for the least time.

If you want a side-by-side look at specific security products, the best website security tools for solo builders article covers that ground. This one is about what you actually do, week to week, so that a tool has less work to do in the first place.

Why small sites get hacked in the first place

It helps to understand how attacks really happen before deciding what to protect. The WordPress ecosystem is a good example because so many small business sites run on it. Security researchers counted more than 11,000 new WordPress vulnerabilities in 2025, and about 91 percent of them were in plugins rather than in WordPress itself. Several reports from early 2026 also found that attackers often start exploiting a newly published flaw within hours, not weeks. The gap between a fix being released and a fix being installed is where most small sites get caught.

The second big path is stolen logins. When a large service leaks passwords, attackers feed those email and password pairs into every login page they can find. This is called credential stuffing, and it works because people reuse passwords. If your hosting account, domain registrar, or email shares a password with some old forum account, you are exposed even if your own site has never had a single bug.

The third path is simply weak access control. A shared admin account, a former contractor who still has a login, or an API key pasted into a public GitHub repo will each do the job. None of these require skill on the attacker's side. They require you to have left something open, which is why the fixes below are mostly about habits rather than products.

Lock down the accounts that control everything

Your website is only as safe as the accounts that can change it. For most solo businesses that list is short but critical: your email, your domain registrar, your hosting or site builder, your payment processor, and your code repository if you have one. Email sits at the top because a password reset for every other account flows through it. If someone controls your inbox, they can take the rest one reset at a time.

Start by putting a password manager in charge of all of these. A unique, long, generated password for every account removes the credential stuffing risk almost entirely, because a leak from one service no longer unlocks another. Most password managers will also warn you when a saved password shows up in a known breach, which turns a vague worry into a specific to-do item.

Next, turn on two-factor authentication everywhere it is offered, starting with email and your registrar. Not all second factors are equal. A text message code is better than nothing, but it can be stolen through a SIM swap, where an attacker convinces your phone carrier to move your number to their device. An authenticator app is stronger, and a passkey or hardware security key is stronger still, because it cannot be phished by a fake login page. If a service offers passkeys, use them for your most important accounts first.

Finally, take a few minutes to check who else has access. Look at the user list on your site, your hosting panel, your analytics, and any shared drives. Remove anyone who no longer works with you, and give the people who stay the lowest level of access that lets them do their job. A freelance writer needs to publish posts, not install plugins.

Keep your software and plugins boring

The fastest way to cut your risk is to run less software and keep what remains up to date. Every plugin, theme, extension, or third-party script is code you did not write and probably have not read. Some of it is maintained carefully, and some of it was last updated three years ago by someone who has moved on. Abandoned plugins are a common entry point, because when a flaw is found there is nobody to fix it.

Once a quarter, open your plugin list and ask a blunt question about each one: would I notice if this disappeared tomorrow? If the answer is no, delete it. Deactivating is not enough on WordPress, since the files still sit on the server and can still be exploited in some cases. For the plugins you keep, check when each was last updated and how many active installs it has. A plugin with a handful of users and no updates in a year is a liability, even if it works fine today.

For updates themselves, turn on automatic updates for minor and security releases where your platform allows it. Many solo founders avoid this because an update once broke their site. That risk is real, but it is smaller than the risk of running a known vulnerable version for months. A reasonable middle ground is to let security patches install automatically and set a calendar reminder to review major version updates every two weeks.

If you build on a hosted platform such as Carrd, Webflow, Shopify, or a managed app builder, the vendor patches the core software for you. That shifts your attention to the parts you still control: your account security, any custom code or embeds you added, and the third-party apps you connected. A connected app with broad permissions can do as much damage as a bad plugin.

Put a safety net under the site

Even careful people get hacked, so the second half of protection is making sure a bad day stays a bad day rather than the end of the business. That comes down to three things: backups you have tested, monitoring that tells you something is wrong, and a plan for what to do next.

Backups first. Your host may already run daily backups, but it is worth checking three details. How long are backups kept, where are they stored, and have you ever restored one? Malware sometimes sits quietly for weeks before anyone notices, so a host that keeps only seven days of backups may leave you with nothing clean to roll back to. Keeping at least one copy somewhere other than your host also protects you if the hosting account itself is compromised. Try a test restore to a staging site once, so the first time you do it is not during an emergency.

Monitoring is the part most solo founders skip. You need some way to learn about a problem before your customers or Google tell you. At a minimum, set up uptime monitoring so you get an alert when the site goes down, and register the site with Google Search Console, which will email you if Google detects malware or hacked content. Free scanners such as Sucuri SiteCheck can also check a public site for known malware and blocklist status on demand.

A web application firewall, usually shortened to WAF, is the next step up. It sits between visitors and your server and filters out requests that look like known attacks, such as attempts to exploit a published plugin flaw. This matters most during that window between a vulnerability being disclosed and you installing the patch. Sucuri is one option built with small sites in mind. Its pricing page lists a firewall-only plan starting at $9.99 a month, and its platform plans add malware cleanup and monitoring for sites that want a service to call if something goes wrong. Some hosts and CDNs include a basic WAF as well, so check what you already pay for before adding another subscription.

A simple routine you can actually keep

Security advice tends to fail because it reads like a project instead of a habit. A short, repeating routine does more than a single weekend of hardening that never gets revisited. Here is a version that fits into a solo schedule without much strain.

  • Weekly, in five minutes: check that updates installed, glance at your uptime alerts, and confirm last night's backup exists.
  • Monthly, in about twenty minutes: review user accounts on your site and key tools, remove anyone who should not be there, and check your password manager for breached or reused passwords.
  • Quarterly, in an hour: prune unused plugins and connected apps, do a test restore from backup, and confirm two-factor authentication is still on for email, registrar, host, and payments.

Write down a one-page incident plan while you are calm. It should list where your backups live, how to reach your host's support, how to put the site into maintenance mode, and which passwords to change first if you suspect a breach. When something does go wrong, adrenaline makes simple steps feel hard, and a written list keeps you from skipping one.

It also helps to know the early warning signs. Unexpected admin users, new files you did not upload, strange redirects that only show up on mobile, a sudden drop in search traffic, or a warning in Search Console are all worth investigating the same day. Most of the long-term damage from a hack, especially to search rankings and customer trust, comes from how long it goes unnoticed.

Frequently asked questions

Is my small website really a target for hackers?

Yes, though usually not personally. Most attacks are automated scans looking for known weaknesses across huge numbers of sites at once. A small site with an outdated plugin or a reused password looks the same to those scripts as a large one. The upside is that the basic steps in this guide stop most of that automated traffic.

Do I need a security plugin if my host already has security features?

It depends on what your host actually provides. Some managed hosts include a firewall, malware scanning, and daily backups, which covers much of what a plugin would do. Others offer little beyond a basic SSL certificate. Read your plan's feature list, and add a plugin or service only to fill a real gap rather than doubling up.

What should I do first if my website gets hacked?

Change the passwords for your hosting account, site admin, and email, and turn on two-factor authentication if it was off. Then contact your host, take the site offline or into maintenance mode if it is serving malware, and restore from a clean backup or use a cleanup service. After that, find and fix the way the attacker got in, or the problem will likely return.

How often should I back up my website?

For most small business sites, daily backups are a sensible default, kept for at least 30 days. If you publish or sell constantly, more frequent backups make sense. The schedule matters less than knowing the backups work, so test a restore at least once.

Are site builders like Carrd or Shopify safer than WordPress?

They remove some risk because the vendor maintains the core software and you cannot install arbitrary plugins. Your account login, connected apps, and any custom code are still your responsibility. A hosted builder with a reused password and no two-factor authentication is not safer than a well-maintained WordPress site.

Where to start this week

If you only do a few things after reading this, do them in this order. Move your important logins into a password manager with unique passwords, then turn on two-factor authentication for email, your domain registrar, and your host. That alone closes the most common way small businesses lose control of their sites.

After that, prune plugins and connected apps you no longer use, and turn on automatic security updates. Confirm your backups exist, are kept long enough, and can be restored. Add uptime monitoring and Search Console alerts so problems reach you quickly. A firewall service like Sucuri becomes worth paying for once those basics are in place, especially if your site runs on WordPress or brings in enough revenue that a few days of downtime would hurt. None of this requires a security background, just a short routine you keep repeating.

Keep reading

More on Your website