Flagged as hacked by Google: the real sequence, and what recovery takes

A compromised site does not lose its traffic on the day of the breach. It loses it on the day a search engine notices, and it does not get it back at the moment the problem is fixed. That gap between three separate dates is what makes this subject poorly understood, and why the bill always lands heavier than expected.

This article sets out the real order of events, the mechanisms that pull visibility down, and what nobody can promise you about how long recovery takes.

The order of events

It is nearly always the same, and no step skips its turn.

1. Something becomes readable. A configuration file served by mistake, a component whose publisher stopped shipping fixes, an administration interface reachable without restriction. At this point nothing has happened: the flaw exists, it is public, and it waits.
2. A bot finds it. Nobody targeted you. Programs sweep the Web permanently, trying the same addresses in the same order on every domain they meet. It is a scan, not an attack.
3. The site serves content its owner never wrote. The common case is not the defaced homepage, which is noticed immediately: it is the quiet injection of pages or redirects aimed at search engines rather than at you. They appear neither on your home page nor in your admin panel.
4. The engine detects the anomaly. Within days, in the cases we observe. The site is then flagged in results, and sometimes in visitors' browsers.
5. Visibility falls. Not all at once, and that is the misleading part: at first the decline looks like seasonality.
6. The cleanup. The injected content has to go, the door has to be closed, and every secret that was readable has to be treated as compromised.
7. The reconsideration request, then the wait. This last step is not under your control, and it lasts.

Between step 1 and step 4 there is a window in which the flaw is already public and nothing has happened yet. It is the only one where an outside observation can make a difference.

Why rankings fall

Three mechanisms act at once, and they are usually mistaken for one.

The flagging. The most visible one. A result carrying a warning loses a large share of its clicks even when it keeps its position. The ranking has not moved; the traffic has.

Crawl budget diverted. Injected pages are crawled like yours. On a site of a few thousand URLs, a mass injection takes up a meaningful share of what the engine is willing to fetch from you, and your real pages get revisited less often. Your legitimate updates stop being picked up at the usual speed.

Loss of site coherence. Injected pages talk about another subject, in another language, pointing at other destinations. They dilute what your site declares itself to be. This effect is the slowest to appear, and the slowest to fade.

The first mechanism is fixed by cleaning up. The other two are fixed by crawling, which means by time.

What Search Console shows, and what it does not

Search Console reports detected security issues and lets you request a reconsideration. It is the reference tool and it deserves watching.

Two limits are worth knowing. First, it is a tool of record, not of prevention. It talks to you once the engine has detected something, which is step 4 above, when the cost is already incurred. Second, it says nothing about the publicly observable signals of steps 1 to 3. A readable configuration file is not an anomaly from its point of view, as long as nobody has used it.

The signals that come first, and can be read from outside

They share one property: they are visible from the Internet, with an ordinary visitor's means, with no credentials and without changing anything.

• A configuration file served as-is. The most serious case, because it hands over usable secrets directly: database password, mail sending keys, API tokens. Blocking access afterwards is not enough: the file may already have been read, and the secrets have to be rotated.
• A component whose publisher stopped shipping fixes. Weaknesses found after end of support stay open indefinitely, and they are publicly documented, so they are the first ones scanning bots try.
• Exposed source code. A version control directory left in the public root gives away the project history, and sometimes credentials that once passed through it.
• An expired or badly chained certificate. The browser warns before the page even renders. The effect on conversion is immediate, and it waits for no search engine.
• Unencrypted resources called from a secure page. A script loaded without encryption can be replaced in transit. Browsers sometimes block it silently, and the page degrades with no visible error.
• Your domain's status with Google Safe Browsing. The same source that triggers the warning in your visitors' browsers, and it can be queried directly.

None of these readings requires access to your server. They record what your site already exposes to whoever asks.

What nobody can promise you

This is the part providers tend to skip, and it is better read before choosing one.

The recovery delay cannot be measured in advance. It depends on a third party's decision. The orders of magnitude we observe run in weeks after the reconsideration request, but publishing a number of days would be an invention.

A finding that disappears does not prove a fix. A pass that no longer finds anything may mean the flaw is gone, or that the pass failed. Two passes are only comparable if each can state that it ran to completion, otherwise « gone » reads as « fixed ».

An outside reading cannot see what is not exposed. Anything requiring an account, a password or server access stays out of reach by construction. That is the limit of any observation made from the outside, and it is structural: lifting it would require access nobody should grant for the sake of a reading.

The order of operations, if it has already happened

1. Close the access, without waiting to understand the whole story.
2. Rotate every secret that was readable. Database, API keys, mail tokens. Treat them as known.
3. Remove the injected content, searching for pages you did not write rather than the ones you know about.
4. Check the offending address after fixing it. An empty 200 is still a response: the file is still being served.
5. Request reconsideration, once, with the detail of what was done.
6. Watch crawling, not just rankings. Positions come back after bot visits come back, never the other way round.

What to take away

The penalty is a visibility penalty, and it lands after the fact. The only room for manoeuvre sits between the moment a flaw becomes readable and the moment an engine notices it, which is exactly where a regular outside reading has value. After that, all that is left is to clean up and wait for a decision that is not yours to make.