In this guide (8)
- 1How a silent attack works
- 2Signal 1: drop in organic traffic with no apparent cause
- 3Signal 2: indexed pages you didn't create
- 4Signal 3: recently modified files with no corresponding work
- 5Signal 4: anomalous HTTP requests in the server logs
- 6Signal 5: different behavior on mobile vs desktop
- 7How to check in 10 minutes with free tools
- 8Why some CMSs are structurally more exposed
The website NapoliBene.it was online, loading regularly, receiving traffic. There was no Google warning, no suspicious redirect, no popup. The site seemed to be working perfectly.
It had been compromised weeks earlier.
They only discovered it when an external user, browsing from a mobile device, was redirected to a spam site. From desktop, everything looked normal. The attack was set up to be invisible to administrators and visible only to certain visitors — a technique called conditional cloaking, used by hackers to stay undetected for as long as possible.
This article doesn't cover the obvious signs of an attack — blatant redirects, Google's red warning screen, an offline site. Anyone would notice those. It covers the 5 invisible signs that point to a silent compromise, the ones most website owners don't know where to look for.
How a silent attack works
The attacks that make headlines — site offline, Google's "dangerous site" screen, ransomware — are actually the least sophisticated ones. A novice attacker wants immediate visibility. A skilled attacker wants exactly the opposite.
The goal of a silent attack is not to destroy the site. It's to use it. Your domain has authority, it has traffic, it has years of history. For a hacker it's a valuable resource to exploit without burning it.
There are three common techniques for silent compromise. The first is SEO spam injection: hidden pages or links are inserted pointing to third-party sites (gambling, pharmaceuticals, scams) to exploit your domain authority. These pages are invisible to administrators but indexed by Google. The second is conditional cloaking: the malicious code activates only for certain users — those coming from mobile, those coming from Google, those not logged in as admin. The third is credential harvesting: a script is installed that intercepts data entered into your site's forms before it is saved to the database.
In all three cases, the site continues to function normally for whoever manages it. The damage emerges weeks or months later.
Signal 1: drop in organic traffic with no apparent cause
A sudden 20-40% drop in organic traffic within a few days, without you having published or changed anything, is one of the first signs of a Google penalty due to compromise. Google discovers the malware or spam links before you do — its crawlers scan the site far more frequently than you check it manually.
How to check: go into Google Search Console → "Search results" section → compare clicks from the last 28 days with the previous period. If there's a sharp drop that doesn't coincide with any change to the site, go to "Security issues" — you'll find all the alerts Google has already detected.
Note: a drop can have various causes (algorithm update, seasonality, competition). But if it coincides with an alert in Search Console or with other signals on this list, the probability of compromise is high.
Signal 2: indexed pages you didn't create
This is the clearest sign of an SEO spam injection. The hacker inserts dozens or hundreds of spam content pages into your site — often in different languages, often with URLs structured to look legitimate — which Google indexes normally.
How to check: go to Google and search for site:yourdomain.com. Scroll through the results. If you see pages you don't recognize — with strange titles, in languages you don't use, on topics that have nothing to do with your site — your site is compromised. This is exactly the kind of problem several Joomla sites we migrated had: Google was indexing content the owners had never seen.
You can refine the search with site:yourdomain.com viagra or site:yourdomain.com casino — these are the most common terms in injected spam sites. If results show up, the problem is already serious.
Signal 3: recently modified files with no corresponding work
Every webshell or backdoor installed by a hacker leaves a trace: a file modified or created on a date when no one worked on the site. On WordPress this shows up in the PHP files of the wp-content folder, often with innocuous names like functions-helper.php or cache-loader.php.
How to check via SSH or FTP: look for files modified in the last 30-60 days in the site's main folders. Over SSH the command is find /path/to/site -name "*.php" -mtime -30 -ls. If you find PHP files modified on dates when you made no updates, open them and check their content — a file with functions like eval(base64_decode(...)) or system($_GET['cmd']) is an active webshell.
To learn more about how to recognize and block webshells, we've written a specific technical guide: Webshell: what it is, how it works and how to block it.
Signal 4: anomalous HTTP requests in the server logs
The server's access logs record every request received. A compromised site shows specific patterns: repeated requests to unusual PHP files, access to paths that don't exist on your site (/wp-admin/admin-ajax.php on a Joomla site, for example), requests with suspicious GET parameters.
How to check: access logs are typically found in /var/log/apache2/access.log or /var/log/nginx/access.log, or are accessible from your hosting control panel. Look for requests with a 200 code (success) to PHP files you don't recognize. A concentration of requests to the same file from different IPs in a short time indicates that someone is actively using a backdoor.
This type of analysis requires SSH access or a hosting panel that exposes the logs. If you don't have access, you can ask your provider — it's data you're entitled to.
Signal 5: different behavior on mobile vs desktop
Conditional cloaking is the most sophisticated technique, and the one that hit NapoliBene. The malicious code runs only under certain conditions: mobile user agent, Google referrer, unauthenticated user. Whoever manages the site — always logged in, always from desktop — never sees the problem.
How to check: use Google Search Console → "URL Inspection" section → "View as Google". This shows you exactly what Google's crawler sees when it visits your pages. If what you see there differs from what you see in your browser, there's cloaking.
A second method: use your smartphone with a mobile data connection (not your home WiFi) and visit the site from a Google search, not by typing the URL directly. This is the condition most similar to that of a regular user arriving organically — and it's often the one that triggers the malicious redirect.
How to check in 10 minutes with free tools
Quick checklist to run right away:
1. Google Search Console → Security Issues — if Google has already detected something, you'll find it here. Free access, immediate data.
2. Google Safe Browsing Transparency Report — enter your domain at transparencyreport.google.com/safe-browsing/search. Result in 10 seconds.
3. Site: search on Google — site:iltuodominio.it — scroll through the first 5 pages of results. Pages you don't recognize are an immediate warning sign.
4. Sucuri SiteCheck — sitecheck.sucuri.net — free scanner that checks for known malware and blacklists. It's not exhaustive, but it's a useful first filter.
5. Mobile view on a data network — access the site as an organic user, not as an administrator.
If any of these five checks returns something unusual, the next step is an in-depth technical analysis — not an "emergency restore" that removes the symptoms without finding the cause.
Why some CMSs are structurally more exposed
SEO spam injection, conditional cloaking and PHP backdoors have one thing in common: they exploit the open file system and plugin ecosystem of an open-source CMS. On WordPress, a vulnerable plugin with 200,000 active installations is an attack vector that hits 200,000 sites in parallel within hours of the flaw being discovered.
This isn't a problem that Wordfence or another security plugin can solve — as we analyzed in detail in the article Has your site been hacked? What it really costs you. An application-level WAF operating inside the very installation it's trying to protect has a precise structural limitation: it can be disabled by the same vector it's meant to block.
The difference with a closed proprietary CMS — without a public plugin ecosystem, without analyzable source code — is that no standardized attack surface exists. An attacker can't write a script that looks for "all sites with vulnerable plugin X" because that plugin doesn't exist. KeideaCMS's protection is built into the architecture, not bolted on top.
If you've run the checks in this guide and found something unusual — or if you simply can't verify because you don't have access to the logs — the free audit we offer analyzes your current stack, identifies concrete vulnerabilities and shows you what's really happening on your site.
