Alan Perkins - Profile and Blog

Alan Perkins is the CEO of SilverDisc and was a co-founder in 1993. Some info about Alan ...

  • Alan has been working in the electronic marketing industry since 1990 and in search marketing since 1995.
  • Alan has developed a number of worldwide patents in search engine technology, for example this one in 1999.
  • Alan has spoken every year at Search Engine Strategies (aka SES Conference) since 2001.
  • Alan is an industry-leading advocate of best practices in search marketing. He has worked directly with search engines to achieve this, e.g. a couple of Google's webmaster quality guidelines were based on his contributions in 2001. Google contacted Alan following a presentation on best practises they saw him give at SES San Francisco that year.
  • Alan lives in Kettering with his wife and teenage sons and walks to work each day.

Connect with Alan through Google+, Twitter or LinkedIn.

alan's picture

Google Results Prefetching in Firefox/Mozilla

It appears that, some time ago, Google removed details of results prefetching from its Webmaster guidelines while continuing to implement results prefetching in its search results.

If you haven't a clue what I'm talking about, the Wayback Machine has the original Google Webmaster help on this topic, which I'll paste here verbatim in order to make it searchable (Wayback Machine pages aren't indexed by search engines):

Results Prefetching Questions

1. What is "results prefetching," and how does it impact my site?

On some searches, Google uses a special <link> tag supported by Firefox and Mozilla to instruct the browser to download the top search result before the user clicks on the result. When the user clicks on the top result, the destination page will load faster than before. This tag is only inserted when it is likely that the user will click on the first link.

For example, when a Firefox user searches for [stanford], Google includes the following tag in the results HTML:

<link rel="prefetch" href="http://www.stanford.edu/">

The official Mozilla Link Prefetching FAQ describes the behavior of this tag in detail.

Prefetching may impact your site because the prefetch request will happen whether or not the user clicks on the result, so it may result in additional traffic to your web server. Google only inserts this tag when there is a high likelihood that the user will click on the top result, but clearly this heuristic is not right 100% of the time.

2. Can I distinguish prefetch requests from normal requests?

Yes, as described in the Mozilla Link Prefetching FAQ, prefetch requests include the additional HTTP header

X-moz: prefetch

3. I want to block/ignore prefetch requests. What should I do?

To block or ignore prefetch requests (from Google and other web sites), you should configure your web server to return a 404 HTTP response code for requests that contain the "X-moz: prefetch" header.

What else do you need to know about results prefetching?

If you run Google Analytics or another JavaScript-based analytics package, you won't see these prefetched pages in your analytics. That's because only the HTML is prefetched, not the images, JavaScript, etc. referenced by that HTML, which means that the Analytics JavaScript is never even fetched, let alone executed. You need to look at raw log files to see prefetched pages.

Google only issues the prefetch code when they are very confident that searchers will click on the #1 result (as in their example, a search for stanford). Most times, particularly for more "normal" sites (i.e. not Stanford), Google won't issue the code. So you may never see this on your own site.

However, it's worth being aware of this issue because if you do see a prefetch in your raw logs you'll want to know why; and because, depending on how you calculate conversions, the fact that a page is prefetched but never viewed by a searcher may significantly affect your conversion tracking and monetisation on that page. I'm surprised that Google removed this info from their Webmaster help.

alan's picture

Nicola has baby

It seems like only last year - and it was - that we posted the happy news of Nicola's marriage to Sam Richards here on SilverDisc blog.

Ever the fast worker, Nicola gave birth yesterday to Caitlin Rose Richards at 10.29am, weighing 7lb 1oz.

Congratulations to Nicola and Sam from all at SilverDisc!

alan's picture

Early Easter Egg - The rel=canonical Calculator

SilverDisc offers an early Easter Egg to Silver Spike readers - a rel=canonical calculator to help you help search engines to deliver more high quality, high converting visitors to your site. This builds on the recent series of posts on this topic:

The rel=canonical calculator will go on general release in the next couple of weeks, and we will be making some PHP code available to insert the rel=canonical tag on your own pages. That's right - FREE CODE. Register using the instructions provided on the rel=canonical calculator page.

alan's picture

a robots.txt equivalent to rel=canonical

In my last post I looked at the rel=canonical tag and finished by promising to look at some of the limitations of rel=canonical and consider some alternatives.

Many of the alternatives have existed for some time - the use of redirects and cookies, for example. However, the introduction of a rel=canonical tag was an opportunity for search engines to also introduce other, more efficient, standards. These are the alternatives I would like to consider - alternatives that don't exist yet, which the search engines could have introduced this time around and may introduce in future.

I see the rel=canonical tag as analogous to the meta robots tag, and therefore suffering from many of the same limitations:

  • The rel=canonical tag is located in a HTML file, and that HTML therefore needs to be fetched and parsed in order for the tag to be seen and acted upon. Therefore, the tag does not save bandwidth or CPU for the Web site or search engine.
  • The rel=canonical tag is located in a HTML file and gives instructions about that file. Therefore, it cannot be used to solve canonical issues for non-HTML files such as images, PDF files or Flash movies.
  • The rel=canonical tag acts at a micro-level rather than a macro-level. Therefore it is difficult to review that a site-wide policy has been correctly implemented using rel=canonical; Every possible file has to be inspected. Also, code changes have to be made in order to write the rel=canonical tag. This may slow its implementation.

Where the above issues apply to rel=canonical, and similar issues apply to the meta robots tag, it struck me that an opportunity has been missed to also solve canonical issues through the robots.txt file. Any fix applied through robots.txt would not suffer from the above problems.

Extensions to robots.txt could be made in a number of ways. For example, a mod_rewrite-type syntax could be introduced. However, I'm not sure anything so advanced is needed. Most canonical issues arise from three things:

  1. the use of query parameters in dynamic URLs.
  2. www versus non-www versions of a site (and other subdomains).
  3. inconsistent use of default index page URLs.

Some simple robots.txt fields to control these issues would fix most problems without the pain and errors that a mod_rewrite implementation would create.

Query Parameters

Google Analytics and Yahoo Site Explorer are two examples of tools that allow simple manipulation of URL query parameters. Yahoo's Dynamic URL Help lists some of the crawling, indexing and ranking benefits of this approach.

Yahoo Site Explorer allows you to remove a query parameter or set a query parameter to a default value within a URL. Using this, a URL such as

could be crawled and indexed as

The session id has been dropped and the referrer has been overwritten as yhoo_srch, meaning all traffic sent by Yahoo Search could be attributed to Yahoo Search rather than the affiliate. This functionality could be implemented in robots.txt using a new syntax something like the following:

User-Agent: Slurp
Disallow:
QueryParam: -sid
QueryParam: refby=yhoo_srch

meaning that the sid query parameter is to be dropped (as it is preceded by '-') and the refby query parameter is to be overwritten with a default value (as a default value is provided). The same effect could be achieved with a single line:

User-Agent: Slurp
Disallow:
QueryParam: -sid, refby=yhoo_srch

One problem with both Google Analytics and Yahoo Site Explorer is that you must list the query parameters you wish to drop from URLs - not the ones you wish to keep. Because third parties can link to your site, you're not in control of the links they create and the query parameters they use. Therefore, canonical issues can only truly be solved by specifying the query parameters you wish to keep, rather than those you wish to drop. To solve this, wildcards could specify the default action to be applied to all non-listed query parameters. Therefore I propose the following syntax:


QueryParam: retainParam[=defaultValue]
QueryParam: -dropParam
QueryParam: [-]*

where...

  • retainParam[=value]: specfies a query parameter you definitely want to keep, and an optional default value you want it set to
  • -dropParam: specifies a query parameter you definitely want to drop
  • *: means keep all query parameters not specified (default)
  • -*: means drop all query parameters not specified

Default domain and Index Pages

Two further, much simpler additions to robots.txt could clear up the majority of other canonical problems. These are Domain and IndexPage:


Domain: defaultDomain
IndexPage: defaultIndexPage

defaultDomain specfies the default domain for this robots.txt file. For example, if the search engine retrieves http://www.example.com/robots.txt and finds ...


Domain: http://example.com/

...it would know to index all URLs under the non-www domain. This would allow multiple parked domains to share the same content and robots.txt file without needing redirects or causing canonical issues, which is currently a common problem.

The IndexPage field specifies a default index page for the domain, i.e. a page for which the following two URLs are considered equivalent:

http://www.example.com/path/
http://www.example.com/path/defaultIndexPage

Conclusion

In this post I've proposed three new fields to add to robots.txt to provide an alternative to the rel=canonical tag, just as the current robots.txt fields are themselves alternatives to the meta robots tag, with their own advantages and disadvantages. The chief advantages I see of canonicalising through robots.txt are:

  • Acting through robots.txt means that a resource does not have to be fetched and parsed in order for the canonicalisation instructions to be followed. Therefore, bandwidth and CPU is saved for both the Web site and search engine.
  • Acting through robots.txt means that canonical issues can be solved for non-HTML files such as images, PDF files or Flash movies.
  • Acting through robots.txt means large scale changes can be made very quickly and easily without the need for any code changes. It's also much easier to review the changes that have been made.

The Domain, IndexPage and QueryParam fields would all be optional and independent of each other. It would be great if the search engines could introduce some or all of these ideas into robots.txt.

alan's picture

rel=canonical tag

So, Google, Yahoo, Microsoft and, more recently, Ask have announced the new "canonical" link type or, more colloquially, the rel=canonical tag. Much has already been written about this tag and its purpose: to help prevent duplicate content issues. Probably the best summary is this Matt Cutts video

:

This tag is a welcome addition to the armoury in the fight against duplicate content issues. In addition to Matt's comments, I would make the following points:

Copyright Protection

Scrapers are forever copying content and publishing it on their own sites/splogs. Sometimes they are exceptionally lazy or stupid, even to the extent that they copy Adsense code onto their own sites. If they copy your rel=canonical tag onto their site, that would give a strong "hint" to the search engine that you were the original owner of the content:

<link rel="canonical" href="href="http://www.mysite.com/my/content/" />

Microsoft Platforms

Matt made reference to the Microsoft platform in his video, but I would emphasise the point. Microsoft's implementation of RFC 2396 is flawed. The path component of a URL is supposed to be case sensitive, but Microsoft makes it case insensitive. If there are n alphabetic characters in the path, then a Microsoft implementation gives 2n possible variations of that path, where there should be only one. For example, if n=1 and the path is "/a/". Microsoft would allow "/a/" and "/A/"; if n=2 and the path is "/ab/". Microsoft would allow "/ab/", "/aB", "/Ab" and "/AB/"; and so on. 2n variations gives vast potential for duplicate content and it is a big issue with sites built on the Microsoft platform. The rel=canonical tag makes it very easy to specify the correct, case-sensitive path on a Microsoft platform:

<link rel="canonical" href="http://www.mysite.com/my/case/sensitive/path/" />

Static Web Content

Static web content is content that is stored in the format in which it is delivered. Typically, static content is served under a static URL (a URL that does not contain a question mark). However, it is possible to link to static content and append query parameters, even though these query parameters will have no impact on the content that is served. One example of when this might happen is when a referrer parameter is passed to a JavaScript function within the static content:

<a href="http://www.mysite.com/?referrer=myAffiliate0001">Affiliate Link</a>

Thousands of links can be created to a single, static URL, each with a different referrer query parameter attached. For sites built on static content, trying to manage such links has been difficult in the past. Now, it's relatively easy. Each page of static content simply needs to contain a rel=canonical tag:

<link rel="canonical" href="http://www.mysite.com/my/static/url.html/" />

Conclusions: rel=canonical

For the reasons stated above, I would recommend the use of a rel=canonical tag in all static content. In fact, I would recommend its use in all content, static or dynamic - with appropriate care of course. It's a powerful tag and using it wrongly could have dire consequences. In the next post I'll look at some of the limitations of the rel=canonical tag and consider some alternatives.

alan's picture

URL Canonicalisation and Normalisation

I’ve been meaning to write about the new rel=canonical tag, which was proposed by Google, Yahoo and Microsoft on February 12. I managed to squeeze some thoughts on it into my presentation and workshop at SES London, and I’ll be speaking more about it at SES New Yorknext month, but before I blogged about it I really wanted to write more about URL Canonicalisation and Normalisation in general.

Canonicalisation or Canonicalization? Normalisation or Normalization?

I’m British, so I say Canonicalisation and Normalisation. Your mileage may vary.

What is URL Canonicalisation?

We’re talking about search engines here, so let’s try a definition that applies generally, but leans towards search:

URL Canonicalisation
involves taking a set of different URLs that all serve or lead to the same or similar content, and applying rules to select one URL from that set under which that content should be indexed or presented.

I’ve hyperlinked the terms I think are important to more detail below, but before we go into them let’s try defining URL Normalisation.

URL Normalisation
involves taking a single URL and applying a normalisation algorithm to produce a standard form for that URL.

Others define normalisation and canonicalisation as all part of the same thing, but I like to think of them as separate processes. To my way of thinking:

  • you can normalise a single URL but you can only canonicalise a set of URLs
  • an un-normalised URL will serve the same content as a normalised URL, because it’s the same URL
  • all indexed URLs are normalised; not all are canonicalised
  • normalisation occurs before canonicalisation

Now let’s go back and look at those hyperlinked terms in more detail.

Set of different URLs

This is the key to canonicalisation and why it’s needed: the same content is being presented at a number of different URLs. By different URLs, I mean those URLs are really different to each other – they could potentially show different content but (in this case) they don’t. Here is an example set of URLs:

  • http://www.example.com/
  • http://example.com/
  • http://www.example.com/index.html
  • http://example.com/default.asp
  • http://www.example.com/?referrer=affiliateName
  • http://www.example.com/?sessionid=123456

All serve or lead to the same or similar content

If each of the above URLs served the same, or essentially the same, content, it’s likely that they would be canonicalised to fewer URLs – possibly only one. If they each served completely different content, then it’s much less likely that this canonicalisation would take place. By “or lead to”, I mean that the URL may redirect (e.g. with a HTTP 301 or HTTP 302 redirect) to another URL.

Canonicalisation Rules

The rules for canonicalisation vary from engine to engine and time to time. Here are a few examples of when canonicalisation will take place …

  • If www and non-www versions of the URL exist, then canonicalise
  • If the same base URL is seen with different numbers of query parameters, then canonicalise
  • If the filename component of the URL matches a known set of index pages (e.g. index.*, default.*, etc.) then canonicalise
  • If the home page (“/”) redirects to another page, then canonicalise

… and here are some examples of how canonicalisation will take place:

  • Choose the URL with the highest Pagerank (or similar link-based or other off-page criteria)
  • Obey rel=nofollow webmaster hint
  • Choose the simplest URL (e.g. the shortest URL, or the one with fewest query parameters)

Indexed or presented

Sometimes only one URL from a set will be indexed, which means that it will always be the candidate URL to be presented in a set of search results. At other times multiple URLs may be indexed, even though they are known to be part of the same canonical set. One of these URLs will be selected to appear in a given set of search results. The URL that is selected may vary (for example, by query or by searcher location) – but only one will ever appear on a given search results page.

Single URL

Normalisation operates on a single URL rather than on a set of URLs. That single URL may need be supplemented with other data in order for normalisation to take place. For example, un-normalised URLs may be relative or absolute. A normalised URL will always be a fully-qualified absolute URL so, along with a relative URL, the containing URL or tag will need to be known in order for normalisation to take place.

Normalisation algorithm to produce a standard form

Like canonicalisation rules, the normalisation algorithm may vary from engine to engine and time to time. However, it’s much less likely to vary. Here is an example of the kind of things that are done during normalisation:

  1. convert a relative URL to an absolute URL
  2. convert the scheme and the host name components of the URL to lower case
  3. remove the port component if it matches the default port
  4. escape characters that should be represented as octets (or a +)
  5. unescape octets that are better represented as plain characters
  6. convert all escape sequences to upper case

Here are some examples of each operation:

  1. In http://www.silverdisc.co.uk/ , a link to “/contact.html” would be normalised to http://www.silverdisc.co.uk/contact.html
  2. HTTP://WWW.SILVERDISC.CO.UK/contact.html would be normalised to http://www.silverdisc.co.uk/contact.html
  3. http://www.silverdisc.co.uk:80/contact.html would be normalised to http://www.silverdisc.co.uk/contact.html, because 80 is the default port for HTTP connections.
  4. http://www.silverdisc.co.uk/contact.html?name=Alan Perkins would be normalised to http://www.silverdisc.co.uk/contact.html?name=Alan+Perkins or http://www.silverdisc.co.uk/contact.html?name=Alan%20Perkins, because a space is not a valid character in a URL.
  5. http://www.silverdisc.co.uk/cont%61ct.html would be normalised to http://www.silverdisc.co.uk/contact.html, because %61 is better represented as the character “a” in a URL.
  6. A %2a in a URL would be converted to %2A for consistency

Summary

That completes this introduction to URL canonicalisation and normalisation. In the next post, I’ll look at rel=nofollow.

alan's picture

Nicola Gets Married!

The preparations seem to have been going on since she joined us three years ago, but today is a big day on the SilverDisc social scene as Nicola, our Head of Paid Search Marketing, gets married! Miss. Brack becomes Mrs. Richards. Loads of congratulation to Nicola and Sam, her lucky new husband. Here's to the bride and groom!

Nicola and Sam Richards

alan's picture

New SilverDisc Web Site Launched

A big day here at SilverDisc. We have launched our new Web site at www.silverdisc.co.uk. While this is very much a version 1.0 release, we're very proud of it nonetheless. For too long our own Web site has been a bit of a "busman's holiday".

Well done to all responsible, in particular Eric and Tony.

alan's picture

Google Adwords trademark policies: what's the billion dollar question?

The Google Adwords trademark policy is aimed at balancing the interests of trademark holders, advertisers and internet users. Does it always do this, or can it sometimes provide a method for trademark holders to restrict competition and potentially cause harm to advertisers, internet users and Google itself? That's the billion dollar question.

Google Adwords is a paid search marketing program offered by Google that allows millions of organisations around the world to advertise their products and services in Google’s search results. That makes Adwords a big deal. Adwords accounts for the lions’ share of Google’s revenues, which totalled $16.5bn in 2007 alone.

Yahoo! and Microsoft offer similar programs to Adwords. However, Google is the market leader, with estimates of its paid search market share ranging from 58% upwards. Google clearly holds a dominant position within the paid search marketplace, so its policy decisions matter.

Google’s dominance has created a significant demand within Adwords from third party advertisers who would like to market products and services against the results of popular trademarks which they do not own. As a result, there have been several instances where Google has faced legal action by trademark holders trying to restrict third parties bidding on those search terms relating to their trademarks. Trademark holders in the US, such as Geico and American Airlines, have previously filed suit . In Europe, Google has been sued by the likes of Louis Vuitton in France .

These legal actions led to the introduction of the Google Adwords Trademark Policy. There are in fact two policies, one or other of which is in force in any location around the world. These policies allow the trademark holder to exert significant influence over the use of their marks within the Adwords program.

Whilst it may seem a reasonable response on the part of Google to seek to recognise and protect the rights of trademark owners, especially in response to suggestions Google may be facilitating passing off and/or infringement of registered trademarks, the problem is that the Google Adwords Trademark Policy may in fact give far more power to trademark holders than they need to protect their goodwill and prevent passing off. Google’s trademark policies may fail to recognise the legitimate right of third parties to use registered trademarks which they do not own to legally sell products and services which they have a right to sell and facilitate Trademark holder to restrict free trade in goods and services.

For example, in the motor market, many private individuals, non-franchise and franchise dealers have a legitimate right to use manufacturer and model trademarks in order to describe a car or range of cars they wish to advertise.

An example would be if you wished to sell your Peugeot 308. Do you really want to have to call it a mid size French 1.9 litre diesel hatchback? Somehow the sale is much more likely to happen if you just call it by its make and model rather than a bland description.

Clearly in this example there is no passing off and no loss of goodwill. It is completely understood by all parties that the advertiser of the car is not necessarily the trademark holder. Yet Google’s trademark policies mean that advertisers can be prevented from using trademarked terms even so. Has this policy really balanced the interests of trademark holders, advertisers and internet users, as Google purports to do? Commenting, Kevin McGuinness of London-based commercial law specialists Sabretooth Law stated

In restricting the use of trademarks Google may have diminished the ability of non-owners of trademarks to legitimately use such trademarks in the course of carrying on their trade. Given the size of the market in which Google operates and the importance of the advertising market to automobile resale sector this is likely to be an area where both English and European competition authorities may take an interest in arrangements which potentially restrict competition to the detriment of the general public.

Antitrust or anti-competition issues have been one area where both the UK and European competition authorities have consistently demonstrated a keen interest in protecting the European consumer and Google’s dominant position in the paid search marketing sector would suggest it needs to ensure its policies are legal, not only in the US but also in Europe.

In the UK, an organisation can be fined 10% of its worldwide annual revenues for engaging in anti-competitive behaviour. As noted earlier, these amounted to $16.5bn for Google in 2007 alone, so 10% would be $1.65bn. That is a large number!

Is it Google’s responsibility, though, or is it the responsibility of the respective trademark holders? Or is it both?

It seems harsh to hold Google solely responsible, when Google has been simply trying to respect trademarks holders’ legitimate rights; especially in light of the fact that Google has been sued by several trademark holders and to some extent its trademark policy is a result of that. In addition, by restricting competition on some trademarked terms, Google may have impacted its own revenues. Kevin McGuinness again:

As Google is the participant in the on-line market place, which is itself restricting the availability for use of other persons’ trademarks, it could be that Google, not the trademark holders, may be found to be at fault. This hardly seems fair given Google’s long standing commitment to ethical good business practice.

Clearly Google does not exercise its trademark policy in isolation. Only when a trademark holder files a trademark complaint in the appropriate jurisdiction does Google exercise its policy. This is why you can see Google Adwords for lots of trademarked terms, but not all.

Evidence of how trademark holders are working with search engines came in a recent interview with New Media Age magazine (subscription required) when Steve Bowler, Marketing Manager of Land Rover, stated:

One of the areas that wasn't looked at properly before was search. Previously it was recognised as being somewhat important yet ancillary to TV, press and outdoor. Now, though, we take search very seriously, working with the search engines on how to deal with issues like trademarking.

As a result, Kevin McGuinness states:

Competition authorities could conclude that Google and trademark holders are each using Google Adwords to prevent competition.

Not only Google but each individual trademark holder could be investigated and potentially fined up to 10% of global revenues. Trademark holders who have restricted their trademarks include Alfa Romeo, Peugeot and Land Rover.

Do the same issues also affect Yahoo! and Microsoft? No. Both of these search companies have much more targeted trademark policies. For example, Yahoo!’s policy is:

As applied to nominative uses of another's trademark, Yahoo! Search Marketing requires advertisers to meet one of the following two conditions: ... Reseller [... or ...] Information Site, Not Competitive

And Microsoft’s policy, though targeted, is elegantly simple:

Affiliates and resellers may bid on trademarked terms relevant to the goods, services, or sites that they promote.

Why does Google not have such a simple policy? Perhaps because, though simply stated, the Yahoo! and Microsoft policies require more editorial intervention than the Google policy, or perhaps because Google’s current policy arises from being sued by trademark holders, rather than being pursued by competition authorities. Google’s official response is posted on their Inside Adwords Blog:

We will not allow the use of a trademark term according to the parameters of the trademark complaint filed by the trademark owner. Therefore, unless the trademark owner specifically grants you permission to use their trademarked term by contacting our Trademark team, we are not able to approve the use of the trademark in your AdWords ads.

There is no explanation there, nor has one ever been offered on the many occasions Google has been given to comment on this issue, but one can only assume that Google believes it is on solid legal ground in operating this policy. The question is: are they correct?

Though a vast improvement on Google’s trademark policy, Yahoo!’s and Microsoft’s policies both restrict comparative advertising (advertising which “explicitly or by implication, identifies a competitor or goods or services offered by a competitor”). A recent European court case showed that such restrictions may be unlawful . However that is a different, and far less contentious, issue than the anti-competition issues raised by the Google Adwords Trademark Policy alone.

So, the question remains. Has Google and/or its advertisers been in contravention of UK or EU competition laws in exercising its trademark policy to date? Microsoft's European court experience should provide ample evidence that American software giants need to be very careful within the European Union. Once the EU competition authorities decide to bite, they rarely let go of their prey quickly. Given the enmity between the two, will Microsoft be at the head of the line to point out the ongoing competition issues in Google’s trademark policies?

Google has, since its inception, been a beacon of best business practice, but it may be on the wrong side of this legal issue by trying to do the right thing by trademark holders who continue to abuse its policies in order to restrict fair competition. With fines of up to 10% of global turnover possible, it’s a high stakes issue.

alan's picture

SilverDisc Celebrates 15th Birthday

SilverDisc is 15 years old today!

SilverDisc was established on March 10, 1993 by three people (Alan Perkins, Allan Todd and Eric Barfield) who had met while working on interactive CD applications at Philips in Surrey. That is why the company is called SilverDisc – because its first products and services were delivered on CD, a “silver disc”.

Alan, Allan and Eric were three guys who enjoyed making a living while having fun doing techie things. Well, they considered it fun anyway! In 1993 they were using very low speed dial-up modems and Compuserve to communicate with each other and a small world of CD developers. In 1994 they got their first Web server and started hosting Web sites for clients. In 1995 they developed a fully functional shop with online credit card capabilities for one client, and started hosting the Web site for HarperCollins, a major publisher – not bad going for three guys working from home and having fun.

Early Years of Search Marketing

In late 1995, on the day AltaVista launched, SilverDisc realised the potential that search engines held for marketing purposes. They started marketing themselves and their clients through search engine optimization, although that phrase was not in use at the time.

During the mid-to-late nineties SilverDisc continued to deliver CD and DVD products and services as well as Internet services and Internet marketing. It remained three guys having fun. Then, a few things happened in quick succession:

  • Allan moved back to Scotland and got a real job working for somebody else – he wanted his young family to get a “proper Scottish education”
  • Alan moved back to Northamptonshire, mainly to tap into a support network for his young family, but remained with SilverDisc
  • Alan and Eric teamed up with a distant relative of Eric’s and formed a new company, e-Brand Management, to take advantage of the “dot com boom”

1998 to 2000 was spent developing patents, products and services based around some ideas that Alan had in the years since 1995. In parallel, SilverDisc continued to service its existing client base.

The patents were filed in 1999 and have since been granted. They cover some very fundamental search engine ground. One patent is in crawling and indexing, and the other is in personalisation – both are hot topics today, nine years later. The first product, Search Mechanics, was launched at the very first Search Engine Strategies to be held in the UK and e-Brand Management was one of only five exhibitors there.

That covers "SilverDisc - the early years". In a future post, I'll look at what has happened since 2000. :)

Syndicate content