My company Onomojo, http://onomojo.com , is searching for a few quality Rails developers to bring onto our team. You need to have some experience under your belt and have urls to show for yourself. You must develop on a Mac or Linux. Windows users need not apply. This is a telecommute position but ideally you’d be located either in Hawaii or North Carolina. If you’re interested, please send your desired salary, date you can start, and your resume to hr at onomojo dot com

I’ve been planning out a content management system in Ruby on Rails for a while now and will be releasing a beta version in the next few weeks. I’m calling the project Rojo. There are quite a few CMSs out there for PHP already and they’re quite mature at this point but the ones I’ve seen for Rails are pretty pathetic to say the least. They’re all really limited in functionality and lack modularity so they’re not always the easiest to extend.

My company, Onomojo, does a decent amount of Ruby on Rails development and have been working on building a solid CMS that’s modular, easily extended, and easily customized. The project itself is coming along nicely. I’ve taken concepts that I like from different content management systems that I’ve used over the past decade and combined them in a way that helps minimize the effort involved in developing Rails sites for our clients. I’m pretty excited about it and I’ll be releasing the core code and the plugin code to the public after we get a few pieces developed so stay tuned for more on Rojo.

I was recently working on improving the search engine rankings of a site with lots of user generated content and noticed that users were creating 404s through bad links. The users were able to add links to other sites in their comments and such but sometimes the links were bad. Sometimes they were even local links so the search engines were effectively seeing a bunch of internal 404s from the user generated content. This was essentially defeating any seo being done elsewhere on the site and needed to be fixed quickly. My original idea was to use hpricot to scrub all the anchor tags and append a rel=”nofollow” tag to them all. I was mulling over how to write the hpricot parsing code when I found the Sanitize gem. It does exactly what I needed and saved me the hassle of writing the hpricot parsing code. The gist of it is:

As an added bonus, it also can scrub out unwanted script tags and more. Now, the site won’t be nicked for having internal 404s from the user generated content since they’ll all have rel=”nofollow” on them.

It’s been a long time coming but we’ve finally published our redesign of the Webster’s Classroom site. Webster’s Classroom helps teachers make classroom websites. We’ve also incorporated a new school site feature which will allow schools to take advantage of the features offered with Webster’s Classroom and get their entire school online. Its a service site offering school website design through my web development company, Onomojo. Check it out and tell your teacher friends about this great free tool.

The short answer is yes. Older domains get ranked better than newer domains. Its minor though and if it changes hands along the way the effect is minimized. Search engines aren’t stupid and just having a long lived domain name isn’t likely to make much of an impact on rankings unless there is some relevant content on the domain during that time. If its not used and not ranked and then you buy it, you won’t likely get too much benefit from better rankings simply because the domain is old.

It is known that the age of a domain does influence rankings but changing hands through purchasing a domain is likely to eliminate whatever minor effect that has. So the long answer is no. Older domains don’t really influence rankings as much as people like to think because you have to purchase older domains from squatters which means it changes hands. If you bought a domain years ago and tossed up a simple landing page or mini site and now you want to revisit that domain and develop it then yes it will have an advantage since you owned it for a while.

I recently got asked by a client which top level domain he should pick. His first .com choice was taken so his second pick was a .me domain. I’ve been asked this a few times so I felt I should clear up any confusion.

The only top level domains that have an influence on rankings are .edu and .gov. I have not read anything that contradicts that. The only thing I can think of that would possibly make me want to pick a .com over a .me domain would be purely from a user’s perspective and not SEO related. I think more people are willing to trust a .com or .net domain than a .me , a .biz , or another less obscure top level domain. Other than individual perception of the top level domain, there is no effect on rankings.

Many sites go through redesigns and in the process URLs change. In particular, most sites we redesign we attempt to use pretty urls that contain keywords for the page. The keywords end up bold in search results if they are in the search terms. The thinking is that the bolding of the keywords increases your CTR on search results. The problem comes when you try to figure out what to do with a site that is already ranked well and you are switching over to pretty urls. The question is whether you should let the old urls just 404 or should you go through and make 301 redirects to the new pretty urls. Here are my thoughts on it:

The search engines will see the 301 redirects and start to modify their index with the new urls. The entire site won’t be reindexed at once so for a period of time it will still think that there are current pages on the site linking to urls that then do a 301. This will negatively impact rankings. How much impact is difficult to say. As the entire site is eventually reindexed the search engines will see that the site no longer links to the old urls and the site won’t be negatively impacted. I’m guessing it’ll take 3 months to remove any negative impact. Its just an educated guess though.

The 301 redirects will also have a positive impact on rankings in that the urls will contain the relevant keywords. As the site is gradually reindexed, the search engines will start to see that there is a navigational importance to the keywords used in the links on the site. It will boost the effect of those keywords and improve how the search engines interpret the site’s internal linking structure. As a result, it will have a positive impact.

Once the site is completely reindexed and the negative impact from the 301 redirects is negligible the site will ultimate have better ranking potential than before the change since the internal linking structure has been given more weight to keywords in navigational structure.

This is all known and predictable. What we can’t be sure of is if the weight of the positive impact will balance the weight of the negative impact in the short term while the site is being reindexed. From my experience, I expect rankings to slide initially and over a three month period regain and surpass the original rankings.

If you simply ignore the current site urls and just do 404s, the search engines will start to reindex your site but will also register a bunch of 404s. This is probably going to give you a much more negative impact than you’ll get from the small decline you’ll get from doing 301s. I strongly advise doing 301 redirects and to remember that your rankings will likely drop slightly but will ultimately recover and exceed where they were before (that’s assuming there wasn’t any changes in the redesign itself that negatively effects your rankings).

I don’t think its necessary to go into the benefits of adding a blog to help market your site. Its widely accepted as an easy way to add new keyword rich pages and help out rankings. There are some questions about whether an off-site blog or an on-site blog is better for rankings. When I’m referring to an on-site blog, I’m assuming its going to be integrated into the main site we’re promoting. An off-site blog might be with a blogging service like Blogger or something similar. The off-site blog will link out to the main site we’re marketing. The thinking is that that off-site blog will generate more rankings potential for the main site because it will be a valuable incoming link to the main site. While that may be true to some extent I still prefer on-site blogs.

An off-site blog may have ranking benefits by having externals links from another site into your main site but the off-site blog will require its own link building campaign independent of the main site so it can get ranked on its own. I’m not sure its a good use of resources to have 2 link building campaigns: one for the blog and one for the mian site. One benefit of an on-site blog would be that we can use the blog pages as potential landing pages for Adwords and other PPC marketing (sure we can do that with an off-site blog but it would require another click before they get to your main site). I think you could write your on-site blog posts in a way that would make the main site an informational resource for its theme. I think the SEO benefit would be better as a
result.

Keep in mind that Google hires teams of people to visit every site in their search index and rate them. The purpose is to improve the quality of search results and get spammy looking sites out of top rankings. I believe there are so many spammy looking blogs out there that just link out to other sites that their effect is decreasing over time as a result of this manual rating. The blogs like this are labeled as thin sites and devalued in ranking once they are reviewed. I think its better to focus on getting blog content on-site that makes your main site look more like an information resource. I would shy away from the traditional blog look and feel and try to make it look more like a rich resource of information about issues related to the topic. When it gets manually reviewed, you’ll more likely get a bigger thumbs up than you’d get from a thin off-site blog.

Of course this is all just an educated guess at best so take it all with a grain of salt.

I build a lot of Rails apps on a regular basis and each one I add to my server takes another bite out of my limited resources. The way I’ve traditionally setup a new Rails app was using a Mongrel cluster. I found it to be a lot more reliable and faster than the fcgi approach people use to use (and some still do). The downside to setting up a few dozen Rails apps on your server with each running a Mongrel cluster is that it eats up all your memory. One of my sites is starting to get a lot more traffic than it has been in the past and its putting additional strain on the server. As a result I decided to find an alternative to Mongrel. I’ve tried searching for alternatives in the past but everything sent me back to Mongrel. Until today of course when I came across Jamie Flournoy’s blog about mod_rails.

Excited for an alternative to raising a pack of resource hungry mongrels on my server I installed the gem and tried it out. It was exactly what I was looking for as far as ease of use straight away. All I needed to do was stop a mongrel cluster and simplify its virtual host directive in Apache to leave out the mod_proxy_rewrite and the other wonky rewrite rules. The first app I tested went smoothly but suddenly the server started misbehaving. Resources were being eaten and it wasn’t clear what was doing it because the app I was testing with is behind an Apache password and I’m the only user. I ended up having to turn off the mod_rails to get my system back in control. The problem turned out to be that by default mod_rails tries to test if your virtual host directory is a rails app or not. I have a few apps that I tossed in an instance of Wordpress into a blog directory inside my rails app directory. I found it convenient to toss them all into the same directory since its all the same website. As a result mod_rails was doing a ../ check to see if the blog directory was a rails app which it decided it was. That’s where the craziness came in because its a php application. Anyway, the quick solution was to move the blog directory out of the Rails app directory.

Other than that my memory usage is way down. I’ve migrated all my low traffic sites to mod_rails and I’m happy with how they’re performing. There is a little delay on the initial load of the app but subsequent calls are quick because its already loaded. I can wait an extra 2-5 seconds for my low traffic apps to load in exchange for hundreds of extra megs of free memory.

I haven’t moved over my higher traffic money making sites yet and I’m not entirely sure I will until I’ve tested mod_rails a bit more. I’m extremely happy with the results thus far though.

Rails page caching is pretty simple to get working usually. If you’re new to caching in Rails, there’s plenty of good tutorials out there to get you up and running in no time like this one from Rails Envy. Rails is a resource hog and on my servers I’ve got about two dozen apps running. Combined they use up most of my memory and on peek hours can push the server to the brink of disaster so caching is extremely important to keeping things under control. The last thing I feel like doing is having to offload some apps to another server. I’ve used fragment and action caching with great success but wanted to use page caching on a new app I am building. The problem I have been having was that the pages were being cached properly but Apache wasn’t serving them up. I tried a whole slew of different tweaks to my Apache configuration before finally finding the problem. I found the problem by including the following in my Apache configuration:

Using that debug information I was able to toy with the rewrite settings that were suggested by the many tutorials out there and find the problem. Most Rails page caching posts I found that used Apache and mongrel_cluster had a suggested rewrite configuration like this:

Now, this may be specific to my Apache configuration but what I found was that the rules weren’t rewriting to the correct urls. They were missing / and ending up relative. The way I fixed it was pretty trivial but took me some time to discover so I figured I post it. The solution ended up being like this:

I added some preceding /’s and removed the / after cache on the second rule since the $1 got translated with the /. This modified configuration got my page caching working properly.