Recognizing the gibberish hack

The gibberish hack is a form of SEO spam that injects pages of keyword-stuffed, nonsensical text into your site. These pages are designed to rank in search results and then redirect visitors to unrelated, often malicious, destinations. The URLs typically follow patterns that are hard to mistake once you know what to look for:

  • www.example.com/cheap-hair-styles-cool.html
  • www.example.com/free-pictures-fun.html
  • www.example.com/nice-song-download-file.php

You may also find them inside randomly named folders, sometimes mixed with odd language combinations:

  • www.example.com/jfwoea/foto-cewe-zaman-sekarang.php
  • www.example.com/jfwoea/www-ki-motn-dudh-photo.php

Start by reviewing the Security Issues tool in Search Console. You can also run a site:yourdomain.com search in Google to see which of your pages have been indexed, then page through the results for anything that looks out of place. If Google shows nothing, repeat the same search on another engine.

Clicking a hacked URL might redirect you elsewhere, display a page of gibberish, or—misleadingly—return a 404 error. Hackers often cloak their content to make the page look clean or removed. Use the URL Inspection tool to see what Google actually renders; if these pages show up there as live and indexed, you are dealing with the gibberish hack.

Cleaning up the hacked files

Keep a full offline backup of your site—and your database if you use a CMS—before you remove anything. Work carefully and methodically, saving copies of every file you delete in case you need to restore it.

Restore the .htaccess file

The redirect behavior of this hack is typically driven by the .htaccess file. Find every instance of .htaccess on your server; a CMS like WordPress, Joomla, or Drupal may have more than one. Replace each one with the clean default version for your CMS. If your setup never included an .htaccess file originally, the one you found is almost certainly malicious—download it as a backup and then delete it from the server.

Remove spam templates and PHP payloads

If you run a CMS, start by reinstalling the core distribution files plus any themes, plugins, and modules. That wipes out any injected content hidden inside known files. Then focus on finding the attacker's own files, which usually come in two forms.

Malicious .txt files act as templates for the spam pages. Use your file manager's search feature to list every .txt file. Most will be legitimate, but look for entries that contain HTML used to build spam pages, not plain text. These files often hold keyword-replacement tokens and code that hides spam links off the visible area of the page:

<title>{keyword}</title>
<meta name="description" content="{keyword}" />
<meta name="keywords" content="{keyword}" />
<meta property="og:title" content="{keyword}" />

<div style="position: absolute; top: -1000px; left: -1000px;">
    Cheap prescription drugs
</div>

If these files are grouped in a single directory, remove the whole directory. If they are scattered, delete each file individually.

Finding the malicious PHP files is more demanding. They may be concentrated in one subdirectory or distributed across the site. Avoid the temptation to open every PHP file. Instead, build a shortlist of candidates by:

  • Ignoring any file that belongs to your freshly reinstalled CMS core, themes, or plugins
  • Sorting by "last modified" and flagging anything changed in the months around the hack discovery
  • Sorting by file size, looking for unusually large files that stand out

Scan those suspicious files for large, jumbled blocks of characters sitting next to functions like base64_decode, rot13, eval, strrev, or gzinflate:

// Hackers try to confuse site owners 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"));

That obfuscated blob is often crammed into one long line to hide its size. In other cases, the code appears as plain, readable script, which makes it ambiguous. If you cannot tell whether a file is malicious, consider consulting the Google Search Central Help Community for a second opinion. When you have finished checking the candidates, save a local copy of each suspicious file and delete it from the server.

Verify the cleanup by returning to the gibberish pages you found earlier and re-fetching them in the URL Inspection tool. If those URLs now resolve as "Not Found," the hack payload is gone and you can move on to sealing off the entry point.

Preventing a repeat hack

A compromised site is likely to be targeted again quickly, so closing the initial vulnerability is essential. If you don't know how the attacker got in, work through these steps:

  • Run regular virus scans on your development machines to keep credentials and tools clean.
  • Rotate passwords frequently for every account attached to the site, including hosting, FTP, and CMS logins, with a distinct strong password per account.
  • Enable Two-Factor Authentication (2FA) wherever it is offered; a stolen password is less dangerous when 2FA is active.
  • Update your CMS and all extensions regularly. Outdated software is the most common entry vector; where possible, turn on automatic updates.
  • Consider a website security monitoring service that can flag new infections before they impact your users.

If you need assistance identifying the original hole, this guide to the top ways sites get hacked by spammers can help you investigate.

When manual cleanup is not enough, third-party scanners may catch pieces you missed. Google neither operates nor officially endorses these tools, but they are commonly used for site checks:

That said, no scanner is guaranteed to catch every type of compromised content. Google's own SafeBrowsing and the Search Central Help Community can provide a second layer of verification if needed.