I have been performing SEO optimization here at Spazstik Software. Up until recently I have had multiple sites that represented my web presence. My main site is http://www.spazstik-software.com. I also have a blog that had two domains: http://www.rodgerhiggins.com, and http://www.spazstik.com. A shortcut domain for my main site http://www.spazsoft.com. And finally I have the domain/landing page for our StackCalc iPhone application http://www.stackcalc.com. All of these domains also have the variance of the 'www' or no 'www'.
I use hover.com for all of these domains. The main http://www.spazstik-software.com is hosted on Amazon Web Services and I was using Amazon's Route 53 to perform the domain service for only the http://www.spazstik-software.com site.
All other domains were using hover.com's domain forwarding feature. This service only performs a 302 redirect. The short of this is that the 302 redirects caused canonical errors when I transitioned to my current web site and in turn was hindering my search engine cheddar.
If you review the http status codes rfc the 302 http response code is labelled as "Found." The description for this response is that the requested resource is temporarily found under a different URI. Which you can imagine will cause google's search engine to not perform any extensive updates. The recommended process for moving your content is to issue a 301 redirect. This indicates that the content has permanently moved over to a new URI. This is what I needed to do.
Hover.com unfortunately only supports domain forwarding using 302 redirects. This required me to come up with a different solution. The solution that I settled on was to move the domain services over to AWS Route 53, route all domains to my web server, and configure the server to issue the 301 redirects.
My web site is a Ruby on Rails application deployed on AWS Elastic Beanstalk. Rails offers a couple of solutions. One solution is to create a before filter in the application controller file and use the standard redirect to statement to perform the redirects. However, the better solution is to configure the rack middleware stack to perform the redirects at a low level. This offers the advantage of requiring less processing on the server then the first solution.
If you are not familiar with Rack I recommend checking out the podcasts, listed below, at the RailsCasts. Ryan Bates has done a excellent walkthrough of the rack middleware stack. Just be aware that some of the episodes require a subscription (well worth the price).
I decided to use the rack-rewrite gem. This gem provides a Rack::Rewrite class that can be inserted into your applications middleware stack along with helper methods for performing your redirects or rewrites.
You can use this gem in a couple of ways. You could add it to your config.ru file, or from your rails application. I chose the latter. This is shown above. To do this you need to call config.middleware.insert_before. The example shows that it is inserting the Rack::Rewrite object into the middleware stack before the Rack::Lock layer.
In a production deployment the rack middleware starts with a Rack::Cache layer followed by the Rack::Lock layer. In a development deployment the rack middleware starts with an ActionDispatch::Static layer followed by the Rack::Lock layer. So inserting before the Rack:Lock layer is consistent between both environments.
The first set of r301 rules force redirects to the specific landing page for the StackCalc application, both with and without the 'www'. The second set of r301 rules force redirects from the spazsoft domains to www.spazstik-software.com domain. These include passing the path to the new site so http://spazsoft.com/about to redirected to http://www.spazstik-software.com/about.
I use Pow in my development environment to test this configuration. I have a link in the .pow directory for each domain that I need to support (I use the same rails project directory for each domain). The only difference is that I need to use .dev as opposed to .com in my urls.
One thing to avoid is using page caching. Page caching happens at the web server level (a lower level). For example, at the Apache/nginx level. The web servers will intercept the request before the redirects if it finds a static copy of your page in your application public directory and respond with that file, but with the wrong domain. If you need web caching, you will probably need to configure rewrites in your web server configuration files.
In my case where I am using AWS Elastic Beanstalk which uses the nginx web server, this option is not available. Using the rails expire caching methods are still available to you. So In my opinion you lose very little.
- Amazon Web Services
- Amazon Route 53
- http status codes rfc
- Ruby on Rails
- RailsCasts Episode #319 Rails Middleware Walkthrough subscription required.
- RailsCasts Episode #317 Rack App from Scratch subscription required.
- RailsCasts Episode #151 Rack Middleware
- Rack: a Ruby Webserver Interface
- Pow: A Zero Config Rack Server
- AWS Elastic Beanstalk