Not every WordPress hack is loud. Some attackers do not want to deface your site or hold it for ransom. They want to quietly hijack your domain’s search authority and use it to rank their own content in Google. These attacks are called SEO cloaking attacks, and they are some of the most damaging compromises a business site can suffer because the owner often does not even know they are happening.
This article walks through exactly how a real SEO cloaking attack works, using a recent Sydney agency case study where every file and dispatcher was identified during a forensic audit. If you run a WordPress site, what follows is the pattern you should know how to recognise.
What cloaking means
Cloaking is the practice of serving different content to search engines than to human visitors. A page might show Googlebot a long article full of keywords for unrelated commercial topics, while showing a normal visitor a generic landing page or a redirect. The goal is to trick search engines into ranking the cloaked content under the authority of an established domain.
Google has rules against this. Cloaking violates webmaster guidelines and can earn a domain manual action penalties or wholesale ranking collapse if it is detected. The attacker does not care because the domain is not theirs.
The five directory pattern
The Sydney case used a particularly clean version of the attack. The attacker had created five new directories at the site root, each named to mirror a real WordPress page. Folder names like about, contact, good-to-know, services, and work all appeared on disk. Each of them contained exactly three files. An index.php dispatcher. A user.php HTML file. A wp-log.php HTML file.
The reason for naming the folders after real pages was simple. When a request came in for /about/ on the site, the web server checked the filesystem first. A folder called about existed, with an index.php inside. The web server resolved that file before WordPress’s own URL routing got involved. Every request to those URLs hit the attacker’s code instead of the legitimate WordPress page.
The dispatcher
The index.php file in each folder was a tiny piece of PHP that did one thing. It inspected the HTTP User-Agent header on the incoming request and routed accordingly. If the User-Agent contained Googlebot, Googlebot-Mobile, or Googlebot-News, it served the contents of wp-log.php. Otherwise it included user.php and exited.
The same file was deployed across all five folders, byte for byte identical. The attacker used one payload and one decision rule. Everything else was data.
The Googlebot payload
The wp-log.php files, despite the .php extension, contained pure HTML. They were enormous, ranging from about 1.3 MB to over 4 MB. Each one was a full HTML page in a foreign language, in this case Indonesian, with spam content covering gambling, e commerce, and Samsung product tracking. The pages were stuffed with structured data, embedded third party tracking scripts, and links designed to outrank legitimate content for the keywords they targeted.
Why call it wp-log.php? Camouflage. To a site owner glancing at the file list, it looks like a WordPress log file, not a suspicious payload.
The human payload
The user.php files were smaller HTML pages that served to actual human visitors. They were doorway pages from unrelated third party sites, also masquerading with a .php extension despite containing no PHP code at all. Anyone who clicked through to one of those URLs from a search result, or who navigated to /about/ on the site, would see content that had nothing to do with the agency.
This is the cloaking part. Google sees the gambling spam in the wp-log.php content, ranks it under the agency’s domain authority, and sends real users to user.php, which delivers a completely different doorway experience. The deception works both ways.
How the attacker got in
The forensic audit could not pinpoint the exact entry vector from the data available, but the strongest suspect was an outdated file manager plugin still installed and active. The plugin family in question has a long history of remote code execution vulnerabilities, with multiple advisories published in past years. With write access through that plugin, an attacker can drop arbitrary files anywhere in the document root.
Crucially, the audit confirmed that WordPress core, wp-config.php, the database, and the active theme were all clean. No backdoor in the application, no rogue admin user, no obfuscated PHP eval. The compromise was entirely in those five folders. That is what made it so silent. Most security scanners look at WordPress files, not at the document root for unexpected directories.
Why this kind of attack is so damaging
SEO cloaking attacks hurt in three ways. First, the spam content gets indexed under your domain, pushing your real pages down or out of the search results. Second, Google can apply manual action penalties or algorithmic demotion when it detects cloaking, which often takes weeks or months to recover from even after the malicious files are gone. Third, the third party scripts and tracking pixels embedded in the spam pages can put your visitors at risk of malware or phishing.
The owner of a cloaked site often notices nothing until traffic collapses or a customer mentions seeing strange content when clicking a search result. By then, weeks or months of damage have already been done.
How to detect this on your own site
A few quick checks will catch most variants of this attack. Browse to your homepage as a normal user. Then run a curl request from a server with a Googlebot User-Agent header and compare. If you see different content, something is wrong.
Check the Coverage and Performance reports in Google Search Console for indexed URLs you do not recognise, especially ones with foreign language queries. Look at the document root via SFTP for folders or files you cannot account for. Run a full malware scan with a reputable security plugin and read the report rather than just clearing alerts.
How to prevent it
Prevention is the same set of habits that prevents most WordPress compromises. Keep core, themes, plugins, and PHP up to date. Remove plugins you do not actively use, especially file managers and shell access tools. Block PHP execution in directories that should never contain PHP. Audit the document root monthly. Use a security plugin that monitors for new files in unexpected locations and alerts when one appears.
Need a hand?
If you are worried that your WordPress site might be hosting cloaked content without your knowledge, Smart Coding can run a forensic audit and tell you exactly what is on your server. Get in touch and we will make sure your domain is only ranking for what it should be.
