lucy24 - 5:15 am on Jan 29, 2013 (gmt 0)
For redirects, use a header checker tool to follow the redirects back. Sometimes you will uncover years of nested redirects, as pages have moved with tons of trusted aged backlinks. To do this, run the your redirects through a bulk header checker, such as the one provided by XXXXXX or one of the many others that are on the web. If you find that some are nested, rerun this data until you get to the original page. Once you've tracked all the redirects back to their original page, run the list through a backlink checker, just as if you were checking for backlinks on 400/500 level pages.
I absolutely love the mental image this creates.
Move or rename a page, redirect it. Check.
A year or two later, move or rename again, redirect again. Check.
Later still, more of the same.
And each time you're redirecting only from the most recent URL to the current one. So people with elderly bookmarks-- and robots with long memories-- end up with
www.example.com/url-from-1998.html >> 301 to
www.example.com/url-from-1999.html >> 301 to
www.example.com/same-url-but-you-changed-your-extensions-in-2001.php >> 301 to
www.example.com/url-from-2004.php >> 301 to
www.example.com/url-from-2006.php >> 301 to
www.example.com/same-url-but-you-decided-to-go-extensionless-in-2007 >> 301 to
... and so on :)
I think that's what they're really saying. Much easier to prevent ahead of time than to find and fix afterward. Every time you add a redirect, look carefully at all your existing redirects and update anything that will also be affected by the newer redirect.
Which is why I've got
/fun/font_input.html (don't ask!)
both redirecting to
/fonts/font_input.html And don't tell me to give everything a better name. The bingbot is still eating 410s from two years ago when I went through Round 1 of name improvements.