FabulousEntertainment

Up to now the main focus on my SEO has simply been to get Fab Swingers out of the infamous Google sandbox and build some PageRank and authority for the site. This is now done and the site is coming up quite high on very competitive terms.

So the time has come to look at some on-page SEO. The most important page on a site is the homepage and there were a few things I hadn’t done a very good job of.

First off the title was Fab Swingers: Totally free swinging site for USA and UK which I’ve now changed to UK Swingers, Irish Swingers, 100% free swinging site. For my core UK market, “UK swingers” is definitely the main term to target, even in my present position on page 2 of Google I’m getting hundreds of visitors from it.

Ireland is the country I’m doing next best in and “Irish swingers” seems to have the highest swinging-related volume in that country.

Finally a lot of people do search for “swinging” but much less than go for “swingers” (which is of course why I called the site Fab Swingers rather than Fab Swinging) so I’ve got swinging and free into the title too. (One of my friends says that marketing is all about free, new or sex!)

The H1 title I’ve changed from Fabulous Swingers in UK and USA to Free UK Swingers, Irish Swingers. I’m afraid that no one is gong to be looking for “fabulous swingers” so I’ve just gone for my top two terms. ‘Free’ is in there largely for the human readers — it’s way too easy to focus so much on SEO that you forget about the most important visitors to the site!

I’ve also changed the meta description from “Fab Swingers is a Fun, Free and Fabulous Adult Dating for USA, UK, Australia, Canada, Ireland and New Zealand.” to “Fab Swingers is the largest completely free swingers site for UK, Ireland, USA, Canada, Australia, New Zealand”. My aim with the description tag is to increase the number of people who click on the link so this description will get chopped off at the end but hopefully it emphasises the size of the site and the free aspect.

I’m estimating search volume for “uk swingers” at about 90,000 a month across all search engines so by getting high on page one of Google we should be getting exposure to about 67,500 people and perhaps 10,000 clicks. If I can achieve a 20% conversion rate then that’s about 2,000 new members a month — conversion rates for free sites are very high! For “Irish swingers” I expect that to come in at just under 10% of the “uk swingers” numbers.

For sometime we’ve needed to implement logging of what’s going on in the chatroom so that we’re able to respond to complaints.

The chatroom software does have an option to dump an archive of the chat every 5 minutes to a method but it is provided in XML so I needed to write a basic parser to convert this to a simple log format. I thought that this would take about 20 minutes but it’s ended up taking up all of an evening and a lot of the night!

I started trying to use Python’s minidom parser but even with help from the excellent Dive Into Python I was struggling.

However after a bit of reading around the web I decided that the sax ContentHandler was a much better option in terms of performance and in coding too so I’ve written a simple handler and it seems to be working fine now.

The site has got to the size where we do need to make a bit more effort in managing the chatroom so I will try to implement video, blocking and banning too in between the work to improve performance.

The good news is that Fab Swingers is really taking off in a huge way with our page views increasing by a million a month (for the last 3 months and for this month too by the look of it so far) and hits are increasing by between 3 million and 5 million a month (hits are useless as a measure of popularity but VERY useful as a measure of server load).

The first problem I have is that I’m about to be thrown off the free Google Analytics as you’re only allowed 5 million page views a month unless you are an AdSense customer. I’ll probably just run a fairly minimal campaign.

The second problem is that Python is really hogging the CPU (Apache and MySQL are fine). On a bit of investigation this is mainly down to SQLObject. SQLObject is an absolutely brilliant piece of software but it’s really only a problem when you’re trying to wring every last drop of performance out of your system. In virtually any environment the programmer productivity benefit would trump the need to beef up the hardware but in the case of Fab Swingers with our tiny ARPU we really need to be at the Plenty of Fish performance levels.

I also think that it would help a lot if I could deploy CherryPy through mod_python rather than using mod_rewrite but I think I’d like to do this after fixing the SQL.

Unfortunately I’m just so short of time at the moment that I’m really not sure I’m going to get a chance to do much work on the site. I think I’ve got about another 2 months to get the performance improved otherwise I’m going to have to throw some hardware at it — which I’m really not keen to do right now.

Aside from the performance I think I’m also going to be bitten on the arse because I’m not very good at handling bouncing email. This needs to be done automatically, if we continue to send email to duff addresses we’ll end up being black listed.

I guess it is a positive that the last few blog posts have been whines about coping with the extra load rather than worries about generating the traffic — I guess this is a good problem to have!

Yesterday I decided to change the Apache Multiprocessing Module (MPM) from prefork to pthread. The pthread module performs much better (although I only suffer Apache performance problems when I bump up against the MaxClients settings).

Upgrading was easy, all I needed to do was apt-get install apache2-mpm-perchild and it all seemed fine. Unfortunately on testing it turned out that the forums weren’t working because the PHP module had been removed.

I dug into it and in the view of the Debian packagers (who are usually right!) PHP4 has problems with the pthread MPM. So for now I’ve decided to go back to the old prefork MPM.

In the future when I have a dedicated image web server I’ll make sure that it is using the fast MPM but I guess that for the other server Apache makes so little difference to the performance that it’s just not worth bothering about.

I’m delighted to say that we’re now on page 2 of both Google.com (results 15) and Google.co.uk (result 18) for swingers UK. This is another 4 places forward which is good progress for the site as it’s a relatively competitive term.

The traffic we’re getting isn’t huge though, we’ll need to be on page 1 before we see significant sign-ups.

I don’t think there’s any single reason for this progress; I suspect it’s a whole lot of factors including our low bounce rates, high traffic, increased inbound links, 10 year domain registration period, constant increases in the site content and internal links.

I guess that I really should do some other SEO too, I’d like to see some progress on Irish swingers. The Irish side of the site has been doing really well and the Alexa rank in Ireland is higher than the UK ranking too!

It’s been quite a while since I’ve done the benchmarking. Here’s the table updated:

I guess the news this time is that Swinging Heaven continues its gentle decline and it looks like Google’s web spam team have implemented a new algorithm which has brought down a lot of the PageRanks.

Fab Swingers has now moved up one place in the table and based on our weekly averages I think we will have moved up another place by the time I next get round to doing the benchmarking.

Although I’ve absolutely loved working with SQLObject I’m afraid that the time has come to switch to hand-crafted SQL.

On some of my browse pages I’ve now managed to move from 420 ms to 160 ms by using the Python DBI directly. For the vast majority of applications a 260 ms speed up would not make any difference but for Fab Swingers it is absolutely essential. In fact, 160 ms is still not really fast enough for me but it’s another good step in the right direction.

In addition I’ve switched from accessing MySQL via the network to accessing through the Unix socket (mysql.sock). I’ve not been able to measure a significant improvement but looking at the MySQL Performance Blog it does seem to be a good idea and just from a common-sense point of view it makes sense to go directly to the database without going through the network interface.