How small business sites actually get hacked
The most important thing to understand about small business site hacks is that they are not targeted. A human adversary did not review your site, assess your business, and decide you were worth attacking. Instead, automated scanning happens at internet scale.
Bots continuously probe every reachable IP address on the internet. When a bot hits a server that responds, it runs a quick fingerprinting sequence: it checks for the standard WordPress login and admin pages to spot WordPress sites, looks for the tell-tale file locations that popular plugins leave behind, reads the software version numbers a site quietly exposes, and compares everything it finds against a public catalog of known security holes. If it spots a WordPress version or a plugin version with a publicly disclosed weakness, it flags the server and hands off to a second tool that breaks in automatically.
This process happens at a scale that makes size irrelevant. A single scanning operation can sweep every address on the internet in under an hour. Whether you have five visitors a day or five thousand, whether you run a dog grooming business or a law firm, whether your site is six months old or six years old, none of that changes whether the bot spots a version number that matches a known way in. What determines your risk is the software you are running and whether it has unpatched weaknesses.
The three categories responsible for the overwhelming majority of small business site compromises are: vulnerable third-party software (CMS plugins and themes), weak or reused authentication credentials, and misconfigured server environments. Each has a different remediation approach. All three are worth addressing, because fixing one while leaving the others open just shifts the path of least resistance without actually closing your exposure.
A final point that changes how you think about the threat: most attacks are not trying to destroy your site or make a statement. The goal is usually resource abuse — sending spam email through your server, hosting phishing pages that impersonate banks and payment processors, or running cryptomining scripts that consume your server's CPU. The attackers want your server's resources and your domain's reputation. A defaced homepage is the exception, not the norm. Many compromises go undetected for weeks or months precisely because the attackers work quietly to preserve the access they have.
The specific attacks: SQL injection, XSS, and brute force
Three attack types account for the bulk of small business site compromises. Understanding what each one does mechanically — not at a theoretical level, but at the level of what the attacker is actually doing to your site — makes the defenses make sense.
Database injection (often called SQL injection) happens when your site takes something a visitor types (into a search box, a contact form, a login field) and feeds it straight to the database that stores your site's information, without first checking it for trickery. The attacker types in commands disguised as an ordinary entry. A weak login form can be fooled into handing over every customer record, letting someone in without a real password, or in the worst cases taking over the whole server. The fix is a standard, well-understood coding habit: the site is built so that whatever a visitor types is always treated strictly as data to be looked up, never as a command the database will obey. Done right, this makes the attack impossible by design. Plugins that handle forms or search are a common source of this weakness, because the people who write plugins vary widely in how carefully they handle this.
Cross-site scripting (XSS) targets your visitors rather than your server directly. The attack works by injecting malicious JavaScript into content your site then displays to other users. If your site allows user-submitted content (comments, reviews, forum posts, profile fields) and displays that content without properly neutralizing it, an attacker can submit code that runs in every visitor's browser when they load the page with that content. The injected code can steal login sessions (letting the attacker impersonate logged-in users), redirect visitors to a phishing site, capture keystrokes including passwords, or silently load more malicious code. The fix is making sure anything a visitor types is always treated as plain text to be shown on the page, never as live code the browser will run. This is a coding discipline issue, and it fails most often in plugin code that handles display of user-generated content.
Brute force and credential stuffing target your login endpoints directly. Brute force tries username-password combinations systematically, cycling through common passwords, dictionary words, and variations until one works or the server blocks the attempt. Credential stuffing is more dangerous because it uses real credentials: username and password pairs leaked from breaches at other services (the Have I Been Pwned database currently indexes over 12 billion breached accounts). If your WordPress admin password was used at any service that was ever breached, a credential stuffing bot may already have it. Two-factor authentication neutralizes both attacks. Even with the correct password, the attacker cannot log in without the second factor. Rate limiting login attempts and blocking repeated failed authentication from the same IP address adds a second layer that makes brute force computationally expensive.
There is a fourth category worth noting: file inclusion and arbitrary code execution vulnerabilities. These are less common but more severe when they occur. A file inclusion vulnerability allows an attacker to execute arbitrary code on your server, often by exploiting a plugin or theme that improperly handles file path inputs. An arbitrary code execution vulnerability goes further. The attacker can run any command on your server as the web server user, effectively taking administrative control of the affected application. These vulnerabilities appear most often in complex plugins with file upload or media handling functionality that was not written with careful input validation.
The WordPress plugin problem
WordPress plugins are the single largest source of small business site compromises. Understanding why requires looking at the structure of the plugin ecosystem, not just the individual cases.
The WordPress.org plugin repository contains over 60,000 plugins. They vary enormously in quality, maintenance frequency, and security practices. A plugin built and maintained by a dedicated commercial team with a security review process is a different risk profile from a plugin last updated in 2021 by a solo developer who has moved on to other projects. The repository does not distinguish between them. The install button looks the same regardless of whether the plugin has had a security audit in the past year or not.
The disclosure-to-exploit window is the specific mechanism that makes this dangerous in practice. When a security researcher discovers a vulnerability in a popular plugin and reports it, the standard responsible disclosure process gives the plugin author time to patch before the weakness is published. Once it goes public, it lands in the well-known security databases that everyone watches, including the ones that track WordPress specifically. Attackers' automated tools are updated to hunt for that exact weakness within hours to days. Sites that have not yet applied the patch face exposure during that window. A plugin with 200,000 active installations and a disclosed SQL injection vulnerability is an enormous target. The attack is automated, so exploiting all 200,000 vulnerable sites is not meaningfully harder than exploiting one of them.
The treadmill problem compounds this over time. A WordPress site does not have a fixed set of software to keep updated. New plugins get added. Old plugins get abandoned (the author stops maintaining them, but they remain installed and active on thousands of sites). Theme updates sometimes conflict with plugin versions. WordPress core updates occasionally break plugin compatibility, causing site owners to defer plugin updates to avoid breaking their site, leaving them on a known vulnerable version for months. This is not a hypothetical failure mode; it is a routine reality for small business sites where the owner is not a developer and is not tracking newly disclosed plugin weaknesses.
The specific plugins with the worst security track records tend to be in certain categories: form builders (WPForms, Contact Form 7 — both have had multiple publicly disclosed security holes), file management plugins, page builders (Elementor and Divi have both had disclosed weaknesses), membership and subscription plugins, and anything that handles file uploads. These categories involve complex functionality with a large attack surface and are often third-party dependencies with no contractual security obligation to the site owner. Knowing this does not mean avoiding all plugins — in many cases they provide genuine value — but it does mean understanding that each plugin you add is a separate dependency you are responsible for maintaining on its own security timeline. Full comparison: WordPress vs. custom →
What every site should have in place
This is the practical checklist. Not a theoretical list of best practices, but the specific things that prevent the attacks described above on real small business sites.
HTTPS on every page, configured correctly. The padlock in the browser address bar encrypts the connection between your visitor and your server, preventing eavesdropping on form submissions, login credentials, and data in transit. Free SSL certificates via Let's Encrypt are available from virtually every reputable hosting provider. A site running over plain HTTP in 2026 has no excuse. Beyond encrypting traffic, confirm your SSL configuration is correct. HTTP requests should redirect to HTTPS (not leave a plain HTTP version live), the certificate should cover both the www and non-www versions of your domain, and the certificate expiration date should be monitored so it does not lapse unexpectedly.
Strong, unique credentials with two-factor authentication on every admin account. Every admin account for your site, your hosting control panel, the company you bought your domain name from, and whoever points that domain at your site should have a password that is long, random, and not reused anywhere else. A password manager handles this with no meaningful friction. Two-factor authentication should be enabled on all of the above. The risk model here is specific. If any of these accounts is compromised, an attacker can modify your site, redirect your domain, intercept your email, or take the site offline entirely. These accounts collectively represent the keys to your entire online presence.
Offsite backups on a documented, tested schedule. A backup stored on the same server your site runs on is not a real backup. If the server is compromised, the backup is compromised. If the server has hardware failure, the backup is gone too. Backups need to go to a separate storage destination, such as a different server, a cloud storage bucket, or anything physically distinct from the primary server. The schedule matters: daily backups for the past two weeks minimum, with weekly backups extending further back. The retention period determines how far back you can roll if a compromise is discovered after sitting undetected for a week. Test your backups by restoring from one to a staging environment. A backup you have never restored from is a backup you cannot rely on.
All software kept current, with security patches applied promptly. For WordPress sites, this means WordPress core, the active theme, and every plugin updated when releases drop, not deferred until convenient. Automatic background updates for WordPress core are enabled by default but can be disabled by plugins or theme configuration. Verify that they are running. For plugins specifically, the relevant question is not just whether you have updates pending, but whether any of your installed plugins have disclosed vulnerabilities regardless of whether an update is available. A plugin abandoned by its developer may have a known, publicly published weakness with no fix coming. In that case the plugin needs to be replaced or removed, not updated. See website maintenance plans →
Correct server settings, so the site can be read but not rewritten. Your site's files should be set up so the server can show them to visitors but cannot quietly overwrite the actual code behind your site. A common, lazy mistake is throwing the doors wide open to fix some permissions error and then never tightening them back up. When everything is left wide open, an attacker who finds any small foothold (through a plugin weakness or a sketchy file upload) can drop new malicious files anywhere on your site. Locked down properly, the server is allowed to display your pages but not to alter the code that produces them.
Monitoring that tells you when something changes. Uptime monitoring confirms your site is up and loading normally, checked from outside your own network. Google Search Console flags security issues when Google's crawler detects malware, phishing content, or harmful downloads on your site. Setting up both takes about 20 minutes and provides the two most important external signals that something has gone wrong. A third layer is change monitoring: tools that keep an eye on the files behind your site and alert you the moment anything is added or altered that you did not do yourself, which catches break-ins the other two might miss. On WordPress, security plugins like Wordfence and Sucuri provide this kind of file-change scanning alongside other security features.
How your hosting environment affects security
Where your site is hosted is not a security afterthought. The hosting environment determines the isolation between your site and other sites on the same server, the default security configuration of the server software, who is responsible for applying server-level patches, and how much visibility you have into security events. These are not abstract concerns.
Shared hosting and account isolation. On typical shared hosting, dozens to hundreds of sites share the same server. The security guarantee is that each account runs under a separate user with filesystem isolation (your files should not be readable by the web server process running another account's site). The quality of this isolation varies significantly between hosting providers. Providers that implement proper user isolation (each account runs under its own separate identity on the server, rather than every site sharing one) contain the blast radius of a compromise. If one account is breached, the attacker cannot trivially read or write files in neighboring accounts. Providers that use a shared PHP user without per-account isolation create a scenario where one compromised neighbor can affect others on the same server. Cheap shared hosting often skips proper isolation because it is more complex to implement and adds operational overhead.
Who patches the server. On unmanaged shared hosting, server-level software (the PHP interpreter, the web server, the operating system) is patched by the hosting provider on their schedule, which may or may not be timely. A PHP 8.1 security update released by the PHP project in January might not be deployed to your shared server until March or later, depending on the provider's maintenance cadence. This is not a hypothetical delay; it is the norm for budget shared hosting. The application you run on top of the server is your responsibility regardless of who hosts it, so you have two independent patching responsibilities on unmanaged hosting: your own application software and the underlying server. Managed hosting, where a developer or hosting provider maintains server software as part of the service, eliminates the second responsibility.
The server software stack. PHP version, web server software, and database version all have their own security track records and supported status. PHP 7.4 reached end-of-life in November 2022. A site running PHP 7.4 in 2026 is running a version that has not received security patches in over three years. PHP 8.0 reached end-of-life in November 2023. If your hosting provider's version selection includes anything below 8.1, you need to either explicitly select 8.2 or 8.3, or consider whether your host is keeping their stack current enough to trust. This sounds like a technical detail until you realize that a PHP interpreter with a three-year-old unpatched vulnerability is a server-level exposure that exists regardless of how carefully you maintain your application code.
Managed hosting with a human responsible for security. The practical difference between managed and unmanaged hosting shows up at the specific moments when something goes wrong. A server-level PHP vulnerability is disclosed on a Tuesday. On managed hosting, the patch is applied before the week is out. On unmanaged shared hosting, you do not know the patch was needed and have no mechanism to apply it anyway. An automated backup taken at 2am catches a file modification that happened at 10pm and lets you restore to a clean state. A backup you were supposed to take manually but forgot last month does not provide that option. See managed web hosting →
Custom code vs. CMS: why attack surface matters
Attack surface is the total set of entry points available to an attacker. Every public-facing endpoint (every URL that accepts input, every login page, every file path that a scanner can probe) is part of the attack surface. All else equal, a smaller attack surface is more defensible than a larger one.
WordPress, by its nature, has a large attack surface. Its login page lives at a standard, predictable web address that brute force and credential stuffing tools are built to hammer. Its admin area sits at another well-known address that is publicly reachable unless someone explicitly locks it down. It also ships with a legacy back-end connection point that bots routinely abuse to guess passwords and to amplify traffic-flooding attacks. In older setups, WordPress will even hand out a list of valid usernames to anyone who asks, giving attackers half of every login before they start. Every plugin adds its own files and entry points. A WordPress site with twenty installed plugins has twenty additional codebases contributing to its attack surface, each maintained by a different developer with different security practices and different update schedules.
A hand-coded PHP site built without a CMS has none of those surfaces by default. There is no login page for a bot to probe unless the site includes one on purpose, in which case it exists because the site specifically needs it, not because some platform bolted it on automatically. There is no standard WordPress login page, no legacy back-end connection point, no plugin files sitting at predictable addresses. The automated scanning tools built to exploit WordPress-specific weaknesses find nothing to match against.
This does not mean a custom PHP site is inherently secure. It means the threat model is different. The automated WordPress-targeting attacks, which are responsible for the vast majority of small business site compromises, find no attack surface. The remaining risk is in how the site itself is written. The database-injection and code-injection weaknesses described earlier can creep in if a developer is careless about how visitor input is handled. These are preventable through good coding habits. A custom site built so that visitor input is always treated as plain data and never as live commands, and that protects its forms from being submitted by impostor sites, has covered the weaknesses that can affect any site, no matter what it is built with.
The practical outcome for a small business: a well-built custom site requires no ongoing plugin management, has no plugin weaknesses to patch, and is not targeted by the automated WordPress-specific scanning that accounts for most small business hacks. Security maintenance reduces to server-level patching (handled by managed hosting) and reviewing any new code added to the site. The alternative on WordPress is an ongoing security management responsibility that does not have a natural endpoint. As long as plugins exist, there will be vulnerabilities in them.
What a breach actually costs your business
The consequences of a compromised website extend well beyond the site itself and often persist for months after the technical issue is resolved. Understanding the full scope of the damage is the most effective argument for investing in prevention rather than recovery.
Google blacklisting and search visibility. Google's Safe Browsing service scans the web for malware, phishing pages, and deceptive content. When Google's crawler detects malicious content on your site — an injected iframe loading a drive-by malware download, a phishing page impersonating a bank, or a redirect to a malicious domain — it adds your site to the Safe Browsing list. The consequences are immediate and severe: Chrome displays a red warning page ("This site may harm your computer") before visitors can proceed, Google Search results show a "This site may be hacked" notice below your listing, and Google Ads pauses any running campaigns pointing to your domain. Getting off the list requires cleaning the site, submitting a review request through Google Search Console, and waiting for Google to re-crawl and re-evaluate — a process that typically takes three to fourteen days. During that period, your site is effectively invisible and unsafe to visit. Organic traffic to a small business site during blacklisting often drops to near zero.
Hosting account suspension. Hosting providers monitor for malware, phishing content, and outbound spam from their servers. When they detect it, they suspend the account, often without prior warning, to protect other customers on shared infrastructure and to protect their own IP reputation. Account suspension typically takes the site offline and may disable email on the same domain simultaneously. Reinstatement requires cleaning the site, providing evidence to the hosting provider that the issue is resolved, and waiting for their review — a process that can take days depending on the provider's support responsiveness.
Email deliverability and domain reputation. A compromised server used to send spam damages the reputation of your domain's IP address and potentially your domain itself on email blacklists like Spamhaus, Barracuda, and Senderscore. If your business uses email on the same domain as your website (such as you@yourbusiness.com) and the server sends tens of thousands of spam emails from your domain, your legitimate business email may be blocked by spam filters at the recipients' email providers. Recovering from email blacklisting requires demonstrating to each blacklist that the spam source has been removed, a process that ranges from immediate (some blacklists auto- expire after 24–48 hours of no spam activity) to weeks-long manual review.
SEO ranking loss from the blacklisting period. Search rankings built over months of organic effort do not survive an extended blacklisting event unscathed. Google's algorithm responds to user signals, and a site that users bounce from immediately (because they see a malware warning) or that does not appear in results at all during a multi-week blacklisting period loses ranking signals that take additional months to rebuild. The indirect SEO cost of a two-week blacklisting period can translate to ranking recovery over three to six months in competitive markets. That is not theoretical analysis. It is the typical pattern for small business sites that experience a blacklisting event and then recover.
The cost of cleanup versus the cost of prevention. Professional malware cleanup for a compromised WordPress site ranges from a few hundred dollars for a straightforward case to several thousand for a site where the attacker has been persistent, has added backdoors to multiple files, and has modified the database. Those numbers do not include the cost of downtime, the value of lost leads during the blacklisting period, or the time you spend managing the incident instead of running your business. A managed hosting plan that includes proactive security patching and offsite backups costs a fraction of that. In the case of a compromise, a clean backup means cleanup is a restore operation rather than a forensic investigation.
Detecting a compromise and responding to it
Because many hacks are designed to be invisible, detection requires active monitoring rather than waiting for something obvious to break. Here is what to monitor and how to respond when a compromise is confirmed.
Google Search Console Security Issues. This is the most important monitoring channel for detecting a compromise visible to Google. Set up Search Console for your domain if you have not, verify ownership, and enable email alerts. When Google's crawler detects malware, phishing, social engineering content, or harmful downloads on your site, it flags the site in the Security Issues report and sends you an email notification. This is often the first external signal that something is wrong. Check the Security Issues report in Search Console at least monthly even if you have not received an alert — the alert delivery is not always immediate.
Uptime monitoring from an external service. Uptime monitoring checks your site from outside your network every 60 seconds and alerts you if the site returns an error or stops responding. This catches hosting suspensions, server crashes, and situations where your site has been modified to redirect all traffic to a different domain. Services like UptimeRobot offer basic monitoring free of charge. More comprehensive monitoring that also checks response content (not just that the server responded, but that the page contains expected content) provides better coverage.
Watching for unexpected redirects and content changes. Periodically load your site in a browser where you are not logged in, from a device you do not normally use, to check whether visitors are seeing what you expect. Attackers sometimes set up redirects that only fire for visitors arriving from a Google search, or only for first-time visitors who have never been to the site before, so that the site looks completely normal when you browse it directly but quietly sends your search traffic off to a spam page. Searching for your own site name in Google and verifying the snippet preview shows normal content from your site is a simple check that catches some of these.
What to do when you confirm a compromise. First priority is containment: take the site offline or redirect to a maintenance page so that no additional visitors are exposed to whatever content the attacker has placed on your site. This also prevents Google from crawling more malicious content, which limits the blacklisting impact. Contact your hosting provider immediately — they will want to know, and depending on the nature of the compromise may have isolation or forensic tools that help with investigation.
If you have a clean, verified backup from before the compromise, the fastest path to recovery is restoring it. This requires knowing approximately when the compromise occurred, which is why daily backups with two weeks of retention matter: you can restore to a point before the infection was present. Before bringing a restored site back online, change every password and access key tied to it: your site's admin login, your hosting control panel, any file-transfer or server access credentials, and any saved keys that connect the site to outside services. The initial breach may have involved a stolen password, and restoring a clean backup without changing those credentials leaves the original entry point open.
If no clean backup is available, the cleanup means going through every file that makes up your site looking for code the attacker slipped in, checking the database for tampered content, reading the server's visitor logs to work out how they got in and what they touched, finding and deleting the hidden back doors they left behind (often tucked away in upload folders or disguised to look like normal WordPress files), and then sealing the way in. This takes someone who knows what a hacked site looks like from the inside. It is slow, expensive, and depending on how long the attacker had access, it may not be possible to finish with full confidence. The reliable alternative to cleaning up from scratch is having a clean backup to restore from, which brings the argument right back to prevention and maintenance.
Key takeaways
- Most small business site hacks are automated and not targeted. Bots probe every IP on the internet for known software vulnerabilities. Your site's size and industry are irrelevant to whether you get hit.
- WordPress plugins are the primary attack vector. Each plugin is a separate piece of software with its own security track record. Unpatched plugins are commonly exploited within hours of a weakness being made public.
- SSL encrypts data in transit but does not prevent your site from being hacked. It is one necessary layer of a multi-layer security posture.
- Two-factor authentication on all admin accounts neutralizes both brute force and credential stuffing attacks. A stolen password alone is not enough to log in.
- Offsite backups — not on the same server — are your recovery mechanism when prevention fails. A backup you have never tested is a backup you cannot rely on.
- A breach costs more than cleanup: Google blacklisting, hosting suspension, email deliverability damage, and months of SEO recovery are the downstream consequences that accumulate after the technical issue is resolved.
- A hand-coded PHP site has dramatically less attack surface than a WordPress site. The automated tools responsible for most small business site compromises have no WordPress-specific patterns to find.