research

LBi and bigmouthmedia release their Innovations in Retail whitepaper

Today LBi and bigmouthmedia release their Innovations in Retail whitepaper, covering the impact of digital technologies on retailers in 2011. Full disclosure – I contributed towards the paper, but it is worth blogging about because it highlights how rapidly the internet is changing expectations within the retail sector. It also provides a really strong summary of some of the opportunities that exist for those able to rapidly innovate.

Playmobil Apple Store

Just yesterday Apple celebrated their tenth year in retail with a store makeover that put the iPad 2 at the forefront of the shopping experience, acting as the product price label and spec sheets. What’s more, the iPad’s enable you to hail an Apple Specialist and compare products as well as enabling Apple to centrally update prices worldwide instantly. It isn’t an option yet it will be would be much of a surprise to see if the iPads offering ‘I want this!’ style social sharing, direct from a traditional retail environment.

Of course, the LBi and bigmouthmedia whitepaper contains plenty of talk about smart phones, tablet devices and internet connected TVs but what is interesting is that the paper steers clear of the standard ‘more people are buying stuff on a mobile’ vernacular and highlights some of the less obvious behaviours such technologies create amongst consumers.

I myself am what is now dubbed a ‘digital shoplifter’. I enjoy the ability to browse a real physical retail environment yet when I find something I want to buy my first reaction is to check the price online via my iPhone. If the price difference is greater than my perceived ‘instant gratification’ value, then I’ll just leave the shop and order online.

This clearly represents a challenge for bricks and mortar retailers, but it also suggests a shortcoming amongst online retailers too – they still are not able compete with the feeling of holding a product in your hands. And cruciually, outside of entertainments and media where digital downloads get you close enough, no-one can get delivery times down to zero. There will always be a desire to get things sooner!

Also as important for retail is the impact of technologies that bridge the physical and the digital. Much more than allowing consumers to pay for items by flashing their phones, the impact of mobile technology within a retail environment could be huge. Imagine offering users instant in store recommendations based on their online purchase habits or instant credit via QR or NFC (Near Field Communication) for checking in via social platforms.

Social media is also becoming hugely disruptive within retail, as the paper points out. The move towards customer service within a social environment will almost certainly have its winners and losers  - only by sharing customer service and support tasks with their most engaged customers will retailers truly get the most from social channels.

It is clear that consumers’ expectations are on the rise and that retailers will need to continue to search for ways to reward loyal, engaged customers with unique and surprising experiences. Take a look at the full paper to find out how – it is available for free online now.

Tags: , , , , , , , , , , , , , ,

0 comments Add This

A look at automotive websites

We recently had a brief look at 10 automotive websites and assessed them based on seven key tasks (Searching for a new car, customising the car, booking a test drive, finding a used car, finding a dealership, booking servicing and contacting the manufacturer). We also looked at the features offered in the owners’ areas as well as reviewing their usage of social media across the site.

We looked at the websites of the following car manufacturers: Audi, Citroen, Ford, Mazda, Peugeot, Renault, Skoda, Vauxhall, Volvo and VW

Searching for a new car

On most of the sites the customer is expected to know the model of the car they want to find information on. A few of the websites (Ford, Renault and VW ) allow the user to filter the models by several criteria.

A few of these websites also allowed the user to save the chosen models to a shortlist and compare them to each other. Volvo also offers a comparison tool that compares the cars to those from different manufacturers.

VW offer filtering tools by default on the Car Range page, as well as allowing users to compare up to four cars. Ford do the same though it is not surfaced as well.

VW offer comparison directly in the cars section

Customising the car

All of the sites reviewed offer a “build your own car” functionality with varying degrees of visualisation provided for the end product

Several websites are very good at informing the user when needed. For some reason, Volvo has two configurators – style your car and build your car. The second tool has very good contextual help and visualisation. It also shows a running total of the price and clearly indicates how much extras are going to cost.

Volvo's Build your own car

A few websites used engaging customisation tools. VW, for example, had very pleasing visuals and informative content.

VW has fun interactive configuration tools

Most of the customising tools showed a running total but pricing was not very clear on several of them (e.g. Audi)

Audi's configurator does not provide clear pricing information

Booking a test drive

All of these websites offer test drive booking. This tends to be handled by a link on the home page though Audi had placed it in a separate section titled “About Audi” in the global navigation bar.

Booking a test drive is not surfaced

Generally the user fills in an online form that specifies their name and phone number as well as the model they wish to test drive and the dealership they wish to do this at. A few websites allow the user to also book a date and time for this (Renault, VW )

On Skoda’s website, the user starts the test drive booking by completing a postcode search for the nearest dealership, whilst Vauxhall has a global link for test drive booking that opens to a lightbox where the user enters the required details.

Vauxhall uses a lightbox for test drive booking form

Renault’s test drive booking system allows the user to book a specific time on a selected date.

Finding a dealership

All websites offered a dealership locator service. In most cases this is handled through a link on the home page.

Most of the websites offer filtering options before the search to ensure the user locates a dealership that offers all the services they need. For example, VW’s retailer search allows filtering by service required and clearly indicates which services are available at each branch.

Vauxhall offers a route planner on their website to provide the user with driving instructions to the dealership.

Vauxhall offers a route planner to the dealership

Finding a used car

All of the websites reviewed offer used cars and filtering for the used car search results as well as a comparison tool. Vauxhall has a separate site for used cars which specialises in this service and has good filtering and comparison tools.

On most sites, the used cars section does not tend to match the overall design of the website (e.g. Skoda’s main site and their used cars site)

Mazda’s used car locator offers a good range of filters for the cars and will remember the search when the user returns to the page.

Booking servicing

Servicing options are generally displayed in the owners’ area of the websites or as a separate category through the home page of the site. Only Audi and Renault allow the user to book servicing online

Renault require the user to save information about their car into the “My Renault” section whilst Audi ask the user to enter some details into an online form.

Vauxhall have an area for owner services which also includes servicing options, though no online booking

Contacting the manufacturer

Whilst all of the websites we looked at did have a separate section for contacting them, most of these were very limited with some only providing a webform (e.g. Vauxhall )

Out of the sites reviewed, only Volvo offered different contact services for people who already owned one of their cars. A few websites had arranged their contact details by the topic that the user wished to contact by but these sections tended to be quite text- heavy (e.g. Audi )

Renault has arranged the contact section into areas based on the user type and question topic.

Owner’s area features

Most of the websites featured owners’ areas – only Volvo and Mazda did not have a specific section for owners

Most of the owners’ sections concentrated on providing information on the service and maintenance plans sold by the manufacturer. Out of the websites reviewed, only a few offer additional value- Renault provide this by hosting a fairly active forum as well as displaying the standard servicing and warranty options, whilst VW’s owners area allows for saving car shortlists and configured cars as well as storing information on current cars.

Social media usage

Social media usage across the sites varied. Most sites we reviewed did not heavily feature social media functionality, some providing the user with an option to “Like” their brand on Facebook (e.g. Citroen ) only.

Vauxhall and Volvo offer the option of sharing a completed car configuration through a range of social media platforms.

Vauxhall allows sharing to social media

Vauxhall also provides links to their YouTube channel under each of the model pages. Renault feeds in their tweets to the My Renault section as well as hosting a forum for Renault enthusiasts.

Mazda is hosting a Yahoo lifestyle section called Mazda mums which has a competition running for advice from one mum to another, as well as having articles on motoring with children, aimed at mums.

Tags: , , ,

1 comments Share

Search engines still struggling with Internationalized Domain Names (IDNs)

Internationalized Domain Names (IDNs) are now a reality and in use by websites right now. Unfortunately, it seems that the search engines are still playing catch-up.

Skip to start of post

Introduction

Note: If you are unable to view the Arabic and Cyrillic letters in this page you may need to install the required fonts.

Now that the first Internationalized Domain Names (IDNs) have gone live and have had some time to get established, it seems like a good time to revisit the finding of my previous article on IDNs “Can search engines handle Internationalized Domain Names (IDNs)?

IDNs went live initially for three countries, all using the Arabic alphabet: Egypt (مصر); Saudi Arabia (السعودية); and the United Arab Emirates (امارات). Russia’s new IDN (рф) went live a little later, adding the Cyrillic alphabet to the mix, and additional IDNs have been created for other countries and alphabets. For this article I’ll take a look at how search engines handle these four IDNs.

To get an idea of how extensively the search engines have indexed sites on these new IDNs I’m going to use the “site:” operator. Although this operator is primarily used for finding pages on a particular website, e.g. [site:lbi.co.uk] it can also work all the way up to the TLD level, e.g. [site:uk].

Searching Google for [site:مصر], [site: السعودية], [site:امارات] and [site:рф] returns results from the IDNs  for Egypt, Saudi Arabia, the UAE and Russia as expected. Whilst the new IDN for Saudi Arabia only had 14 pages indexed when checked, the other IDNs all feature thousands of results.

Screenshot of a search for [site:рф] in Google:

Google search for site:рф

Trying the same searches in Bing, however, does not return any results:

Bing search for site:рф

It appears that the site: operator does not work with these new IDNs in Bing (searching for other domains, e.g. [site:com], works as expected).

IDNs in search results?

The next area tested is whether the search engines will return these domains in their search results. To test this I picked out some random web pages on the new Egyptian IDN and tried searching for their title tags in both Google and Bing.

Searching both Google and Bing for the title of one web page, [مراكز التميز في البحث والتطوير - وزارة الإتصالات], brought up a number of web pages. The results from Google and Bing both contained a result from an IDN:

Google snippet featuring an IDN:

Google snippet featuring an Arabic IDN

Bing snippet featuring an IDN:

Bing snippet featuring an Arabic IDN

More IDN bugs

Earlier I described how Bing’s site: operator does not yet work with IDNs. However, Google also has a number of IDN woes. Searching for [site:مصر] (the new IDN for Egypt) brings up the site سجل.مصر – however, clicking on the “Show more results from سجل.مصر” link in Google appears to be listing sites on domains other than سجل.مصر. Additionally, the “Show all results” link is percent encoded rather than listing the site name in the Arabic font.

Screenshot of Google IDN bug

In my previous look at how search engines handled IDNs I had found that Google’s links to “Translate this page” and “Cached” were broken for IDNs. Today it appears that Google has fixed the translation links – however, the cache links still do not appear to function.

Conclusion

The situation is much the same as it was back in February. The search engines can index websites which use IDNs – however, all of the major search engines still have bugs with their IDN support.

Given that the number of IDNs is set to grow and the number of websites using IDNs is likely to vastly increase in the near future, it’s vital that the search engines iron out the bugs in their IDN support. After all, if a search engine can’t handle websites from a particular properly, people might decide to switch to a search engine that can.

Tags: , , , , , , , ,

0 comments Share

SEO breadcrumbs for site hierarchies in Google

This latest LBi research explores Google site hierarchies and SEO best practice for implementing breadcrumbs in order for them to be picked up by Google.

Since November, when Google announced the arrival of ‘site hierarchies‘, we have been considering the best method of adding breadcrumbs to your site in order to be picked up by Google and added to its search results pages. The official advice provided in this Google Webmaster video for implementing breadcrumbs is somewhat vague, simply being to use a

“Set of delimited links on your site, that accurately reflect your site’s hierarchy.”

So we decided to investigate exactly what this means in terms of best practice for SEO, in order to provide the best chance of having your breadcrumbs picked up and used within Google search results. It is worth noting that Google indicates that this has not yet been rolled out for all sites:

“By analyzing site breadcrumbs, we’ve been able to improve the search snippet for a small percentage of search results, and we hope to expand in the future.”

Of course, whether having these site links is beneficial to any particular site needs to be addressed on a case-by-case basis. It will depend on whether a particular site is well suited to the use of breadcrumbs, and how your site uses top-level category pages within your site hierarchy.

A few notes on general best practice for breadcrumbs

Breadcrumbs are a secondary navigational feature used in combination with main navigation elements on large hierarchical sites. They provide a reference as to where a user is within a site’s hierarchy and help the user to quickly navigate to a higher level. This also provides the associated benefits of improved usability and reduced bounce rates.

Google’s definition of ‘delimited links that match your site’s hierarchy’ is a good description of breadcrumbs. The ‘delimiting’ character is usually a ‘greater than’ symbol, or ‘>’, which contributes to usability through recognition of uniform navigational elements. There should be no more than a few levels, and the link should start on the homepage and end on the current page. The last ‘breadcrumb’ should not be a link, as it would simply link to the current page and having a description of the current page written with no link provides additional navigational context.

The research

In order to investigate the use of breadcrumbs, we found existing examples of instances in which Google either has or has not picked up a set of delimited links and used them in its results pages. We selected 15 three word queries including keywords with navigational, informational and commercial intent, and analysed the top ten results in Google.co.uk, a total of 150 sites. We initially selected a larger sample, but retrieved enough data to make assertions sooner than expected.

Where to place breadcrumbs on the page

Breadcrumbs are usually seen at the top of the page just under the main navigation. In terms of the Document Object Model (DOM), you can expect to see breadcrumbs some way into the code. They are a secondary navigational element, included after the primary navigation and contained within the hierarchical environment of the DOM. With the addition of CSS, which can place elements anywhere on the page regardless of where they reside in the code, it is unsurprising that we found examples of breadcrumbs lower down the page, and even at the bottom of the page which triggered Google site hierarchies in search results.

However, we recommend placing breadcrumbs at the top of the page for best usability, as this is where most people will search for and recognise them.

Where to place the ‘delimiting’ characters?

Logic prevails here: the ‘delimiting’ characters should be placed in between the links. We saw a couple of sites which had either preceding or trailing delimiting characters, and these did not get picked up by Google.

Which ‘delimiting character’ should be used?

We wouldn’t advise against using any particular characters until further testing has been undertaken, although we found site hierarchy links in the search results for sites using ‘>’, ‘> >’, ‘›’ and ‘»’ characters, with white space and inline elements appearing to be inconsequential (see this example of bold tags on the home link).

The golden rule here is to make whatever is between the breadcrumb links identical, which was the case for 100% of sites which had breadcrumb links in Google results pages. Where this was not the case, breadcrumb links were not attributed to the page.

As a side note, we also found examples which did not use any characters at all, but used block level elements instead, such as the London School of Economics Website, which has a hierarchical structure and no breadcrumb links. Links in the main left hand navigation are separated via individual ‘<div>’s, which were picked up by Google and included in the results pages. This could of course be a false-positive, given that the ‘>’ character is included in the code between the links, but is unlikely.

Other tags which were found in breadcrumbs which were included by Google in the results pages included; ‘<li>’, ‘<div>’, ‘<td>’ and ‘<p>’. In each case, as with the LSE website, they were added between links in a uniform manner.

In summary, the most common method of indicating site hierarchy to Google is by separating links with a symbol such as ‘>’, ‘> >’, ‘›’ or ‘»’, but other methods involving block level elements may be used. This will need to be tested before we can recommend exactly which block level elements to use, and may prove useful where more advanced or decorative breadcrumbs are desired.

Can images be used to separate breadcrumbs?

From the sample we looked at, no images were found in the set of sites which did have Google site hierarchy links, but images were found in the set which did not, even though they had breadcrumb links. The same was the case where CSS was used to insert images as dividers.

As a best practice, we would advise against the use of images as breadcrumb link delimiters. However, we have noted that a site may be able to use images and be picked up by Google if images are contained within block-level elements or combined with relevant characters and appropriate replacement techniques. This is something which we will need to test.

Does a site need to be strictly hierarchical?

The short answer is no. Take this example from South West Water,
where the majority of the pages are numbered using a URL variable. The internal link structure and breadcrumbs are the only clues to the site’s hierarchy. Another example of site hierarchy links showing in Google even though the URL is not hierarchical is Yahoo! Shopping. You will need to follow the link to fully appreciate this. For many reasons, it is best to provide a hierarchical structure, but in a case where this is not so, breadcrumbs make an ideal addition to a site until such time as a redesign structural overhaul is feasible.

Should the first breadcrumb link to the homepage?

We found site hierarchy links in Google search results for pages both with and without breadcrumbs including links to the homepage. From a usability perspective, this is useful, in that where you have a large number of directories, missing the first few may still indicate site hierarchy for search. It is worth noting that the majority of sites do include a link to the homepage in breadcrumbs, and that we would recommend including this as it provides additional context to the hierarchical structure denoted by the breadcrumbs.

Should the last breadcrumb be a link?

We found examples of site hierarchy links in Google from both pages which did and pages which did not use the last breadcrumb to link to the current page.

It provides no benefit to the user if the last link points to the current page, and if the last breadcrumb is simply a description of the page with no link, it can only add to the relevance of the page and context of the breadcrumbs. It says “you are here”, which adds to the usability of the breadcrumbs.

Therefore our recommendation is to have a trailing breadcrumb for the existing page which is not a link. However, if it is, it will not stop you from gaining site hierarchy links in Google.

Can breadcrumbs be cross-domain or cross-subdomain?

Sites which we found with breadcrumbs which contained cross-subdomain links were not included in Google site hierarchies. Bearing in mind that the root domain is listed in the search result, this would render the hierarchy links inaccurate.

Semantically, what code should be used to mark breadcrumbs?

Although HTML lists lend themselves well to writing breadcrumbs, and were used in several examples of sites which were included in Google’s site hierarchy links, breadcrumbs are, by their hierarchical nature, not a list. HTML lists enable the use of customisable bullets to delimit links, but via CSS, which is not written to the page. Only where the list elements were separated by a delimiting character were breadcrumbs included in the search results.

It makes sense to contain the breadcrumbs within a block level element in order to distinguish them in the code, as well as to provide a clear signal to Google as to which content is actually your breadcrumb links. We would recommend using a ‘<div>’ element specifically for this purpose. The breadcrumb links should be placed inside the block level element and should then be separated by the same ‘delimiting’ character (most likely ‘>’). The same number of new lines should be used between each link (no new lines are required, but using one in between each link and each delimiting character will increase code readability).

Should you ‘label’ your breadcrumbs?

Often, breadcrumbs are labelled in the code as IDs, Classes or similar, with names such as ‘breadcrumbs’, ‘crumbs’ or ‘sitenav’. This is not required. We found examples of both labelled and non-labelled breadcrumbs which had been recognised by Google.

That said, there is no reason why you cannot label your breadcrumbs. A label in the code will make it more readable, and it won’t hurt to give an extra clue to search engines as to the content held within the containing element.

Semantically, an ID should be used over a Class, as an ID is a unique identifier to an element on the page, whereas a class can be used multiple times.

How long does it take for breadcrumbs to be found?

A ‘site:’ search in Google, followed by a restriction by date will show that pages are indexed faster than they have the breadcrumb links added. It was noted that this sometimes happens a handful of weeks apart, which suggests that it is a separate process which considers site hierarchy links outside of general indexing procedures.

Best practices for writing breadcrumb code

Based on our findings, an example of the ideal code layout for breadcrumbs is:

<div id="breadcrumbs">

<a href="http://www.cheese.com/">Home</a>

&gt;

<a href="http://www.cheese.com/soft-cheese/">Soft Cheese</a>

&gt;

<strong>Brie</strong>

</div>

A breakdown of the above code elements is as follows:

  • Hierarchical links which match the structure of the site
  • A link to the homepage
  • A reference to the page the site is on rather than a link
  • Contained within a ‘<div>’ element with an ID of ‘breadcrumbs’
  • Uniformly divided links using ‘>’ symbols as ‘delimiting characters’, written as ‘&gt;’
  • Single line break between lines (no line break is required, but adding them makes the code more readable. Remember that if you do add any to keep the number of lines consistent between links.)
  • As per our standard recommendations the inline tag <strong> has also been added to emphasise the keyword in the breadcrumb relating to the current page

A final thought 

Bearing in mind that Google has said it is still experimenting with site hierarchies and that some sites may not be suitable for site hierarchy links (think Wikipedia, or sites with minimal architecture), it does not mean that just because breadcrumb links are implemented a site will receive site hierarchy links in search results (in fact, sites which were setup by LBi to test site hierarchies are still not achieving site hierarchy links).

In addition, the code above is not definitive and, as stated in this article, inline elements such as ‘<b>’ and ‘<span>’ may be added without preventing Google from understanding your breadcrumbs. That said, unless abso
lutely necessary, this is probably best avoided.

For further information on Breadcrumbs, see this article on Smashing Magazine which provides some useful information outside of the scope of this article.

Tags: , , , ,

1 comments Share

Can search engines handle Internationalized Domain Names (IDNs)?

Internationalized Domain Names (IDNs) have been approved by ICANN and are set to become a reality. Are the search engines prepared for them?

Skip to start of post

Introduction

Note: If you are unable to view the Chinese and Arabic letters in this page you may need to install the required fonts.

In October 2009, ICANN voted to allow the use of non-ASCII characters in domain names. Non-ASCII characters have existed within domain names for a while – for example, many Hong Kong sites feature Chinese characters (example: http://香港儒釋道院.組織.hk). However, before now, these characters were not allowed within TLDs and, as such, URLs still required ASCII characters (in the example above, the ccTLD “.hk”).

ICANN launched the IDN ccTLD Fast Track Process in November, and last month announced that four top-level IDNs had successfully passed the initial stage of approval (three Arabic-language IDN ccTLDs for Egypt, Saudi Arabia and the United Arab Emirates, and one Cyrillic-language IDN ccTLD for the Russian Federation). At the time of writing, there are another 13 IDN ccTLDs on their way through this process, representing 10 different languages in total.

In order to provide the Internet community time to prepare for the rollout of new IDN domains, ICANN has set up a number of IDN domains for testing purposes. Each of these test domains is written as “example.test” in it’s respective language, and content has been made available to view on each site.

Seeing as most of the initial IDN ccTLDs are likely to be in Arabic, I have used ICANN’s test Arabic domain (مثال.إختبار) for my research.

Before I start, I need to quickly explain what Punycode is, as it it used to support the addition of IDN domains to the existing Internet infrastructure. The problem with the current system is that the Domain Name System (DNS) only allows certain ASCII characters, which means that it is not possible to simply add Unicode characters to it. Punycode was invented to get around this issue. Essentially, it is a method by which Unicode characters can be translated to (and from) the ASCII characters allowed within the DNS. When your browser requests a domain name containing Unicode characters, it converts it to the ASCII-formatted Punycode before sending the request.

For this experiment, I have looked at the way in which the search engines handle both the Unicode form of the Arabic domain (http://مثال.إختبار/) as well as the corresponding Punycode format (which, in this case, is http://xn--mgbh0fb.xn--kgbechtv/). Note that, because Arabic is an RTL (right-to-left) language, pages on this site will have the URL path to the left of the hostname, rather than to the right.

One last note before we look at the results – the test page does not feature a meta description tag, so any snippet text is likely to come from text within the page itself.

Here are the results.

Google

Searching Google for the Unicode variant of the URL returns the homepage of the domain as the first result, with an additional nested result for a second, internal page on the domain:

  Google Unicode

Initially, everything seems to be in place here. The title tags, snippets and URLs are correctly displayed in Arabic, and Google has highlighted the search text in bold as usual. Additionally, the “Similar” pages link works, and the “jump to” successfully takes you to an anchor within the page. Lastly, the URL path is written in the correct RTL form for the second result.

However, not all is well. The first URL that Google is listing, the homepage, is actually a 301 redirect to an internal page. Google should be indexing the destination page, not the redirecting homepage.

There are several other issues too. Firstly, the cached copy link did not work:

Google cached copy

I tried a number of pages on the site and Google’s cached copy did not work for any of them, so Google may have an issue with this feature at present.

Additionally, the “Translate this page” links for both results do not correctly function, and an error message is shown:

Google Translate error

Side note – the “See original page” link does correctly point to the Arabic domain name.

Next I tried searching Google for the Punycode form of the URL:

Google Punycode

Google has returned the same two URLs, which is a good sign of consistency. The title tags are the same, and the URL is still written in Arabic and not displayed in the Punycode form.

This time around, Google has picked out some text on the page which matches the Punycode search term. Although this particular snippet is rather less attractive than the ones from the previous query, matching the exact text on a page is probably the best approach. However, it would also make sense for Google to at least highlight the Unicode version (for example, in the URL), which it currently does not do.

Again, while the “Similar” pages link works, the “Cached” and “Translate this page” links are broken. This seems to be an issue that Google needs to fix.

Yahoo!

Searching Yahoo! for the Unicode or Punycode version of the URL does not return any results from the domain:

Yahoo! Arabic domain fail

Similarly, entering the URLs within Yahoo! Site Explorer simply redirects back to the main Yahoo!
search results. Performing “site:” searches (for either variant) also fails (looking at the HTTP headers, you can see that Yahoo! actually redirects the query to Site Explorer, which then redirects you back to the standard web search results).

I tried a few additional ICANN test IDN domains in other languages and none of them worked. Yahoo! seems to fail completely at handling IDNs.

Given that Yahoo! is likely to use Bing’s search in the future, let’s see how Bing performs next.

Bing

Searching Bing for the Unicode version of the URL does return a page from the site, although it’s at position 8, which is not ideal (when searching for a URL you would usually want the URL to appear at or near the top of the search results). The snippet appears as follows:

Bing Unicode

Only one URL is shown, which isn’t quite as useful as Google’s result, but is still adequate. The title tag, snippet and URL are all correctly shown in Arabic, which is good. The “Translate this page” and “Cached page” links both work, whilst they didn’t on Google.

Bing does have some issues, however. Although Bing has indexed the destination URL (the link goes directly to the destination URL), for some reason Bing only displays the URL of the homepage in the snippet. Additionally, although Bing has highlighted the domain in bold in the snippet, it has not highlighted it within the URL.

Bing does have a number of problems with its handling of this domain. However, they are fairly minor and definitely less important than the issues that Google has with this site.

Searching Bing for the Punycode version of the URL, Bing returns the URL at position 2 instead, which is a bit better:

Bing Punycode

Again, like Google, Bing has picked out the text from the page which matches the query for the snippet but has not highlighted the Arabic equivalent in the snippet. Otherwise, this result is much the same as the Unicode search variant.

Ask Jeeves

I have also looked at Ask Jeeves (known as just “Ask” in the US).

Searching Ask Jeeves for the Unicode version of the URL returns the site at position one. Like Google, it includes a second indented URL at position two. Interestingly, these are the same two URLs that Google returned for this search (it is worth remembering that Ask Jeeves might be using Google’s results at times).

Ask Jeeves Unicode

Ask Jeeves is correctly displaying both the title and the snippet in Arabic, but the URL is written in the Punycode form instead, which is clearly far from ideal.

There is another major issue with Ask Jeeves’ implementation – the second URL goes through a redirect, but the hostname given by the redirect has been encoded in a way which makes Firefox and Internet Explorer fail to load the page (Google Chrome and Opera did successfully load the page from the redirect). Note: This does not always happen – reloading the page sometimes returns the URL without the redirect, and in this case it works correctly.

Searching Ask Jeeves for the Punycode version of the URL results in much the same as we have seen earlier. Again, the snippet includes the text from the page which matches the query. Ask Jeeves includes a small screenshot of the page too:

Ask Jeeves Punycode

Ask Jeeves’ binoculars feature, which displays a small thumbnail screenshot of the site, does appear to work correctly. However, it is possible that there are issues here as well.

Ask Jeeves Binoculars

Although it’s difficult to make out due to the small size of the thumbnail, it appears that the English text renders correctly but the Arabic text (although correctly displayed in an RTL fashion) looks like it might be showing a nonsense placeholder character, in the same way that web browsers which do not render Unicode characters do. That said, it is difficult to determine for sure from the small thumbnail that Ask Jeeves provides.

Conclusion

In conclusion, Google, Bing and Ask Jeeves do support IDNs to varying degrees. If I had to proclaim a winner at the moment, I would say that Bing had a slight lead, but all of these search engines had some issues. Hopefully these issues will be ironed out by the time that IDNs eventually roll out en-masse.

Yahoo! appears to completely fail to support IDNs at present. Once it switches to Bing’s search engine, however, we assume that it will inherit all of Bing’s IDN support as well.

Tags: , , , , , , , , , ,

2 comments Share