Well, we've studied a lot of SEO (for other sites) and didn't intend really for bug.gd to be that kind of a "content" site initially. I think we need to revisit this, though, so your pointers are quite valid. We got an incredible amount of traffic last year when we were covered on TechCrunch and other sites, but that settles-down after the initial fanfare.
We've prototyped some text classification mechanisms to try to pinpoint the product/category from the error message, but I think we're going to wait until we get more of our embeddable libraries released (that could be included in specific products), our planned Dr. Watson replacement available, and maybe some subsites for particular technologies (e.g. Ruby and Python error messages).
We'll see what we can do, but high on the ROI list would be getting the solution pages less 'deep' for search engine crawling-- thanks for the advice there.
Keep in mind (or FYI), our revenue model is actually not focused on ads or anything of that nature. We're looking to use bug.gd as an engine/toolset to sell to corporations that want to have more a P2P tech support model to reduce help desk costs. Lots of little ideas for this, but this project was really driven by the need for this in a large enterprise I was formerly involved with. The productivity gains can be impressive when your employees have a collective wisdom when it comes to problems.
Due to this path for the company, the core bug.gd site is really intended just to build up solutions to help everyone while remaining free and ad-free. We think of it as a win-win situation and really want all of our new sites to work that way.
We've prototyped some text classification mechanisms to try to pinpoint the product/category from the error message, but I think we're going to wait until we get more of our embeddable libraries released (that could be included in specific products), our planned Dr. Watson replacement available, and maybe some subsites for particular technologies (e.g. Ruby and Python error messages).
We'll see what we can do, but high on the ROI list would be getting the solution pages less 'deep' for search engine crawling-- thanks for the advice there.
Keep in mind (or FYI), our revenue model is actually not focused on ads or anything of that nature. We're looking to use bug.gd as an engine/toolset to sell to corporations that want to have more a P2P tech support model to reduce help desk costs. Lots of little ideas for this, but this project was really driven by the need for this in a large enterprise I was formerly involved with. The productivity gains can be impressive when your employees have a collective wisdom when it comes to problems.
Due to this path for the company, the core bug.gd site is really intended just to build up solutions to help everyone while remaining free and ad-free. We think of it as a win-win situation and really want all of our new sites to work that way.
Thanks again.