Editing URL redirection (section)

== Purposes ==
There are several reasons to use URL redirection:

=== Forcing HTTPS ===

A website may potentially be accessible over both a secure [[HTTPS]] URI scheme and plain HTTP (an insecure URI beginning with "http://").

If a user types in a URI or clicks on a link that refers to the insecure variant, the browser will automatically redirect to the secure version in case the website is contained in the [[HTTP Strict Transport Security|HSTS]] preload list shipped with the application or if the user had already visited the origin in the past.

Otherwise the website will be contacted over HTTP. A website operator may decide to serve such requests by redirecting the browser to the HTTPS variant instead and hopefully also priming HSTS for future accesses.

=== Similar domain names ===
<!-- Do NOT give any examples of misspelled  domain names. "examlpe.com"  currently leads to a site that tries to load malware on your computer. -->
A user might mistype a URL. Organizations often register these misspelled domains and redirect them to the intended location. This technique is often used to "reserve" other [[top-level domain]]s (TLD) with the same name, or make it easier for a ".edu" or ".net" site to accommodate users who type ".com".

=== Moving pages to a new domain ===
Web pages may be redirected to a new domain for three reasons:
* a site might desire, or need, to change its domain name;
* an author might move their individual pages to a new domain;
* two web sites might merge.

With URL redirects, incoming links to an outdated URL can be sent to the correct location. These links might be from other sites that have not realized that there is a change or from bookmarks/favorites that users have saved in their browsers. The same applies to [[search engine]]s. They often have the older/outdated domain names and links in their database and will send search users to these old URLs. By using a "moved permanently" redirect to the new URL, visitors will still end up at the correct page. Also, in the next search engine pass, the search engine should detect and use the newer URL.

=== Logging outgoing links ===
The access logs of most web servers keep detailed information about where visitors came from and how they browsed the hosted site.  They do not, however, log which links visitors left by.  This is because the visitor's browser has no need to communicate with the original server when the visitor clicks on an outgoing link. This information can be captured in several ways.  One way involves URL redirection.  Instead of sending the visitor straight to the other site, links on the site can direct to a URL on the original website's domain that automatically redirects to the real target. This technique bears the downside of the delay caused by the additional request to the original website's server. As this added request will leave a trace in the server log, revealing exactly which link was followed, it can also be a privacy issue.<ref name="NtrEdf" /> The same technique is also used by some corporate websites to implement a statement that the subsequent content is at another site, and therefore not necessarily affiliated with the corporation. In such scenarios, displaying the warning causes an additional delay.

=== Short aliases for long URLs ===
{{Main|URL shortening}}

Web applications often include lengthy descriptive attributes in their URLs which represent data hierarchies, command structures, transaction paths and session information. This practice results in a URL that is aesthetically unpleasant and difficult to remember, and which may not fit within the size limitations of [[microblogging]] sites. [[URL shortening]] services provide a solution to this problem by redirecting a user to a longer URL from a shorter one.<ref name="NtrEdf" />

=== Meaningful, persistent aliases for long or changing URLs ===
{{See also|Permalink|PURL|Link rot}}

Sometimes the URL of a page changes even though the content stays the same. Therefore, URL redirection can help users who have bookmarks. This is routinely done on Wikipedia whenever a page is renamed.

=== Post/Redirect/Get ===
{{Main|Post/Redirect/Get}}

Post/Redirect/Get (PRG) is a [[web development]] [[design pattern]] that prevents some duplicate [[form (web)|form]] submissions if the user clicks the refresh button after submitting the form, creating a more intuitive interface for [[user agent]]s (users).

=== Device targeting and geotargeting ===

Redirects can be effectively used for targeting purposes like [[geotargeting]]. Device targeting has become increasingly important with the rise of mobile clients. There are two approaches to serve mobile users: Make the website [[responsive web design|responsive]] or redirect to a mobile website version. If a mobile website version is offered, users with mobile clients will be automatically forwarded to the corresponding mobile content. For device targeting, client-side redirects or non-cacheable server-side redirects are used. Geotargeting is the approach to offer localized content and automatically forward the user to a localized version of the requested URL. This is helpful for websites that target audience in more than one location and/or language. Usually server-side redirects are used for Geotargeting but client-side redirects might be an option as well, depending on requirements.<ref name="KFihp" />

=== Manipulating search engines ===
Redirects have been used to manipulate search engines with unethical intentions, e.g., [[URL hijacking]]. The goal of misleading redirects is to drive search traffic to landing pages, which do not have enough ranking power on their own or which are only remotely or not at all related to the search target. The approach requires a rank for a range of search terms with a number of URLs that would utilize sneaky redirects to forward the searcher to the target page. This method had a revival with the uprise of mobile devices and device targeting. URL hijacking is an off-domain redirect technique<ref name="NAY3X" /> that exploited the nature of the search engine's handling for temporary redirects. If a temporary redirect is encountered, search engines have to decide whether they assign the ranking value to the URL that initializes the redirect or to the redirect target URL. The URL that initiates the redirect may be kept to show up in search results, as the redirect indicates a temporary nature. Under certain circumstances it was possible to exploit this behavior by applying temporary redirects to well-ranking URLs, leading to a replacement of the original URL in search results by the URL that initialized the redirect, therefore "stealing" the ranking. This method was usually combined with sneaky redirects to re-target the user stream from the search results to a target page. Search engines have developed efficient technologies to detect these kinds of manipulative approaches. Major search engines usually apply harsh ranking penalties on sites that get caught applying techniques like these.<ref name="vMaE1" />

=== Manipulating visitors ===
URL redirection is sometimes used as a part of [[phishing]] attacks that confuse visitors about which web site they are visiting.<ref name="XP9Dh" /> 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 installing a [[Trojan horse (computing)|Trojan]] of some sort instead.

=== Removing <code>referrer</code> information ===
When a link is clicked, the browser sends along in the [[HTTP request]] a field called [[HTTP referer|referer]] which indicates the source of the link. This field is populated with the URL of the current web page, and will end up in the [[server log|logs]] of the server serving the external link. Since sensitive pages may have sensitive URLs (for example, <code><nowiki>https://company.com/plans-for-the-next-release-of-our-product</nowiki></code>), it is not desirable for the <code>referrer</code> URL to leave the organization. A redirection page that performs [[Referer#Referrer hiding|referrer hiding]] could be embedded in all external URLs, transforming for example <code><nowiki>https://externalsite.com/page</nowiki></code> into <code><nowiki>https://redirect.company.com/https://externalsite.com/page</nowiki></code>. This technique also eliminates other potentially sensitive information from the referrer URL, such as the [[session ID]], and can reduce the chance of [[phishing]] by indicating to the end user that they passed a clear gateway to another site.