A Hacked Website Is Bad. What Google Does Next Is Worse.

The call usually comes in the same shape. A business owner rings, calm at first, because the website looks completely normal on their screen. Then someone told them to search their own business name on Google. Now they are not calm.

Take a physiotherapy clinic in Carlow. Composite of the jobs we get, but the details never change much. The owner had done nothing wrong that morning. She had not touched the site in weeks. Yet a patient had phoned to say that clicking the clinic's link brought up a full red screen warning them the site was dangerous. Another new enquiry, a good one, simply never arrived, because the person searching saw a grey line of text under the listing: "This site may be hacked." They booked elsewhere.

The clinic's website was fine. That was the cruel part. The files were mostly intact, the booking page worked, the phone number was right. The damage was not on the site at all. It was in the search results, and it had already started costing her the one thing a local clinic runs on, which is new patients finding it.

The site was never the target. Your ranking was.

Most owners get one thing wrong about being hacked. They picture someone stealing their data or defacing the homepage with a skull. That happens, but it is rare for a small business. Far more often, the attacker does not want your customer list. They want your Google standing.

Google calls this hacked content, and it defines it plainly: content placed on your site without permission because of a security hole. It comes in two main flavours. Page injection, where the attacker quietly adds hundreds of new spam pages to your domain, usually selling counterfeit goods, dodgy pharmaceuticals or worse. And code injection, where malicious script is threaded into pages you already have, often set up to redirect visitors somewhere else entirely.

Why bother with a small clinic in Carlow? Because your domain has something the attacker's throwaway spam domain does not: history, trust, and a foothold in Google's index. They are borrowing your reputation to rank their junk. In practice that means a stranger's counterfeit-handbag pages are now living on your address, and Google is reading them as yours.

There is a nastier trick layered on top. Cloaking. The injected code checks who is asking. Show a search engine and human visitor two different things, so Googlebot sees the spam while you, logged in from your own office, see your normal homepage. That is precisely why the owner sees nothing wrong. Most compromises are built to stay hidden from the person who owns the site, which is a problem we have written about before in how a WordPress site can be silently compromised for weeks before anyone notices.

What your customers actually see

Now walk it back to street level. None of the technical detail matters to the person searching for a physio at nine on a Sunday night. They see one of two things, and both stop them cold.

The softer one is the label. Under your listing, in plain grey text, Google prints "This site may be hacked." It is not a full block. People can still click. Almost nobody does. You have spent years earning a spot near the top of the local results, and a single line of text has just turned it into a warning sign.

The harder one is the red screen. If the injected code is serving malware, Google's Safe Browsing service steps in. By Google's own account this service guards billions of devices and checks enormous volumes of URLs every day, and when it decides a page is dangerous it throws a full-page red interstitial in front of it. Your customer taps your link and gets told, in the strongest terms the browser has, to go back. No booking. No enquiry. Just a warning with your name on it.

Sit with what that does to a business that lives on local trust. The clinic's reputation was never in the injected code. It was in the fact that the entire town's first impression of it, for as long as the flag stayed up, was a security alert. You cannot un-ring that for the people who saw it and quietly went elsewhere.

Cleaning the files is the easy part

This is where the story turns, and where most owners get blindsided. They assume that once the site is scrubbed, the warning vanishes with it. It does not. After a hack you are running two separate clocks, and they do not keep the same time.

The first clock is the server. Removing malicious files, deleting the injected pages, restoring a clean version, closing the hole the attacker climbed through. For a competent operations team this is often an afternoon's work. On a site with a verified clean backup from before the compromise, a rollback to a known-good restore point can have production genuinely clean in well under an hour.

The second clock is Google's, and it does not start until you tell it to. The flag on your listing will not lift on its own. Google gives you exactly one place to deal with it: the Security Issues report inside Search Console, which shows you what it found and, crucially, is the only channel to request a review. So the recovery sequence is fixed. Verify the infection is genuinely gone. Confirm the entry point is closed. Then open Search Console and request the review.

Then you wait. In our experience the review can clear in a day or stretch to a couple of weeks, depending on whether Google classed it as hacked spam or outright malware. And here is the sync reality check nobody enjoys hearing: even after the flag lifts, your rankings do not spring back to exactly where they were. Google re-crawls, re-assesses, and the positions you lost while flagged can take a further while to climb back. The warning is temporary. The dent in visibility outlasts it.

One more trap. If you request that review while a single malicious file is still lurking, the review fails, and you are back at the start of the queue. A half-clean site is, for this purpose, a dirty one.

Why it keeps happening to the same sites

The clinic's story had a second act, and it is the one worth learning from. Six days after the first clean-up, by a different provider, it was flagged again. Same spam, back from the dead.

I will own a version of this mistake from our own early days. We once cleared a compromised site, verified the files were spotless, watched Google lift the flag, and moved on satisfied. We had not properly closed the entry point, an outdated plugin with a known hole. It was reinfected inside a week. The lesson landed hard and it has shaped how we work since: cleaning the symptom without closing the door is not a fix, it is a delay.

That is the whole game with reinfection. Removing the spam pages does nothing about the vulnerability that let them in. An abandoned plugin, a reused admin password, a theme that stopped getting updates two years ago. Until that door is shut, you are just tidying up before the next break-in. Reviewing our incident logs, the sites that get hit twice are almost always the ones where someone deleted the payload and declared victory.

This is also where prevention quietly beats recovery every time. A managed platform that keeps the server hardened, scans for malware continuously, and takes automatic nightly backups is not selling you peace of mind as a slogan. It means the entry points are being closed before an attacker finds them, and it means that if the worst does happen, you have a verified clean restore point from last night to roll back to, rather than a rebuild from memory. Web60 runs exactly that kind of hardened, continuously monitored infrastructure, where the boring, unglamorous work of patching and scanning happens without the owner ever having to think about it.

What actually keeps you off both clocks

Strip away the drama and the defence is not exotic. A site that rarely ends up flagged tends to do a handful of dull things well.

1. Patch fast. The overwhelming majority of these break-ins ride in through a known vulnerability in an out-of-date plugin, theme or core file. Keeping them current closes most doors before anyone tries them.
2. Lock the front door. Strong, unique admin credentials and server-level protection against brute-force login attempts. Most attackers are not clever. They are just persistent, and they walk in through weak passwords.
3. Scan continuously. Automatic malware scanning that catches an injection early, ideally before Google does, so you find it on your terms rather than in a customer's phone call.
4. Keep a clean backup you have actually tested. A verified nightly backup with one-click restore turns a catastrophe into an inconvenience. An untested backup is just a hope with a filename, which is why a proper WordPress security and backup routine is the single most valuable thing a business site can have in place before trouble arrives.

Now the honest concession, because you deserve one. If your web presence is a genuinely static, single-page brochure with no logins, no database and no plugins, your exposure to this whole category of attack is genuinely low. There is not much surface to inject into. But the moment you have a real WordPress site with a booking form, a content system and an admin login, which is to say the moment your site is actually useful to your business, you have a surface worth defending. Most businesses cross that line the day they go live.

The lesson the clinic took away

The Carlow clinic is fine now. Cleaned properly, entry point closed, flag lifted, rankings recovered over the following weeks. But the owner said something at the end that stuck with me. She had always assumed being hacked was a data problem, something that happened behind the scenes. What actually hurt her was public, and it was her reputation in Google's results, shown to every customer who searched while the warning was up.

That is the real shape of it. The compromise is technical. The cost is reputational, and it plays out in the one place your customers form their first impression of you. Cleaning a site is a task with a clear end. Rebuilding trust with the people who saw a red warning where your name should have been is not.

So the practical takeaway is not a panic. It is a shift in where you spend your attention. Decide now, while everything is quiet, whether your site is being patched, scanned and backed up by someone whose job that is. Because the afternoon it matters, you want to be running a rollback, not a rescue.

Sources