Website security
& malware cleanup
in Chicago

The owner opens the home page and everything looks normal. A customer calls to say the site sent them to a pharmacy shop. Both are telling the truth. Much of the malware found on small business sites is conditional. It decides, on every request, whether this visitor should see the attack or the ordinary page.

The conditions are simple and effective. A common one is the referrer. Visitors who arrive from a search result are redirected, while anyone who types the address directly sees the real site. Another is the device. Phones get the redirect, desktops do not. Some scripts fire only once per visitor, set a cookie, and then stay quiet so that a second visit shows nothing wrong.

Logged-in users are usually excluded. The script checks for the admin session cookie and hides from it. This is why the person who manages the site is often the last to learn about the problem. Every time they look, they look as an administrator.

Search engines get their own version. The crawler may be served a page full of spam links or foreign keywords, while humans see the normal text. The first sign is often a strange snippet under your page in search results. Sometimes a notice arrives in the search console about spam or hacked content.

So how is a hidden infection confirmed? Stop testing from the admin browser. Use a private window with no cookies. Load the site from a phone on mobile data. Follow a real search result instead of typing the address. Fetch pages with a crawler user agent and compare the raw HTML with what a browser shows. The URL inspection tool in the search console shows the page as the engine received it.

Server logs help once you know what to look for. Unusual outbound redirects, requests to files that should not exist, and bursts of traffic to pages the site never linked are all clues. A log line with a search engine referrer followed by a redirect status is close to a signature.

The code behind this behaviour hides in predictable places. It may sit at the top of a theme file, in a rewrite rule in the server configuration file, in a plugin that looks legitimate, or inside the database as a stored script in an option or a widget. Some variants load their instructions from a remote server, so the local file contains only a short loader that looks harmless.

Cleaning has to cover all of them. Removing the visible redirect while leaving the loader in place only buys a few days. A proper cleanup compares core files with fresh copies, reads rewrite rules line by line, reviews every plugin and theme against its official source, and searches the database for script tags and encoded strings.

Afterwards, test the same way the infection chose its victims. Search referrer, phone, fresh browser, crawler. Repeat the checks a week later. A conditional infection that survived will reveal itself only to the conditions it was built for, so the test has to recreate them each time.

Ask the cleanup team for the list of conditions they found. Knowing that the script targeted phones from search results tells you which reports from customers to take seriously next time. It also tells you which monitoring check would have caught the problem earlier.

That check is worth setting up once the site is clean. An external monitor can request a few key pages every hour with a search referrer and a mobile user agent, then alert when the response is a redirect to another domain. It costs little. It watches from outside, which matters, because a compromised server can also tamper with any monitoring that runs on it. Pair it with file change alerts on the server and the two together cover most of the ways this kind of infection returns.