Image Alt

Site Hacks and SEO Impact

Site Hacks and SEO Impacts...

Site Hacks and SEO Impact

Many SEO experts will warn about rich-snippet abuse, negative SEO attacks and Penguin / Panda penalties from Google. Less talked about, yet (potentially) equally devastating, are malicious code insertions by hackers. Often these hacks are performed for commercial purposes, e.g: inserting pop-up ads on your site, pointing to external products (or services) on the web

Sometimes hackers will create addresses on your site which redirect externally to steal traffic. These types of attack can also be cloaked via clever referrer / user-agent conditions (for example, only redirect the user when a user lands on a page after being referred from Bing or Yahoo)

Search Console Notifications

Often Google will notify webmasters of hacked content from within Google Search Console:

Stretching back through time to previous versions of Search Console (and back to Google Webmaster Tools), Google has actively notified webmasters of potential hack attacks:

By the time these notifications are received, Google performance is likely to be impacted. Google won’t link their users to potentially harmful or hacked content. The web is littered with posts and studies, revealing the impact of hacked content on Google rankings. Even more recently in 2020, more studies on the impacts of security failures on SEO are becoming available

You might think that your traffic from other channels (e.g: FaceBook Ads, referral and direct traffic) would still be safe. Due to Google Chrome’s popularity however, this is false:

Google’s Chrome browser is the most popular by a long way. When Google pick up signs that a site may be hacked, they alert users through their browser interface. Really, there’s no getting around it. Hacked sites and content need cleaning up ASAP, before performance is hit

Early Signs of Site Hacks

If your site is hit by a redirection hack, it’s hard to spot the issue from a traditional Analytics suite like Google Analytics. For Google Analytics to function and track, JavaScript must be initiated. Redirecting URLs do not load up any source code, including tracking scrips (so redirect hacks often go undetected)

I’m sure there are security experts out there with better methods of detection, but I have actually uncovered a few hack attacks using Google Search Console data (before Search Console gives a hacked content notification):

Search Console data comes from Google’s end. Google are tracking clicks and impressions to your site from their search engine, so it doesn’t matter if the URL on your site can render a tracking script or not. Be on the lookout for URLs relating to adult enhancements, experimental medication or unrelated services. Look for URLs which break the architectural norms of your website (for example; if your site never uses “_” within URL strings, if you spot an underscore – that may be suspicious)

If you use WordPress, I’d highly recommend installing WordFence which can track and alert you to file changes:

WordFence will alert you to files which have been modified (functions.php, which resides within your theme or child theme’s directory – is a common target). WordFence will also highlight unrecognised files, which typically deliver the malware payload. Often functions.php is modified to create a back-door into your site, which may allow the malware to repair itself (or a malicious third party to restore their malware on your site)

Cleaning Up Hacks & Further Insulation

Foreword: my experience here is limited to WordPress, but I imagine these general notes have more than one application

So all you have to do is restore an old functions.php file and erase the unknown files, right? This may or may not be all you need to do. For example, if running an old version of PHP created a vulnerability which allowed the injection, clean-up alone wouldn’t prevent the hack from re-appearing (you’d also have to upgrade PHP)

If a nulled theme or plugin was responsible for the malicious code injection, cleaning up the bad code may have no impact (as the plugin or theme may regenerate the malware). Once you believe you have truly cleaned up the hack, you obviously need to regenerate login details for all your WordPress users (as well as resetting all FTP account passwords and cPanel / hosting management passwords). Be sure to check for unusual looking database users using PHPMyAdmin

There are some top-line security patches which you can apply to your .htaccess file to harden your HTTP response headers:

If your site runs on HTTPS and you already have architecture in place which forces HTTPS (through redirects), setting a strict HSTS policy is a no-brainer. Once implemented you should submit your site for the HSTS preload list. One thing to note is that, once all this is done – there’s really no going back to HTTP (even for partial functionality, even locked to certain areas of your site). If your SSL certificate dies, your site will die too. Even though that’s true, many sites are now fully HTTPS / HSTS compliant – it’s not a super big deal. A strict HSTS policy helps you avoid man-in-the-middle (MITM) attacks which utilise SSL stripping

A proper content security policy will really help to lock down your site. Control where various resources or streams of data may or may not be loaded from. The problem with this is, it requires a lot of testing to get it right. If you tell your site that it can only load resources from ‘self’ (itself), then suddenly fonts which are pulled in externally could break. That may not sound like a big deal, but analytics tracking could break and payment gateway payments may even be blocked. The potential for disaster is huge. Installing Firefox and it’s addon Laboratory (by Mozilla), is highly recommended. With this tool you can perform all user actions on your site (front-end and back) and record a content policy snippet. Sometimes these need a bit of tweaking to avoid bugs

Implementing a feature policy and x-security headers is a no-brainer. Those two are the easiest patches you could apply

Final Thoughts

In essence, to be confident of hack-removal, you have to be really sure about two things. Firstly you have to be sure of what was changed (so that you can reverse it). After that, you have to have a firm idea of which hack impacted you (try Google searching for some of the malicious code, read some forum threads) and how the injection was initiated

Was it simply that your site was vulnerable, someone got in and pushed the malicious code up? Or was it that a rogue plugin or theme, contained a script which continually fires – making sure that the malicious code is present? You don’t want to go through all the effort of removing the hack, only for it to re-appear a day or so after. To permanently kill a hack, the back-door (which allowed the code insertion, or which was scripted to keep creating the access point / malware) MUST be closed

With plugins like WordFence, understanding what was changed is relatively easy. Understanding the deployment vehicle is much harder, and something which you should probably leave to a cyber-security specialist

Written by

SEO & digital marketing specialist of nearly 10 years. A master of Google Data Studio, XPath and more. Applied data-driven analysis, to increase revenue and on-site conversions. Architecting information, to bring you closer to your online audience!

Post a Comment