During the past several months, many discussions have been taking place in the search engine marketing communities concerning what many refer to as pagejacking. What you are about to read concerns everyone who has a website online, this is not an isolated incident. Those who are involved with the page jacking issues may not even know that they are causing harm to those they are linking to using a 302 Found redirect. Many of the 302s are generated from exit tracking scripts.
"An explanation of the page hijack exploit using 302 server redirects. This exploit allows any webmaster to have his own "virtual pages" rank for terms that pages belonging to another webmaster used to rank for. Successfully employed, this technique will allow the offending webmaster ("the hijacker") to displace the pages of the "target" in the Search Engine Results Pages ("SERPs"), and hence (a) cause search engine traffic to the target website to vanish, and/or (b) further redirect traffic to any other page of choice."
"A page hijack is a technique exploiting the way search engines interpret certain commands that a web server can send to a visitor. In essence, it allows a hijacking website to replace pages belonging to target websites in the Search Engine Results Pages ("SERPs").
When a visitor searches for a term (say, foo) a hijacking webmaster can replace the pages that appear for this search with pages that they control. The new pages that the hijacking webmaster inserts into the search engine are "virtual pages", meaning they don't exist as real pages. They appear to the search engine as copies of the target pages, but having another web address (URI) than the target pages.
Once a hijack has taken place, a malicious hijacker can redirect any visitor that clicks on the target page listing to any other page the hijacker chooses to redirect to. If this redirect is hidden from the search engine spiders, this can be sustained for an indefinite period of time.
Possible abuses include: Make "adult" pages appear as CNN pages in the search engines, set up false bank front ends, false storefronts, etc. All the "usual suspects" that is."
In laymen's terms, a 302 redirect instructs the useragent (e.g. search engine spider) to maintain the requested resource (e.g. a website address or URI) but redirect the useragent to a temporary resource (the destination URI). From a search engine spidering standpoint, this means that the main URI, the first one requested, is the one to get indexed by the search engine spider, not the target URI (where you are redirected once you follow the link). What does a 302 redirect look like?
"The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field."
"SHOULD - This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
"So, the SHOULD word in the RFC text on 302s is not to be interpreted as "MUST", it's more like "RECOMMENDED". It's a significant technical detail that means that the search engines are not forced in any way to do as RFC 2119 says. If they have valid reasons not to do so, they will actually be conforming to RFC 2119 by not following it to the letter."
You can utilize our Check Server Headers Tool to determine how a URI is being treated by the server. Our CSH Tool will show you "recursive" results so you'll be able to see the first server response returned and then any redirects that may be taking place. In the instance of possible 302 pagejacking issues, you will most likely receive two server responses. The first server response will show the 302 Found redirect. The second response will most likely be a 200 OK status which is the target URI or the URI that the first 302 is being redirected to.
Here's example of what a server might return for a 302 Found redirect. We have a special test URI that you can cut and paste into our Check Server Headers Tool to test the 302 server response.
Test URI: /w3c/status-codes/302
SEO Consultants Directory Check Server Headers - Single URI Results Current Date and Time: 2005-03-14T19:00:00-0800
#1 Server Response: /w3c/status-codes/302 HTTP Status Code: HTTP/1.1 302 Found Server: Microsoft-IIS/5.0 Date: Wed, 14 Mar 2005 19:00:00 GMT MicrosoftOfficeWebServer: 5.0_Pub X-Powered-By: ASP.NET Location: / Connection: Keep-Alive Content-Length: 0 Content-Type: text/html Cache-control: private Redirect Target: /
#2 Server Response: / HTTP Status Code: HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Wed, 14 Mar 2005 19:00:01 GMT MicrosoftOfficeWebServer: 5.0_Pub X-Powered-By: ASP.NET Connection: Keep-Alive Content-Length: 17260 Content-Type: text/html Cache-control: private
Admin Note: It is unfortunate that this type of information is available publicly. I'm certain that once those in the know get a hold of this, there are going to many more 302 pagejacking incidents that are intentional. If you read what Claus Schmidt has to say, the only way to address this issue is to go public with the information forcing the search engines to correct their current methods of handling 302 Found redirects.
Article Disclaimer: The SEO Consultants Directory does not endorse the opinions and/or facts expressed by members who provide marketing articles for our site. These search engine optimization and search engine marketing articles are here for you to review and make your own decisions.
If you are a member of the SEO Consultants Directory, you can submit a search engine marketing article for review by following the instructions in our Member Submitted SEO/SEM Articles section.