FamilySearch Wiki:Redirects

A redirect is a page which has no content itself, but sends the reader to another 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 has 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  Page_name  syntax.

This page contains guidance on the proper use of redirects on FamilySearch Wiki. For technical help relating to how redirects work, see Help:Redirects.

Purposes of redirects
Reasons for creating and maintaining redirects include:
 * Alternative names
 * Less specific forms of names
 * More specific forms of names
 * Abbreviations
 * Shortcuts
 * Alternative spellings or punctuation
 * Likely misspellings
 * Plurals
 * Related words
 * Likely alternative capitalizations
 * Sub-topics or other topics which are described or listed within a wider article
 * Representations using ASCII characters. Titles containing dashes should have redirects using hyphens

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, Somerset redirects to the article Somerset, England Genealogy). For deciding which should be the actual title of the article, see Page or article naming.

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.

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.

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.

Double redirects
The software will not follow chains of more than one redirect (see Double redirects). 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 anyway normally fixed by a bot after some time.)

Categorizing redirect pages
Most redirect pages are not placed in any categories. However there is an exception to this:
 * 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.)

When should we delete a redirect?
To delete a redirect without replacing it with a new article, add the following wikitext at the top of the article: delete template as explained in the deletion process.

Marking in this way 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 FamilySearch Wiki:Requested moves to request help from an admin in doing that.

The major reasons why deletion of redirects is harmful are:
 * a redirect may contain nontrivial edit history;
 * if a redirect is reasonably old, then it is quite possible that its deletion will break links in old, historical versions of some other articles—such an event is very difficult to envision and even detect.

Note that there could exist (for example), links to the URL anywhere on the internet. If so, then those links might not show up by checking for (clicking on) "What links here"

Therefore consider the deletion only of either really harmful redirects or of very recent ones.

Reasons for deleting
You might want to delete a redirect if one or more of the following conditions is met (but note also the exceptions listed below this list):


 * 1)  The redirect page makes it unreasonably difficult for users to locate similarly named articles via the search engine.
 * 2)  The redirect might cause confusion.
 * 3)  The redirect is offensive or abusive.
 * 4)  The redirect makes no sense, such as redirecting Apple to Orange.
 * 5)  It is a cross-namespace redirect out of article space, such as one pointing into the User or FamilySearch Wiki namespace.
 * 6)  If the redirect is broken, meaning it redirects to an article that does not exist or itself, it can be deleted immediately, though you should check that there is not an alternative place it could be appropriately redirected to first.
 * 7)  If the redirect is a novel or very obscure synonym for an article name, it is unlikely to be useful. Implausible typos or misnomers are potential candidates for speedy deletion, if recently created.
 * 8)  If the target article needs to be moved to the redirect title, but the redirect has been edited before and has a history of its own, then it needs to be deleted to make way for move.
 * 9)  If the redirect could plausibly be expanded into an article, and the target article contains little information on the subject. In these cases, it is better that the target article contain a redlink pointing back to the redirect.
 * 10)  If the redirect constitutes self-promotion or spam.

Reasons for not deleting
However, avoid deleting such redirects if:
 * 1)  They have a potentially useful page history. If the redirect was created by renaming a page with that name, and the page history just mentions the renaming, and for one of the reasons above you want to delete the page, copy the page history to the Talk page of the article it redirects to. The act of renaming is useful page history, and even more so if there has been discussion on the page name.
 * 2)  They would aid accidental linking and make the creation of duplicate articles less likely, whether by redirecting a plural to a singular, by redirecting a frequent misspelling to a correct spelling, by redirecting a misnomer to a correct term, by redirecting to a synonym, etc. In other words, redirects with no incoming links are not candidates for deletion on those grounds because they are of benefit to the browsing user.  Some extra vigilance by editors will be required to minimize the occurrence of those frequent misspellings in the article texts because the linkified misspellings will not appear as broken links.
 * 3)  They aid searches on certain terms.
 * 4)  You risk breaking incoming or internal links by deleting the redirect.
 * 5)  Someone finds them useful. Hint: If someone says they find a redirect useful, they probably do. You might not find it useful—this is not because the other person is a liar, but because you browse FamilySearch Wiki in different ways.
 * 6)  The redirect is to a plural form or to a singular form, or to some other grammatical form.

Neutrality of redirects
Note that redirects are not covered by FamilySearch Wiki's neutral point of view policy. This covers only article titles, which are required to be neutral (see FamilySearch Wiki:Neutral point of view). Perceived lack of neutrality in redirects is therefore not a valid reason for deletion. Non-neutral redirects should point to neutrally titled articles about the subject of the term.

Non-neutral redirects are commonly created for three reasons:


 * 1) Articles that are created using non-neutral titles are routinely moved to a new neutral title, which leaves behind the old non-neutral title as a working redirect.
 * 2) Articles created as POV forks may be deleted and replaced by a redirect pointing towards the article from which the fork originated.
 * 3) The subject matter of articles may be commonly represented outside FamilySearch Wiki by non-neutral terms. Such terms cannot be used as FamilySearch Wiki article titles, per the  neutral point of view policy.

If a redirect is not an established term and is unlikely to be used by searchers, it is unlikely to be useful and may be nominated for deletion. However, if a redirect represents an established term that is used in multiple mainstream reliable sources (as defined by FamilySearch Wiki:Verifiable), it should be kept even if non-neutral, as it will facilitate searches on such terms. Please keep in mind that RfD is not the place to resolve most editorial disputes.

What needs to be done on pages that are targets of redirects?
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 mis-spellings 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.

If the redirected term could have other meanings, a hatnote 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.

Do not "fix" links to redirects that are not broken
There is nothing inherently wrong with linking to redirects. Some editors are tempted, upon finding a link to a redirect page, to remove 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 redirect with redirect.

It is likewise unhelpful to edit visible links for no reason other than to avoid redirects. That is, editors should not change, for instance, Franklin Roosevelt to Franklin D. Roosevelt just to "fix a redirect". This rule does not apply to cases where there are other reasons to make the change.

Reasons not to change redirects include:
 * Redirects can indicate possible future articles.
 * 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.

Furthermore, not only are FamilySearch Wiki editors asked not to worry about performance, changing redirects to direct links does not significantly improve performance anyway.

Exceptions:
 * It is preferable to change redirected links in navigational templates, such as those found at the bottom of articles. In this case, when the template is placed on an article, and contains a direct link to that article (not 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.
 * It may be appropriate to make this kind of change if the hint that appears when a user hovers over the link is misleading.

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 was a separate page but was merged.) However it is acceptable to link to a title which redirects to a section within the article, especially in a long article that cannot be viewed all at once on an average-sized computer screen.

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.

Redirects for templates can cause confusion and may 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 such must be made for each of its its aliases (including T2 in this example).

Category redirects
Although it is possible to attempt to redirect categories by adding a line such as  #REDIRECT Category:African Americans  to a category, it is not generally recommended because of limitations in the mediawiki software. Categories "redirected" in this way do not prevent the addition of articles to the redirected category. Articles added to the "redirected" category do not show up as in the target category. Until these issues are addressed (in future versions of the software), #REDIRECT should not be added to category pages.

Suppressing redirects
When a page is moved, a redirect is automatically left behind. Administrators have the ability to suppress the redirect, i.e., to prevent it being created, by unchecking the box labelled "Leave a redirect behind." This is useful to save time when performing moves for which a redirect is inappropriate, such as reverting page move vandalism.

However, in general, unless there is a good reason (such as vandalism or userfying recently created malplaced items) to suppress the redirect, it is best to leave it behind, as a useful entry in the history. This leaves 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, usually we don't suppress nor delete redirects. As Brion Vibber said, "Not breaking links helps everyone, especially us first and foremost". He also described the removal of (file) redirects as "extremely user-hostile and makes the project less useful".