That’s not bad for one day.

Looking at the analytics, those 5561 visits were from 5261 absolute unique visitors, and they made 10,013 pageviews.

That amount of traffic was a bit of a spike – usually the site was getting around 400-500 visits/day, so something unusual must have happened.

Looking at the top pages report in Google Analytics, the Tracking Santa and the Home page accounted for most of the pageviews. Around 60% were to the page, called (not surprisingly) tracking-santa. So you’d figure it was search engines sending the traffic.

Using Google Analytics to filter the keywords to those containing “santa” and “track”, on that day there were actually 440 combinations of phrases, totalling 4011 visits.
So yes, that one page brought 4011 out of 5561 visits to my site that day. The rest were general Christmas queries.

But on Christmas Eve, everyone wants to track Santa, using Norad’s Santa Tracker. The day before, it had only been 56 search phrases sending 204 visits. Definitely a one day spike.

I hadn’t even edited that page this year – i’d set it up a year or so ago, and left it there. But it was optimised, for content, inlinks, heading etc – all the usual.

I haven’t syncd AdSense and AdWords reports, so I can’t tell exactly how much each keyword earnt, but I can tell that the banner at the top of the page was the top earner that day – even though it was just enough for a cup of coffee each for me and the kids. Shucks – the day before, we could have only had 2 cups of coffee.

But I’m sure we had one.

(And I thought 1500 visits on Halloween Eve had been good)

The two main takeaways for me were:
1. Using hCard format for your contact details on your website.
2. Preparing for the future, when Google may scrape hReviews (standardised microformat for reviews) as testimonials, and place them on your Place page.

It’s always good to go back and review your Place page, to see if you need to correct the categories, add a status, add some photos, ask for reviews. These will all help your Place page rank higher.

Previously I thought you only used the rel=canonical tag on unusual pages when you wanted to concentrate/redirect links. But after reading the above and other articles, it’s a great tag that should always be in use as a preventative measure, rather than in response to a problem.

Rel=canonical

A canonical page is the preferred version of a page when you have multiple versions with identical content. It’s great for handling sessionid parameters, tracking links, and also multiple urls from tagging and categories. Also slight variations, such as when the sort order of a page is changed.

For example the page /content.php may also appear as /tag1/content.php, /tag2/content.php, /category1/content.php, /content.php?ssid=blah, and /content.php?utm=trackinginfo

But we really only want /content.php indexed, and we want all the seo juice concentrated on that page. And so you would use the rel=canonical tag to specify the preferred url as http://www.yourdomain.com/content.php, for all of the above urls.

Most good CMSs, blogs and shopping carts will have rel=canonical already included in the more recent versions of their software: WordPress, x-cart, Drupal all include it.

If your CMS doesn’t already include rel=canonical, you can build it yourself using server-side coding to strip out the parameters for use in the canonical statement. Eg in PHP:
$RequestURI = $_SERVER[REQUEST_URI];
$RequestURI = str_replace(strstr($RequestURI,’?utm’),”,$RequestURI);
echo ‘
‘;

It may be easier if your CMS has a separate user-maintained clean-url field that can be used in the rel statement.

301 Redirects

301 redirects actually redirect the visitor from an old URL to a new URL. They redirect and consolidate link juice, and are best when the old page no longer exists. Using them to manage duplicate content can destroy the navigational path of the visitor, if they were systematically browsing through a section of the site and expect to remain there.

Robots.txt

You can list pages and folders you wish to be excluded from search engines in your robots.txt file.

The robots disallow statement, for either the whole site, a folder or URL, is supposed to tell search engine robots not to visit – not to crawl the page.

However if people are linking to the page that you have tried to exclude, given that you are blocking rather than redirecting, you are wasting link juice, which is why other techniques are frequently used.

And Google actually says they may index URLs if other pages are linking to them (“While Google won’t crawl or index the content of pages blocked by robots.txt, we may still index the URLs if we find them on other pages on the web”). So you’re at the mercy of others – this isn’t a foolproof way of excluding pages from the index.

Meta Robots: NoIndex/Follow tag

Noindex tells search engines not to index the page, thus eliminating duplicate content. Follow tells search engines to still follow the links found on this page, thus still passing around link juice.

The Meta Robots tag is generally considered more reliable than the robots.txt file, for excluding a page from being indexed.

Alternate link page

Similar to the canonical link tag, used mainly for International or Multilingual SEO purposes.

All pages will still be indexed, but this helps Google choose the best result for the individual country versions of Google. And eliminates the problems Google may run into treating pages as duplicate content.

How you handle multilingual sites depends on whether you have localized the content, or just the navigation/framework. But that’s a different post, and a future experiment.

Can’t do that no more, after the latest AdWords “upgrade”.

Theoretically to make it easier for us, AdWords moved Campaign, Ad Group and Account reporting, out of Reports, and into the Campaign tab. They’ve actually disabled the Campaign/Account/Ad Group report types in the report menu, so you can’t create any more new reports there. So instead of grabbing one of my old custom report templates and changing the month, I now have to go to Campaigns, select Control Panel, Select the report, change the month and run the report. If it lets me.

If you try to segment the data on the Campaigns tab by month for more than 14 months, it tells you you can’t do that – it’s too big a time frame. Not nicely, either. Let’s say I have a date range of 14 months, and I click on Segment, then month, to get a monthly break down. That’s fine. Change it to 13 months. That’s fine – it redisplays with fresh data. Change it to 15 months – uh oh – back to the default view, no error message, no warning, no nothing. Disgraceful degradation.

That’s not upgrading, that regression. Taking away useful functionality.

My old report template was still there from when I ran it last month, for the period Jan-2007 through to July-2010. I clicked on the report name, and the template appears. Select the month from the dropdown so that it’s now August. Run the report. And get the following message:

We’re sorry, but we’re unable to process this request. Some of the possible reasons for this include:
- Trying to view a report that no longer exists.
- Trying to view a report that doesn’t belong to you.
- Trying to download a report that has not finished running.
If you believe you have reached this page in error, please double-check your report parameters and resubmit your information. We apologize for any inconvenience.

Balderdash. It’s my report, I own it, and you didn’t let it even start running.

For inconsistency, if I click on run report, using last months July date, it runs happily.
But no, I can’t change the date to August and run it.
And I can’t produce the report from the Campaigns tab, as it’s more than 14 months.

Shame, Google, Shame.

Halloween Australia has been one of my best performing sites in a couple of ways. It is usually number 1 at Google for Halloween Australia, and also Halloween Events Australia. Probably because it has one of the few dedicated halloween event calendars, listing around 50 events each year, ranging from streets offering trick-or-treating to big commercial events, and it was definitely built with SEO in mind, to get organic traffic. It was light, source-ordered content, highly optimised, and had some nice incoming links. And with Google AdSense and a few affiliate links, it would make October my highest earning month online.

Last halloween it peaked at 1600 hits on 31 October, but at this time of year its still around the 30 visits/day mark, but it’s starting to ramp up now. There have been 4 events added so far, and a magazine contacted me for an interview last month. (Haven’t done it yet).

But it was labour-intensive. I had to manually approve each event, as it was added – actually by editing a field on the database – I had never got around to writing an approval program. And photos were also supposed to be manually uploaded. I didn’t make it easy for people.

So it was time to convert to Drupal again, to get more community oriented.

I took a few shortcuts. Reused my Christmas Drupal template, and just changed the colour scheme. Styled a few view tables that hadn’t needed styling on the old white background.

Then I had to copy the content across. Create new data types for events, recipes, craft, stories. Create new views for each data type. Manually add the events from this year. Check that access was fine for new members. Then importantly, redirect the old URLs (eg halloween-recipes.php) to the new format (/halloween-recipes/).

Elapsed, it took from Fri night to late Sat night, with a few late tweaks on Sunday, to add polls, and finish the redirects. Probably 6 hours all up.

Again, it will be interesting to see how the traffic continues for the new site. Whether the redirects will work properly, or if I lose any ranking at Google for changing the page URLs.

There didn’t seem to be any negative impact on traffic for Womens Health and Fitness – it’s still around 30 visitors/day.

But now it’s time to learn a new CMS for work – goodbye Drupal, and hello Mura. (There goes Sunday afternoon…..)