The first thing most owners say when their site starts redirecting visitors to a pharmacy page is some version of "why would anyone target us?"
Nobody did. That is the part worth understanding, because it changes what you should do about it.
How it actually happens
Automated scanners crawl the web continuously, looking for one thing: a known weakness in a known piece of software. When a vulnerability in a popular plugin is published, its details become public the same day, and within hours scanners are testing every site they can reach for that exact version.
They are not reading your site. They do not know what your business does. They are checking a list, and an unpatched plugin on a small florist's site answers that list exactly like an unpatched plugin anywhere else.
That is why "we are too small to be a target" is the wrong model. You are not a target. You are a match.
The five ways in, in the order I actually see them
1. An outdated plugin or theme
By far the most common. Usually it is something installed for a single feature years ago, still active, and no longer updated by its author. Abandoned plugins are the worst case: no patch is ever coming, but the vulnerability is public.
2. A reused or weak admin password
Credential-stuffing attacks take username and password pairs leaked from unrelated breaches and try them everywhere. If the site's admin password is one you have used elsewhere, no vulnerability is needed at all.
3. Nulled or pirated premium plugins
A paid plugin offered free on a download site is free for a reason. Backdoors are frequently built directly into them. This one is particularly unpleasant, because the site is compromised from the moment it is installed, by the person who installed it.
4. A shared hosting neighbour
On cheap shared hosting with poor isolation, an infection on someone else's site can reach yours through shared file permissions. You did nothing wrong, and you are still infected.
5. An old staging copy nobody deleted
A forgotten /old/ or /dev/ folder running a two-year-old copy of the site is a perfect entry point: same server, no updates, nobody watching.
What an infection actually looks like
Defacement is rare, because visible damage gets fixed quickly. Attackers prefer to stay hidden:
- Spam pages quietly added in their hundreds, usually for pharmaceuticals or counterfeit goods, to borrow your domain's search reputation.
- Conditional redirects that send visitors elsewhere only when they arrive from Google, and only on mobile, so the owner never sees it.
- Mail sending, which is why the first symptom is often that your legitimate emails start landing in spam everywhere.
- Card skimming on checkout pages, which is the version that turns a technical problem into a legal one.
- Hidden admin accounts, so that cleaning the files alone does not lock the attacker out.
What actually prevents it
Almost none of this requires expensive tooling. In rough order of how much good it does per hour spent:
- Update monthly, and delete what you do not use. Every deactivated plugin still sitting on the server is still code on the server. Remove it.
- Unique passwords and two-factor authentication on hosting, the CMS and the domain registrar. A password manager makes this a non-event.
- Fewer plugins. Every one is code written by a stranger, running with full access to your site. Twelve carefully chosen plugins are safer than thirty convenient ones.
- Off-site backups you have actually restored once. An untested backup is a belief, not a backup, and backups stored only on the same server are lost with it.
- Never install nulled plugins. Ever.
- Delete old copies of the site, and any staging folder you are not actively using.
- A web application firewall. Cloudflare's free tier blocks a large share of automated scanning before it reaches your server.
If it has already happened
Order matters here, and the instinct to "just delete the bad file" usually causes reinfection within days.
- Take a copy of the infected site before changing anything. You may need it to work out how they got in.
- Change every password: hosting, CMS, database, FTP, registrar.
- Look for unfamiliar admin users and remove them.
- Restore from a backup taken before the infection, if you have one that predates it.
- Update everything immediately afterwards, or you are simply restoring the same hole.
- Check Google Search Console for a security notice, and request a review once you are clean.
- Find the entry point. Skipping this step is why sites get reinfected repeatedly.
If customer data or card details may have been exposed, that is no longer just a technical cleanup. Legal obligations to notify people can apply, and they vary by state and country. Talk to someone qualified before deciding it was nothing.
The honest summary
Most infections I have cleaned came down to one abandoned plugin and a site nobody had updated in over a year. The fix was not clever security software. It was an hour a month, a password manager, and deleting things that were not being used.
