It would be nice if the sysop tool of move revert (accessible from the move log) would auto-delete the pages that are currently only redirected.
If that's not clear, here's an explanation. We occasionally get vandals who use tabbed browsing or something to that effect to move large numbers of pages to nonsense or offensive page names. The simplest way for sysops to undo this is to revert the moves themselves (from the move log). But the move reverts leave the offensive/nonsense name pages as redirects to the original article. So sysops then go through each individual redirect and delete them one by one. It would save significant time and effort, if the act of reverting a move would also automatically delete the new page (the page to which the original was moved (the move which was reverted)).
I'd like to automate that last step. Can we do this? --PeterTalk 23:02, 25 March 2008 (EDT)
If it's not possible to automate, I wonder if at least another checkbox could be added... right now there's two when you're reverting a move: "move associated talk page" and "watch this page"... perhaps a third could be "delete current page after move" or something to that effect – cacahuatetalk 20:18, 29 March 2008 (EDT)
I think I understand why you want to remove these redirects, but believe that in 99% of all cases the redirects should be left in place. To make sure I'm on the same page, let's do a case study:
I grew up in Madison, Ohio. The town next to us, Perry, was our football rival. The week before the big game, I rename the Perry page to "Idiotville", which is reverted. I then send all my friends links to the Idiotville page and we laugh that Idiotville redirects to Perry. What a classic internet joke.
The reason to remove this redirect is obvious, however, the reason to keep the redirect is less obvious-- and I assume the same as why the software creates it. When someone moves a page, people accessing the old page receive what's called a 301 redirect. This is considered a "permanent" redirect, and search engines are very sensitive to it. Whenever Google (or other search engines) encounter a 301 redirect, they pretty much delete all information on the old url and transfer it to the new url. Google loves this site, and it happens to pick up on these changes very quickly. In the Sicily example above, Google could have registered that change in a matter of minutes.
For the sake of argument, let's say that Google did notice the Sicily change in a matter of minutes, and let's say that it was at some point after this that someone noticed this and reverted the change. If that redirect has been deleted, then the original page will become lost to Google. In fact, if it's not redirected back, people who get to our site by googling "Sicily" will actually end up on the "SiciZOMGthe Lulz" page! It will take a long time for Google to re-calculate the page rank for these two pages and fix itself. This opens up a huge can of worms for spammers. I take 50 of the biggest pages on this site and redirect them to a different page. They all get reverted, most before google redirects them, but not all. I then take these stub pages and add some text about visiting my awesome spam / malware site. Now, when people get here from Google, instead of seeing content about a destination, they see an ad for my site.
My basic point is that the redirects are there for a purpose. Is there anything that I'm missing here? —Unsigned comment by IB-Dick (talk • contribs) .
Forgive me for being crude, but most cases involve pages being moved to something like "Real person's name"'s giant ¢@#$ is stretched by "racial epithet"'s massive cock" or "Racial epithets" or "someone's real name" should be killed and mutilated". We already delete these as a matter of policy, and almost always do so within seconds of the vandal's move; we're just asking you to help make the job easier. --PeterTalk 18:38, 22 February 2010 (EST)
I'm not familiar enough with google's crawling to make an informed comment on that, but the end result is the same, since we already delete those redirects manually, and it doesn't seem to have hurt us thus far, even though our major articles are the prime target. Regarding the spam trick, that won't work, since the page containing any spam will be deleted during the clean up. sertmann 18:36, 22 February 2010 (EST)
IB really need to decide whether they are getting involved with site policy here. From what they have said in the past, there is a separation between the owners of the site and the community. The owners run the servers, and get the adsense revenue. The community contribute to the site, decide what articles are here, and own the content.
We have well established community policies as to when we keep a redirect, and when we do not. They are established, well discussed, and administered by the Wikitravel community. We delete redirects when they do not conform with the policy, and keep them when they do.
We are asking the owners of the site to implement a tool to make administering the already determined community policy easier. If IB want to get involved in developing the policy as to whether and where redirects should be kept, they should firstly be upfront in saying that they are now getting involved in community policy, and secondly they should do it in the correct policy forums, and not in tech requests. --Inas 20:20, 22 February 2010 (EST)
Oh, and I just ran a quick test on a couple of redirect pages - and it doesn't appear to return a 301 at all. Are you sure that is how it is configured? --Inas 21:10, 22 February 2010 (EST)
Never attribute to malice what can be explained by sheer cluelessness, a quantity that IB is well known to exhibit in spades. Jpatokal 03:01, 20 March 2010 (EDT)
Indeed, all redirects on this site return a 200 OK response, not a 301 Moved Permanently. So far as I know, 301s aren't even available as a standard MediaWiki feature, and would have to be edited into the code by hand. — D. Guillaime 02:05, 21 May 2010 (EDT)
No, MW does return 301s internally -- try eg.
curl -v http://wikitravel.org/en/Main%20Page
(note use of %20 for space) and see what happens. Jpatokal 08:28, 24 May 2010 (EDT)
But that's a different situation than what this request is about. Mediawiki redirects have no 301 intermediate, e.g.
We are working on getting captcha registration enabled for you. Will let you know when it's done. Unfortunately we cannot enable the revert auto delete. However we will continue to look for solutions on how to get spam managed properly. Thanks, Ibsteph 9:53 am, 12 July, 2010 (PST)
There's some urgency to this, as we're getting a round of move vandalism daily right now, which only gets caught some 60-100 pages into it each time.
To provide a sense of why this tech is necessary, the vandal tonight spent 30 minutes move-vandalizing 100 pages. It took me 25 minutes to revert all the moves and then delete the newly created redirects. That's in spite of sysop privileges + intimate knowledge of how to clean up this type of vandalism most efficiently.
The most basic element of good site architecture on a wiki is that it should take significantly more time and effort to damage the site than to repair it. Unfortunately, this is not the case. A more savvy vandal could actually do the damage in the exact same amount of time it takes a sysop to clean it up (and that's only if the sysop actually knows how to clean it up most efficiently).
In sum, this isn't as significant to the site as the high-value form-based listings editor, but it is more urgent, and I hope someone has at least noticed this request. --PeterTalk 23:20, 27 March 2008 (EDT)
I noticed this request and I'll pass it to tech. You've made a good case here, and I'll check back with you on it. JuCo 15:15, 28 March 2008 (EDT)
JuCo, what did they say? – cacahuatetalk 02:12, 28 June 2008 (EDT)
Thanks for checking back in Cacahuate. I need to investigate where tech is with this and then I'll let you know. JuCo 21:04, 30 June 2008 (EDT)
The latest update has more or less given us this feature (although I'd still prefer that the checkbox for preserving the redirect be unchecked by default). But, especially as move vandalism is less of a problem nowadays, as moving pages is restricted to auto-confirmed users, I think this can be closed. --PeterTalk 14:19, 12 June 2012 (EDT)