If you earn money from Google’s AdSense or from some other affiliate or internet related source do you declare it? Do you pay tax on your income?

I’m betting a lot of people don’t treat this kind of income as real income and don’t pay any tax on it. If you have a normal day job which you pay tax on, and you just get a ‘pocket money’ income from your blog or website it would be pretty easy to overlook the tax implications (either innocently or deliberately).

Everyone’s tax situation is different, laws are different in different countries, and of course I’m not a tax expert! I can’t therefore say what you should do. I can however say what I do with my blog and website earnings.

I always fill in the HMRC’s self assessment online form (as I’m UK based), which is where I declare the usual bits of income such as salary, interest, and capital gains.

On the ‘Other UK Income’ page I tick the ‘Any other income’ box.

Then on this page I enter the total amount of income I’ve made from AdSense, Amazon referrals, etc. And I put a short description saying that it is income from my hobby websites.

And that is all! This extra income is now factored into the end of year tax calculations, and treated as ordinary untaxed income. I therefore pay ordinary income tax on it. To me this sounds like a sensible way to do it, but I don’t know if it is the official or correct way. It is however declared, and tax has been paid on it, so hopefully the HMRC are happy.

I’ve declared by blogging incomes in this way for quite a number of years, and have never had anyone from the HMRC ask me for more details. I should however point out that my blogging income is very small – less than a thousand pounds each year. If you have a more significant amount of income coming from your websites you should get professional tax advice.

What do you do with your blogging income? Do you declare it and pay tax on it? What method do you use to declare this money? Do you treat your domain name, and web hosting costs as tax deductible? I’d be very interested to hear from anyone else on the same subject.

More »

Here is a comparison of the actual viewing figures for this site (as recorded in Google Analytics), against the values that Alexa reports.

Alexa vs Google Analytics page views

This is a fairly small blog, getting 600-800 page views per day. If you too have a website which is of a similar size you might be interested in just how wrong Alexa’s statistics can be. Here is Alexa’s estimate as to how the number of page views I’m getting has changed in the last three months (snapshots all taken on the 15th July).

Looks pretty amazing right? A 2420% increase in page views in three months. But all is not as it seems. Here are my actual page views from Google Analytics (same three month period). You can see the actual figures show a very gentle increase in page views.

Alexa operates by sampling data from the people who have installed its toolbar, or who have installed (or had installed for them!) some other piece of software which sends data back to Alexa.

The percentage of internet users who have Alexa software on their computers is small so the data is subject to anomalies, especially as the website gets smaller. A large website such as Facebook or MySpace probably gets ok results from Alexa as there will be thousands of people browsing these sitse who have the toolbar installed. But the smaller the site, the bigger the potential for the results reported by Alexa to be out of sync with the actual results.

Alexa vs Google Analytics page views per person

So why the huge reality vs Alexa distortion for my site? I’ll come to that later. Next let’s looks at another graph. This is how Alexa thinks my page views per person is doing.

Pretty impressive! The page views per person has gone from 1-2 all the way up to 30 pages viewed per user. If that were accurate it would mean that people really love reading what I write! But unfortunately my blog isn’t quite that engaging. Here are the real figures. Each of my visitors looks at about 1.3 pages. That figure has remained fairly flat over the last three months.

Alexa vs Google Analytics visitors per country

Here is my final set of figures. This is where Alexa thinks most of my visitors are coming from.

You can see from their figures that they think most (74%) of my visitors are in Japan. It is vaguely plausible as I do have quite a few Japan related postings on this site. However it isn’t accurate. Here are the real figures.

You can see that only 1.4% of my visitors are in Japan. This largest percentage of viewers is actually from the UK (44%), but Alexa only believes that 4.5% of my viewers come from the UK.

So why is Alexa so badly wrong?

What is causing Alexa to be so badly out of sync from reality? I am pretty sure I’ve worked out the reason. I believe that the massive inaccuracies are the result of a single person. Me.

Not on purpose, I did it entirely accidentally. But it is interesting that one person could cause the perceived page views of a 600-800 page per day blog to jump 2420% in three months. It is also interesting that one single person could accidentally cause the Alexa traffic rank to jump from about 600,000 to 200,000 in such a short time. And it is impressive that one single person could cause Alexa to think that 74% of visitors are from Japan when in fact only 1.4% of them are. Also that I could cause the average page views per person to go from 1-2, all the way up to 30ish.

How did I (accidentally) cause Alexa’s figures to be so wrong?

There is one main cause of this massive misreporting of figures. I installed the Quirk SearchStatus extension for Firefox. This extension add some small items to your status bar at the bottom of the browser. They can show the Google PageRank for the web page you are currently on, and they can show the Alexa traffic rank for the website you are on.

But the extension doesn’t silently report the statistics. It actually affects the Alexa traffic rank statistics. As you are browsing where you go will now be recorded by Alexa.

In my case I spend a lot of time on my own blog. It is WordPress blog so I need to access it to put up new posts, edit posts, check posts, moderate comments, and install/configure new/updated plugins. In a typical day this could easily generate another 30-50 page views of my blog that are reported to Alexa.

It would seem that although all my page views are coming from the same IP address, they are still able to make Alexa think that my blog is seeing a huge surge in traffic.

The timing is right too. The time I installed the plugin matches the time I started seeing this huge surge in Alexa rankings. And that’s not all. A short while after installing the plugin I headed to Takamatsu in Japan and continued working on my blog from there.

The fact that I had moved from the UK to Japan caused caused Alexa to think that most of my visitors were now coming from Japan.

Almost all of this was caused by me accessing my WordPress blog in a normal way whilst having this Firefox extension installed.

What it shows is how inaccurate the numbers can be for small sites such as mine. The number of people whose browsers report statistics to Alexa is sufficiently small that a single person can seriously skew the data.

So look at Alexa’s statistics if you really want to. But remember that unless you are looking at the stats for a huge site, they may well be way off the mark.

More »

1and1 doesn’t have mod_deflate or mod_gzip enabled on its home or business virtual server packages which means that many of the usual .htaccess tweaks to compress your web pages won’t work. Here’s something very simple tweaks that will work with 1and1, and with other hosts too.

Set up your .htm and .html files so that they are parsed by the PHP interpreter by adding this one line to your .htaccess file.

AddType x-mapp-php5 .html .htm

Then create and upload a php.ini file to your websites root directory. The contents of the php.ini should be as follows.

zlib.output_compression = On

This line causes PHP files to be served as compressed if the browser supports it. And as we have registered .html and .htm as being PHP files they will now be compressed.

You can test that the HTTP compression is turned on by using this simple HTTP compression checking tool, or by using the more comprehensive Page Speed add-on for Firefox from Google.

Here are the results from the HTTP compression checking tool showing that compression is now on, and that the home page HTML is being served using 76% less data. Note that this saving refers only to the HTML page, and not to any other images, style sheets, or JavaScript.

Increasing expiry time of images on 1and1

Another quick tweak you can make to your .htaccess is to increase the expiry time of your images, and other data files. This will result in quicker loading times for regular visitors as the files will stay in their browsers cache for longer.

Add this to your .htaccess. You can increase the expiry times if you don’t think those files will change.

#Increase cache time for resources

ExpiresActive On
ExpiresByType image/gif "access plus 2 weeks"
ExpiresByType image/jpeg "access plus 2 weeks"
ExpiresByType image/png "access plus 2 weeks"
ExpiresByType image/ico "access plus 2 weeks"
ExpiresByType text/css "access plus 2 weeks"
ExpiresByType text/javascript "access plus 2 weeks"
ExpiresByType application/x-javascript "access plus 2 weeks"

Use Google’s Page Speed add-on to verify that this has worked. Go to the Resources tab to see the headers for each individual file served from the HTTP server. Below you can see the current date/time, and that the expiry time is set two weeks into the future.

Caching and expiry changes combined

Here are before and after results for Google’s Page Speed tool of applying both the above changes to another of my websites. You can see that these quick changes give the website a small increase in score.

From 88 to 92.

This isn’t a big jump, but it may make a difference. I highly recommend you look at the other performance recommendations from the Page Speed tool, as it can give you loads of ideas for how to make your site faster and more responsive.

More »

I have an old website which is almost defunct, and I wanted to redirect all the traffic from it to this website – APART from a few selected directories. This is how I managed to get the redirects working using a .htaccess file.

For this example the directory containing the material that I don’t want to redirect is called ‘goodstuff’. The RewriteCond conditions are setting up the excluded directories (the exclamation mark means ‘not’).

RewriteEngine on
RewriteCond %{REQUEST_URI} !^/goodstuff/.*
RewriteCond %{REQUEST_URI} !^/goodstuff$
RewriteRule .* http://www.reviewmylife.co.uk/blog/ [R=301,L]

The reason I have two RewriteCond lines is because the web address could either be written with the trailing slash or without. E.g. reviewmylife.co.uk/blog/ and reviewmylife.co.uk/blog are the same, but I use two lines to cope with both cases.

The first RewriteCond matches all files and folders within this directory. The second is only matching the directory name without the trailing slash added.

The RewriteRule is telling the web server where to redirect the traffic to. The traffic is being redirected permanently (301 code), and the L states that this is the final rule for anything that matches our conditions.

Here’s another way of doing it which works, but isn’t as precise. It redirects all addresses which start with ‘goodstuff’. This means it would match all the files that the first example matched. But it could match others as well.

RewriteEngine on
RewriteCond %{REQUEST_URI} !^/goodstuff.*
RewriteRule .* http://www.reviewmylife.co.uk/blog/ [R=301,L] 

As well as matching a /goodstuff and /goodstuff/ directory, it could also match a /goodstuffhere/ directory, and a /goodstufffile.html.

More »