Thus far in 2015 we have seen a 180% increase in the number of sites getting hacked and a 300% increase in hacked site reconsideration requests. While we are working hard to help webmasters prevent hacks in the first place through efforts such as blog posts and #NoHacked campaigns, we recognize that our reconsideration process is an important part of making recovering from a hack faster and easier. Here's what we've been focussing on:

1) Improved communication
2) Better tools
3) Continuous feedback loop

1. Improving communications with webmasters of hacked sites

Last year we launched the "Note from your reviewer" feature in our reconsideration process. This feature enables us to give specific examples and advice tailored to each case in response to a reconsideration request. Thus far in 2015 we have sent a customized note to over 70% of webmasters whose hacked reconsideration request was rejected, with specific guidance on where and how to find the remaining hacked content. The results have been encouraging, as we've seen a 29% decrease in the average amount of time from when a site receives a hacked manual action to the time when the webmaster cleans up and the manual action is removed.

Example "note from your reviewer" with detailed guidance and a custom example of hacked text and a hacked page

We have also completed our second #NoHacked campaign, with more detailed help on preventing and recovering from hacks. In the campaign, we focused on ways to improve the security on your site as well as ways to fix your site if it was compromised. You can catch up by reading the first post.

2. Better tools including auto-removal of some hacked manual actions

Last year we launched the "Fetch and Render" feature to the Fetch as Google tool, which allows you to see the website exactly as Googlebot sees it. This functionality is useful in recovering from a hack, since many hackers inject cloaked content that's not visible to the normal user but obvious to search engine crawlers like Googlebot.

This year we also launched the Hacked Sites Troubleshooter in 23 languages which guides webmasters through some basic steps to recover from a hack. Let us know if you have found the troubleshooter useful as we're continuing to expand its features and impact.

Finally, we're beta testing the automated removal of some hacked manual actions. In Search Console if Google sees a "Hacked site" manual action under "Partial matches", and our systems detect that the hacked content is no longer present, in some cases we will automatically remove that manual action. We still recommend that you submit a reconsideration request if you see any manual actions, but don't be surprised if a "Hacked site" manual action disappears and saves you the trouble!

Example of a Hacked site manual action on a Partial match: if our systems detect that the hacked content is no longer present, in some cases we will automatically remove the manual action

3. Soliciting your feedback and taking action

Our improved communication and tools have come directly from feedback we've collected from webmasters of sites that have been hacked. For example, earlier this year we hosted webmasters who have been through the hacked reconsideration process in both Mountain View, USA and Dublin, Ireland for brainstorming sessions. We also randomly sampled webmasters that had been through a hacked reconsideration. We found that while only 15% of webmasters were dissatisfied with the process, the main challenges those webmasters faced were in clearer notification of their site being hacked and clearer guidance on how to resolve the hack. This feedback contributed directly our more detailed blog post on hacked recovery, and to much of the content in our latest #NoHacked campaign.

(for hi-res version) https://goo.gl/photos/TkvkwYt23MpVHBwz6  

Googlers in Dublin brainstorming ways to improve the hacked reconsideration process after meeting with local webmasters

We will continue to support webmasters of hacked sites through the methods detailed above, in addition to the Webmasters help for hacked sites portal and the security, malware & hacked sites section of our forum. And we'd love to hear your ideas in the comments below on how Google can better support webmasters recovering from a hacked website!

Posted by Josh Feira and Yuan Niu, Search Quality Team

In order to protect the quality of our search results, we take automated and manual actions against sites that violate our Webmaster Guidelines. When your site has a manual action taken, you can confirm in the [Manual Actions] page in Search Console which part of your site the action was taken and why. After fixing the site, you can send a reconsideration request to Google. Many webmasters are getting their manual action revoked by going through the process.

However, some sites violate the Webmaster Guidelines repeatedly after successfully going through the reconsideration process. For example, a webmaster who received a Manual Action notification based on an unnatural link to another site may nofollow the link, submit a reconsideration request, then, after successfully being reconsidered, delete the nofollow for the link. Such repeated violations may make a successful reconsideration process more difficult to achieve. Especially when the repeated violation is done with a clear intention to spam, further action may be taken on the site.

In order to avoid such situations, we recommend that webmasters avoid violating our Webmaster Guidelines, let alone repeating it. We, the Search Quality Team, will continue to protect users by removing spam from our search results.

Posted by Google Search Quality Team

When it comes to search on mobile devices, users should get the most relevant answers, no matter if the answer lives in an app or a web page. We’ve recently made it easier for users to find and discover apps and mobile-friendly web pages. However, sometimes a user may tap on a search result on a mobile device and see an app install interstitial that hides a significant amount of content and prompts the user to install an app. Our analysis shows that it is not a good search experience and can be frustrating for users because they are expecting to see the content of the web page.
Starting today, we’ll be updating the Mobile-Friendly Test to indicate that sites should avoid showing app install interstitials that hide a significant amount of content on the transition from the search result page. The Mobile Usability report in Search Console will show webmasters the number of pages across their site that have this issue.
After November 1, mobile web pages that show an app install interstitial that hides a significant amount of content on the transition from the search result page will no longer be considered mobile-friendly. This does not affect other types of interstitials. As an alternative to app install interstitials, browsers provide ways to promote an app that are more user-friendly.

App install interstitials that hide a significant amount of content provide a bad search experience

App install banners are less intrusive and preferred

App install banners are supported by Safari (as Smart Banners) and Chrome (as Native App Install Banners). Banners provide a consistent user interface for promoting an app and provide the user with the ability to control their browsing experience. Webmasters can also use their own implementations of app install banners as long as they don’t block searchers from viewing the page’s content.
If you have any questions, we’re always happy to chat in the Webmaster Central Forum.
Posted by Daniel Bathgate, Software Engineer, Google Search.

With the new Search Analytics API, it's now time to gradually say goodbye to the old CSV download scripts for information on queries & rankings. We'll be turning off access to these downloads on October 20, 2015.

These download scripts have helped various sites & tools to get information on queries, impressions, clicks, and rankings over the years. However, they didn't use the new Search Analytics data, and relied on the deprecated Client Login API.

Farewell, CSV downloads, you've served us (and many webmasters!) well, but it's time to move on. We're already seeing lots of usage with the new API. Are you already doing something neat with the API? Let us know in the comments!

Posted by John Mueller, Webmaster Trends (and query, impression, & click trends) Analyst

Today in our #NoHacked campaign, we’ll be discussing how to fix the injected gibberish URL hack we wrote about last week. Even if your site is not infected with this specific type of hack, many of these steps can be helpful for fixing other types of hacks. Follow along with discussions on Twitter and Google+ using the #NoHacked tag. (Part 1, Part 2, Part 3, Part 4)

• Temporarily Take your Site Offline
• Treating your Site
• Checking your .htaccess file
• Identifying other malicious files
• Removing malicious content
• Identifying and Fixing the Vulnerability
• Next Steps
• Appendix

Temporarily Take your Site Offline

Taking your site offline temporarily will prevent your site’s visitors from going to hacked pages and give you time to properly fix your site. If you keep your site online, you run the risk of getting compromised again as you clean up your site.

Treating your Site

The next few steps require you to be comfortable making technical changes to your site. If you aren’t familiar or comfortable enough with your site to make these changes, it might be best to consult with or hire someone who is. However, reading through these steps will still be helpful.

Before you start fixing your site, we advise that you back up your site. (This backed up version will still contain hacked content and should only be used if you accidentally remove a critical file.) If you’re unsure how to back up your site, ask your hosting provider for assistance or consult your content management system (CMS) documentation. As you work through the steps, any time you remove a file, make sure to keep a copy of the file as well.

Checking your .htaccess file

In order to manipulate your site, this type of hack creates or alters the contents of your .htaccess file. If you’re not sure where to find your .htaccess file, consult your server or CMS documentation.

Check the contents of your .htaccess file for any suspicious content. If you’re not sure how to interpret the contents of the .htaccess file, you can read about it on the Apache.org documentation, ask in a help forum, or you can consult an expert. Here is an example of a .htaccess modified by this hack:

• <IfModule mod_rewrite.c> 
•   RewriteEngine On  
•   #Visitors that visit your site from Google will be redirected  
•   RewriteCond %{HTTP_REFERER} google\.com 
•   #Visitors are redirected to a malicious PHP file called happypuppy.php 
•   RewriteRule (.*pf.*) /happypuppy.php?q=$1 [L] 
• </IfModule>

Identifying other malicious files

The most common types of files that are modified or injected by this hack are JavaScript and PHP files. Hackers typically take two approaches: The first is to insert new PHP or JavaScript files on your server. The inserted files can sometimes be named something very similar to a legitimate file on your site like wp-cache.php versus the legitimate file wp_cache.php. The second approach is to alter legitimate files on your server and insert malicious content into these files. For example, if you have a template or plugin JavaScript file on your site, hackers might add malicious JavaScript to the file.

For example, on www.example.com a malicious file named happypuppy.php, identified earlier in the .htaccess file, was injected into a folder on the site. However, the hackers also corrupted a legitimate JavaScript file called json2.js by adding malicious code to the file. Here is an example of a corrupted json2.js file. The malicious code is highlighted in red and has been added to the very bottom of the json2.js file:

To effectively track down malicious files, you’ll need to understand the function of the JavaScript and PHP files on your site. You might need to consult your CMS documentation to help you. Once you know what the files do, you should have an easier time tracking down malicious files that don’t belong on your site.

Also, check your site for any recently modified files. Template files that have been modified recently should be thoroughly investigated. Tools that can help you interpret obfuscated PHP files can be found in the Appendix.

Removing malicious content

As mentioned previously, back up the contents of your site appropriately before you remove or alter any files. If you regularly make backups for your site, cleaning up your site might be as easy as restoring a clean backed-up version.

However, if you do not regularly back up your site, you have a few alternatives. First, delete any malicious files that have been inserted on your site. For example, on www.example.com, you would delete the happypuppy.php file. For corrupted PHP or JavaScript files like json2.js, you’ll have to upload a clean version of those files to your site. If you use a CMS, consider reloading a fresh copy of the core CMS and plugin files on your site.

Identifying and Fixing the Vulnerability

Once you’ve removed the malicious file, you’ll want to track down and fix the vulnerability that allowed your site to be compromised, or you risk your site being hacked again. The vulnerability could be anything from a stolen password to outdated web software. Consult Google Webmaster Hacked Help for ways to identify and fix the vulnerability. If you’re unable to figure out how your site was compromised, you should change your passwords for all your login credentials,update all your web software, and seriously consider getting more help to make sure everything is ok.

Next Steps

Once you’re done cleaning your site, use the Fetch as Google tool to check if the hacked pages still appear to Google. You'll need to bring your site back online to test with Fetch as Google. Don’t forget to check your home page for hacked content as well. If the hacked content is gone, then, congratulations, your site should be clean! If the Fetch as Google tool is still seeing hacked content on those hacked pages, you still have work to do. Check again for any malicious PHP or JavaScript files you might have missed.

Bring your site back online as soon as you’re sure your site is clean and the vulnerability has been fixed. If there was a manual action on your site, you’ll want to file a reconsideration request in Search Console. Also, think about ways to protect your site from future attacks. You can read more about how to secure your site from future attacks in the Google Hacked Webmaster Help Center.

We hope this post has helped you gain a better understanding of how to fix your site from the injected gibberish URL hack. Be sure to follow our social campaigns and share any tips or tricks you might have about staying safe on the web with the #nohacked hashtag.

If you have any additional questions, you can post in the Webmaster Help Forums where a community of webmasters can help answer your questions. You can also join our Hangout on Air about Security on August 26.

Appendix

These are tools that may be useful. Google doesn't run or support them.

PHP Decoder, UnPHP: Hackers will often distort PHP files to make them harder to read. Use these tools to clean up the PHP files so you understand better what the PHP file is doing.

Posted by: Eric Kuan, Webmaster Relations Specialist & Yuan Niu, Webspam Analyst

Today in our #NoHacked campaign, we’ll be discussing how to identify and diagnose a trending hack. Even if your site is not infected with this specific type of hack, many of these steps can be helpful for other types of hacks. Next week, we’ll be following up with a post about fixing this hack. Follow along with discussions on Twitter and Google+ using the #NoHacked tag. (Part 1, Part 2, Part 3)

• Identifying Symptoms
• Gibberish pages
• Cloaking
• Monitoring your Site
•  Looking for a surge in website traffic
•  Tracking your site appearance in search results
•  Signing up for alerts from Google
• Diagnosing your Site
•  Gathering tools that can help
•  Checking for hacked pages
•  Checking for cloaking on hacked pages
• Appendix

Identifying Symptoms

Gibberish pages

The hallmark of this type of hacking is spammy pages that appear to be added to the site. These pages contain keyword-rich gibberish text, links, and images in order to manipulate search engines. For example, the hack creates pages like www.example.com/pf/download-2012-free-full-crack.html which contain gibberish content like below:

Cloaking

This hack often uses cloaking to avoid webmasters from detecting it. Cloaking refers to the practice of presenting different content or URLs to webmasters, visitors, and search engines. For example, the webmaster of the site might be shown an empty or HTTP 404 page which would lead the webmaster to believe the hack is no longer present. However, users who visit the page from search results will still be redirected to spammy pages, and search engines that crawl the site will still be presented with gibberish content.

Monitoring your Site

Properly monitoring your site for hacking allows you to remedy the hack more quickly and minimize damage the hack might cause. There are several ways you can monitor your site for this particular hack.

Looking for a surge in website traffic

Because this hack creates many keyword heavy URLs that are crawled by search engines, check to see if there was any recent, unexpected surges in traffic. If you do see a surge, use the Search Analytics tool in Search Console to investigate whether or not hacked pages are the source of the unusual website traffic.

Tracking your site appearance in search results

Periodically checking how your site appears in search results is good practice for all webmasters. It also allows you to spot symptoms of hacking. You can check your site in Google by using the site: operator on your site (i.e. search for site:example.com). If you see any gibberish links associated with your site or a label that says “This site may be hacked.”, your site might have been compromised. 

Signing up for alerts from Google

We recommend you sign up for Search Console. In Search Console, you can check if Google has detected any hacked pages on your site by looking in the Manual Actions Viewer or Security Issues report. Search Console will also message you if Google has detected any hacked pages on your site.

Also, we recommend you set up Google Alerts for your site. Google Alerts will email you if Google finds new results for a search query. For example, you can set up a Google Alert for your site in conjunction with common spammy terms like [site:example.com cheap software]. If you receive an email that Google has returned a new query for that term, you should immediately check what pages on your site are triggering that alert.

Diagnosing your Site

Gathering tools that can help

In Search Console, you have access to the Fetch as Google tool in Search Console. The Fetch as Google tool allows you to see a page as Google sees it. This will help you to identify cloaked hacked pages. Additional tools from others, both paid and free, are listed in the appendix to this post.

Checking for hacked pages

If you’re not sure if there is hacked content on your site, the Google Hacked Troubleshooter can walk you through some basic checks. For this type of hack, you’ll want to perform a site: search on your site. Look for suspicious pages and URLs loaded with strange keywords in the search results. If you have a large number of pages on your site, you might need to try a more targeted query. Find common spam terms and append them to your site: search query like [site:example.com cheap software]. Try this with several spammy terms to see if any results show up.

Checking for cloaking on hacked pages

Because this type of hacking employs cloaking to prevent accurate detection, it’s very important that you use the Fetch as Google tool in Search Console to check the spammy pages you found in the previous step. Remember, cloaked pages can show you an HTTP 404 page that tricks you into thinking the hack is fixed even if the page is still live. You should also use Fetch as Google on your homepage as well. This type of hack often adds text or links to the homepage.

We hope this post has given you a better idea of how to identify and diagnose hacks that inject gibberish URLs on your site. Tune in next week where we’ll be explaining how to remove this hack from your site. Be sure to follow our social campaigns and share any tips or tricks you might have about staying safe on the web with the #NoHacked hashtag.

If you have any additional questions, you can post in the Webmaster Help Forums where a community of webmasters can help answer your questions. You can also join our Hangout on Air about Security on August 26.

Appendix

These are tools that scan your site and may be able to find problematic content. Other than VirusTotal, Google doesn't run or support them.

Virus Total, Aw-snap.info, Sucuri Site Check, Wepawet: These are tools that may be able to scan your site for problematic content. Keep in mind that these scanners can’t guarantee that they will identify every type of problematic content.

Posted by Eric Kuan, Webmaster Relations Specialist & Yuan Niu, Webspam Analyst

Today in our #nohacked campaign, we’ll be talking about two-factor authentication. Follow along with discussions on Twitter and Google+ using the #NoHacked tag. (Part 1, Part 2)

There was once a time when having a relatively strong password or answering a security question was a reasonable way to protect your online accounts. However, according to a study from Stop Badware, stolen credentials is a common way for hackers to compromise websites. Additionally, even reputable sites can fall victim to hacking, potentially exposing your personal data like passwords to attackers.

Fortunately, two-factor authentication can help you keep your accounts safer. Two-factor authentication relies on an additional source of verification, in conjunction with your password, to access your account. You might have used two-factor authentication before if you have ever been prompted for a code from your phone when logging into a social media site or from a chip card reader when logging into a bank account. Two-factor authentication makes it more difficult for someone to log into your account even if they have stolen your password.

As a website owner, you should enable two-factor authentication on your accounts where possible. A compromised account can cause you to lose important personal data and valuable reputation for your site. Two-factor authentication can give you the ease of mind that your accounts and data are safer. 

Google currently offers 2-Step Verification for all of its accounts, including accounts from Google Apps domains. You can use your phone, a hardware token like a Security Key, or the Google Authenticator app to verify your account. These options give you flexibility when traveling or when you don’t have access to the mobile network.

If your hosting provider, Content Management System (CMS), or any type of platform you use for managing your site doesn’t offer two-factor authentication, ask their customer support for an option to use two-factor authentication in the future.They can build two-factor authentication into their own platforms using Google’s open source code. If your platform or hoster doesn’t provide strong protection against unauthorized access consider hosting your content elsewhere. You can see a list of websites that support two-factor authentication, including what types of authentication options they offer, at https://twofactorauth.org/.

If you have any additional questions, you can post in the Webmaster Help Forums where a community of webmasters can help answer your questions. You can also join our Hangout on Air about Security on August 26.

Posted by: Eric Kuan, Webmaster Relations Specialist & Yuan Niu, Webspam Analyst