Restructuring/Removing 301 Redirects Due To Newly Optimized Keywords

[LogicalMediaGroup]

Just to be clear, this is for one unique page on a website.  Also, please see my diagram attached.

Let's say that a page's URL was originally /original.  So, you optimize the page for a new keyword (keyword 1), and therefore change the URL to /keyword-1.  A 301 redirect would then be placed...

• /original > /keyword-1

However, let's say 6 months down the road you realize that the keyword you optimized the page for (keyword 1) just isn't working.  You research for a new keyword, and come up with (keyword 2).  So, you'd like to rename the page's URL to /keyword-2.

After placing a redirect from the current page (keyword 1) to the 'now' new page (keyword 2), it would look like this...

• /original > /keyword-1 > /keyword-2

We know that making a server go through more than one redirect slows the server load time, and even more 'link-juice' is lost in translation.

Because of this, would it make sense to remove the original redirect and instead place redirects like this?

1. /original > /keyword-2
2. /keyword-1 > /keyword-2

To me, this would make the most sense for preserving SEO.  However, I've read that removing 301 redirects can cause user issues due to browsers caching the now 'removed' redirect.  Even if this is ideal for SEO, could it be more work than it's worth?

Does anyone have any experience/input on this?  If so, I greatly appreciate your time!

oDvLl.jpg

[LogicalMediaGroup]

Hi Corey,

I appreciate the you taking the time to read through our questions and provide some insight.  Thanks for all of your help!

P.S. we're also from Chicago.  So if I see you out and about, remind me that I owe you a brew.

Thanks,

Drew and the rest of the Logical Media Group team

[CoreyNorthcutt]

Sure, the chaining redirects thing is something that Matt Cutts has talked about, I think in a few videos.  I'm blessed with the ability to actually test/observe this stuff on loads of major sites that are in production as well, which is always the ultimate bit of validation on an SEO theory.  Every now and again even Google will give advice that is flat out wrong, and for the most part, the SEO community will repeat it again and again as it's lore.

As for extracting headers, I have some back-end automation that I've written.  Here's a nice little free tool that lets you see a single page though:

http://www.northcutt.com/tools/free-seo-tools/http-header-viewer/

If you have a chain of redirects occurring on a page, it will show.  Sometimes this is necessary, especially if you have them flying in from all over (ie. in the application, in your .htaccess, in the Apache config files).  It always helps to test; I've surprised a few clients with this one.  

[LogicalMediaGroup]

Hi Corey,

Thanks for taking the time to read through this and provide a response!

I'm happy to hear that you think the latter is indeed a better method.  You say that chaining redirects causes other issues as well.  Do you mind elaborating on this?  I just watched a Matt Cutts video and he does confirm that you should avoid chaining too many redirects because Googlebot could actually stop following them at some point (sounds like around 4 or 5).

It's also interesting to hear that you mine for this situation during your auditing process.  Do you do this by looking through the .htaccess file or is there a tool you use?

Thanks again for taking the time to help us out with this!  Any additional feedback is greatly appreciated!

Thanks,

The Logical Media Group Team

[CoreyNorthcutt]

Well, first of all, you can't use a keyword as your TLD.  

I think I see what you're getting at though.  No, don't ever chain redirects; part of my auditing process in fact involves mining for that exact thing, because it causes other issues.  Instead of:

/originalUrl.php -> /secondTry.php -> /thirdTry.php

Do:

/originalUrl.php -> /thirdTry.php
/secondTry.php -> /thirdTry.php

I'd also add, at least half of the SEO blogs that I've read over the years are provably wrong in one way or another.  But I think I see what that person was getting at too.  301 redirects do sometimes get cached, because a 301 redirect is supposed to be a permanent redirect (unlike a 302 redirect).  That doesn't mean that you can't change it though.

In the scenario that they described, they said that they would not just remove the redirect and expect everything to return to normal.  It was a 'permanent' redirect.  It needs to be 'permanently' directed back to definitely be undone where actually possible.

Good luck.