Should redirects be collapsed with a background robot to reduce server load?

Question

@Dennis Wheeler wrote in another question's comment:

• the more lookups (redirects), the more strain it  puts on our own server. so we want to minimize duplicates, in order to minimize the number of redirects.

To which @Paula J added:

• Here is a quote from the protecting and merging help page:
  • "Google won't follow more than three or four redirects in a chain."

Therefore, it seems a tool should be created to periodically scan our database and look for redirects to pages that are themselves redirects and automatically edit the first redirect to instead redirect to the target of its redirect.  Over time this would result in chains being removed and pages redirecting to the final target page.

Comments

reference to other question: https://www.wikitree.com/g2g/486652/should-we-recover-lower-number-for-surname

Answer 1

Strongly support

todays approach always merging to lowest number doesnt work if someone is starting to change surname.

Ex. A-12 and A-14 is same person
A-14 is merged to A-12 and A-14 gets a redirect to A-12

Someone thinks A is the wrong surname and change to B ==>

1. A-12 gets a redirect to B-1
2. A-14- redirects to A-12 that redirects to B-1

Someone thinks A is the correct name and change B-1 to A-15

1. B-1 gets a redirect to A-15
2. A-12 has a redirect to B-1 that redirects to A-15
3. A-14 redirects to A-12 that redirects to A-15

Its a mess and it needs to be cleaned plus the merge code should fix this directly when merging..... I think we have been speaking about this for more than 2 years

    

Comments

I have created an analysis of the problem: https://www.wikitree.com/wiki/Space:WikiTree_redirection_efficiency

---

I approve for what it counts. LOL It doesn't even have to be run monthly. It could just be run in the background as a low priority system. That way if the server load increases it will suspend it. And if it is run ON the server itself it uses processor power but no bandwidth.

---

Thanks Roger, great write up!

Answer 2

But part of the problem is, there are still references to the original ID link (such as in the change log to show merges).

And anyone deep linking to an old url would get a broken link, instead of a redirect.

Comments

I don't have access to the code, so my comments on the matter may be a bit incomplete or even inaccurate, but I do understand how the process works in general.

---

I'm not following what you are describing as an issue.  The original ID would redirect still, just edited to point to a later ID in the chain.  Don't see how that would break a link?

---

you're right... there could possibly be some cleanup of the long multiple chains. but it could make following the change history more difficult.

---

I think the point is some of these chains may be 5, 6, 7 or more redirects long. Google may only do 3 redirects before considering it an invalid link. That means people linking to the beginning of the chain will no longer be able to get to the profile. Now the suggestion of if you redirect to a link that has a redirect, if the first goes to the second which goes to the third then you change the first to go to the third. Now it does it in one jump.

This will not "eliminate" redirects but what it will do is limit it to 1 redirect only. So a goes to b which goes to c which goes to d. If it is shown a goes to b which goes to c, switch it to a goes to c and b goes to c. Now a goes to c which goes to d. Switch a goes to d, then b and c will also go directly to d. This will cut down on chains, eliminate multiple redirects which end up sending an invalid response, and keep all the url links to the old profiles still valid.

This would run in the background and eventually reduce server time during searches. I also wonder if there might be a flag added so the suggestion reports won't bother searching the redirects but only the end target.