I’ve been writing this blog for a couple of years now. With over 500 posts, it’s consumed a scary amount of my time, but at least it’s finally something useful to do with the markwilson.co.uk domain that I first registered back in the late ’90s when I was thinking of leaving my job and working as a freelance IT contractor!

Over time I’ve tried to move towards a standards-compliant website, with lots of information that people find useful. I’ve still got some way to go – not being a developer, my code is not as standards-compliant as I’d like it to be (although the website that I have been working on recently with my buddy Alex should soon be pretty much there from a CSS and XHTML standpoint) and the usefulness of the content is totally subjective (but the blog started out as a dumping ground for my notes and that’s still its primary purpose – if others find it useful then that’s great and the trickle of Google AdSense/PayPal revenue is always welcome).

From time to time I look at the website statistics (webstats) for the site and always find them an interesting read. I can’t claim to be an expert in search engine optimisation (nor do I want to be) but the Webalizer webstats that my ISP provides are great because they let me see:

• How many hits I’m getting (not surprisingly I get more hits after I post new articles and less when I’m busy with work or other projects) on a monthly, daily or hourly basis.
• The HTTP response codes that Apache dishes out (200s are good, 404s are bad).
• The top 30 URLs that are being hit (not surprisingly /blog is number 1, but it also helps to see pages that account for lots of bandwidth but not much traffic – the ones where maybe I should be looking at optimising the code).
• Entry and exit pages (there’s a big correlation between these two, so obviously I’m not encouraging enough browsing of the site).
• Where people visit from (mostly crawlers, although unfortunately I can see how the stats are skewed by my own broadband connection at number 18 because I use the site so much to look things up for myself).
• Who is referring visitors to me.
• What people are looking for when they get referred here.
• What browser people are using.
• Where people are visiting from.

This information lets me understand which pages are most popular as well as highlighting technical issues with the site but it doesn’t always go far enough.

Some time ago, I applied for a Google Analytics (formerly Urchin) account and last week I finally set it up. Whilst the Webalizer stats are still useful in many ways for me as a website administrator, the Google Analytics information is much richer. For example, I no longer need my ClustrMaps map because I can see a geomap along with my pages per visit ratio, how many visitors return and who sends them here. For marketeers there are tools to track campaigns and see how they are progressing, and I can also find a whole load of technical information about my visitors (e.g. connection speed used, browser, platform, java and flash capabilities, language, screen colours and resolution – all of which can help in decisions as to what features should be incorporated in future). There’s also information about how long visitors spent viewing a particular page (in fact there are so many reports that I can’t list them all here).

So, what have I learned from all of this – well, from Google Analytics I can see that most of you have a broadband connection, are using Windows (94%), IE (65%, vs. 29% for Firefox), view the site in 32-bit colour and have a screen resolution of 1024×768. That means that most of you should be able to see the content as I intended. I also know that people tend to visit a single page and then leave the site and that Google is my main referrer. Webalizer tells me that Apache gave a strange error 405 to someone this month (somebody obviously tried to do something they shouldn’t be trying to do) but also some 404s (so maybe I have some broken links to investigate). I can also tell that (for the IP addresses that could be resolved) most of my visitors were from Western Europe or the United States but hello to everyone who has visited this month from Australia, China, India, Japan, Malaysia, New Zealand, Pakistan, Saudi Arabia, Singapore, South Africa, South Korea, Thailand, and the United Arab Emirates.

I hope this has illustrated how website statistics can be useful, even for small-time website operators like me and I encourage you to check out Webalizer (which reads Apache web server log files) and Google Analytics (which needs some JavaScript to be added to the website code). Alternatives (e.g. for IIS users) include AWstats and Christopher Heng also has a list of free web statistics and web log analysers on his site.

A couple of weeks back, a little GeoURL icon was added the side panel of this blog (underneath the feedmap). GeoURLs are a way of encoding location information within a website.

For example, whilst I try to make the information on markwilson.co.uk applicable to a wider audience, inevitably some of it is UK-specific. Geolocation by IP address can help to match users with localised content, but it does have some issues. A DNS lookup on markwilson.co.uk tells me that it is an alias for hp.force9.net (212.159.8.1). Using the CAIDA Internet geographic database (NetGeo) to look up 212.199.8.1 tells me that this address is actually allocated to Force 9 Internet in Sheffield, UK (latitude 53.38, longitude -1.50) but that’s not much help for localising services as that’s where my ISP is registered (it may not even be the location of their servers) and I’m nowhere near there. In addition, the CAIDA database is also no longer maintained, so other tools may be more appropriate, but of far more interest is the location to which the site’s information applies.

For locating an Internet site or service (such as a location-specific web page or RSS feed), geolocation using geotags is probably more applicable. For markwilson.co.uk, the actual code which identifies the geoURL (the geo-structure tag or geotag) is found in the HTML head and reads:

<meta name="geo.position" content="52.1542;-0.7122" />
<meta name="geo.region" content="GB" />
<meta name="geo.placename" content="Olney" />

These geotags can be generated using the geotag generator (I found out the latitude and longitude using multimap). It’s also possible to use an ICBM tag such as <meta name="ICBM" content="52.1542, -0.7122" /> but geo-structure tags are newer and also include region (using the ISO-3166-1 country names and region names specifications) and placename information.

GeoURL is a location-to-URL reverse directory (although at the time of writing it only lists 211,991 sites). A GeoURL lookup on markwilson.co.uk returns a list of sites located nearby and although it’s of limited use at the moment, as more and more sites are geotagged, information like this will become more and more relevant, particularly when combined with services such as Google Maps.

Last year I blogged some advice on spam-proofing a website from Thomas Brunt’s Outfront site. Although Outfront is billed as a “FrontPage learning community” (urgh!), it also includes some practical advice for web authoring techniques such as looking at writing pages which are compliant with web standards, advanced use of mailto links and preparing photos for publication on a website, as well as some topics I have covered in this blog like custom error pages and the use of .htaccess files.

The site also features a good description of RSS (although most people familiar with blogs will also know RSS!) and design tips for producing a good website.