Step 5: Assess the damage (spam)

Make a list of all affected files and determine the hacker's intent.

This step pertains to sites hacked to host spam, often with the warning "This site may be hacked" displayed in search results. It's one of the longest steps in the recovery process. In this step, you'll compile a list of the damaged files on your site. You'll use this list in Step 7: Clean and maintain your site.

If your site was affected by malware, displaying the warning "This site may harm your computer" in search results, please see the corresponding article, Step 5: Assess the damage (malware).

You'll need:

  • Shell/terminal administrator access to your site's servers: web, database, files
  • Knowledge of shell/terminal commands
  • Verified ownership of site in Google Search Console

What you'll do:


  1. Create a document to record findings from this step. The document will eventually include (at minimum) the name/location of each damaged file and notes about how it was infected, and will serve as the basis for Step 7: Clean and maintain your site.
  2. (Optional) Watch the video above to see how hackers use sites for spammy purposes, and how they can hide their tracks.
  3. Learn one of these three techniques below, which don’t require logging into the webserver.
    • Performing a cache: Google search
    • Using Fetch as Google
    • Using cURL or Wget

    These techniques, outlined below, can help you safely investigate hacked pages. Do not open hacked pages in a browser as the hacker may have recently configured the spammy page to distribute malware (i.e., opening the page in a browser could damage your computer).

Performing a cache: Google search

The first technique is to perform a cache: Google search to see what Google has previously indexed for the page. To do a cache search, complete the following steps:

  1. In the Google Search box, type "cache:", then the URL: [cache:]
  2. The hacker's undesirable content may be obvious from the cached result, but if not, click text-only.
  3. Take detailed notes of any damage you see.

Please be aware that this technique may not be helpful (i.e., will not aid the investigation) for all hacked sites with spammy content. This is because there are cases where Google Search is able to restore some of your hacked site’s pages to the last clean version prior to the hacker's damage. In these cases where the content is restored, the cache: search may not reveal helpful hacked information.

Using Fetch as Google

The next technique is to use the Fetch as Google feature in Search Console to see the content served to Google in real-time. To use Fetch as Google, complete the following steps:

  1. Make sure that your site is back online.
  2. Sign in to Google Search Console.
  3. Select the site that you verified in Step 4.
  4. Click Crawl, and then click Fetch as Google.
  5. Enter the URL of the page you want to fetch (for example, page.html). Generally, you won't have to change the dropdown menu from Web. Then click Fetch.
  6. If you see a Success link, click to see the contents of the page as retrieved by Google's crawler, Googlebot.

As you review the content, look for any of the following:

  • Spammy text and links. These may be obvious, but if not, try searching for common spammy keywords like the names of pharmaceutical products or words like "cheap," "free," "casino," and "amateur."
  • Obfuscated spammy text, links, or meta refreshes (which can be harder to detect). Try searching the page code for words like base_64. For example, text like eval(base_64_decode("aisiYSlbYlaws...")) might be used for cloaking.

If no damage is found through Fetch as Google, the hacker may have configured your site to only serve the spammy page at certain times of day or only to users who come from a specific referrer (such as from a search result page or only to users of a specific browser). To simulate this behavior, you can use cURL or Wget.

Using cURL or Wget

These freely-available tools can make HTTP requests that include referrer or browser information. For example:

$ curl -v --referer “” --user-agent "Mozilla/5.0 (Macintosh; Intel 
Mac OS X 10_6_8) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30"

Preliminary investigation of spam content

Investigate the hacked URL examples provided by Search Console. You'll complete this step before you log in to your server.

For phishing

If your site is affected by phishing--

  1. Navigate to Message Center in Search Console.
  2. Copy the URL examples provided in the phishing notification message into your investigation document (created above).
  3. Confirm the hacker’s damage on each of the phishing URL examples using any of the techniques listed in the Preparation section above (e.g., cache: Google search, Fetch as Google, cURL or Wget). Record all findings of damage in your investigation document.

For spammy content

If your site is affected by spammy content (not phishing pages)--

  1. Navigate to Security Issues in Search Console.
  2. Investigate all hacked categories (e.g., Content injection, Code injection) listed in the hacked section of Security Issues for your site. Additional information about hacked URLs from the category can be found by clicking Show details. (Details may include sample content snippets injected by the hacker.)
  3. For each category, copy the following into your investigation document:
    • All example hacked URLs listed for the hacked category in Security Issues.
    • Any additional damaged pages you uncover during your investigation.
    • Detailed findings about the hacked URLs, such as the type of damage caused.

Information to aid the investigation for each hacked category is below:

Broader web-based investigation

If you haven't already, perform a site: search on Google to find more pages damaged by the hacker. The site: operator search, such as [], returns results limited to the pages that match the specified site.

  • Skim these pages for spammy content. If all results look clean, try including additional query terms to the site: search, similar to: [ (cheap|free|viagra|cialis|casino|amateur)]
  • Continue to make note of any affected pages uncovered through a site: query.

Filesystem damage assessment

Next, you'll need to log in to your site's filesystem for more in-depth investigation. Be aware that -- among other things -- the hacker may have modified existing pages or database records, created entirely new spammy pages, written functions to display spam on clean pages, or left "backdoors" that will allow the hacker re-entry to your site or that will continue performing malicious tasks if not deleted.

If your site is online, you can take it back offline for this step.

  1. If you believe you have a clean backup of your site, work to identify files which have been created or modified since the backup:
    $ diff -qr <current-directory> <backup-directory>
    For example:
    $ diff -qr www/ backups/full-backup-20120124/
    You can also use
    $md5sum <current-page> <backup-page>
    For example:
    $ md5sum www/page.html backups/full-backup-20120124/page.html
  2. Add all findings to your list of affected files.
  3. Log in to the filesystem and investigate both the URLs listed in the Search Console message and the URLs from the site: query.
    • Damage may not be limited to the affected HTML page, configuration file, or database record. It may be caused by a function in a JavaScript or PHP, located in a separate script or system file. Again, take note of the page and the hacker's damage.
  4. Perform a broader filesystem investigation to thoroughly record all damage to your site.
    • Check server, access, and error logs for any suspicious activity, such as failed login attempts, command history (especially as root), the creation of unknown user accounts, and so on. Be aware that the hacker may have altered these logs for their own purposes. (If helpful, some examples are shown in the video for Step 6: Identify the vulnerability.)
    • Check configuration files, such as .htaccess and httpd.conf, for redirects. Hackers often create conditional redirects based on the user-agent, time of day, or referer.
  5. Check folder and file permissions for too-lenient write privileges, such as 777 (which equates to world-writable access). Often hackers tamper with permission in hopes that if they remain undetected, they'll have a way back into the site.
    • Check folders with permissions greater than 755 (rwxr-xr-x). Make sure any looser permissions are really necessary. On Unix-based systems, try:
      find <your-dir> -type d -not -perm 755 -exec ls -ld {} \;
    • Check files with permissions greater than 644 (rw-r--r--). Again, make sure any looser permission are really necessary.
      find <your-dir> -type f -not -perm 644 -exec ls -la {} \;
  6. ​If you have a database, investigate records as thoroughly as possible. You may want to use tools like phpMyAdmin for easier visibility.

Determine the hacker's intent

  • The hacker may have intended to steal confidential or sensitive information from you or your site's visitors, such as with phishing pages. In this case, check out available resources at
  • Perhaps the hacker was trying to exploit a good website to drive traffic to, or improve rankings of, her less-reputable online business by adding spammy text or links to her site. In this case, completing the remaining Help for hacked sites steps, can address this issue.

What's next:

Step 5: Assess the damage is now completed. The next step in the process is Step 6: Identify the vulnerability.

Step Technical expertise required
1. Watch the overview Beginner
2. Contact your hoster and build a support team Beginner
3. Quarantine your site Intermediate
4. Touch base with Search Console Intermediate
5. Assess the damage (spam) or
    Assess the damage (malware)
6. Identify the vulnerability Advanced
7. Clean and maintain your site Advanced
8. Request a review Intermediate


Was this article helpful?