URL redirection

From Wikipedia, the free encyclopedia
Jump to: navigation, search
For redirection on Wikipedia, see Wikipedia:Redirect.



There are several reasons to use URL redirection :

Similar domain names[edit]


Moving pages to a new domain[edit]


  • a site might desire, or need, to change its domain name;
  • an author might move his or her individual pages to a new domain;
  • two web sites might merge.



Logging outgoing links[edit]




Short aliases for long URLs[edit]

Main article: URL shortening


Meaningful, persistent aliases for long or changing URLs[edit]

See also: Permalink, PURL and Link rot



Main article: Post/Redirect/Get


Manipulating search engines[edit]

Redirect techniques are used to fool search engines. For example, one page could show popular search terms to search engines but redirect the visitors to a different target page. There are also cases where redirects have been used to "steal" the page rank of one popular page and use it for a different page, They will also redirect using searches with search engines as searches, usually involving the 302 HTTP status code of "moved temporarily."[2][3]

Search engine providers have noticed the problem and are working on appropriate actions.[citation needed]


Manipulating visitors[edit]

URL redirection is sometimes used as a part of phishing attacks that confuse visitors about which web site they are visiting.[citation needed] Because modern browsers always show the real URL in the address bar, the threat is lessened. However, redirects can also take you to sites that will otherwise attempt to attack in other ways. For example, a redirect might take a user to a site that would attempt to trick them into downloading antivirus software and, ironically, installing a trojan of some sort instead.

Removing referer information[edit]



Several different kinds of response to the browser will result in a redirection. These vary in whether they affect HTTP headers or HTML content. The techniques used typically depend on the role of the person implementing it and their access to different parts of the system. For example, a web author with no control over the headers might use a Refresh meta tag whereas a web server administrator redirecting all pages on a site is more likely to use server configuration.

Manual redirect[edit]


Please follow <a href="http://www.example.com/">this link</a>.

This method is often used as a fall-back — if the browser does not support the automatic redirect, the visitor can still reach the target document by following the link.

HTTP status codes 3xx[edit]

In the HTTP protocol used by the World Wide Web, a redirect is a response with a status code beginning with 3 that causes a browser to display a different page. The different codes describe the reason for the redirect, which allows for the correct subsequent action (such as changing links in the case of code 301, a permanent change of address).

HTTP/1.1 defines several status codes for redirection:

  • 300 multiple choices (e.g. offer different languages)
  • 301 moved permanently
  • 302 found (originally "temporary redirect" in HTTP/1.0 and popularly used for CGI scripts; superseded by 303 and 307 in HTTP/1.1 but preserved for backward compatibility)
  • 303 see other (forces a GET request to the new URL even if original request was POST)
  • 307 temporary redirect (provides a new URL for the browser to resubmit a GET or POST request)


(Status codes 304 not modified and 305 use proxy are not redirects).

An HTTP response with the 301 "moved permanently" redirect looks like this:

HTTP/1.1 301 Moved Permanently
Location: http://www.example.org/
Content-Type: text/html
Content-Length: 174
<p>This page has moved to <a href="http://www.example.org/">http://www.example.org/</a>.</p>

Using server-side scripting for redirection[edit]

Web authors producing HTML content can't usually create redirects using HTTP headers as these are generated automatically by the web server program when serving an HTML file. The same is usually true even for programmers writing CGI scripts, though some servers allow scripts to add custom headers (e.g. by enabling "non-parsed-headers"). Many web servers will generate a 3xx status code if a script outputs a "Location:" header line. For example, in PHP, one can use the "header" function:

header('HTTP/1.1 301 Moved Permanently');

(More headers may be required to prevent caching[4]).

The programmer must ensure that the headers are output before the body. This may not fit easily with the natural flow of control through the code. To help with this, some frameworks for server-side content generation can buffer the body data. In the ASP scripting language, this can also be accomplished using response.buffer=true and response.redirect "http://www.example.com/"

HTTP/1.1 allows for either a relative URI reference or an absolute URI reference. If the URI reference is relative the client computes the required absolute URI reference according to the rules defined in RFC 3986.

Apache mod_rewrite[edit]

The Apache HTTP Server's mod_alias extension can be used to redirect certain requests. Typical configuration directives look like:

Redirect permanent /oldpage.html http://www.example.com/newpage.html
Redirect 301 /oldpage.html http://www.example.com/newpage.html

For more flexible URL rewriting and redirection, Apache mod_rewrite can be used. E.g. to redirect a requests to a canonical domain name:

RewriteEngine on


Refresh Meta tag and HTTP refresh header[edit]

Netscape introduced the meta refresh feature which refreshes a page after a certain amount of time. This can specify a new URL to replace one page with another. This is supported by most web browsers. See

A timeout of zero seconds effects an immediate redirect. This is treated like a 301 permanent redirect by Google, allowing transfer of PageRank to the target page.[5]


<meta http-equiv="Refresh" content="0; url=http://www.example.com/" />
<p>Please follow <a href="http://www.example.com/">this link</a>.</p>

This technique can be used by web authors because the meta tag is contained inside the document itself. The meta tag must be placed in the "head" section of the HTML file. The number "0" in this example may be replaced by another number to achieve a delay of that many seconds. The anchor in the "body" section is for users whose browsers do not support this feature.

The same effect can be achieved with an HTTP refresh header:

HTTP/1.1 200 ok
Refresh: 0; url=http://www.example.com/
Content-type: text/html
Content-length: 78


Here is a simple CGI program that effects this redirect:

print "\r\n";
print "Please follow <a href=\"http://www.example.com/\">this link</a>!"


The W3C discourage the use of meta refresh, since it does not communicate any information about either the original or new resource, to the browser (or search engine). The W3C's Web Content Accessibility Guidelines (7.4) discourage the creation of auto-refreshing pages, since most web browsers do not allow the user to disable or control the refresh rate. Some articles that they have written on the issue include W3C Web Content Accessibility Guidelines (1.0): Ensure user control of time-sensitive content changes, Use standard redirects: don't break the back button! and Core Techniques for Web Content Accessibility Guidelines 1.0 section 7.

JavaScript redirects[edit]





However, HTTP headers or the refresh meta tag may be preferred for security reasons and because JavaScript will not be executed by some browsers and many web crawlers.

Frame redirects[edit]


<frameset rows="100%">
  <frame src="http://www.example.com/">
    <body>Please follow <a href="http://www.example.com/">link</a>.</body>


This cloaking technique may be used so that the reader sees a more memorable URL or to fraudulently conceal a phishing site as part of website spoofing.[7]

The same effect can be done with an inline frame:

<iframe height="100%" width="100%" src="http://www.example.com/">

Redirect chains[edit]

One redirect may lead to another. For example, the URL http://www.wikipedia.com/wiki/URL_redirection (note the domain name) is first redirected to http://www.wikipedia.org/wiki/URL redirection and then to the correct URL: http://en.wikipedia.org/wiki/URL_redirection. This is unavoidable if the different links in the chain are served by different servers though it should be minimised by rewriting the URL as much as possible on the server before returning it to the browser as a redirect.

Redirect loops[edit]

Sometimes a mistake can cause a page to end up redirecting back to itself, possibly via other pages, leading to an infinite sequence of redirects. Browsers should stop redirecting after a certain number of hops and display an error message.

HTTP/1.1 states:

A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).

Note: An earlier version of this specification recommended a maximum of five redirections ([RFC2068], Section 10.3). Content developers need to be aware that some clients might implement such a fixed limitation.




URL redirection services[edit]








Referrer masking[edit]



Here is a simplistic example of such a service, written in PHP.

header( 'Refresh: 0; url=http://'.$url );
<!-- Fallback using meta refresh. -->
  <meta http-equiv="refresh" content="0;url=http://<?php echo $url; ?>">
 Attempting to redirect to <a href="http://<?php echo $url; ?>">http://<?php echo $url; ?></a>.

The above example does not check who called it (e.g. by referrer, although that could be spoofed). Also, it does not check the url provided. This means that a malicious person could link to the redirection page using a url parameter of his/her own selection, from any page, which uses the web server's resources.

See also[edit]


  1. ^ "Google revives redirect snoopery". blog.anta.net. 2009-01-29. ISSN 1797-1993. Archived from the original on 2011-08-17. 
  2. ^ "Google's serious hijack problem – Spammers hijack web site listings in Google". Pandia.com. September 13, 2004. Archived from the original on 2013-06-05. 
  3. ^ "Stop Scrapers From Hijacking your Web Pages". Lori's Web Design.com. Retrieved 2013-12-18.
  4. ^ "PHP Redirects: 302 to 301 Rock Solid Robust Solution". WebSiteFactors.co.uk. Archived from the original on 2012-10-12. 
  5. ^ "Google and Yahoo accept undelayed meta refreshs as 301 redirects". Sebastian's Pamphlets. 3 September 2007.
  6. ^ "Advanced JavaScript Redirections". Online Marketing Technologies. 
  7. ^ Aaron Emigh (19 January 2005). "Anti-Phishing Technology" (PDF). Radix Labs.
  8. ^ "Net gains for tiny Pacific nation". BBC News. 2007-09-14. Retrieved 2010-05-27. 

External links[edit]