The new version is version 2.0 and was completely redesigned focusing on speed, usability, new features and making it beautiful.

Here are the main new changes you will find in version 2.0:

• Complete App Redesign
• Full Screen Mode Option
• Faster Search Autocompletion
• Faster Page & Swipe Load Times
• Image Search Redesigned Adding Full Screen, High Resolution Images & Save Image Feature
• Swipe Away Web Pages To Return To Results
• Search Within Web Pages
• Faster Switching Between Images, Places, News, Web & Other Verticals
• Quicker Access To Google Apps

I am a bit surprised Google is making it that easy to save images from Google Image search to your camera roll, with the issues of copyright and Google Images – but they are.

Here is a screen shot of the new image search results page:

For more details, see the Google Blog.

Related Stories:

• Google Mobile iPhone App Gets Overhaul, Becomes Google Search App
• Google iPhone Search App Gets Doodles
• Google Tests New Colorful iPhone Search Design
• Official: Google Instant Now Available On iPhone & Android
• Google Custom Search Mobile For iPhone, Android & Palm Pre
• Google Brings Voice Search To The iPhone

Al was at the talk in Sydney and let me know that the smartphone bot had visited some of the sites he is responsible for and told me about the initial results. Mantra.com.au is the site we discussed most; iPhones and Androids are now showing the mobile-optimized urls instead of desktop urls in some (not all) searches.

While I am writing this case study up, Al gets most of the credit for his keen observations about the behavior of the bot and its impact on search results. As it may be useful to have a short case study out there, we’ll review the specific case of the smartphone bot, and how its indexing has played out in the Mantra mobile crawling, indexing and ranking.

Keep in mind this is just one site, and other sites may have different experiences with the smartphone bot, but here is what Al and now I have observed thus far.

Smartphone Bot Crawling

As I alluded above, I have done lots of research to see which sites are being affected and which are not. Many of the large sites do not appear to be showing evidence of the smartphone bot yet.

This includes sites like Facebook, Amazon and YouTube, which all still show ‘www’ desktop urls in searches from Androids and iPhones. Either the bot is crawling them and not indexing the mobile content, or perhaps I am not doing the right tests, to generate the mobile results (more on that later).

One of the most interesting aspects of this case study is that Mantra.com.au was crawled by the smartphone bot in early December, according to Al, slightly before the new bot was even announced (sneaky Google!). Al explained that their content has always been crawled quite regularly, and that they did not do anything special like submit a sitemap for the mobile subdomain or set up any special robots instructions, except to disallow content that did not belong in results at all.

The Mantra site is using conditional 302’s to redirect mobile traffic from the desktop pages to their mobile counterparts. Note that 302’s are much less common in traditional SEO, but very common in mobile user-agent detection and redirection, but a 301 would be fine as well.

The mobile optimized urls do not appear to be exact mirrors of each other, though they do match up in the final element of the file name; for instance, a vacation property in Sydney on Bond Street has the following two urls and meta data:

Desktop Url: http://www.mantra.com.au/new-south-wales/sydney-and-surrounds/sydney/accommodation/hotels/mantra-2-bond-street/

Desktop Title Tag: Mantra 2 Bond Street | Sydney Hotels | New South Wales NSW

Desktop Description Tag: The hotel is centrally located close to Sydney attractions such as the Sydney Opera House, Pitt Street Mall, Darling Harbour and The Museum of Contemporary Art.

Mobile Url: http://m.mantra.com.au/buildings/mantra-2-bond-street

Mobile Title Tag: Mantra 2 Bond Street Sydney NSW

Mobile Description Tag: NONE

Interestingly, the desktop title tag and description tags are still present in the mobile ranking, and so far, the only thing that has changed is the replacement of the desktop page url with the mobile page url as shown below.

This is not exactly what Google had promised in the announcement and description of how the bot worked:

Smartphone Bot Mixes Desktop & Mobile Page Info in the SERP

The crawler is relying almost 100% on the 302 redirect without additional signals of affiliation between the desktop page and the corresponding home page. Mantra is linking back to the desktop site with a text link at the bottom of every page, which uses cookies to stick the user to the desktop site, but it is a page-to-homepage link.

This is great, (and obviously good enough for Google) but it might not provide users or engines as much value as a page-to-page link could in the long term. Also, Mantra is not using canonical tags to help associate the mobile versions of the pages to their desktop counterparts.

Al really did a great job maximizing the crawl efficiency on the mobile site by minimizing DUST (duplicate url, same text). Here is what he told me:

“I’ve worked very closely with our in-house developers to minimize unnecessary redirects within the site & every iteration we’re dropping more & more where possible. We’re handling duplicate content using redirects and have currently handled URL casing (force lower case), protocol (can only view a URL in the intended protocol, but need to get that changed to a 301 as its currently a 302) and I’m waiting on another small update to strip trailing slashes via a 301 as well.”

Al also mentioned that he has made sure that the developers were eliminating unnecessary redirects and keeping the mobile code clean and light. He wins the gold medal here because this will all really ensure that all of his mobile and desktop content will be crawled and indexed without slowing the bots down – which is exactly what has happened.

Mantra Group is also using user agent detection to deliver a low-fi version of their mobile websites, allowing visitors using less capable smartphone devices to transact online instead of simply saying “your device isn’t supported”.

Smartphone Bot Indexing

While this has not been stated outright, there has been no mention of a new smartphone index, and historical Google mobile rankings indicate that they think that it is perfectly acceptable to rank and serve desktop pages to smartphone searchers.

This is also in-line with the recent history of Google updates, in which Google appears to be trying to speed up the delivery of their SERPs by not having to query multiple indexes, but instead tagging all entries in one index with specific ‘Universal’ ranking information – exactly what happened with the launch of Caffeine in June of 2010. (Why the separate mobile WAP index still exists is up for debate, but will be covered in another blog post.)

As far as we know, the new smartphone bot is just attaching alternate mobile attributes and meta data to pages that exist in the desktop index.

In the case that smartphone-optimized pages exist without desktop counterparts, these pages are also getting added to the primary Google index, with mobile indicators, to hopefully prevent them from appearing in desktop search results (or at least, that is what has been implied by Google).

Al explained that the mobile-optimized urls on Mantra.com.au were not showing up in ALL searches, and this he supposed was related to the nature of the redirects and the quality of the pages. In his own words:

“What is interesting is that not all URLs that we have specific redirects for seem to show the optimized URL & I’m not quite sure what the driver for that is. I was thinking that maybe Google have a quality signal associated to whether or not they’ll optimize the URL or not. For example, we use the same breadcrumb markup throughout our site but not all sections of our site show breadcrumbs in the search results – which I assume is a quality/link signal not being strong enough for those particular sections of our sites & I was thinking maybe the same sort of thing exists for mobile optimized URLs”

It could also be that not all of the pages have been crawled and indexed by the new smartphone bot, or some other less obvious problem that the smartphone bot found with the redirect, the content or the similarity of the two pages. Illustrations of the differences in indexing are included below.

A Page Affected By The Smartphone Bot

Where the desktop page used to be, the mobile page now ranks in its place. The link goes directly to the mobile property page without needing to be redirected. The listing shows the Desktop Title Tag and Description, but the mobile page url.

The smartphone listing links directly to the mobile optimized page

 A Page Not Affected By The Smartphone Bot

The desktop page is requested from the search result, but the server redirects to the mobile home page because there is not mobile page that is a direct match to this desktop page.

The listing that shows the desktop site is redirected to the mobile home page

Smartphone Bot Ranking

The most interesting thing about the activity and rankings of the smartphone bot crawl is that the results are not universal across the site, and appear to be keyword dependent.

Generic iPhone and Android queries on the brand name or brand+product were still returning the desktop home page url. The category and top level pages did not yet have a corresponding mobile page, so it makes sense for them, but the homepage did have a corresponding mobile page, so this was a bit odd.

In Al’s words:

“While we’re obviously redirecting our desktop home page to the mobile home page, none of our primary brand terms produce an optimised URL for the home page. ….At the moment, I have specific redirects in place for the ‘property’ content and all other URLs fall back to the mobile home page. As such, you’ll get mobile optimized URLs showing for queries that return hotel content such as [mantra 2 bond st], [mantra crown towers], [mantra circle on cavill] but not a generic query like [mantra sydney] or [mantra melbourne] – unless we have a hotel page that ranks for that term as well.”

Also interesting is the changes in the mobile sitelinks, which are sometimes different between desktop and mobile queries.

Apparently, the new smartphone crawler is choosing its own sitelinks, presumably based on their perceived relevance or optimization for mobile users, and including those instead of the sitelinks that are returned in a desktop search, as shown below:

Mobile Sitelinks	Desktop Sitelinks
Site Links Differ from Mobile To Desktop

What I thought was interesting was that some of the sitelinks returned in the mobile SERP with the desktop homepage listed were to pages that did not have a mobilized version, (for instance Mantra Resorts). This also occured when a mobile url was included with sitelinks, the sitelinks did not always go to pages that had been mobilized, shown below.

Mobile Sitelinks

When in portrait mode, there was only one sitelink, but two are displayed in landscape:

One Site Link in Portrait but Two in Landscape, All to Non-Mobile Pages

Desktop Sitelinks

This time, the sitelinks are the same on mobile and desktop, except desktop has one more: 

Three Site Links for Desktop

This is totally baffling, because on one hand, it appears that the smartphone bot is changing which site links appear, but it is not doing it in a mobile-optimized way.

Here is what Al had to say about that:

“I see room for improvement from Google on this front for mobilising the breadcrumb URLs displayed in the SERPs as well. Currently the title links to the mobile URL but the breadcrumb URLs are the same as the desktop URLs, for which we don’t have mobile specific pages or redirects in place just yet. I’d be great in the future if the “Gold Coast” link in the screenshot also linked to a mobile optimized URL (when we release those URLs into the mobile sites). It is possible that could happen currently but because we don’t have those type of pages on the mobile site & therefore don’t have the redirects, the breadcrumb in the SERPs isn’t being optimized yet.”

To me, this seems like a very bad user experience, because searchers expect to be delivered to a mobilized version of the Gold Coast page (reinforced by the title, description and bread crumb trail that are all pulled in from the desktop ranking), but instead are delivered to the mobile home page, where they will not be able to find the Gold Coast page, because it has yet to be mobilized.

In this case, it would be better if Google had left the desktop page link, because at least that has the information that the searcher was looking for. Hopefully this is a glitch that will quickly be fixed!

Conclusion

So that is the data. It does seem like the smartphone bot is a bit quirky, and there are a lot of odd things that are going on. It is odd that the smartphone bot is affecting sites like Mantra.com.au before sites like Facebook and Twitter. Odd that it is not updating home page urls in mobile search results, and results more likely generated by long-tail searches than generics. It’s also odd that it is changing sitelinks but not to make them direct people to pages that are mobile friendly.

Perhaps the new smartphone bot is on vacation somewhere in Australia, relaxing before full-on, logical deployment, but we will have to wait and find out. If you have interesting experiences, or similar experiences, please post them in the comments – we would love to hear them!

The Mobile App extension — currently for smartphones only, not tablets — will help advertisers raise awareness of the fact that they have an app. When users are searching on their smartphones for a brand name or product category, they’ll see relevant ads displayed, and advertisers that have apps can append a link to their app below the ad description. If a user is searching for Wells Fargo or Walgreens, for example, the ad would allow users to see that they could get information via the brand’s app, rather than going to the mobile web site.

AdWords with the Mobile App extension will have two links — one from the headline to the regular landing page, and a second one on the app which will lead to Google Play or the Apple App Store.

To set up a Mobile App extension, advertisers need a mobile app that’s live within one of the two marketplaces. They’ll also need the Package Name, if it’s Android, or App ID, if it’s iOS, along with the URL of the page within the app store where users can install or learn more about the app. The Mobile App extensions are available within the Ad Extensions tab within the Campaigns tab in AdWords.

Google has also added additional information to click-to-download ads. When a user searches and sees the click-to-download ad, they will be able to see image previews, a description of the app and, when applicable, pricing and rating information. The additional information will be drawn automatically from Google Play and the Apple App Store.

If they’re marketing an Android app, advertisers will be able to track downloads from Google Play within their AdWords account — they will appear as AdWords conversions. Advertisers can set this up via the “Conversions” tab under the “Tools and Analysis” tab.

Finally, Google has introduced an ad type for app developer/publishers that want to incorporate Custom Search within their tablet apps. Custom Search Ads for Mobile Apps will appear along with organic search results when a user performs a search within the app. Google shares revenue generated with the publisher.

In reality, with Google’s Old Possum/Skip Redirect update in December, user agent redirection is all that’s necessary for mobile sites to rank ahead of desktop sites in smartphone search, even if it’s the same content formatted differently.

With canonical tags back to the desktop site for duplicate mobile pages, both mobile and desktop pages will be able to rank for competitive terms. As I’ve said often in this column, and as Google has said elsewhere, it’s a different paradigm in mobile search, and mobile sites are not, by definition, duplicate content.

However, there are duplicate content issues in mobile SEO that don’t exist in traditional or desktop SEO. These issues will split link equity within a mobile site.

Though this will likely not be a problem for mobile duplicates that are properly redirected, these issues could make it more difficult for your unique mobile URLs to rank, and could result in less link equity being passed to your desktop pages from your duplicate mobile URLs.

If your mobile site exhibits any of these seven common characteristics, you could have canonicalization issues that make your desktop and unique mobile content less competitive in search.

1.  App Interstitials

Many sites promote their mobile app when searchers try to access mobile Web content, taking them to a page created for users of their platform before taking them to the home page.

For example, Open Table takes Android users to an Android page and iPhone users to an iPhone page, and both of these pages are indexed in Google.

Does your mobile site have one of these? You could be splitting link equity.

Like Flash intro splash pages in the early days of this century, there’s a possibility( however remote) that users will link to and share the platform-specific URLs rather than the home page. This can split link equity of one of your strongest pages, making it less competitive in search.

Some companies get around this issue by promoting the app within the page rather than taking the searcher to a separate URL. Others get around it by making a mobile Web user experience that’s good enough to stand on its own. If you must promote your mobile app on your mobile website, it’s best not to have separate URLs per platform.

2.  Carrier Pages

Years ago on Google’s mobile webmaster guidelines, they warned about creating duplicate pages for each carrier. And though that warning is no longer on their mobile guidelines, many companies are still creating deck-specific content that could dilute link equity.

For example, NBC’s mobile site lists a show recap here that’s exactly the same as this show recap here, with the exception of the return to t-zones text at the bottom of the second page.

NBC.com page for T-mobile's t-zones is a duplicate of another recap page except for two words: t-zones Home

Both of these pages are indexed in Google with their own link equity.

If you must create carrier pages, use the canonical tag; or if the page is parameter-based, use Google parameter handling to let Google know they’re duplicates.

3.  Indexed Legacy Transcoder Duplicates

In the initial rush to go mobile, many companies used solutions like Usablenet as a stopgap solution to allow them to provide some sort of mobile content to their users. For various reasons, including SEO, some of these companies then elected to stop using a transcoder like Usablenet and build a mobile site in-house.

Sears.com is one such case. Usablenet currently has 180,000 pages indexed in Google with Sears.com in the URL, but Sears no longer uses Usablenet to power their mobile site.

In fact, they’ve created a jQuery mobile showcase on m.sears.com, which has 381,000 pages indexed in Google. Many of these Usablenet pages are duplicates with older, potentially more trusted links, and they’re splitting the link equity of the Sears mobile site.

One of 180,000 indexed pages of the legacy Sears Usablenet site

Canonical tags on the Usablenet legacy content could fix this problem, but contacting an old vendor to have them implement changes on a site they no longer generate revenue from is never very easy to do.

4.  Other Cross Domain Duplicates

Though transcoded mobile content seems to be the most common instance of cross domain duplicates, there are other instances where the same content will be hosted on two different domains with no canonical tags to indicate which one the search engines should promote.

For example, if you access CBS Sports mobile site directly you could do it through m.cbssports.com. But if you were to access the same page from T-mobile’s deck, you would see the same content at this URL: http://cbstmobile.mo2do.net/?src=tmobile.

If you were to attempt to access it through search by putting in the keywords [cbs sports mobile], you would find the same content at this URL: http://wap.sportsline.com/

Is this a screenshot of A) m.cbssports.com B) wap.sportsline.com C) cbstmobile.mo2do.net D) all of the above?

Again, the same content on different domains could indicate reduced ability to rank for competitive terms. Best to indicate a canonical site through rel canonical or parameter handling in Google Webmaster Tools.

5.  Mobile Site Showcase On Desktop Site

Major League Baseball, the NBA and the NFL all have pages on their desktop sites promoting their mobile websites.

NBA's desktop page promoting their mobile app may appear when mobile searchers are looking for the mobile site.

In spite of Google’s focus on relevance in search results, sometimes these pages intended for a desktop user show up in search results for brand + “mobile site” queries ahead of actual mobile sites.

While these types of pages rarely result in any significant link equity, they can take link equity away from the actual mobile site and make it difficult for it to rank (assuming it’s not a duplicate, which will rank with redirects).

We would love to hear from Google whether pages like this can safely include canonical tags back to the mobile home page, as the content is similar and isn’t something desktop searchers are going to want to find in search. But if the canonical tag is questionable, the pages should at least be excluded or redirected back to the mobile site for mobile users so that they don’t compete with the mobile site in search results.

6.  Duplicate WAP Sites

It’s springtime in America, and many sports fans are rooting for the home team again until the big finish in October.

Do you think any of them can tell the difference between this:

Screenshot of wap.mlb.com

And this?

Screenshot of m.mlb.com. Don't look too hard for differences.

That’s because it’s the same content. The difference is that the former was built for feature phones and the latter was built for smartphones.

These days many companies are building accessible mobile sites at m.domain.com with progressive enhancement in mind, eliminating the need for a duplicate site on a wap.com subdomain.

If you do have a wap site on a separate subdomain (and there are almost 8 million pages indexed on wap.*.com subdomains in Google) the best practice is to use canonical tags to transfer the link equity to one mobile site.

7.  Promoting Mobile Apps Ahead Of Mobile Web Content

Some companies don’t have a mobile website at all, but promote their mobile app instead. There are numerous problems with this strategy that I’ve covered in a past column, but from an SEO standpoint, it often results in creating native app content that can’t be linked to or shared.

So while companies are often duplicating their content and splitting link equity, this particular duplication doesn’t result in any additional links or shares which could ultimately help them rank for competitive terms in search.

If you are creating software or mobile Web functionality that truly can’t be replicated on the mobile Web, by all means build an app. But if you’re just building a stripped down version of your desktop website with mobile searchers in mind, make your mobile content accessible on the Web first.

Chitika “looked at hundreds of millions of impressions between April 8 and 14 and broke down traffic depending on operating system, search traffic, and the type of search query.” The company also broke out local searches (often inferred from the query category).

These data don’t measure activity within or involving apps in any way.

Chitika reported that 54 percent of browser-based web traffic from iOS was being driven via search (Google, Bing, Yahoo, etc.). Chitika didn’t report the breakdown of that traffic by search engine and told me that would require an additional analysis. However other data suggest that Google represents about 95 percent of mobile search traffic coming from browsers.

The data argue that iOS browser activity is more “search-centric” than usage behavior on PCs (Mac or Windows). This is also somewhat counter-intuitive given than search is generally easier to use on a PC than on a mobile device.

In terms of local search, the directional relationship among iOS, Android and Windows is roughly the same as in general search chart. However Mac and Linux-based searches reverse positions in the local search data chart. It’s curious and Chitika didn’t really have an explanation for the phenomenon. I asked whether there could have been an error and I was told essentially “no.”

Chitika is saying that 36 percent of search query volume coming from iOS devices has a local intent. This compares to Google’s 40 percent figure for mobile. In contrast, 28 percent of Android search traffic carries a local intent according to Chitika. Figuring out why is an interesting exercise.

Why would iOS users be doing more local searches than Android users? That’s a version of the larger question about why iOS users might be doing more searches generally than Android users? (Once again, these data don’t reflect or measure activity in apps.)

One partial explanation might be that iOS includes iPads, where there is a lot of search activity. But that doesn’t fully explain these findings.

Mobile vs. PC Local Search Volumes (BIA/Kelsey Forecast)

Source: BIA/Kelsey (2012)

In some categories such as restaurants and travel, mobile searches represent 15 – 20 percent or more of overall query volumes. There can be no dispute that mobile search is now a huge phenomenon. But will it eclipse PC local search query volume in three years?

Let’s think out loud a bit, shall we?

50 Billion Local Queries on the PC

Using the Google 20 percent figure as a guide we can estimate that in March there were approximately 3.7 billion local searches on the PC in the US. In the absence of significant month over month growth that would translate into roughly 44 billion annual local queries coming through US search engines on the PC. But let’s assume modest local query growth and say there will be something on the order of 50 billion local queries on search engines in the US in 2012. (The number could be higher of course.)

Now, how many local-mobile search queries are there?

Answering that question depends on whether we include app-based local search (e.g., Yelp, Foursquare, yellow pages apps, Urbanspoon, etc.). Data from comScore, Localeze and 15 Miles finds that half of US mobile consumers (survey respondents) say they use apps at least some of the time for local search. However, we don’t know the frequency or the volume of in-app search because no one is really tracking those numbers today.

Let’s limit the definition of “mobile search” to browser based search through one of the major US search engines. However right now Google represents about 95 percent of the total “mobile search” market in the US.

12 Billion Local Queries on Smartphones

If there are roughly 125 million smartphone owners in the US (50 percent of 250 million mobile subscribers) and a large number of smartphone owners do an average 20 mobile searches per month, then there are something like 30 billion mobile searches annually right now in the US. (Let’s leave out tablets of this discussion.) If 40 percent of that overall mobile search volume is local, that would mean roughly 12 billion annual local searches on mobile devices. (This number may be slightly inflated today.)

We can assume growth in smartphone penetration and some growth in per-person mobile search query volume — though this assumption is a wild card for several reasons. It also may be a bit risky to assume that the percentage of overall mobile search that is local will continue to climb significantly, though it could reach 50 percent (which is what Microsoft says it is today on Bing).

Let’s assume smartphone penetration reaches 75 percent (say 187 million people) and each person does 40 mobile searches per month (doubling our per-person monthly query assumption). That translates into 90 billion annual mobile queries. If the local percentage of mobile search volume grows to 50 percent, we’d have 45 billion annual local-mobile search queries.

That event would get us pretty close to PC-mobile local search parity, if there weren’t dramatic PC local search growth. However a number of factual assumptions must come to pass. And the future is not guaranteed to look like the past.

What If the Paradigm Shifts?

The proliferation of mobile apps (whether native or HTML5) combined with the rise of Siri and other voice assistants could mean that browser-based mobile search doesn’t grow much over time. Google has cited figures of 130 percent year over year mobile search growth. But there are reasons to believe that the current PC search model on the smartphone small screen will be supplanted, at least to some degree in the relatively near future.

More than a couple of years out it all starts to get very speculative, since mobile is evolving so rapidly. However, regardless of whether the BIA forecast comes true in three years — I don’t think it can without including in-app search volumes — it’s certainly directionally accurate. And one day in the relatively near future it’s clear that people will be using mobile devices to find local information as much or more than their laptops and desktop PCs.

The video is pretty cool. You see someone starting their day, getting information about subway closures, walking directions with heads-up display of turns to take, speaking to the glasses to make a reminder to buy concert tickets, speaking to take a picture, taking a phone call with video and more.

Watch it yourself below:

Click here to view the embedded video.

The reality is, well, we don’t know. The video is not showing the actual glasses in action but rather a concept of what they might be able to do. Even the pictures of people on the Google+ page that serves as a home for Project Glass aren’t showing the real glasses but rather “design photos.”

From the page:

A group of us from Google[x] started Project Glass to build this kind of technology, one that helps you explore and share your world, putting you back in the moment. We’re sharing this information now because we want to start a conversation and learn from your valuable input. So we took a few design photos to show what this technology could look like and created a video to demonstrate what it might enable you to do.

So those glasses, perhaps they’re prototypes or perhaps the actual functioning glasses are much more bulky.

Nick Bilton from the New York Times reports there are several different prototypes actually being used and has spoken to some who have worn them. One person talks about taking a picture with them, but by using a button, not by speaking.

From the pictures, perhaps one of the biggest questions will be, if they do ever get sold, do you want them in black or white? I see both colors in the design models:

Want to test them yourself? Calm down. There’s no formal testing program that was announced, nor anything confirming earlier rumors they’d go on sale later this year. In fact, Steven Levy over at Wired reports Google indicates that any sale by the end of this year is extremely unlikely.

Rather, Project Glass is asking for feedback, so follow it on Google+ here, if you’re interested.

Postscript: See Google Cofounder Sergey Brin Spotted Wearing The “Google Glasses”

We could do the same again right now, because Google has tried to top itself with another round of April Fool’s Day jokes that pretty well span the globe of Google’s international properties. Below is a recap of Google’s (and a few others) pranks, and we’ll do our best to update this as the day goes along.

Google Racing: Self-Driving Cars Hit NASCAR

The main joke at the moment is Google’s “announcement” of a partnership with NASCAR called Google Racing, which brings Google’s self-driving cars to NASCAR race tracks “by the middle of next season.”

There’s also a faux news video about Google Racing (with no embed code – the cruelest joke of all!) starring Jeff Gordon and a couple other NASCAR drivers, not to mention Sergey Brin pretending to be Google’s first NASCAR driver … or whatever you call the person who doesn’t actually drive the car.

And if you go to Google.com, the “I’m Feeling Lucky” button has been renamed “I’m Steering Lucky” and there’s a link to the Google Racing microsite.

Google Maps In 8-Bit For NES

Google’s pranks began early this morning with a blog post announcing that Google Japan has created an 8-bit version of Google Maps for the original Nintendo Entertainment System.

You can relive all your favorite 1980s graphics by clicking the “Quest” button in the upper right corner on maps.google.com.

Google Street Roo

In Australia, where Google Street View cars and trikes can’t get to remote areas of the continent, Google says it’ll use kangaroos with mini-cameras mounted on their noggins to photograph the Australian outback. They’re calling it Google Street Roo. Hopefully the 1,000-plus kangaroos won’t mistakenly collect any personal data via wifi while they’re hopping across Australia.

Google China: Underwater Search

I said it was worldwide, right? Well, even Google China has gotten in the act with an underwater search gag. It’s more like a Google doodle than a prank, though.

Google’s Really Advanced Search

Speaking of search, this one will probably go over well with our audience. Google’s really advanced search page has some pretty funny options, like this:

You can also narrow your results based on what font the page uses, what textured background the page has and which “embarrassing grammatical faux pas” is found on the page. If you’re into SEO, you’ll like this one. You may even find yourself wishing that the page actually worked.

Google Search: Weather Control

Another search gag: Google Weather Control. Type in any weather-related search (like “seattle weather”) and you can make the weather anything you want it to be. You can turn Seattle into Phoenix, if you’d like.

Google AdWords: Click-to-Teleport

The AdWords team has a new extension called Click-to-Teleport that lets “potential customers to instantly teleport to your business location directly from a search ad.”

The YouTube Collection

YouTube’s annual April Fool’s Day prank is the YouTube Collection — all of YouTube on DVD. Once you order, 175 trucks will deliver the DVDs right to your door. Oh, just watch the video. Make your checks payable to “Matt McGee” if you’re planning to order.

Play Music In Google Analytics

I’m not seeing this (yet?) in my Google Analytics account, but this Aussie blog says there’s a little music icon on the Visitors Overview page in Google Analytics. You can play a piano or sitar while enjoying (or bemoaning) your website’s performance.

Google Chrome Multitask Mode

The Google Chrome team thinks one mouse/hand isn’t enough for web browsing, so they’ve launched Multitask Mode — two mice/hands at once.

Gmail Tap

Gmail Tap converts your keyboard from 26 letters to just two — dots and dashes, just like Morse code.

Google Fiber Bar

Forget that fiber optic network thing. Google Fiber is actually just a fiber-filled candy bar that helps you be up to 100 times more productive than ever before.

That’s Not All…

There are other search-related April Fool’s Day gags, perhaps my favorite of which is Google Nigeria, which jokingly asks you to input your bank account number so you can “search for inheritance.”

Don’t be alarmed: the search box just runs a normal Google search (not that you’d actually put your bank account number in there, anyway, right?) and, while this is NOT an official Google gag, it also doesn’t appear to be run by some Nigerian prince. (It’s a production from 85by55.com.)

There’s also TheGoogleButton.com, which lets you make a fake Google search result page with whatever website (and title/snippet) you want in the No. 1 spot.

Flickr has announced that all photos can now be seen in the 1980s style “Atkinson dither,” accessible via a small button in the lower right part of any photo page.

And last, and probably not least, the folks at Reddit announced “reddit timeline,” which brings a touch of Facebook to the proceedings and is pretty funny — especially when you click on “1970s” and get the animated rainbow header, along with “news” about Led Zeppelin, Pink Floyd and the war in Vietnam.

And now that April Fool’s Day has actually begun … time to sign-off, at least until the next prank comes along.

Postscript:

As expected, we have a few more pranks to add and they all come from Google. Here you go!

GoRo: Google Mobile

Google Mobile has introduced a program called GoRo — the name is a play on the actual “Go Mo” campaign — that encouraged business owners to learn how to optimize their websites for rotary phones. Why? Because “technology is cyclical.”

Google Analytics: Interplanetary Reporting

Google Analytics jokingly wrote about a sneak preview of “interplanetary reports” that let website owners “understand visitor activities from neighboring stars and planets.”

Interplanetary reports will be rolled out in 2030, Google says, “when we anticipate local space travel becomes widespread.” Heh. Watch them be right about that part.

Google AdWords: Planetary Targeting

The AdWords folks didn’t stop just with Click-to-Teleport (see above). Oh no, there’s more. If you login to your AdWords account and edit location settings on one of your campaigns, you’ll see a joke about being able to do planetary targeting.

And yes, if you follow through and type “Mars,” for examplem, it shows up as one of the targeting options. There’s even a fake support page explaining how it all “works.”

At least I think it’s fake. Who can tell anymore?

NOTE: See our own follow-up analysis, No, Google Doesn’t Make Four Times More Off The iPhone Vs. Android

The publication reports “Android generated less than $550m in revenues for Google between 2008 and the end of 2011.” It further derived an average revenue per Android handset per year figure of $10.

Interestingly this is a figure that Eric Schmidt estimated Google could make off each Android user. In 2010, then CEO Eric Schmidt speculated that Android would become a $10 billion revenue stream if a billion users generated $10 per year for Google. And in early 2011 Piper Jaffray analyst Gene Munster estimated that Android was generating about $5.90 per user for Google and saw that figure growing to $9.85 in 2012.

The Guardian also estimated that Google made roughly $30 per year, per PC with a couple of caveats.

Earlier this month Macquarie Capital estimated that in 2011 Google made just over $1.3 billion in paid search revenue from its default position on iOS devices. Apparently Google gave the lion’s share of that back to Apple under the terms of a default search agreement between the two companies.

In other words, Google made more (top-line) revenue in one year from the iPhone than it did in three years from Android handsets.

If Google activates 800,000 Android devices daily it would mean 292 million devices activated per year. Using the $10 per user, per year revenue formula that would translate into $2.92 billion in global Android revenue over the course of a hypothetical year.

Below is a Google mobile revenues forecast from Cowen and Company. It shows $5.8 billion in revenue this year.

Mobile is becoming an increasingly strategic part of Google’s business and one of the places where the greatest growth is occurring.

Postscript: Upon closer inspection of the settlement document that apparently forms the basis for The Guardian’s analysis, it’s very difficult to verify the accuracy of the claims and estimates above. The numbers may therefore be highly untrustworthy. See our own follow-up analysis, No, Google Doesn’t Make Four Times More Off The iPhone Vs. Android.

Postscript II: Google told us Friday that the figures appearing in the court documents that The Guardian relied upon have no relationship to current Android revenues.

Related Entries

• Google Will Make $10 Per Android User In 2012: Report
• US Subpoenas Apple For Details About Default iOS Google Search Deal
• Report: 25 Percent Of Paid-Search Clicks Will Come From Mobile By December

Today Google announced a new release of Maps for Android (6.5) featuring a richer UI and other improvements. Most of those have to be experienced, however, on Android 4.0 (“Ice Cream Sandwhich”) phones (e.g., Galaxy Nexus).

Google has created a new homescreen that provides quicker access to locations and previous destinations. The company has also made the map crisper, with more contrast and less clutter.

Here’s what Google said about the new look:

If your device has a high pixel density screen, such as those on Galaxy Nexus, Galaxy S II, Droid Razr and others, you’ll now get higher resolution map tiles that take better advantage of the pixels-per-inch on your screen. The result is a crisper, less cluttered map that is easier to read . . . 

The road network is easier to see, less obstructed by labels, and has more color contrast. At more zoomed-in levels, you’ll notice a more controlled amount of maps labels to avoid cluttering the map and blocking out street names. The new style also helps maps react faster to panning, zooming and twisting.

Users are also able to set default or preferred transit and routing choices. Google Navigation in particular is the thing that I miss most about switching from Android to the iPhone as my primary device.