TechInfoDepot:Redirect

A redirect is a page which has no content itself, but sends the reader to another article, section of an article, or page, usually from an alternative title. For example, if you type "UK" in the search box, or follow the wikilink UK, you will be taken to the article United Kingdom, with a note at the top of the page: " ( Redirected from UK ) ". This is because the page UK contains the wikitext #REDIRECT United Kingdom , which defines it as a redirect page and indicates the target article. It is also possible to redirect to a specific section of the target page, using the #REDIRECT Page name  syntax.

This page contains guidance on the proper use of redirects on TechInfoDepot. For technical help relating to how redirects work, see Help:Redirect. Other relevant pages are TechInfoDepot:Double redirects, TechInfoDepot:Hatnote and WikiProject Redirect.



Purposes of redirects
Reasons for creating and maintaining redirects include:
 * Alternative names (for example, Edison Arantes do Nascimento redirects to Pelé), a redirect to the most appropriate article title.
 * Plurals (for example, Greenhouse gases redirects to Greenhouse gas).
 * Closely related words (for example, Symbiont redirects to Symbiosis).
 * Adjectives/Adverbs point to noun forms (e.g., Treasonous redirects to Treason)
 * Less specific forms of names, for which the article subject is still the primary topic. For example, Hitler redirects to Adolf Hitler, whereas Johnson is a disambiguation page rather than a redirect, since no Johnson is regarded as the primary topic for that name.
 * More specific forms of names (for example, Articles of Confederation and Perpetual Union redirects to Articles of Confederation).
 * Abbreviations and initialisms (for example, DSM-IV redirects to Diagnostic and Statistical Manual of Mental Disorders). But often an abbreviation will have multiple meanings, none of which is a primary topic—in that case a disambiguation page should be created rather than a redirect.
 * Alternative spellings or punctuation. For example, Colour redirects to Color, and Al-Jazeera redirects to Al Jazeera.
 * Punctuation issues—titles containing dashes should have redirects using hyphens.
 * Representations using ASCII characters, that is, common transliterations (for example, Pele also redirects to Pelé while Kurt Goedel and Kurt Godel redirect to Kurt Gödel).
 * Likely misspellings (for example, Condoleeza Rice redirects to Condoleezza Rice).
 * Likely alternative capitalizations (for example, Natural Selection redirects to Natural selection). This is not necessary for user searching, but may aid linking from other articles and external sites.
 * To comply with the maintenance of nontrivial edit history, pursuant to WP:MERGETEXT for copyright licensing requirements.
 * Sub-topics or other topics which are described or listed within a wider article. (Such redirects are often targeted to a particular section of the article.)
 * Redirects to disambiguation pages which do not contain "(disambiguation)" in the title (for example, America (disambiguation) redirects to America). These help maintenance by allowing deliberate links to disambiguation pages to be distinguished from links which need to be disambiguated.
 * Shortcuts (for example, WP:V redirects to TechInfoDepot:Verifiability). This is commonly done in project space, but not in article space.
 * Old-style CamelCase links (if already in existence) (AnnaKournikova redirects to Anna Kournikova).
 * Links auto-generated from Exif information (Adobe Photoshop CS Windows redirects to Adobe Photoshop).
 * Finding what links to a section, when links are made to the redirect rather than the section.

There are redirect templates to explain the reason for a redirect.

Note that redirects to other Wikimedia projects, other websites, or special pages do not work. These should be avoided or replaced with a soft redirect template. Soft redirects are also used in category space (using the category redirect template).

How to make a redirect
To create a basic redirect manually, set #REDIRECT target page name here  as the only body text of the page. For instance, if you were redirecting from "" to "United Kingdom", this would be the entire body of :

Redirects can also be automatically created when you move (rename) an existing page.

How to edit a redirect or convert it into an article
Sometimes an existing redirect should really be handled by a full article, per Category:Redirects with possibilities. For example, the name of a notable musician (who does not yet have an article) may instead be a redirect to an existing article about a band of which the musician is a member. In this case you may edit the redirect to make it into an article. Also, if an existing redirect points to the wrong page, you may edit the redirect to point to a different page.

If you want to edit a redirect page you must use a special technique in order to get to the redirect page itself. This is because when you try to go straight to the redirect page and edit it, the redirect page will automatically redirect you to its target page (because this is what a redirect page is meant to do). Below is an example of why you might need to go to a redirect page itself (to do a small edit) and how to actually get there. For example, say Trygve Halvdan Lie did not have his own article, and so this link was a redirect to the page Secretary-General of the United Nations. If, later on, the page Trygve Lie was created as a biography, the page Trygve Halvdan Lie should be changed to redirect to Trygve Lie per WP:COMMONNAME. To do this, go to the redirect page by clicking the redirect note on the target page, which in this case would read "(Redirected from Trygve Halvdan Lie)". Once there, you may click the "Edit" tab, and change the page from #REDIRECT Secretary-General of the United Nations  to #REDIRECT Trygve Lie .

Targeted and untargeted redirects
Most redirects are untargeted, i.e. they lead simply to a page, not to any specific section of the page. This is usually done when there is more than one possible name under which an article might be sought (for example, Cellphone redirects to the article Mobile phone). For deciding which should be the actual title of the article, see Article titles.

It is also possible to create a targeted redirect, i.e. a redirect to a particular point on the target page—either a section header or an anchor. For example, Malia Obama redirects to Family of Barack Obama. Therefore, entering "Malia Obama" will bring the searcher straight to that section of the article Family of Barack Obama which deals with "Malia and Sasha Obama".

Consider that when the target page is displayed, it is likely that the top of the page will not be shown, so the user may not see the helpful "(redirected from... )" text unless they know to scroll back to the top. This is less likely to cause confusion if the redirect is to a heading with the same name as the redirect.

The text given in the link on a targeted redirect page must exactly match the target section heading or anchor text, including capitalization. (In the absence of a match, the reader will simply be taken to the top of the target page.) It is often helpful to leave a hidden comment in the target text, to inform other editors that a section title is linked, so that if the title is altered, the redirect can be changed. For example:

==Vaccine overload==

To ensure that a redirect will not break if a section title gets altered, or to create a redirect to a point on the page other than a section heading, create an explicit target anchor in the page, e.g., by using the anchor template. The anchor text will not be visible (unless the visible anchor template is used), but it will serve as a permanent marker of that place on the page. Editors should generally not remove or alter such anchors without checking all incoming links and redirects.

For example, in the Google search article, the text   is placed at the point where Google Calculator is described. The title Google Calculator can then be redirected to Google search.

Warning

 * 1) Don't give an anchor the same name as a section heading – this creates invalid code, as anchor names must be unique.
 * 2) Be careful with anchor capitalization – section redirects are case-sensitive in standards-compliant browsers.

Double redirects
The software will not follow chains of more than one redirect - this is called a double redirect. A redirect should not be left pointing to another redirect page.

Double redirects often arise after a page is moved (renamed)—after moving a page, check whether there are any redirects to the old title (using the link on the move result page, or using "What links here"), and change them to redirect straight to the new title. (Double redirects are usually fixed by a bot after some time.)

Linking to a redirect
You can link to a redirect page just as you can link to an article page by placing the redirect page name within a set of double brackets, such as: replacing Redirect page name with the name of the redirect page to link.

To link to a redirect page without following the underlying redirect, use: replacing Redirect page name with the name of the redirect page to link. Clicking on a noredirect link will send the reader to the redirect page rather than the final redirect destination.

Categorizing redirect pages
Most redirect pages are not placed in any categories. However there are three types of exception to this:
 * Certain categories have been created for particular types of redirects, such as Category:Redirects from abbreviations, in which a redirect page may be placed using the R from abbreviation template. See TechInfoDepot:Template messages/Redirect pages for a full list of these templates.
 * Sometimes a redirect is placed in an article category because the form of the redirected title is more appropriate to the context of that category. (Redirects appear in italics in category listings.)
 * Discussion pages. If a discussion/talk page exists for an article, please change the article's class to "class=Redirect" for all projects.

When should we delete a redirect?
To delete a redirect without replacing it with a new article, list it on redirects for discussion. See the deletion policy for details on how to nominate pages for deletion.

Listing is not necessary if you just want to replace a redirect with an article, or change where it points: see these instructions for help doing this. If you want to swap a redirect and an article, but are not able to move the article to the location of the redirect please use TechInfoDepot:Requested moves to request help from an admin in doing that.

What needs to be done on pages that are targets of redirects?
We follow the "principle of least astonishment"—after following a redirect, the reader's first question is likely to be: "hang on ... I wanted to read about this. Why has the link taken me to that?". Make it clear to the reader that they have arrived in the right place.

Normally, we try to make sure that all "inbound redirects" other than misspellings or other obvious close variants of the article title are mentioned in the first couple of paragraphs of the article or section to which the redirect goes. It will often be appropriate to bold the redirected term. For example:
 * James Tiptree, Jr. (August 24, 1915 – May 19, 1987) was the pen name of American science fiction author Alice Bradley Sheldon ...
 * James Tiptree, Jr., redirect from Alice Sheldon
 * Water (H2O, HOH) is the most abundant molecule ...
 * Properties of water, redirect from H2O, NB not bolded

If the redirected term could have other meanings, a hatnote (examples) should be placed at the top of the target article directing readers to the other meanings or to a relevant disambiguation page. This is usually done using one of the redirect disambiguation templates (examples).

It may also helpful to search the List of Categories for related terms; adding a hatnote and a category link to the old term will make related pages easier to locate.

Redirects that replace previous articles
Removing all content in a problematic article and replacing it with a redirect is common practice, known as blank-and-redirect. This practice is supported by the guideline to be bold when editing; if other editors disagree with this blanking, its contents can be recovered from page history, as the article has not been formally deleted.

To make it easier for other editors to find the history of the blanked article, it's good practice to add a short notice at the talk page of the target article, even if no content has been merged there. This is specially useful if the blanked article had few visits and infrequent edits. If the redirect is replacing an article that had been deleted by an administrator, this notice is the only way for editors to know that a previous version of the article existed at all.

If the topic of the article can be reasonably thought to describe a notable topic, mark the redirect with the template Redirect with possibilities to indicate that it could be expanded in the future. You may also consider turning the article into a stub by removing all unsourced content and keeping the valid references, instead of blanking it.

Note that certain forms of blanking are not allowed. Illegitimate blanking of valid content without reason is considered vandalism, a form of disruptive editing. Other forms of blank-and redirect, although not vandalism, are still undesirable. If you want to rename the article by cutting and pasting text to a new article with a different title, you should instead move the page with the Move option. If you want to keep some content from the blanked article and add it to the target article, you should follow the instructions at TechInfoDepot:Merging. Both processes will create proper links to the edit history, which is required by the TechInfoDepot license for legal reasons to preserve attribution of content to its authors.

Do not "fix" links to redirects that are not broken
There is nothing inherently wrong with linking to redirects to articles. Some editors are tempted, upon finding a link to a redirect page, to bypass the redirect and point the link directly at the target page. While there are a limited number of cases where this is beneficial, it is generally an unhelpful exercise, and it can actually be detrimental.

With a few limited exceptions, there are no good reasons to pipe links solely to avoid redirects. It is almost never helpful to replace  with   to   just to "fix a redirect". This rule does not apply to cases where there are other reasons to make the change, such as linking to an unprintworthy redirect.

Reasons not to change (bypass) redirects include:
 * Redirects can indicate possible future articles (see Redirect with possibilities).
 * Introducing unnecessary invisible text makes the article more difficult to read in page source form.
 * Non-piped links make better use of the "what links here" tool, making it easier to track how articles are linked and helping with large-scale changes to links.
 * Shortcuts or redirects to sections of articles or of TechInfoDepot's advice pages should never be bypassed, as the section headings on the page may change over time. Updating one redirect is far more efficient than updating dozens of piped links.
 * Intentional links to disambiguation pages always use the title with "(disambiguation)", even if that is a redirect.
 * If editors persistently use a redirect instead of an article title, it may be that the article needs to be moved rather than the redirect changed. As such the systematic "fixing of redirects" may eradicate useful information which can be used to help decide on the "best" article title.

Exceptions:
 * In many cases it is preferable to change redirected links in navigational templates, such as those found at the bottom of many articles (e.g., US Presidents at the end of George Washington). In this case, when the template is placed on an article, and contains a direct link to the same article (rather than a redirect), the direct link will display in bold (and not as a link), making it easier to navigate through a series of articles using the template. There are exceptions to this exception: where a redirect represents a distinct sub-topic within a larger article and is not merely a variant name, it is preferable to leave the redirect in the template.
 * It may be appropriate to make this kind of change if the hint that appears when a user hovers over the link is misleading.
 * One of the valid reasons behind making a redirect is plausible typos. These redirects enhance the reach of the TechInfoDepot readers when using the search box. However, following the general rule of having no typographical errors in the article, such redirects should not be used in links. Such redirects should have R from misspelling added in order to flag them as unprintworthy and avoid their use in normal wikilinks.

Self-redirects
Avoid linking to titles which redirect straight back to the page on which the link is found. This situation may arise if a redirect is created from a red link on the page, or if the title was once a separate page but was merged. Linking to a title which redirects to a section or anchor within the article (redirects with R to section or R to anchor) has pros and cons: It facilitates navigation on a long article that cannot be viewed all at once on an average-sized computer screen; however, contrary to section links that work almost instantly, section redirects impose an Internet connection delay which may be undesirable over slow or high-traffic connections. It is not necessary to remove section redirects if they are marked with R with possibilities as they have the potential to become an independent article in the future.

Template redirects
A template can be redirected to another template in the same way, e.g., by entering the following markup at the top of a template T2:
 * 1) REDIRECT Template:T1

This allows the template name T2 to be used instead of the actual template name T1. All the parameters of T1 will be respected by T2.

A categorisation template such as R from move may be added to T2 (below the  line) as follows:

Redirects for templates can cause confusion and make updating template calls more complicated. For example, if calls to T1 are to be changed to some new template TN1, articles must be searched for  and a separate search must be made for each of its aliases (including T2 in this example). Moreover changes to syntax, corrections, scans and other processes (for example tag dating) must take into account all redirects.

Category redirects
Do not create inter-category redirects, by adding a line #REDIRECT :Category:target category to a category page. Articles added to a "redirected" category do not show up in the target category, preventing proper categorization. What's worse, since redirected categories do not become "red links", editors won't be aware even when they add an article to a redirected category.

For an attempt to fix this issue in MediaWiki, see.

Instead, "soft" redirects are used. It can be created by placing in the category page. See TechInfoDepot:Categories for discussion.

Suppressing redirects
When a page is moved, a redirect is automatically left behind. Some groups of users (those who possess a  right) have the ability to prevent the redirect being created, by unchecking the box labelled "Leave a redirect behind." Currently these groups are administrators, bots and global rollbackers. In some circumstances, a page should be moved, but a redirect from its current name is inappropriate, such as reverting page-move vandalism. Suppressing the redirect can avoid an extra action (page removal) and save time in these cases.

However in general, the redirect will be a useful entry in the history, and it is best to leave it behind, unless there is a good reason to suppress the redirect, such as vandalism, userfying recently created malplaced items or freeing a title to be occupied immediately by another page (e.g., moving term to accurate term and term (disambiguation) to term ). Redirects leave a trail to help readers find the old article, in case a new article is created at its previous location, and to prevent linkrot. Therefore, we usually neither suppress nor delete redirects. As Brion Vibber said, "Not breaking links helps everyone, especially us first and foremost". He also said that the removal of (file) redirects is "extremely user-hostile and makes the project less useful".