|
The SEO way to safely redirect a Page or folder using 301 redirects |
||||||||
In a recent project we are restructuring a site to be more intuitively architected. But what impact will moving the directories or pages have on all that hard earned Search Engine Ranking Optimisation work?
This article deals with how to safely redirect users from an old page or folder to the new URL, and keep Search Engine's informed of your changes without leading them to dead content (Dead content is bad and will adversely affect your Site rankings).
The most Search engine friendly way to redirect a user from an old page to a new one is using a 301 redirect. Search engines (Google in particular) will 'hard' remember the 301 redirect when they crawl your site. They will actually update their indexes with them, rather than 302 redirects (Moved Temporarily) which they will simply follow.
301 Redirects are handled on the server side, so a user's browser will never actually hit the old URL, meaning that all your analytics and tracking will naturally report on the new redirected URL.
I am using a few different technologies, so I thought I'd work out the best way to implement 301 redirects in each of them.
Isapi ReWrite
Isapi ReWrite is a URL re writing engine that uses Regular Expressions to create more interesting URL's http://www.isapirewrite.com/
The first example will redirect an entire domain (mysite.com to www.mysite.com).
2RewriteRule (.*) http\://www\.mysite\.com$1 [I,RP]
The next example will redirect specific page URL's:
I wont go into the specifics here, but the site link above has extensive documentation.
IIS
Using Internet Information Services it is possible to do this at a server level.
- In internet services manager, right click on the file or folder you wish to redirect
- Select the radio titled 'a redirection to a URL'
- Enter the redirection page
- Check 'The exact url entered above' and the 'A permanent redirection for this resource'
- Click on 'Apply'
Coldfusion
You could also do this in code, I guess either in your default document, or in the 'application.cfm' file.
2<cfheader name="Location" value="http://www.mynewdomain.com">
This feels a bit more like a hack to me, and I think this sits squarely in the servers remit, so I think I'm going to use IIS to handle all my 301 redirects.
You can test your redirects online with various tools, one that I have always found accurate is here: http://www.webconfs.com/redirect-check.php
That said, I think have redirects at any of the levels is valid. I am not sure that one holds more benefit over the other. The closer you get to the ColdFusion layer, they more dynamic it can get. For example, we had one product-based site where we changed the URLs and we had the old ones stored in the database. When the Search Engine (or whoever) hit an OLD url, we had to look it up and 301 redirect to the new one. Not something we could have done at a higher level without hard-coding a vast number rules.
That said, the higher you go - IIS / mod-rewrite, the faster the performance is probably (in a small way) and the less your CF code would need to know about it.
All in all, I think all of these approaches is equally valid with different "Sweet spots" and levels of "debug-ability."
I've thought of doing something similar involving dynamically writing the Isapi rewrite file, but haven't got that far into it yet.
It would be interesting to see if there are any performance variations. I may have to write some tests :-)
I can tell you with the project we worked on, the issue was not so much getting the BAD urls - that was no more than a matter of parsing out the ID (ex. 143):
/products/some-product-name-143.htm
... the hard part was generating the appropriate URL for the redirect (ex.):
/products/some-category/new-product-name-143.htm
That's *really* the thing we were looking up in the database. Once we had the 143 it was a matter of looking up the product name and potentially a category and then generating the "real" URL.
But again, each problem requires it's own set of unique circumstances. This kind of config file could definitely be generated - nothing too tricky going on. If it's a performance issue - now that is curios.