302 Redirect Hijacking

Sometimes what search engines see as “best practice” in the way they discern site behaviour and content and their resulting SERPs is often at odds with what people actually put out. And this can lead into a range of issues, including opportunities for shady players. Sometimes these disconnects are due to lazy dev, sometimes it’s human error, and other times its plain old ignorance. In the rare occasion its a gap in the way search engine crawlers and algorithms treat certain web commands.

Often this disconnect leads to a Blackhat playground. (Rishi Lakhani is awesome)

And one of these loopholes has led to one of the most dangerous black-hat SEO tactics of all time, 302 redirect hijacking.

302 Redirect Hijacking – Nothing New.

302 Hijacking might sound like something new, but it has been around as long as we recall, in fact we just found this post that stretches all the way back to 2014(!): Search Engine Roundtable “Bait & Switch”.. 302 Redirect hijacks have been causing havoc amongst the SEO community and with webmasters everywhere.

In fact, in the google community alone there have been over 600 incidents relating to 302 hijacking:

302 Redirect Hijacking: The Basics

Before we dive right in, let’s go back to the basics.

When we discuss 302 redirects, we are discussing off domain redirects – in the words of Matt Cutts:

Now let’s talk about off-domain 302 redirects. By definition, those are redirects from one domain A.com to another domain B.com that are claimed to be temporary; that is, the web server on A.com could always change its mind and start showing content on A.com again.

The interesting take from that 2006 (!) post is that the BigDaddy update was “supposed” to deal better with 302 hijacks. Fact is it didn’t.

A 302 redirect is a temporary redirect which redirects users and search engines to another page. Because it is only a temporary redirect, Google will hold onto the original URL just in case it comes back. This means ranking signals, such as authority, content relevancy will not always be passed onto the new page, as Google sees this as a temporary location for the content:

And here is where the scary bit comes in. Since a 302 redirect is not actually a page, but just a command instructing Google of a temporary redirect of an existing URL to another, this allows hijackers to take over your site in search results.

At this point the blackhat can, given ideal conditions, manipulate Google into thinking that their page is the original and that “Page A” is in fact the temporary location:

When this situation occurs, and the setting is ideal (we won’t go into specific tactics that would help power up the hijack as we don’t want people to abuse them) then the crawler has to decide which page (or site) to rank and which to demote.

In the Webmaster Support forum examples above, in most cases, Google has made the wrong decision to demote the original page / site and promote the new (redirected) URL. This means the 302 hijacker is effectively stealing your traffic.

The clever or insidious part is a clever blackhat can redirect the page ONLY to crawlers in a way to “cloak” the real intent. When a real user lands on the site, they would be redirected to a payload of choice.

A successful 302 hijack can have serious implications. Not only can the hacker send human visitors to dodgy sites, but they can also pretend to be a real business and steal the credit card or bank details of many vulnerable users.

The worst thing is that the site being attacked won’t even know that they have been attacked until they see a big hit in their rankings and traffic.

Can 302 Redirect Hijacks Be Used for Good?

One reason WHY I spend so much time learning the dark side of SEO is to have an arsenal of ideas that could be applied in legitimate ways. I have used 302 Hijacks for two reasons in the past:

1. Brand short term recovery. A little while ago a couple of sites that were hit by some pretty hard manual penalties due to guest posting which saw them wiped out of the SERPs for even their brand terms. I force indexed a couple of 302 redirected domains allowing them to rank INSTEAD for branded terms while the penalty recovery work was going on in the background.
2. Mask crappy URLs. Sometimes sites just dont have a way to create decent marketing URLs – especially if used for offline campaigns.  So we simply found and created a short URL redirect tool that could be forced  indexed for offline campaigns that also show up in SERPs.

The Hijack Flow:

Now that you have a fair idea of what 302 redirect hijacking is, it’s time to get down to the details. You might be wondering whether your website could be hijacked via a 302 redirect? And the answer is yes…all websites are vulnerable to this type of threat.

And because of the way Google handles 302 redirects, there is very little you can do to stop it.

Here is a how a full site can theoretically be taken over:

1. First thing: You have a site in place – its crawled and indexed.
2. The hijacker sources a domain and essentially places a redirect from that domain to yours – probably using “wildcard redirects”.
3. The Hijacker then feeds the URL to google (there are plenty of ways to do this).
4. Crawlers then *crawl* the redirect and establish a “temporary relationship” between the two sites.
5. Conditions being ideal (for the hijacker!) crawler does its own thing and decides that there are TWO versions of a site now. One being the original, the second the hijackers domain.
6. Crawler then applies its 302 logic and decides that it prefers to show the redirecting URL over the origin site.
7. Slowly the redirecting (hijack URL) starts to replace the original sites rankings in the SERPs.
8. Hijacker then plays the “bait and switch” game – showing the redirect (and sometimes even the content) from the origin site while users are delivered payloads, or sent to ad-filled pages, or apply even more insidious tricks such as credit card details theft.

Other SEO Hijacks

302 Redirect hijacking is the main reason URLs get hijacked in the Google search results rather than straightforward hacking. Because of this it is really important that you monitor inbound links (plenty of tools will report redirects as inbound links) and your organic traffic regularly.

However 302 redirect hijacks aren’t the only other hijacks that can be used in the SERPs.

Content Auto Canonicalisation

This isn’t a hijack that works as much as it used to, but it can do from time to time. In fact at one point – a previous experiment of mine replaced 2000 urls from a high authority site in the SERPs.

One thing a lot of SEOs don’t seem to remember, is that the Google algos are built to be smart. This means, often they would include little inconsistencies that only a human eye can fix.

One of these inconsistencies is what we like to call “auto canonicalisation”. Theoretically this part of the algo was created to counter wide scale scraping that used to fill up googles results. However some of the logic is still “weak” in my opinion.

This is how Dejan and his team managed to hijack a bunch of sites.

In a nutshell – presented with two similar pieces of content – Google will canonicalise one over the other, absent any other signals.

Manipulate Weak Architectures

Sometimes it doesn’t matter that the site you are hijacking has a higher authority than yours, if structurally it has issues.

To demonstrate how easy it is to hijack a URL in the search results, Dan from Screaming Frog ran an experiment to hijack the rankings of Google’s SEO guide. Back in 2017 Google’s SEO guide was being hijacked by many other sites in the search results page, as it appeared to be using a 302 redirect making it vulnerable.

Screaming Frog wanted test how vulnerable the tactic really was by uploading the exact same SEO starter guide PDF onto their own domain. A week later their site was ranking in the top spot for many keywords of the same keywords as Google’s guide. They had officially hijacked Google and all those other hackers by beating them in the search results page.

Then a few days later Screaming Frog’s PDF was completely gone from the index.

From this experiment, Screaming Frog learnt that 302 redirect issues shouldn’t be fully blamed for the hijacking. Instead where files were hosted, problems with indexation and how much authority a site has, all have an impact on the rankings of the original source. What was more interesting from their study was the power of Canonicals in combating hijacking.

Summary

• While 302 redirect hijacking is rare, it does happen. To keep your site safe we suggest:
• Limiting 302 redirects on your site or just use 301 (permanent) redirects instead.
• Keep a clean architecture and make sure all documents and uploads are properly set up.
• Make sure every page on your site has a Canonical set.
• Use absolute links on your site. In other words, links with the full domain (i.e. https://www.example.com/page-a/).
• Use the ‘Base’ meta tag. This is used to specify the ‘base’ URL for relative URLs.

The one thing we haven’t addressed is how you could hijack your OWN site via On-Domain 302 redirects. We have an interesting case study on these – so make sure you follow us on twitter 🙂

If you think your site has been hijacked or need help with your organic search rankings, please contact our team.