Web U: Redirection Home

Redirects -- a common and legitimate practice -- can get you in trouble when combined with the actions of search engines. It's important to use the right method for the result you want, or you could wind up having your URLs hijacked by unscrupulous spammers or even inadvertently hijacking someone else's link popularity and page-ranking yourself.

The reason redirects are so common is that the web is a dynamic environment. Webmasters are constantly reorganizing sites and changing domains, so they need a way to make sure that users and search engines can find their new locations. There are a few ways to accomplish this: JavaScript, meta-refresh tags, and server-side redirection. JavaScript can cause problems if it appears that the code is being used to obscure the redirect's true destination. In such instances, Google may mistake your site for spam and remove it from the index. Also, since spiders don't typically execute JavaScript, your redirect won't be catalogued and any authority or PageRank will not be transferred to the new page.

The most common redirect is the meta refresh, simply because it's the easiest to implement. It is one line of HTML that you insert in your document's header, and it doesn't require editing configuration files on your Web server. Zero-second meta refreshes are popular because such a refresh takes you immediately to the new page without stopping on the original page. Using a meta refresh is perfectly acceptable, but be sure you understand how search engines interpret them. The general rule is that less than one second is equivalent to a 302 (temporary) redirect, while more than one second equals a 301 (permanent) redirect.

This brings us to the most problematic redirect methods: the server-based redirects. If you want a new URL to replace an old one, 301 redirects should be used; 302 redirects should be implemented when you want to keep the original URL in the search-engine index. Ideally, when a 301 redirect is used, the popularity of the original page's link and the PageRank will pass on to the new page. With a 302 listing, the original page retains those features when being considered by search engines.

When handling a redirect within a domain, Yahoo! retains the URL from the new page for a 301 and the old page for a 302. When handling a redirect between domains, however, Yahoo! treats 301 and 302 redirects the same, by replacing the new page's URL in the search listings. By treating all cross-domain redirects as permanent, Yahoo! eliminates the possibility of hijacking, which exists in Google (because Google follows the rules published by the Worldwide Web Consortium, which recommends but doesn't require that the new address in a 302 redirect should replace the old one).

Hijacking occurs when a Web site replaces your Web site's URL in a search-engine results page. This can be either inadvertent or malicious. Very simply, a page outside your site uses a 302 redirect to a page on your site in an attempt to tell the search engine that your page is a temporary URL for the content and that the URL redirecting you is the permanent listing. The end result is that two copies of your page appear on the search-engine index. One of them will be considered duplicate content and deleted; which page gets deleted depends on which one has the best authority or "off page" ranking factors. If your page is deleted, then the offending page with redirect takes over your position in the rankings. Currently, Google is the top-targeted search engine by hijackers. Hijacking is a highly charged topic; some debate that it even exists, and there's evidence on both sides of the argument.

Of course, this isn't the way it always works. There is an inconsistency in the way search engines work to manage billions of html documents and the interlinking involved. But forewarned is forearmed.

Todd Friesen is director, search engine optimization, Range Online Media. (todd@rangeonlinemedia.com)