Nobody Is Targeting Your Website. Bots Still Find It

Almost every small business owner we talk to about website security says a version of the same thing: why would anyone bother with us? We have no credit card data, no secrets, nothing worth stealing.

That is a reasonable thing to believe and it is the wrong model of the problem. Nobody picked your website. A script did, somewhere between three in the morning and three in the morning, working through a list of IP addresses and domain names it bought or scraped. It does not know your turnover, your city or your industry. It knows you are running a version of something with a known hole in it.

The thing worth stealing is not your data. It is your hosting account, your domain's reputation and your server's ability to send email. Those have resale value regardless of what your business does.

What the bots actually want

Once an automated attack gets write access to your site, the payoff is almost always one of a handful of things:

Spam pages. A few hundred new pages appear in a folder you never look at, selling fake pharmaceuticals or streaming links, each one linking back to a network of other hacked sites. Your domain is older than theirs and carries more trust, which is exactly why they want it.
Hidden redirects. Visitors who arrive from a Google search get bounced to a scam page. Visitors who type your address directly, or who are logged in as admin, see the normal site. That is why owners often insist nothing is wrong for weeks after it started.
Phishing kits. A fake bank or courier login page, hosted quietly in a subfolder of your domain, sent out in SMS campaigns. Your site is the disposable host.
Email relay. Your server sends thousands of spam messages. The practical result is that your domain lands on blocklists and your own invoices and quotations stop arriving in customers' inboxes.
A foothold on the server. On cheap shared hosting, several sites sit on the same account or the same machine with weak separation. One stale site that nobody has logged into since 2019 can be the way into the four you actually care about.

The cost to you is rarely a ransom demand. It is Google Search Console showing a Security Issues warning, browsers putting a red interstitial in front of your home page, your host suspending the account at 9am on a Monday with no notice, and a fortnight of your own time spent proving you are clean again.

How they actually get in

Three doors, in roughly this order of frequency.

Old code with a published hole

When a popular WordPress plugin fixes a vulnerability, the fix is public. So is the description of what was broken. Within hours, scanners are sweeping the internet looking for sites still running the old version. You are not being researched. You are being matched against a pattern. The same applies to PHP itself — each PHP version has a published end-of-life date, after which it receives no security patches at all, and a surprising number of Indian shared hosting accounts are still running something years past it.

Guessed and reused passwords

Brute-force bots hammer /wp-login.php and /wp-admin with lists of common passwords, and separately with username-password pairs leaked from completely unrelated breaches. If your site admin password is the one you also used on a forum in 2016, nobody has to guess anything.

The developer's machine, not yours

FTP credentials saved in an editor on a laptop with no antivirus, shared over WhatsApp, or left in the hands of an agency you parted ways with three years ago. This one is boring and extremely common.

The basics that actually stop this

Commodity attacks are stopped by commodity defences. You do not need a security budget; you need a short list of things that are true about your site.

Updates applied within days, not quarters. WordPress applies minor core security releases automatically by default. Plugins and themes usually do not, unless you switch auto-updates on per plugin. For anything business-critical, someone should be applying updates on a staging copy first and then live — that is the whole of what sensible ongoing technical support consists of.
Delete what you are not using. A deactivated plugin still has its files on the server and can still be exploited. Unused themes, old backup.zip files sitting in the web root, that staging copy at /old/ from the last redesign — all of it is attack surface with zero business value.
Unique long passwords and two-factor authentication on admin accounts. A password manager and 2FA (two-factor authentication — a code from an app in addition to the password) ends the brute-force problem for practical purposes.
Fewest admins possible. Content people get Editor or Author roles. Admin is for people who install software. Remove accounts the day someone leaves.
Rate-limit the login page. Lock out an IP after a handful of failed attempts. This is a setting, not a product.
HTTPS everywhere. Let's Encrypt certificates are free and almost every host offers them with one click. Check that HTTP requests return a 301 redirect to the HTTPS version rather than serving both.
Backups that live somewhere else and have been restored once. A backup stored on the same hosting account as the site is not a backup; it is a second copy of the same problem. Restore one to a staging site once a year so you know it works.
Hosting that is current. Ask your host which PHP version your account runs and whether it is still receiving security support. If nobody can answer, that is the answer.

What we would not buy

Security is a category full of things that feel protective and are not.

A premium security plugin as a substitute for updating. Firewall plugins are genuinely useful at blocking login floods and known bad requests. They are not a reason to leave a vulnerable plugin in place. Treating the subscription as cover for not patching is the most common expensive mistake we see.

A paid SSL certificate for a normal business site. A ₹4,000-a-year domain-validated certificate encrypts exactly the same traffic as a free Let's Encrypt one. Unless you have a specific compliance requirement, this is a line item hosts sell because people assume paid means safer.

One-off malware removal with no entry-point investigation. Someone cleans the infected files, charges for it, and the site is reinfected within a fortnight because the hole is still open and the attacker's hidden admin account is still there. Cleaning without finding the way in is laundry, not repair.

Anything guaranteeing you will never be hacked. Nobody can promise that, including us. What is buyable is a smaller attack surface, fast patching, and a tested path back to a clean copy.

"Unlimited" shared hosting at ₹99 a month for a site that takes orders. You are sharing resources and sometimes file permissions with hundreds of strangers. For a brochure site, fine. For anything carrying payments or customer records, not fine.

If it has already happened

Order matters here, and the instinct to delete the bad files first is wrong.

Take a full copy of the site as it is, infected. You will need it to work out how they got in.
Change every password: hosting panel, FTP/SFTP, database, all site admin accounts, and the email address those accounts recover to.
Look at the user list for accounts you did not create, and at file modification dates — the cluster of files changed at 4:17am on a Tuesday tells you when it started.
Restore from a backup taken before that date, then immediately update everything before putting it back online. Restoring to the same unpatched state reinfects within hours.
Check Google Search Console's Security Issues report and request a review once you are clean. Check your domain against common email blocklists if your mail is also affected.

Be honest about the uncertainty here: on a site that has been compromised for weeks, you often cannot prove you found everything. If the site is small and the content is recoverable, a clean rebuild on fresh hosting is frequently faster and more trustworthy than forensic cleaning.

What to do this week

Open your site's admin panel. Count the plugins. Delete the ones you do not use. Note which have updates pending and how long they have been pending. Then open your hosting panel and find the PHP version. That twenty-minute exercise tells you most of what you need to know about your risk, and it costs nothing.

If what you find is a site nobody has touched since it launched, that is worth a conversation — either about putting a maintenance routine in place, or about whether the site is old enough that rebuilding it properly is the better spend. Tell us what you found and we will tell you which one we think it is.

Questions we get asked

My website is just a few pages with our phone number. Do I really need security?

Yes, because attacks are not aimed at your content. A brochure site with an outdated plugin is useful to an attacker as a host for spam pages or a phishing login screen, and that works just as well on five pages as on five hundred. The defences are also small: keep software current, use unique passwords with two-factor authentication, and keep an off-site backup.

Is a free Let's Encrypt SSL certificate as safe as a paid one?

For encryption purposes, yes. A domain-validated Let's Encrypt certificate uses the same encryption as a paid domain-validated certificate from a commercial seller. Paid certificates differ in warranty terms, support and validation level, none of which changes how securely data travels between your visitor and your server.

Will Google remove my site from search results if it gets hacked?

Google documents a Security Issues report in Search Console, and browsers can show warning interstitials for sites flagged as distributing malware or hosting phishing pages, which collapses your traffic even if your pages are still indexed. Once you have genuinely cleaned the site and closed the entry point, you can request a review from within Search Console. How quickly normal traffic returns varies and nobody can promise a timeline.

We had our site cleaned once and it was hacked again a month later. Why?

Almost always because the original way in was never closed, or a hidden administrator account or backdoor file was left behind. Cleaning infected files without identifying the vulnerable plugin, outdated PHP version or leaked password just resets the clock. Any genuine clean-up should end with an explanation of how they got in and what changed so it cannot happen the same way again.

How often should website plugins and core software be updated?

Security releases should be applied within days of publication, because the vulnerability details become public at the same time as the fix and scanners start sweeping for unpatched sites almost immediately. Routine non-security updates can sit on a monthly schedule. For anything that takes orders or payments, apply updates on a staging copy first so a broken update does not take the live site down.