What actually happens when a small site gets hacked

When a small business site gets hacked, no human picked it. A bot scanned a few hundred thousand sites in an afternoon, found one running an outdated plugin, and broke in automatically. The owner usually finds out weeks later, from a customer or a Google warning.

I build sites for local businesses around Heber City and Park City, and I am studying Security+ SY0-701 and eJPT right now, so I spend a lot of time reading how these break-ins work. Fair warning about my limits: I have not run incident response for a big company. But small-site hacks follow a boring, predictable script, and knowing the script is most of the defense.

Nobody picked you. A script did.

WordPress runs roughly 43 percent of the web, and most small business sites sit on it, usually with a stack of plugins nobody has updated since the site launched. Attackers do not search for nail salons in Heber City. They scan for version fingerprints: a contact form plugin with a known hole, a theme with a file upload bug. Scanning tools sweep the whole internet on a loop. When your site matches a fingerprint, the exploit fires automatically, no person involved.

That is the part that surprises owners the most. A dog groomer's site and a hospital's site look identical to the scanner. The only difference is which one got patched last week.

What the hack actually looks like

Three outcomes cover almost every small-site case I have read about:

1. SEO spam injection. The most common and the sneakiest. Your site looks completely normal to you. Hidden in the code are thousands of links or auto-generated pages selling fake pharmacy pills, casino signups, or knockoff sneakers. Often the spam is shown only to Google's crawler, not to visitors, which is called cloaking. You find out when you search your own business name and see gibberish pages in another language listed under your domain. One variant is common enough that it has a name: the Japanese keyword hack.
2. Redirects. Visitors who click through from Google get bounced to a scam page. When you type the address yourself it loads fine, which is why owners argue with the first customer who reports it.
3. Defacement. The classic hacked-page takeover. Rare for small businesses now. Spam pays and graffiti does not.

Then comes the part that does the real damage: blocklisting. Google Safe Browsing flags the site. Chrome shows visitors a full-screen red warning. Search results can add a hacked-site label. Traffic drops to almost nothing. Email sent from your domain can start landing in spam folders, because reputation lists share data. For a salon or a landscaper that gets calls from Google, the red screen is the injury. The hack was just the cause.

What cleanup really involves

The honest checklist, in order:

1. Take the site offline or into maintenance mode. Stop the bleeding.
2. Find the way in. Usually an outdated plugin or a stolen password. Skip this step and you get reinfected within days, because the same bots come back on schedule.
3. Remove the injected code. Restore a clean backup from before the infection if one exists, or clean the files by hand. Attackers leave backdoors: extra admin accounts, files with innocent names buried in upload folders. Miss one and you start over.
4. Update everything and rotate every password. Hosting, admin, database, email.
5. Request a review in Google Search Console. Getting off the blocklist typically takes a few days to a couple of weeks after the site is actually clean, and search traffic recovers slower than that.

Hiring this out usually costs a few hundred dollars per incident. Between the cleanup fee and the lost weeks of traffic, the episode often costs more than the site did to build.

The boring defenses that work

• Update software weekly, not yearly. Most break-ins use holes that were patched months before.
• Run fewer plugins. Every plugin is a door.
• Use a unique password plus two-factor on hosting and admin logins. Reused passwords are the other big front door.
• Keep automatic offsite backups, and test restoring one, once.
• Or remove the moving parts entirely. The sites I build for local businesses are static files: no database, no admin login, no plugins to patch. There is nothing server-side for a bot to inject. The tradeoff is real: a static site cannot do customer accounts or built-in booking without leaning on outside services, and it will not save you if someone steals your hosting or domain password. No setup removes every risk. But it deletes the exact category of attack that catches most small sites.

If you have a site and you do not know what it runs on, when it was last updated, or whether a backup exists, that is normal, and it is checkable in an afternoon. I do a free 24-hour audit, three real findings, yours to keep either way. Start at /audit.