Many have lamented the rise of apps and the return of “closed” proprietary platforms  (e.g., Apple, Facebook). Recently in a widely discussed interview Google’s co-founder Sergey Brin pointed to “walled gardens” and government censorship as threats to the established web. He later clarified that the biggest threat to the web was from government censorship and not Apple.

One of the reasons that Brin and others don’t like apps is that their internal content is not indexed. Plenty of apps surface in search results but not what’s inside.

A number of app search engines have arisen to confront the so-called “app discovery problem.” Among them are Quixey, Chomp (recently acquired by Apple), Appsfire, Appolicious and Xyologic. Yahoo has built an app search engine; and one can also search Google Play for apps of course. Bing also dabbled in app search for a time.

The central difference between most of these sites and Quixey is that the latter is not simply indexing and searching mobile apps. Quixey characterizes what it does as “functional search” rather than app search. It’s indexing available apps across platforms (including the PC), as well as web content pertaining to those apps.

The idea is that users will enter queries that describe tasks or goals to accomplish rather than specific apps or even app categories. For example, in response to the query “learn french,” the search engine produces a range of results that show mobile apps but also “apps” for Firefox, Facebook, Mac and Windows (both paid and free).

Quixey won’t go so far as to say that it’s a direct competitor to Google. However it does regard itself as more effective for discovering apps and app content (broadly defined). It also suggests by implication that it’s something of a Google successor in some respects. It uses the tagline “a new type of search” on its site.

The company was founded in 2009 and has raised just over $4 million to date. Eric Schmidt is an investor. It’s also talking to various third parties about powering their app search. This is something that other app search engines are doing as well.

In one way of looking at the world apps now represent a parallel universe of content to the more traditional “open web.” HTML5 may eventually succeed in bridging the two worlds; however that hasn’t happened yet. Many assume and some are banking on the idea that apps are now a permanent new way to deliver web content — whether in mobile or online. In that arena Quixey is trying to the Google for the new apps era.

Related Entries

• App Search Engine Appolicious Introduces “AdWords For Apps”
• In Chomp, Apple Gains A Social Search Engine For Apps
• Chomp: An Apps Search Engine Or “Yelp For The App Store”
• New comScore Study Suggests 50 Percent Of Local-Mobile Search Happening In Apps
• More People Now Using Mobile Apps Than Browser — comScore

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.

Below are the overall most-searched categories and the fastest growing across the YP Local Ad Network (Q3 vs. Q4 2011):

The top mobile search categories are similar but not identical to the list in the graphic above:

1. Restaurants
2. Automotive
3. Movie Theaters
4. Beauty Services
5. Hotels

Mobile searches now represent “more than 30 percent of all searches” across the YP Local Ad Network. This number is higher than the mobile percentage of general search, which is more like 15 – 18 percent overall, though higher in some categories.

Last quarter AT&T Interactive said that its mobile users click ads 2X more than PC users. Mobile users are also more inclined to call a business than their online counterparts, who are more likely to visit a website.

The graphic below reflects actions taken by consumers on a business profile/more information page, after the initial click:

In Q4 2011, AT&T said that the top advertisers on the YP Local Ad Network by ad spend were the following:

1. Building Contractors
2. Legal
3. Medical
4. Automotive
5. Financial Services
6. Home Maintenance Services3
7. Pet and Animal
8. Moving and Storage
9. Real Estate
10. Insurance

Between iOS and Android there are more than 900,000 apps. App discovery is now a major problem for both consumers and developers — hence the new advertising option on Appolicious. Chomp was planning to introduce a similar capability and then was bought by Apple. Appolicious is currently the only app engine or marketplace where developers can bid for placement in search results.

Developers can bid for placement by keyword and by broad match or exact match. It works like a simplified version of AdWords. There’s no guidance currently about bid amounts, but it’s a relative bargain at this early stage.

A considerable amount of mobile display advertising these days is devoted to promoting app downloads. Appolicious CEO Karl Stillner contends the difference between those broadly distributed mobile display ads and paid-search ads on Appolicious is that users on his site are much more targeted prospects.

Appolicious also has an expanding network of partners that include Best Buy and Samsung. Eventually the paid-search app ads will make their way to the company’s partner network.

Mobile marketing must seem that way to a lot of companies, and as a result, far too many of them are sitting on the sidelines. Fortunately, there are a few vendors out there offering a shortcut to the mobile Web:  a turnkey publishing platform that allows a marketer to quickly deploy mobile landing pages.

The question is: how effective are these pages in the context of mobile search?

The Case For Mobile Landing Pages

Turnkey landing pages are usually considered because of special circumstance:

• Budget. When most dollars get spent to support desktop sites, the remainder may not actually be enough to support a full-blown mobile effort.
• Direct response campaigns. Sometimes a media campaign concept drives the need for mobile landing pages to catch the resulting traffic. QR codes at trade show booths, mobile offers sent via text, and even plain-old PPC ads can drive the need for a quickly-built mobile site.

The systems available to deploy mobile landing pages change every month. So rather than single-out a single platform and dissect its features, let’s look at the factors you’ll want to keep in mind when evaluating and using these services.

Laying A Foundation

The first thing you’ll want to investigate is whether or not these landing pages can be read by a search engine. Here are a few features to look at closely:

• Dynamic Pages. Some turnkey systems use dynamic pages to quickly create pages that can respond to campaigns or even individual ads. Dynamic pages include lots of parameters in their URLs, and can cause problems for mobile search, just as they do in the desktop world.
• On-Page Coding. Mobile landing pages sometimes use special coding to create a seamless app-like experience. I’ve talked about JQuery Mobile in the past, and there are other frameworks such as XUI, JQTouch, not to mention plain-vanilla JavaScript. These schemes don’t get a 100% thumbs-up or thumbs-down – it depends on how they are used. The key is to ensure that your landing pages are actually composed of distinct pages, instead of a single downloadable page with a chameleon-like ability to alter its content.
• Navigation. If your turnkey site is built to catch campaign traffic, it may just be a collection of free-standing landing pages, with links to connect them to each other. If that’s the case, you won’t benefit from the SEO support these pages would lend to each other. Furthermore, without nav links, you may lose a connection back to the home page, which typically has the strongest SEO scoring.
• Flash. Flash is not usually employed on these sites (thank you Steve Jobs) so that’s one less thing to worry about.

Getting There From Here

Looking at all the points above, you might get the impression that optimizing your mobile landing pages will be an end in itself. And it partially is: you’ll be living with them for a while, so it’s worthwhile to see what sort of SEO performance can be extracted from it.

But you can also take a broader view. If the turnkey site and its campaigns are successful, it’s likely that more mobile projects will follow, including the creation of a more comprehensive “official” mobile website.

With that in mind, your turnkey site can be considered a precursor, one that can be used to lay a foundation for the construction of a future brand presence.

A bit of preparation can help to make that happen:

• Domain Name.  Try to anticipate the URL that will be used for your future mobile site. If you can start using that URL today, you’ll create a footprint that will help search engines discover your next website more quickly. Conversely, you should talk to your vendor if they suggest a URL based on *their* domain name, because you may lose access to it when you transition to your next mobile website.
• Recyclable URLs. What works at the site level also works at the page level. Choosing locations for landing pages that will echo the page locations of a future website will also help smooth the transition. Granted, it’s hard to predict what your future site will look like, but for basic pages like “About Us” or pages promoting on your bread-and-butter product lines, some predictions can be made.

Your short-term mobile landing pages (left) may not have as much content as your future mobile website (right.) But the more they resemble each other in structure, the better your mobile SEO will be down the road.

Altogether, mobile landing pages are a great tactic for getting yourself into the mobile space. And with advance planning, that short-term success can be leveraged into an asset that can feed into successive projects, creating a win-win for both mobile search and your time-to-market.

The trouble is potentially two-fold: not only is it hard to track visitors, but once Google’s December changes take effect, it may be hard to attract those visitors in the first place.

One common source of this tracking problem is the series of redirects that make-up the desktop-to-mobile switchboard.

Three aspects of this switchboard are worth checking:

• 301 redirects.  SEO’s are no stranger to the 301 redirect. But in a mobile situation, you might have your doubts. If the web server is 301-ing mobile traffic to your m-dot URLs, does that disrupt the indexing process for the desktop site? And what about link equity? Actually, Google expects this pattern and it’s perfectly safe, but only if you…
• Manage user agents. To manage mobile traffic, you need to know for sure that they’re on a phone. User agents – ID strings that identify your web browser – are the industry-standard technique for sniffing-out a phone. To make this work properly for mobile search, your user agent list should be complete and up to date. This should include the defacto “devices” that GoogleBot-Mobile uses to perform its mobile indexing. If you don’t treat GoogleBot-Mobile like a phone, you’ll accidentally serve-up your desktop page, possibly getting dinged for mobile performance factors like long load time.
• One-to-one mapping. Redirects can be seen as the roads connecting your pages, and how your roads are laid-out can have a significant effect on how users and engines get around your site. GoogleBot-Mobile looks for redirects that connect matching pages, and will make a point to show your mobile URL as your search listing. If your redirects don’t map to specific pages (i.e. sending everyone to the mobile home page) you run the risk of never showing “m.website.com” in the SERPs. It’s still too early in the game to cite studies on this, but it stands to reason that a lack of m-dot URLs will quickly become a quality signal to both user and engines that your site isn’t mobile-friendly.

Google still shows desktop URLs for both mobile searches (left) and desktop searches (right), but the switchboard action that helps send users to the right destination can sometimes result in a loss of tracking data.

One last comment about 301 redirects, and why they’re especially important in this context. A lot of web developers bemoan the SEO industry’s (and Google’s) insistence on 301 redirects as the one best option for managing traffic. But for mobile tracking it’s even more important, because of the way HTTP server codes are handled.

301′s Keep Your Data Connected

With a 301, the referring URL that got users to Page-A is automatically copied over to Page-B’s referrer. From a metrics perspective, this is a great convenience: instead of having to track how a user hopscotched through the redirect, you can just look at the 1) real source of the traffic, and 2) the real landing page of the user.

With other types of redirects (302, JavaScript, meta-refresh) no such copying of the referrer data is performed. Therefore the data is lost – and that could be why you only see your desktop site in your traffic data. You’re only seeing the hopscotch, instead of the true source of your mobile traffic.

Bottom line, these steps will go a long way toward cleaning-up your metrics, and help you to better weigh the mobile site’s impact. They’ve been tested in both Google Analytics and Omniture to good effect, but if you’ve had experiences with other tracking tools (good or bad) please share them in the comments.

Essentially the UI has been simplified, colors have been muted and there’s an improved “visual hierarchy” at each level of zoom. It’s challenging for me to specifically tell what’s new on Bing Maps, however. Here’s more from a Microsoft spokesperson:

This week, as an extension of the Microsoft-Nokia partnership, a new joint map design will begin rolling out across Bing Maps, Nokia Maps and Windows Phones. This unified map style will feature key elements from Microsoft’s metro design, including strong typography, improved readability and a clean user interface to help people find and use mapping information more quickly. As part of the update, Bing Maps will also be improving its global mapping coverage in countries such as Egypt, Israel, Venezuela and many others, refreshing the maps with new roads, subdivisions and additional refinements.

The new mapping UI and features will appear on both companies’ PC and mobile sites. While there are still UI and user experience differences between Bing Maps and Nokia Ovi Maps, the look and feel is very close.

Below is comparison of maps on Bing and Nokia in response to the query “San Jose Convention Center,” where I am now at SMX West:

Bing Maps

Nokia Maps

For comparison purposes, here are Yahoo Maps (also powered by Nokia) and Google Maps results for the same query.

Yahoo Maps

Google Maps

The new Bing-Nokia maps are less visually cluttered than Google or Yahoo Maps. But some may equally characterize that as a “washed out” quality. Indeed, the assessment of the new mapping UI for Bing and Nokia will depend on your subjective aesthetic preferences.

Whose maps do you prefer?

Related Entries

• Bing Maps To Be Powered (Replaced) By Nokia?
• Powered By Nokia, The New Yahoo Maps Goes Live
• Google Maps Vs. Bing Maps: Summer Vacation Planning Showdown
• Bing To Become Default Search (And Maps) On RIM BlackBerry Devices
• Bing Maps’ “Game Changer”: Hi-Res Aerial Imagery Coming To Entire US and Western Europe
• Bing Maps Overhauls Interface, Exposes Map Apps To All
• Bing Maps Adds Transit Directions

If you’re a regular reader of this column and you don’t have a mobile experience, you are in the majority of site owners; but you’re also way behind and may not be able to catch up if you wait much longer.

So are you ready? Let’s talk about the ideal set up for your mobile site for SEO purposes.

There are cheaper, easier solutions, but this is the one that I would recommend to webmasters looking not just for a mobile friendly solution, but something that’s truly optimized to bring in traffic from mobile searchers.

If you want to build a mobile site in a way that will increase your organic search engine traffic, this is how to do it.

1. Make It Truly Mobile

Before you even think about subdomain options, you better know your mobile user: the person who you’re building this for who will ultimately make it a success or failure.

What are they looking for and why? Use the AdWords keyword tool to get mobile volumes and desktop volumes for keywords related to your brand, and to your products and services, and then find the mobile percent of total volume, or the mobile ratio, as Sherwood Stranieri put it. This gives you a sense of what concepts and keywords overindex with smartphone and mobile searchers, and it will help you build more than a desktop experience.

For example, for Walgreens, it’s clear from their brand keywords that index high among mobile searchers that the majority of searchers are looking for a Walgreens near them. It’s clear from the volume of queries where more than 30% of the total volume is mobile (smartphone and feature phone):

And it’s clear from a long tail analysis of the same list:

These are highly qualified searchers, as they’re very likely to convert offline, so why not make it as easy for them as possible?

Now that we know what our mobile users want, we can design the mobile site so that it provides those things with ease. And this will differ for all businesses, but it’s likely to be different from how your desktop website is structured.

Walgreens seems to know this, as they designed their mobile website differently than their desktop website, specifically taking advantage of the unique capabilities of a mobile device.

Instead of having their mobile searcher find a site with a lot of irrelevant content crammed on to one page that’s intended for desktop users, they’ve highlighted those areas that are most relevant to the mobile user experience.

For example, instead of doing nothing with their site and hoping that a mobile searcher finds the sections they’re looking for (which I’ve highlighted in red in the second image):

Walgreens has presented a simplified version of the home page that highlights those areas of the site that are most relevant to the mobile user experience:

When you hit the “find near me” button, it uses the phone’s GPS to find the locations closest to you, taking advantage of the specific functionality of mobile browsers rather than completely transcoding the desktop site with desktop functionality to look good on mobile browsers (i.e. responsive design).

Walgreens.com isn’t the paragon of mobile SEO, unfortunately, as they’ve done a lot of things wrong when it comes to the findability of their mobile site. With the design they really should have included a small keyword-rich text box that conveys the relevance of the page to users and search engines, as there’s not a lot of text or keywords on the page to help search engines understand that it’s relevant for what search engine users are looking for.

For some brands, there may also be concepts and keywords that aren’t included in the desktop site that need to be linked to from the homepage.

I’m guessing this is because the page was designed with users rather than SEO in mind, as someone hired the non-search-friendly mobile platform Usablenet to design the site and disallowed it in the robots.txt file so that it only appears in search engines when you put in the navigational keyword [m walgreens com].

They also promote the app over the mobile site by sending the searcher to a splash page first, which isn’t good for users or search engines.

Nonetheless, like State Farm and too few other companies, they did build a separate mobile user experience rather than used stylesheets to serve a formatted desktop experience, which is the first big step to getting a search-optimized mobile site.

2. Create A Hybrid Of Mobile-Optimized & Mobile-Friendly Content

Once you’ve settled on the design and site architecture, you need to determine the best way to host your mobile site. Though there are many opinions on the matter, the best solution is to host your mobile homepage and mobile-only pages at m.domain.com subdomain or /m subfolder.

For all other pages with content that won’t change from desktop to mobile, it’s perfectly acceptable to keep them at the same URL as your desktop and simply reformat them for mobile user agents. Redirects work fine too, but the best practice for transcoded desktop URLs is currently to add canonical tags to pass the link equity back to desktop pages.

For mobile only pages that are not strict duplicates, canonical tags are unnecessary, and could make your most valuable pages invisible to searchers.

3. Redirect Appropriately

For mobile-only content, you’ll need to set up the proper redirects. My colleague Cindy Krum has a handy tool for PHP and .NET redirects that makes it easy for novices to set up mobile redirects.

When Googlebot comes by, serve it your desktop content; but when her sisters Googlebot mobile and smartphone Googlebot arrive, give them your feature phone site (if you have one) and your smartphone site, respectively.

If you have a tablet site, by all means serve it to tablet searchers instead of your desktop or smartphone site, but there currently is no tablet Googlebot to receive your tablet site.

If you don’t have a tablet site, serve your tablet searchers desktop content, as research shows that’s what they respond to best. Just make sure you’ve removed all traces of Flash before serving it up to the iPad or other tablets that don’t support Flash.

4. Don’t Forget the Images!

It has been a long time since mobile SEO was about optimizing WAP sites, and in the near future we may be optimizing for a literal pair of Google Goggles, with a Terminator-like overlay that searches for more information on the things around us, just by analyzing images and comparing them to Google’s image and Google Goggles image database.

SEOs can prepare for this brave new world today by ensuring images are optimized for mobile searchers.

5. Analyze & Optimize

Sure, there are mobile SEO best practices beyond this, but best practices only go so far. If you want to retain the edge that optimizing your site in this way gives you, you can’t just set it and forget it.

Given how rapidly this practice is changing, and how much it has changed in the last five or six years, mobile SEO requires regularly looking to your web analytics and to columns like those in the Mobile Search section in Search Engine Land in order to stay optimized.

There are many ways to go mobile, and many of them will actually hurt your visibility among mobile searchers. If you create mobile content when appropriate, redirect appropriately, optimize your images for mobile searchers, and analyze your site for new opportunities, there won’t be many mobile webmasters who will be able to compete with you in natural search.

Chomp can either be described as a search engine for apps or “Yelp for the app store,” because of its reliance on reviews as a ranking signal and its engaged community of users.

The CEO Ben Keighran and his CTO are apparently already working at Apple/iTunes in anticipation of a significant redesign of the app store, using some of the infrastructure that Chomp is bringing over.

Apple essentially failed to develop a social network with Ping for iTunes. As a secondary benefit of buying Chomp it may get another opportunity to do so via Keighran and company.

The revamped iTunes store, whenever it launches, will also no doubt be much more search centric, as Chomp is. We’ll probably hear more about Chomp (or iTunes) SEO accordingly. Chomp SEO could even spawn a bit of a cottage industry.

As others have pointed out, Chomp’s technology is also the basis for Verizon’s app store. However, it’s likely that the Android version of Chomp and the Verizon relationship will atrophy over time — if not immediately. However Apple might want to maintain Chomp for Verizon to preserve good relations with the carrier.

Chomp took roughly $2.5 million in investor money according to published reports. If that’s accurate and the $50 million acquisition price is also correct it’s quite a return for everyone involved.

Apple has nearly $100 billion in cash burning a hole in its pocket. CEO Tim Cook has indicated he’s more flexible than Apple founder Steve Jobs in terms of what to do with that cash. And while Apple has made deliberate, irregular acquisitions in the past it may step up the pace under the leadership of Cook.

Below is a demo video of the Android version of Chomp featuring CEO Keighran.

Related Entries

• Chomp: An Apps Search Engine Or “Yelp For The App Store”
• Hello Chomp, Goodbye Android Market