Website Malware and Blacklisting: Prevention, Detection and Recovery

A business owner usually finds out their website has been hacked in one of three ways: a customer emails to ask why the site tried to download something, Chrome shows a full-page red warning before the site loads at all, or organic traffic falls off a cliff for no visible reason. By the time any of those three happen, the malware has usually been sitting on the server for days or weeks already, quietly doing what it was put there to do — and the visible symptom is rarely the first sign, just the first one a human noticed.

Website malware and search-engine blacklisting are two different problems that usually arrive together. The malware is the infection: injected code, a backdoor script, spam pages hidden inside the site’s file structure. The blacklist is the consequence: Google, and sometimes browsers directly, warning visitors away from the site before they ever load it. Fixing the infection without addressing the blacklist leaves the site clean but still marked as dangerous. Getting delisted without actually removing the infection just means the warning comes back.

How Websites Actually Get Infected

Almost none of it is a targeted attack against one specific business. The overwhelming majority of infections come from automated scanners that continuously probe the entire internet for a small number of known weaknesses:

• Outdated core software, themes or plugins — a known vulnerability in an old version of WordPress or a popular plugin gets exploited within days of being publicly disclosed, on every site still running that version.
• Weak or reused admin passwords — automated credential-stuffing tools try thousands of common passwords against login pages around the clock.
• Nulled or pirated plugins and themes — files distributed outside official marketplaces frequently ship with a backdoor already built in, installed by the site owner without knowing it.
• Compromised hosting neighbors — on shared hosting, a poorly isolated account on the same server as a compromised site can be affected even without a direct vulnerability of its own.

None of these require the attacker to know the business exists. That’s the uncomfortable part for a small business owner who assumes “nobody would bother hacking us” — nobody has to bother, the scanning is already running against every reachable server on the internet, all the time.

What an Infection Actually Looks Like

Spam Injection

The most common pattern for a marketing-driven site: attackers insert hidden pages or hidden links selling pharmaceuticals, counterfeit goods or gambling, visible to search engines but hidden from normal visitors through CSS or conditional loading. This is often discovered by searching site:yourdomain.com in Google and seeing page titles that have nothing to do with the business.

Malicious Redirects

Visitors, or sometimes only visitors arriving from a search result, get silently redirected to another domain entirely. This is usually the version that generates a customer complaint before anything else does, since it’s the most visible to a normal user.

Backdoor Scripts

A hidden file that lets an attacker re-enter the site even after the original vulnerability is patched. This is the reason a surface-level cleanup — deleting the obviously malicious file and calling it done — so often fails: the backdoor that let the attacker in the first place is still there, untouched, waiting to be used again.

Cryptomining or Botnet Scripts

Code that quietly uses server resources for the attacker’s benefit rather than targeting visitors directly. Often the first visible symptom is server slowdown or an unexplained spike in resource usage rather than anything a visitor would notice.

Detection and Recovery: A Practical Sequence

1. Confirm the Blacklist Status

Google’s Safe Browsing site status check shows whether Google currently considers a domain unsafe, and why. This is the fastest way to confirm whether visitors are actually seeing a warning, separate from confirming whether malware is present at all — a site can be infected without yet being blacklisted, and rarely, flagged without an active infection due to a false positive.

2. Isolate Before Cleaning

Take the affected site offline or put it into maintenance mode before starting cleanup. An infected site left publicly reachable during cleanup can reinfect itself from a backdoor that hasn’t been found yet, undoing the work in progress.

3. Find Every Modified File, Not Just the Obvious One

Compare the live file set against a known-clean backup or a fresh copy of the core software and every plugin’s official release, looking for any file that’s been modified, added, or has an unusual modification timestamp. A single deleted malicious file is not a cleanup — the same vulnerability that let the first file in will let a second one in the same way, usually within hours.

4. Rotate Every Credential

Admin passwords, database passwords, FTP/SFTP credentials, and API keys should all be reset after any confirmed intrusion, not just the account that was obviously used. An attacker with backdoor access for even a short time may have harvested credentials that look completely unrelated to the original entry point.

5. Patch the Actual Entry Point

Cleanup without identifying and patching the vulnerability that allowed entry just resets the clock until the same scanner finds the same opening again. Server logs from around the estimated infection date are the most reliable way to identify which request actually got through.

6. Request Reconsideration

Once the site is confirmed clean, Search Console‘s Security Issues report is where a review request gets submitted. This step only removes the browser warning — it does nothing to fix the underlying infection, which is why it has to come last, not first.

Prevention Costs Far Less Than Recovery

Every step above is reactive, and reactive work on a live incident is always more expensive — in time, in reputation, and often in lost search ranking — than the prevention that would have avoided it. The prevention checklist is short and unglamorous: keep core software and every plugin updated on a defined schedule rather than “whenever there’s time,” use unique, generated passwords with two-factor authentication on every admin account, avoid nulled or pirated extensions entirely, keep offsite backups that are tested (not just scheduled), and put a web application firewall in front of the site so that a large share of the automated scanning traffic never reaches the application layer at all. This is the kind of ongoing work that a server administration arrangement is built to cover on a continuing basis, rather than something that only gets attention after an incident.

For a site that’s already showing symptoms — unexplained slowness, unfamiliar admin accounts, strange search results — a technician who can diagnose the specific cause quickly is worth involving before more time passes, since every additional day an infection sits undetected increases both the cleanup effort and the chance it’s already been indexed by search engines under someone else’s spam content.

FAQ

How do I know if my website has malware?

Common signs include unexpected redirects, a Safe Browsing warning in Chrome, unfamiliar pages appearing in a site:yourdomain.com search, unexplained server slowdowns, or a sudden drop in organic traffic. Google’s Safe Browsing status check is the fastest first step to confirm a blacklist, though absence of a warning doesn’t guarantee absence of an infection.

How long does it take Google to remove a blacklist warning after cleanup?

Once a reconsideration request is submitted through Search Console, Google typically reviews it within a few days, though it can take longer. Submitting a request before the site is genuinely clean risks a rejection and a longer overall delay.

Can shared hosting cause an infection even with a secure website?

Yes, on hosting environments with weak account isolation, a compromised neighboring site on the same server can sometimes affect others. This is one of the practical arguments for VPS or dedicated hosting once a site has meaningful traffic or handles customer data.

Is restoring from a backup enough to fix an infection?

Only if the backup predates the infection and the original vulnerability is also patched before going back online. Restoring an infected site to its previous state without fixing the entry point typically results in reinfection.

Do small business websites really get targeted?

Almost never individually. The realistic risk is automated scanning that targets known vulnerabilities across the entire internet regardless of business size — a small site running outdated software is exactly as exposed as a large one running the same version.

What’s the difference between a firewall and antivirus software for a website?

A web application firewall filters malicious requests before they reach the site’s code, reducing exposure to known attack patterns. Server-side malware scanning looks for signs of infection after the fact. Both matter; a firewall alone doesn’t detect an existing infection, and scanning alone doesn’t prevent new attempts.

The Bottom Line

Malware and blacklisting are two different problems that need two different fixes: removing the infection completely, including the entry point that let it in, and separately requesting the search-engine or browser review that lifts the warning. Skipping either half leaves the site either clean but still flagged, or delisted but still vulnerable to the same attack that got in the first time. The cheapest version of this problem is the one that’s prevented — kept-current software, unique credentials, tested backups and a firewall — rather than the one that has to be cleaned up after the fact.