Google has undergone a major algo change over the last few weeks. This change will have a significant on how well your sites do in Google.

Codenamed ‘Brandy’ by the SEO industry, this latest update is the biggest series of changes to happen to Google since Autumn 2003 Florida and Austin updates. Interestingly all three of these major updates are only really indicative of what Google are planning when examined together. Florida removed a lot of sites from Googles overall index. Austin out some back (people speculate that Florida went a bit further than even Google expected and Austin was an attempt to pull things back a little) and now Brandy seems to have reinstated almost all sites – we seem to have returned to a pre-Florida state.

However, there’s been a big change since Florida about the way Google now ranks sites and what it places importance on. Of course the very basic idea is the same – high quality, frequently updated content will always do well sooner or later – but the overall emphasis is changing.

It used to be that on-page factors were equally as important as off-page factors. For example, good use of Title and elements together with a keyword/phrase rich body would see you doing reasonably well. Particularly if you had lots of quality backlinks. Since Brandy it seems that these factors are not so important. Thats not to say they’re unimportant but Google is making a conscious effort to reduce the chances for SEO spamming to occur by lessening the impact these elements can have.

The big change for on-page optimisation factors is LSI (Latent Semantic Indexing). This is a logic system that Google have always been very keen on incorporating into their algo. What it does is basically study the theme of the page, then remove all associated keywords/phrases but look and reward words and phrases that share a semantic root.

A practical example: The site I run at work concentrates on Loans, Mortgages and Insurance. Traditionally I would use these keywords in the Title,

elements and repeat the keywords as much as possible in the body text. What the LSI system will do is ignore all these (or more likely lessen the impact they’ll have individually) but look for related words to support the theme of the page e.g. for a loans page it might look for mentions of holidays, new cars, furniture etc as these are things you might require a loan for and hence they are part of the theme of the page.

Latent semantic indexing adds an important step to the document indexing process. In addition to recording which keywords a document contains, the method examines the document collection as a whole, to see which other documents contain some of those same words. LSI considers documents that have many words in common to be semantically close, and ones with few words in common to be semantically distant. This simple method correlates surprisingly well with how a human being, looking at content, might classify a document collection. Although the LSI algorithm doesn’t understand anything about what the words mean, the patterns it notices can make it seem astonishingly intelligent.

LSI Definition.

Using this system makes it a lot more difficult for a SEO spammer to guess what semantically related words/phrases Google might assign most weight to in relation to the theme of the page.

Its also very likely that Google will be stepping up the importance of high-quality backlinks and will almost certainly use LSI techniques to judge the impact of these links. So for my Insurance pages it might be worth my while trying to get links on a holiday site (travel insurance related) or a dentists site (dental insurance related) or on a car sellers website (car insurance) as oppose to relying on big finance related directories.

This will probably have an impact on PR which may be used more ‘locally’ to distribute ranking around your site and reward each page due to the amount of themed pages that link directly (as oppose to through the home page) to it. As ever, text links will do better than image links.

You can read the whole of the article I linked to above at the Middlebury College site.

As part of my continuing quest to find ways of redeeming Flash in unobtrusive yet useful ways, it occurred to me that you could use Flash as a data unification tool. What I mean by that is that you could use Flash to process disparate coding environments – particularly client side and server side code.

How This Came About

The idea first occurred to me when I was just starting the redesign of my work site. Basically, my boss wanted to ditch support for 800px width users and I thought that would be commercial suicide and said so. I quoted him the figures and he asked me to confirm that level from our own users.

So I had a nice problem to solve. For one week I had to collect data about our users screen resolution. My first idea was our web logs but our current package didn’t support the ability to detect screen resolution so I decided to use Javascript and record the data somehow. I realised immediately I had two problems.

Firstly, I had to find a way to get my Javascript data into SQLServer. Not being a hardcore SQLServer guy I didn’t know a way to get Javascript variable data in easily.

Secondly, I had to discount the possibility of multiple hits from the same user on different pages. So my solution would need to detect the screen res and IP Address of each user, once.

I knew I could detect screen width with Javascript but I also knew that Javascript couldn’t pick up IP Addresses so I was in a bit of a quandary until it occurred to me – I needed a central processing area that could handle both: Flash.

The Solution

The actual Flash part of the solution is negligible. Its simply a 1px by 1px SWF that collects variables and then passes them on to a server side script to insert them into SQLServer. For the purposes of this post I’m going to assume you know how to do this already. I’ll just concentrate on getting client side and server side data into Flash together.

It should also be remembered that this is a fairly basic application I’m building here. I see no reason why this couldn’t be extended to work in a variety of ways. I should also mention that at the time of writing it has one large drawback – the page it sits in won’t validate as XHTML 1.0 Strict. I’m positive its due to my rusty javascript skills rather than an actual inability so feel free to pick it apart and tell me where I screwed up.

Before we delve into the code though, go see it working. This illustration has a display obviously so that you can see it but in a production environment it could sit invisibly on the page. In my example, the top number is your IP address thats passed in from PHP and the second number is your screen width thats passed in from Javascript.

OK, onwards. First we start with a simple PHP one-liner – pick up the visitors IP Address.

Simple. Next up is the core of the technique. It involves creating a Javascript function that creates the Flash movie and appends all your desired data to the querystring of the movie reference declaration:

So firstly, I assigned the value of the screen width to a variable I called ‘w’ (Imaginative eh?). After that comes the all-important line to pass the URL-encoded values in:

data="http://www.kevinleitch.co.uk/testarea/catchswf.swf?r=' + w + '"

As this line is written by a Javascript document.write, appending the value of ‘w’ to it is straightforward. Its also very straightforward to append a PHP name/value pair by getting the Javascript to actually write out the code required. This is the line that could be extended to pass in as many variables as you need from any source. As the code is being generated by Javascript you aren’t limited to just PHP, you could easily use ASP – or even a combo of PHP and ASP if you so desired (and your server was capable).

For me this solved my main problem of bringing together into one potential recordset data from both client and server side technologies. All I had to do now was pass both these values to a PHP script that in turn checked the users IP, queried SQLServer and discarded the recordset if there was a recordset with that existing IP and submitted the recordset into SQLServer if there was no IP match. Job done. And because it all happened in Flash it all happened ‘behind the scenes’ without my user ever being troubled by it. Nice, quiet, unobtrusive. Here’s the code in full:

What Next?

This is very dirty code. It needs tidying up and made to validate. It also needs extending into an easy-to-use methodology so that its obvious how to extend the functionality into multiple name/value pairs and/or arrays etc. I may be the one to do that or I may not. If you fancy having a go then go right ahead.

I’m now writing the final draft of the final article of the final part of Project: New Part I. I’ve had to do this one quicker than I usually do as Naomi (my wife) is now down to T-minus 14 days and counting until B-Day (thats Birth Day) but she’s been having contractions for the last two or three days – not of the Braxton Hicks variety (sounds like a team of celebrity web designers!) – but the real thing so we don’t think its going to be too long now.

I’m going to try and get this issue done and out the door (so to speak) as soon as possible and then it won’t be preying on my mind. I _hate_ unfinished things hanging around!

I thought I’d write down a few things about how I found the process of writing it all down and what I got out of it – it wasn’t an entirely selfless act of generosity I can tell you.

I have to tell you the truth and say that writing it was an act of will unlike anything else I’ve ever done and you’re talking to a man who gave up smoking five years ago! What I mean by that is that it took an act of will to commit to writing it and to keep writing it. As must be obvious by my recent spate of redesigns I get bored pretty easily and I was worried that I’d do the first couple and then it’d just tail off into a dusty half-finished site.

But that didn’t happen. As I said it was an act of will but it also became fun committing ideas and concepts that I’d learnt sometimes years before to ‘paper’. Somebody wiser than me once said that the concept of thought is only complete with an act of actualisation and doing this certainly taught me the truth of that statement. We, as designers, get so used to doing things on instinct as thats a large part of what we do – making instinct about an idea/concept/service/product respond in a positive way – that actually stopping and thinking about why we do these things doesn’t always come easy. In some instances I’ve said things that I’ve never thought of in such literal ways before and in some instances I’ve had the help of a great bunch of people to say things better than I ever could.

So this has been a positive learning experience for me too. I feel much more ‘plugged in’ to my profession that I have for a few years. Deciding to concentrate on Flash so heavily 4 or 5 years ago was a big mistake in lots of ways. In terms of my thoughts of processes and adaptability that decision cost me heavily. In terms of my ability to build websites that clients and users like rather than other designers like it also cost me heavily and I feel that I’m still not in a position to really say I’ve caught up in that respect even now. But I do feel that writing Project: New has brought me to a position where I can participate on a level that will enable me to start pushing myself to catch up.

After my baby’s born, obviously ;o)

We all know that Search Engines hate change. Whenever we decide to do a total restructural change of any site we run the risk of pissing off search engines. And when we piss off search engines, we start to drop down the rankings.

Why? Because when we change the structure of a site (i.e. add or remove pages from the existing structure) Google doesn’t know where to find the new pages until we tell them. Now we could just use a meta refresh but search engines have to come to view these as spamming tactics and you run the risk of being penalised. So instead you need to permanently redirect your bots (and human visitors!) to the new page, straight from the old page and create a safe association in the consciousness of Google between those two pages.

You can set up server side methods to allow for 301 redirects on both Apache and IIS but sometimes you’re on a shared hosting account that doesn’t allow access to these methods. So what do you do? You script the changes manually. You can use PHP, or ASP or .NET to script a 301 page very easily.

PHP

ASP

VB.NET

So you simply paste this code into your old pages, remove the content that used to be in there and adjust the target URI to point to the new page – job done. Google now associates the new page with the old and you should keep your hard-fought for PR and rankings.

What about when you have a *lot* of pages that are being redirected? For example, an old version of the Group site I work on changed from trad ASP to .NET and hence all our pages needed rebuilding and the site structure changed a lot. The old version of the site ran off the index.asp page with pages being called in depending on the values in the query string e.g. …/index.asp called in the home page obviously but …index.asp?TYPE=02 called in the Mortgage pages and …index.asp?TYPE=02&aid=5 called in the first time mortgages page in the mortgage section. So I had to allow for all these pages which were indexed in search engines and working nicely. I did this like so:

I saved that page as index.asp (which didn’t conflict with my new index.aspx page) and then every time a search engine sent a visitor to an old page the case statements sorted out where to send the visitor in the new structure. Job done!

A report on AWARES.org highlights a BBC documentary that finally lays the MMR/Autism connection to rest.

Andrew Wakefield was one of 13 authors of a paper published in The Lancet all edging a connection between MMR and autism. In fact, there were only 12 people studied, 9 of whom were autistic – it seemed Wakefield made the schoolboy error of deciding on his conclusions and working backwards to find his ‘culprit’.

On the question of these 12 subjects, it later transpired that some of the 12 were not randomly selected but supplied to Dr Wakefield by a firm of lawyers acting for the parents who believed their kids were ‘made’ autistic by the vaccine. Accoring to ratbgs (see below) Wakefield was paid about £50,000 for his work and was lined up for lots more as a paid expert witness when legal action against the Pharma’s swung into action. As Ratbags say:

Put bluntly, Wakefield was paid to find a certain result (which matched his beliefs anyway) and was going to get a lot more money if he found it.

Shortly afterwards 10 of the 13 authors of the original report authors issued a statement saying that the paper was not evidence of a connection between MMR vaccine and autism and The Lancet now say they would never have published the paper at all if they’d known about Wakefields payments.

In the last few years study after study has repeated the fact that MMR does not cause autism but anti-vax campaigners said that because all these studies were epidemiological (in other words they only looked the stats) they were useless and what was needed was someone to look at the bowels of autsitic kids.

And thats exactly what the BBC documentary shows – a team of renowned scientists looking at the bowels of autistics.

Now, such research has been carried out. Scientists at Guy’s Hospital, in London, have been studying a large group of 100 autistic children. They examined their blood samples, looking for traces of the measles virus in their blood and in that of another group of non-autistic children. The samples were analysed in some of Britain’s leading laboratories, using the most sensitive methods available. The scientists found that 99 per cent of the samples did not contain any trace of the measles virus. Crucially, there was no difference between the autistic and non-autistic children.

And thats pretty much that. I’ve no doubt at all that this will do nothing to silence the most vocal and shrill of the anti-vax brigade – they’ll accuse the scientists who conducted the study of being in the pocket of the big pharma companys no doubt – but hopefully it will reassure the vast majority of parents that MMR is safe in this respect.