The Warning Sign Most Business Owners Miss
Most hacked websites don't look hacked. The homepage still loads. The contact form still works. Everything seems fine — until someone Googles your business name and finds pages about "clearance bike covers" or "cheap office furniture" indexed under your domain. Or worse, until Google sends a manual penalty and your legitimate pages disappear from search results entirely.
This is called a cloaking attack. The malicious content is invisible to regular visitors and even to you when you browse your own site. It's only shown to search engine crawlers — which is precisely why it's so dangerous and so commonly missed.
What Is a Cloaking Attack?
Cloaking is a technique where a server delivers different content to different visitors based on the requestor's identity. Legitimate SEO tools use cloaking for A/B testing. Attackers use it to inject thousands of spam pages onto your domain that Google indexes — boosting the spammer's content on your domain authority — while hiding everything from you.
The attacker benefits from your domain's age, authority, and reputation. Your domain gets penalized. You may not notice for months. By the time Google deindexes your site for spam policy violations, the damage is already done.
How to Confirm Your Site Has Been Compromised
The fastest way to check: go to Google and search site:yourdomain.com. If you see pages you did not create — random product listings, foreign-language spam, unrelated services — your site has been compromised. Also check Google Search Console under Security Issues for Google's own detection of the attack.
A more thorough check involves looking at your server's indexed URLs. If you have GSC set up, go to Coverage and look for URLs Google has indexed that you don't recognize. Filter by "Valid" — every URL in that list should be a page you intentionally created.
Where to Look for the Injected Code
The injection point is almost always one of four places:
1. The .htaccess File (Apache Servers)
Attackers add conditional redirect rules that serve spam content only when the visitor's user-agent matches a known search engine crawler. Open your .htaccess file and look for rules referencing Googlebot, Bingbot, or user-agent string comparisons. Any redirect logic you don't recognize should be treated as suspect.
2. PHP Files with Obfuscated Code
Look for PHP files containing base64-encoded strings, eval() calls, or gzinflate(). These are classic obfuscation patterns used to hide malicious code from site owners. Run a server-side search for these patterns across your entire codebase. On Linux servers: grep -r "base64_decode" /var/www/ and grep -r "eval(" /var/www/.
3. Injected Files in Upload Directories
Upload directories (like WordPress's wp-content/uploads/) are often world-writable. Attackers upload PHP files disguised as images — a file named image.jpg.php or simply a .php file in a directory that should only contain images. Audit any directory that accepts file uploads.
4. Compromised CMS Plugins or Themes
If your site runs on a CMS, outdated plugins and themes are the most common entry point. An attacker exploits a known vulnerability in an old plugin version to gain write access to your server. Check your CMS for any plugins or themes that haven't been updated in over six months.
Cleaning Up the Compromise
Once you've identified the injected code, the cleanup process follows a specific order — skipping steps can leave backdoors that allow reinfection within hours.
First, take a full backup of your current state (even the compromised version) before making any changes. This preserves evidence and gives you a rollback point if cleanup goes wrong. Then remove all identified malicious files and code. Reset all server passwords — FTP, SSH, database, and CMS admin accounts — because the attacker may have captured credentials. Update every plugin, theme, and CMS core to the latest version. Finally, audit file permissions and lock down any directories that shouldn't be writable by the web server.
Recovering Your Google Rankings
Cleaning the site is only half the battle. Google still has the spam pages indexed. You need to actively remove them:
Use Google Search Console's URL Removal tool to request removal of the specific spam URLs. This is a temporary measure (removals expire after 6 months) but it immediately stops Google from showing those pages in search results. Submit a fresh sitemap containing only your legitimate pages to help Google re-crawl and re-evaluate your site. If Google issued a manual penalty (visible in GSC under Manual Actions), you need to submit a Reconsideration Request after cleanup with documentation of what was compromised and what you've done to fix it. Recovery from a manual penalty typically takes 2-4 weeks after a successful reconsideration request.
Preventing Reinfection
The most common reason sites get reinfected: the entry point was never fully addressed. After cleanup, implement a web application firewall (WAF) to block common attack patterns before they reach your server. Enable two-factor authentication on all admin accounts. Set up Google Search Console alerts so you're notified immediately if new security issues are detected. And schedule regular file integrity monitoring — automated tools that alert you when server files change unexpectedly.
The Business Cost of Waiting
A site compromise that goes unaddressed for six months can result in full deindexing — every page removed from Google's search results. For a local business that depends on organic search traffic, this is catastrophic. Recovery from full deindexing takes months of active effort even after the technical issues are resolved. Every week you delay addressing a confirmed compromise compounds the damage.
If you've found spam pages indexed under your domain and aren't sure where to start, a 25-minute consultation can help triage the situation and outline a recovery plan specific to your site's stack and hosting environment.