Digital Iconoclasm

iPhone *go SMS bug/hack

2009-05-19T07:15:00.000-07:00

A friend freaked me out recently when he sent a SMS to my iPhone. There seems to be a bug/exploit/hack whereby prefixing the text in an SMS message with *go makes the recipient's iPhone look like this:

This was a result of sending myself the SMS

*go Your iPhone belongs to me

on the UK's O2 network. It seems to interupt whatever you're doing. I haven't tried it while using an app yet, but that would be really annoying.

Here at Wahanda we're big iPhone fans, but it makes you wonder what other undocumented iPhone commands are out there.

This only works iPhone to iPhone (i.e. you can't send the SMS from your Nokia to an iPhone). I'm sure that someone with more time that me will spend a lot of time putting the word *go in front of every verb in the English language...

I say tomato/, you say tomato?sort=name-desc

2009-02-20T03:07:00.000-08:00

Last week Google, Yahoo and Microsoft agreed to support a new HTML tag hidden in the head section of a webpage. The tag, which is generally called the canonical tag, looks like this:

<link rel="canonical" href="http://www.wahanda.com/"/>

This new tag is designed to help alleviate the issue of duplicate content; a real problem for any SEO conscious site. Basically the tag is an instruction to search engine crawlers that says "I don't care what URI you used to reach this page, the URI I want indexed is the one in the canonical tag".

For our site, Wahanda, this solves two problems.

The first is where a single page gets indexed under several different URIs, even though the content is identical. We recently had our Valentine's Day page indexed in Google under three different URIs:

/seasonal/valentines-day-gifts
/seasonal/valentines-day-gifts/
/seasonal/valentines-day-gifts?x=y

This is partially our fault; we should have 301 redirected all the variants to one 'canonical' form of the URI, but it's irritating that the engines don't compare the content of pages with similar URIs to see if they actually represent the same page.

The second problem for us is internal search result and listing pages. These two pages:

/therapists/pro-personal-trainer/in-london-uk
/therapists/pro-personal-trainer/in-london-uk-depth-1/sort-profile-name-desc

Are logically the same set of results, just with different sort orders. There is no value in having both of these pages indexed. In fact, for all listing pages we only really want to get the first page of results in the deafult sort order indexed. The canonical tag lets us do this by having the same canonical URI for all of the different views on this set of results.

This is all well and good, but supporting this tag means changes to a lot of pages for us. Verifying that a page has a canonical URI set and checking that it points to the correct page involves an awful lot of viewing-of-source and cutting-and-pasting. With that in mind, we've written a canonical tag Firefox extension to help. Hopefully it will be of some use to others!

When will my page be indexed?

2009-01-13T05:05:00.000-08:00

If you use Sitemaps, pretty quickly it would seem. Valentine's Day is an important event in the health, beauty and wellness calendar, so here at Wahanda we've launched a new Valentine's Day gifts page. Obviously we wanted this new page to be available in Google as soon as possible.

There are generally two ways to inform Google about a new page on a website: wait for Google to crawl you and find the page on its own or let them know by submitting a Sitemap. Sitemaps are explained in detail at sitemaps.org, but it's a way of letting the search engines know about all the pages on your site that you'd like to have indexed. Here's an example site map from Wahanda.

We've been debating the usefulness of Sitemaps for some time. Are they actually used by the search engines at all? Do they have any effect on the time taken to index and crawl a page?

Well with the Valentine's Day page, I tried to answer the second question. I published the page to the website, but made sure that no other page linked to it. I then added the URI to one of our Sitemaps and let Google know (through webmaster tools) that the Sitemap had been changed.

Google downloaded the sitemap in less than ten minutes and the page was available in the index less than two hours later.

Now this isn't a very scientific experiment, but we can see from our logs that Google treats Sitemaps very seriously. An updated Sitemap is almost immediately downloaded and every URI in the Sitemap crawled.

As always, the way Google works is a mystery, but having used Sitemaps for about nine months, we've come up with a set of techniques that seem to work for us:

Be honest with the 'priority' element. This is a scale from 0.1 to 1.0 which lets the search engine know the relative importance of pages within your site.
Only include URIs for pages that have real value and that you'd be happy for a new customer to land on (i.e. don't include every sub-page of every set of search results)
Don't update the Sitemaps more than once every two days.
Write an application to generate your Sitemaps programatically. They will get out of date very quickly otherwise.