A compromised site isn't always obvious at a glance: many attacks are deliberately designed to stay invisible to the site owner while generating value for the attacker (spam traffic, manipulated links, redirects to other domains) only in front of crawlers or users arriving from a specific search. Understanding how to technically detect these compromises, before Google detects them and applies a manual action, is the difference between a quiet cleanup and weeks of lost traffic while a public warning in search results gets resolved.
Spam content injection: the most common attack and the easiest to miss
The most common pattern involves injecting content (usually links or text related to pharmacy, gambling, or branded product knockoffs) into legitimate pages on the site, often visually hidden via CSS (text the same color as the background, or positioned off-screen) so a human visitor never notices it but a crawler still processes it. Searching Google for site:yourdomain.com alongside terms obviously unrelated to the business (for example, "viagra" or "casino") is a quick, free check that reveals whether Google has already indexed this kind of injected content.
Cloaking: showing Google something different than users see
Cloaking means serving different content depending on who's making the request: Googlebot gets shown an apparently normal page, while a human user arriving from the search result gets redirected to a different domain (usually fraudulent ads or malware). It's one of the most serious manipulation techniques as far as Google is concerned, with severe penalty consequences if detected, and also one of the hardest for the site owner to detect, precisely because browsing normally (without arriving from a real search) makes the problem invisible.
// Basic check: compare the server response
// across different user-agents from the command line
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1)" https://yourdomain.com/page
curl -A "Mozilla/5.0 (Windows NT 10.0)" https://yourdomain.com/page
// If the content differs substantially, that's a sign of cloakingConditional malicious redirects
A frequent variant redirects users (but not crawlers) to a different domain only under certain conditions: mobile devices, a specific referer (arriving from Google specifically), or even only on each user's first visit to make detection harder. These patterns are usually injected into compromised .htaccess files or PHP code added to CMS templates, and a file-integrity review (comparing current files against a known-clean backup) is the most reliable way to find them.
How Google communicates a detected compromise
Search Console has a specific section, Security Issues, where Google explicitly notifies if it has detected malware, hacked content, social engineering (phishing) or spam injected into the site. The severity of the response varies: from a visible warning in the search result ("this site may be hacked") to complete removal of the site from the index in the most serious cases or if the problem persists unresolved.
The technical cleanup process: why disabling the symptom isn't enough
A common mistake is cleaning up only the visible symptom (deleting injected spam text, disabling a suspicious plugin) without finding and closing the actual entry point that allowed the compromise. If that entry point (a weak password, an outdated plugin with a known vulnerability, a misconfigured file permission) stays open, the attack repeats within days or weeks, often more aggressively. The correct technical process includes: identifying the real entry vector (reviewing server logs for anomalous requests and the file change history), cleaning up all injected code (not just what's visible, but also hidden backdoors that allow re-injecting content later), updating all vulnerable software (CMS, plugins, dependencies), and rotating every access credential, not just the ones suspected of being compromised.
Requesting the review: order matters
Once the full cleanup is confirmed, Search Console lets you request a manual review of the security issue. Requesting it before the root cause is actually resolved (for example, only after deleting the visible content but without closing the vulnerability) usually lengthens the process: if Google's human reviewer finds the same problem during the check, or if the site gets compromised again during the review, the request gets denied and the whole process has to start over.
Prevention: continuously reducing the attack surface
Beyond recovering from a compromise, a set of technical practices substantially reduces the risk of it happening: keeping the CMS, plugins and dependencies always updated to their latest stable version; using unique, strong passwords for every account with access to the server or admin panel; limiting file and folder permissions to the minimum the application needs to function; and taking regular, verified backups (actually testing they can be restored, not just that they're generated) that let you revert to a known-clean state if a compromise goes unnoticed for a while.
Frequently asked questions
How long does it take Google to remove the security warning after a cleanup?
Once the manual review is requested with the cleanup already confirmed, the process usually takes anywhere from a few days to two weeks, depending on the volume of requests Google is handling at the time and the case's complexity.
Does a hack affect rankings even without any visible manual action?
Yes: even without a visible warning in results, a compromised site usually suffers an indirect performance drop from the technical degradation the attack itself introduces (malicious code running, server resources consumed by the attacker, possible redirects Google detects as a low-quality signal).
How do I know if my site has been a cloaking victim without realizing it?
Comparing the server's response across different user-agents (as shown in this guide's example) is the most direct technical check; it's also worth periodically reviewing Search Console's Security Issues report, not just when a problem is suspected.
Is it enough to just restore a backup from before the attack?
Only if that backup predates the actual moment of compromise (not just when it was detected, which can be much later) and if the vulnerability that allowed entry is also closed; restoring without closing that door usually results in reinfection shortly after.
Is shared hosting more vulnerable than a dedicated server?
It can be if isolation between accounts on the same server is poor: a security flaw in another site hosted on the same server can, in badly isolated setups, also affect other accounts on that same hosting, something far less likely on a dedicated server or with robust account isolation.