User:Utfor/Merged postmove cleanup guidance

Post-move cleanup
Please perform appropriate post-move cleanup after a successful move, as needed. It is important that you clean up after any move you perform. Accordingly, you should not close any move if you are unwilling to do the necessary clean up tasks listed below.

Fixing fair use rationales
If the page move involves a change in the topic structure, most often consisting in a move to or away from a primary title, please check whether there are any images on the moved page with fair use rationales (any Commons images can be immediately excluded, easily recognizable by the logo on the image page: Commons-logo.svg). If you find such fair use images present, you will need to edit the files' own Wikipedia page, changing the non-free use rationale to refer to the new article title. This is to ensure continued compliance with the non-free content criteria (part 10c), which if not followed, may result in the image being marked for deletion as orphaned.

Fixing category sort keys
Many pages have a template above the page categories in the form. When the sort key is the old title of the page, the DEFAULTSORT template can be deleted in most cases. DEFAULTSORT only needs to be used when we want a sorting key different from the article name. In that case, the sort key might need to be updated. Alternatively, in some pages categories are piped in the category links themselves, e.g.,. In the example you would fix the name of the film.

Fixing hatnotes, disambiguation pages, first sentences in leads and technical restrictions
Though not as common as the above, a move may occasionally render a hatnote obsolete. The documentation page at Hatnote templates documentation may be instructive in finding a suitable replacement, if one is needed (sometimes simple removal may be appropriate). Often the reason for the hatnote is because there is either a disambiguation page related to the topic, or another topic pointing to yours and vice-versa per WP:TWODABS. In such cases you should visit either the DAB page or the other article with the hatnote, and replace the old name of the article you have just moved, with its new name. Since the article name is reflected in the lead section, that section may need to be updated to be consistent with the new name. Along with generic lead corrections, add appropriate hatnotes where appropriate to affected pages.

Note that formerly a hatnote on the article could be added by a human notifying that a move discussion is underway. At present, this hatnote is being added by RMCD Bot, and subsequently removed by this bot. Attention is only needed if removal is delayed by more than an hour (the bot runs every 15 minutes).

If the article meets the criteria for italic titles given in the Article titles policy, place italic title at the top of the article. Some infobox templates, e.g. Infobox album and Infobox book, automatically italicize titles. If only part of the title should be italicized after the move, use DISPLAYTITLE instead.

The moved page may have an existing DISPLAYTITLE that will become invalid after the move and will produce red warnings. It is highly recommended to update these values appropriately to reflect the new title. If its corresponding talk page has a DISPLAYTITLE, it would need to be updated as well.

Fix double redirects
Generally, don't. "Double redirects are easily and automatically fixed by bots, and most are fixed within a few minutes of creation. Because of this, human editors are better off putting their time on other tasks that can't be automated."

Redirects to redirects, a.k.a. double redirects, aren't automatically followed (this prevents infinite loops and spaghetti linking). Don't fix double redirects if you think your move might be controversial and be reverted.
 * 1) Open Special:WhatLinksHere for that page (there may be a shortcut link on the page-moved summary screen to this directly).
 * 2) In the section of that page marked filters, click on the button labeled "Hide links" to filter to redirects to the prior name. For each redirect, change its target to the new page title.
 * 3) If there are more than 50 redirects listed, don't forget to navigate to all parts of the list using the "next 50" or other links available.

Unless subsequently usurped, a page move will result in a redirect page at the old title that sends the reader to the new one. Generally, there is no problem with this – for example, one should not change inbound links in articles to bypass the redirect.

Editing of this redirect itself is usually not helpful, but if such a need exists, then a special care should be taken about inbound "double" redirects. If the page was moved because of a misnomer (i.e. its content has a sense, but does not match the title), then its old title should be replaced or deleted. It should be done quickly, otherwise bots will start to alter redirects bound to the old title, pointing them to the new title, which is obviously not a correct solution in the case of a misnomer.

Contrarily, if the page had a lot of legitimate inbound links, but has to move because of a title usurpation, then inbound redirects should be promptly examined. If most redirects rightfully belong to the page just moved, then the old→new redirect should not be replaced until bots fixed those double redirects. Early replacing the old→new redirect with old→something_else can be especially disruptive, since bots start to "fix" redirects to "something_else" target – see [ example] after usurpation of the title Viper.

Sidebars and navbars
Any navigation templates (like sidebars or navboxes) that link to the page will need to be edited so that the link is direct. This is to preserve the correct appearance of the template: when a navigation template is displayed on a page, the entry for that page is meant to appear unlinked and in bold; this will not work if the page is linked via a redirect – but the link will rather appear as a blue wikilink instead.

Editnotices
Occasionally, a page has an accompanying editnotice in the template namespace. For example, the editnotice for 0.999... is Template:Editnotices/Page/0.999.... Sometimes, a page may be accompanied by a group editnotice (like this one), or more rarely, a protection editnotice (like this one). If a page with an editnotice is moved, the editnotices should move with them. Currently, this requires the technical assistance of an administrator, pager mover or template editor. If the move was done by a non-page-mover a redirect may be left over. This should typically be deleted as G6, unless the editnotice also applies to the redirect itself.

Fixing talk page archiving
If the talk page is automatically archived, it will have archiving bot settings (such as with or  ) which have hardcoded page names. After closing the move and moving the talk page and its archived subpages, the bot settings needs to be updated or the archiving bot will stop archiving the moved talk page. In some circumstances, this will involve updating (moving) a hard-coded bot subpage.

Update talk page notifications
Usually, the move discussion has a tag. Follow the instructions given in the tag to inform that the discussion is closed.

Moves of disambiguation pages to primary topic titles
Unlike most moves where the pages that link to the moved title will still point to it after the move because of redirects, when a disambiguation page is moved to a primary title, this severs the connection between pages which linked to the primary title. For example, if  is moved to a parenthetically disambiguated name, and   is then moved to , everything that linked to Foo, now leads to the primary disambiguation page. In such instances, significant cleanup involving hand dabbing of the pages that formerly linked to the title may be needed – all inbound links and redirects to each of the pages concerned should be checked and retargeted if necessary.

An example is at Talk:Shinola Detroit. In that case, the base name "Shinola" was moved from a Detroit company's article to an article about the original product and company. All of the mainspace links on the "Shinola" What links here page that were originally meant to link to "Shinola Detroit" had to be fixed in a similar manner to when a base name is moved to a disambiguation page. Each page had to be opened, and every link to "Shinola" had to be changed to "Shinola Detroit".


 * Redirects
 * There may be occasion to retarget to a disambiguation page a redirect that is left behind from a page move. If Foo (ambiguous) were moved to Foo (more focused), it may be that the redirect left behind should be retargeted to Foo (disambiguation).  In such a case, significant cleanup may again be necessary to disambiguate the links to the left-behind redirect.

Wikidata update
Near the bottom of some "successfully moved" pages is a link to the associated page on Wikidata that might need to be updated (this may be done automatically when a page is moved); a link named "Wikidata item" could also appear in the left sidebar in the "Tools" section. In the upper right of the Wikidata page is an "edit" link (scroll to the right if necessary), which is used to update the main information in the topmost box. The leftmost field is for the new page title, and the description field in the center can be used for any type of disambiguation (do not include the "(disambiguation)" in the title field), Wikimedia lists, and so on. Alternative names can be included in the rightmost field. When finished, click "save" in the upper right, and the Wikidata page will be updated.

Categorizing redirects
Redirects should be categorized per the WikiProject Redirect style guide.

Categories and subcategories
Ensure there are no pages in categories that will no longer be used because of moves. Subcategories from wiki markup and templates should be updated with the new category.

If the title of the article coincides with the name of a category, consider requesting that the category name be changed accordingly. This should be done at Categories for discussion/Speedy specifying criterion C2D.