Recognizing the cloaked keywords hack

The cloaked keywords and links hack injects large volumes of nonsensical pages into your site. These pages often reuse elements of your site's template, so casual visitors may not immediately realize anything is wrong—but the content itself is gibberish, packed with random keywords and links.

The purpose of these pages is to manipulate search rankings. Attackers typically monetize the hack by selling the injected links to third parties, or they redirect visitors to unrelated pages that generate revenue. This is why the pages are cloaked: the content is hidden from site owners and moderation tools, but visible to search engines and, in some cases, to redirected users.

Start by checking the Security Issues report in Search Console for any flags Google has already raised. You can also search for site:_your site url_ in Google Search and review several pages of results for URLs that look out of place. If nothing shows up there, run the same query on a different search engine.

Search results generated by this hack.
The hacked pages show up in Google Search results. These were created by someone other than the site owner. In the descriptions, you can see the gibberish text created in this hack.

Clicking a link to a hacked page usually results in a redirect to an unrelated site or a page containing gibberish. However, some hacked pages return a 404 error. Don't take that as a sign the problem has resolved itself—attackers often use cloaking to hide the injected content from everyone except search engines and their own targeted redirects.

To check for cloaked content directly, enter suspicious URLs in the URL Inspection tool, which will show you the actual content Googlebot sees.

An example page created by this hack.
An example of a page created by this hack.

Removing the malicious files

Before you touch anything on your server, make a full offline backup of your site—files and database. If you use a CMS, check its documentation or plugin ecosystem for a reliable backup method.

Clean up .htaccess files

This particular hack frequently works through your .htaccess file, using it to automatically generate cloaked pages. Familiarity with Apache's .htaccess documentation helps, but it's not essential.

  1. Locate every .htaccess file on your server. If you're using WordPress, Joomla, or Drupal and can't find it, search for your CMS name plus ".htaccess file location." Multiple files may exist, so write down each location.
  2. Inspect the contents for a rewrite rule referencing a .php file that doesn't belong to your site's normal structure. The line won't look the same on every compromised site—variable names like cj2fa or tobeornottobe are arbitrary. What matters is the .php filename being referenced. It will usually be something innocuous like horsekeys.php or potatolake.php, never an obviously malicious name.
  3. Replace each .htaccess file with a clean or default version. Search for "default .htaccess" along with your CMS name. If you never configured one of these files yourself and no default exists, the file on your server is almost certainly malicious—back it up offline and remove it.
RewriteRule (.*cj2fa.*|^tobeornottobe$) /injected_file.php?q=$1 [L]

Track down and delete compromised PHP files

The malicious .php file referenced in .htaccess is your first lead, but it likely isn't the only compromised file on your server.

  1. Reinstall your CMS core files, along with all themes, plugins, and modules you've added. This immediately clears any injected code from the default distribution.
  2. Delete the .php file you identified in .htaccess. Back it up offline first.
  3. Build a list of remaining suspicious files. After reinstalling your CMS, focus your search on files that aren't part of the default distribution. Sort your files by modification date and look for anything changed within a few months of when you first noticed the hack—or sort by size and look for unusually large files.
  4. Inspect the suspicious files for encoded payloads. The classic signature is a block of obfuscated text preceded by PHP functions like base64_decode, rot13, eval, strrev, or gzinflate. Often the entire block sits on one long line. If you're not confident reading PHP, compare the file against the default from your CMS or check with experienced webmasters in the Google Search Central Help Community.
  5. Back up and delete each confirmed malicious file.
// Hackers try to confuse webmasters by encoding malicious code into
// blocks of text. Be wary of unfamiliar code blocks like this.

base64_decode(strrev("hMXZpRXaslmYhJXZuxWd2BSZ0l2cgknbhByZul2czVmckRWYgknYgM3ajFGd0FGIlJXd0Vn
ZgknbhBSbvJnZgUGdpNHIyV3b5BSZyV3YlNHIvRHI0V2Zy9mZgQ3Ju9GRg4SZ0l2cgIXdvlHI4lmZg4WYjBSdvlHIsU2c
hVmcnBydvJGblBiZvBCdpJGIhBCZuFGIl1Wa0BCa0l2dgQXdCBiLkJXYoBSZiBibhNGIlR2bjBycphGdgcmbpRXYjNXdmJ2b
lRGI5xWZ0Fmb1RncvZmbVBiLn5WauVGcwFGagM3J0FGa3BCZuFGdzJXZk5Wdg8GdgU3b5BicvZGI0xWdjlmZmlGZgQXagU2ah
1GIvRHIzlGa0BSZrlGbgUGZvNGIlRWaoByb0BSZrlGbgMnclt2YhhEIuUGZvNGIlxmYhRWYlJnb1BychByZulGZhJXZ1F3ch
1GIlR2bjBCZlRXYjNXdmJ2bgMXdvl2YpxWYtBiZvBSZjVWawBSYgMXagMXaoRFIskGS"));

After removal, revisit the gibberish URLs you found earlier. Run them through the URL Inspection tool again—if they now respond as "Not Found," your cleanup is on the right track.

Preventing a repeat infection

Cleaning up the files is only half the work. A site that has been compromised once is likely to be compromised again unless the underlying weakness is addressed. Research shows roughly 20% of hacked sites are re-hacked within a day of being cleaned.

If you don't know how the attack happened, review the most common ways sites get hacked by spammers and work through this checklist:

  • Run regular virus scans on your local machines to keep credentials and files clean.
  • Change passwords frequently for every account tied to your site—hosting, FTP, CMS administration, and anything else. Use strong, unique passwords for each.
  • Enable 2FA or a passkey where available. Even a stolen password isn't enough to grant access when a second factor is required.
  • Keep your CMS, plugins, and extensions current. Outdated software is one of the most common entry points for attackers. Enable automatic updates if your CMS supports it.
  • Consider a security monitoring service to watch your site for signs of reinfection.

Further help and scanning tools

If your site is still showing signs of infection, third-party scanners can help identify remaining problematic content. Google doesn't operate or endorse these services, with the exception of VirusTotal:

These scanners won't catch every possible issue, so keep checking your site's security regularly even after they report clean results. For additional guidance, the Google Search Central Help Community is a good place to get experienced eyes on your problem, and monitoring Google SafeBrowsing will alert you if your site is flagged in Google's own lists.