Emily Grossman – Search Engine Land News On Search Engines, Search Engine Optimization (SEO) & Search Engine Marketing (SEM) Fri, 27 Aug 2021 14:41:40 +0000 en-US hourly 1 https://wordpress.org/?v=5.8.1 App Indexing & The New Frontier Of SEO: App Packs & App Store Search /app-indexing-new-frontier-seo-app-packs-app-store-search-242319 Fri, 19 Feb 2016 16:06:14 +0000 http:/?p=242319 In this third and final installment of a series on app indexing and how it impacts search engine optimization, contributor Emily Grossman discusses how to rank apps in Google search results, as well as in Google Play and the iTunes App Store.

The post App Indexing & The New Frontier Of SEO: App Packs & App Store Search appeared first on Search Engine Land.


SEOs who are not paying attention to apps are missing a large part of the mobile SEO picture. Even if your company does not have an app, recent changes to Google mobile results allow apps to compete with your website for the same rankings. In many cases, app results are winning.

In addition to Google’s Deep Linking changes, which focus on crawling and ranking internal app screens, there have been significant changes to the way Google ranks entire apps, often directly at the top of the search results.

The inclusion of App Packs in mobile search results has dramatically improved app discovery in Google. Now, 27 percent of people find apps through web search, compared to just two to three percent in 2014.

Beyond that, Google is further minimizing the Google Play Store by testing Android app downloads directly from search results. Despite these gains in mobile web search, 40 percent of people still find apps by searching the OS-specific app stores (the Google Play Store and the iTunes App Store), so the app stores and app store optimization are still a critical part of any app marketing strategy.

Apps and app deep linking have changed mobile SEO substantially, especially in the past nine months, and their impact has become much more visible.

This is the third in a series of articles designed to demystify the important linkages between SEO and app marketing. The first and second articles focused on how to use deep linking and app indexing to drive discovery of deep app screens in iOS9 Apple Search and in Google Search.

This article will explain how to rank entire apps in Google search results, called App Packs, as well as in the OS-specific app stores, Google Play and the iTunes App Store.

The relevant ranking factors that will be discussed in this article are summarized below:

How To Rank In Google Apps

Google has been ranking apps directly in mobile and desktop search results for some time now. But until recently, Google only displayed apps as traditional blue links to app store download pages, which were evaluated with an algorithm similar to the regular web-ranking algorithm.

Historically, searchers looked for apps in OS-specific app stores. Unlike a search engine in a browser, the app stores were included natively on the phones and only showed app results that were compatible with the search’s device.

In the past year, however, Google has gotten better at evaluating and ranking apps, as well as detecting and filtering for device and OS compatibility. Now, more and more app search traffic is moving to Google.

To meet the growing demand, Google added the new Universal “App” option in the top of their mobile navigation, and soon after, launched the stylized App Packs to search results.

As you will recall, App Packs are different from app deep links because they send search traffic directly to the OS-specific app store landing page, rather than opening a deep screen in the app on the user’s phone.

App Pack results are OS- and device-specific, so only apps that will work on the device that you are searching from (based on the handset and OS version number) will rank.

As shown below, they are presented in Google’s mobile search results as colorful tiles that include the app name, icon, star ratings and price.


App Packs can include one, three or six apps and often also include an AJAX expansion arrow (highlighted above) that will allow as many as 12 apps to be shown. For every app that is included in an App Pack, one web ranking is pushed off the page.

This means that even if you are not promoting an app, the App Pack rankings could dramatically impact your brand’s mobile search visibility. If your website was ranking number one, it could be in position seven now because it has been pushed down by six apps above it.

App Packs are triggered in mobile search results when Google determines that a user is looking for an app or a task that could be performed by an app. Right now, App Packs primarily show up when a user searches for common app head-terms like “games” or for tool-related queries like “photo editor” or “travel planner.

App Packs are also ranking well in queries for specific app titles or brands, like “Angry Birds” or “Disney.” App Packs may also be triggered by different types of keywords, depending on the context.

NOTE: Most keyword reporting tools are not effectively reporting on App Packs, so you should test on physical devices or a device-specific simulator to see the real impact that App Packs are having on your top keywords. Remember, Android and iOS devices will be different.

Google has not published any data on the number of searches that are currently containing App Packs. This is presumably because they can vary substantially depending on the searcher’s device and because Google is still testing and tweaking the value that App Packs provide users.

Google has also not provided any click-through rate (CTR) data on this type of result, but it would seem the CTR varies based on the number of apps that are presented and the placement of the apps. Google could even use this data to test and tweak the App Pack presentation aspect of the algorithm.

When there is a sizable and strong group of potential apps to rank, Google will generally float the App Pack to the top, but if there are fewer or weaker apps that should rank, Google will sometimes put the App Pack at the bottom of the results.

It is currently possible, but less common, to see an App Pack mixed into the middle of a result set, like a News or Image result might be.

App Pack Ranking Factors

Google crawls app landing pages from both app stores and uses its own algorithm to determine which apps should rank in an App Pack. They do not rely on rankings in the OS-specific app stores (Google Play or the iTunes App Store) for these rankings.

However, often the apps that rank well in an App Pack also rank well for similar searches in their OS-specific app store because they share many of the same ranking signals.

Google treats App Titles like Title Tags and App Descriptions like on-page text. In a previous iteration of the App Pack presentation, a portion of the App Description was included like an SEO meta description, and though the current presentation does not include any part of the description, it does still contribute keyword relevance.

One of the best ways to target Google App Pack search results is by adding appropriate keywords to your App Titles and Descriptions when submitting apps to the OS-specific app stores. For example, users in an app store may not search for “kids app” because “app” is implied from the context, but a Google searcher will almost always include “app” if they are looking specifically for an app. Similarly, searchers in the Google Play store may not include “Android” in their query, but Google searchers likely will.

Google may also rank apps based on keywords from the user reviews that are included on the app landing page. Like traditional on-page SEO, keywords at the top of the page are given the most weight so the impact of keywords in user reviews is often quite minimal but can occasionally improve an app’s ranking in the Pack.

Star ratings are also a strong App Pack ranking signal. It is possible for an app with a keyword match in just the description to outrank an app with a keyword match in the title if the app has a higher star ranking. Star ratings can also impact the click-through rate for the app, since Google scrapes and displays star ratings in the App Pack result.

Google has also indicated that App Indexing may have a slight, positive impact on App Pack rankings. The algorithm may also evaluate external links and social signals to the app download pages, as it does on traditional web page rankings, but this is still unclear.

Ranking In OS-Specific App Stores

In addition to App Packs in Google Search, OS-specific app stores can also rank and drive downloads to entire apps. Since a large portion of searchers (40 percent) are still using the OS-specific app stores to find apps, it is important to make sure that your app is ranking there, as well.

The optimization of applications for ranking in the OS-specific app stores is called App Store Optimization (ASO). In many cases, developers that build and submit apps in these marketplaces are unaware of the value and strategy behind ASO, so simple changes can sometimes drive significant results.

Most SEOs have a normal workflow that they rely on to optimize web content and even app content for rankings in Google, but measuring success and ranking in the app stores is a bit different. Besides having less sophisticated ranking algorithms and reporting, neither of the OS specific app stores has directly engaged with the SEO community to communicate Best Practices. There has been no explicit discussion of the prioritization of ranking signals beyond simply specifying character counts and warning about trademark infringement.

Most of what is “known” about the OS specific app store algorithms has been determined through testing and experimentation over the years.

OS-specific app stores have access to more information about the app than Google’s crawlers do, but they are still in the early phases of search engine development (think web directory submissions à la 1995). 

Neither app store appears to have access to any of the deep linked content from within apps,* so currently, they determine keyword relevance for search results based primarily on meta data that is submitted with the app manifest and dynamic ranking factors that reflect how the app is performing at the time. Apps with the highest overall performance in both areas will achieve the highest rankings.

*Google could easily share App Indexing data like app screen titles and descriptions with the Google Play Store to influence Google Play rankings in the future. We suspect that they have held off on using App Indexing as a major ranking factor in the Google Play Store because it would unfairly disadvantage apps without web parity that are unable to participate in App Indexing (apps without web parity can only participate in App Indexing if they are part of an exclusive beta).

Submitted Meta Data

The iTunes App Store and Google Play use slightly different algorithms. With the exception of the Keywords Field, both stores evaluate the same elements (sometimes called different names), but they attribute different algorithmic weight to each.

A summary of Submitted Meta Data components including the App Title, App Category, Keyword Field, App Description and Developer Account Name are outlined below, along with their relative weight in both of the app store algorithms.

Submitted Meta Data
Store Name App Title App Category Keyword Field App Description Developer Account Name


Green cells are weighted higher in the store ranking algorithms. Red cells are not considered in the store ranking algorithms.

Now let’s dig into each of these pieces of submitted meta data a bit more…

App Title

One of the first things to consider when submitting an app is what its name should be. Each app actually has two names — the official “App Title” and the “App Display Name.”

The official App Title appears on the app store landing page. This is set in iTunes Connect or the Google Play Developer console when the app is submitted, and it plays a major role in app store search rankings. App Titles can be up to 30 characters long in the Google Play Store and up to 75 characters long in the iTunes App Store (a recent change from the previous 255-character limit).

The App Display Name is the name under the app icon on a user’s device. It DOES NOT contribute to keyword rankings. On iOS, the App Display Name is called the “App Bundle Display Name,” which is set in the info.plist file in Xcode, and on Android it is called the “Label Attribute,” which is set in the AndroidManifest.xml.

The Best Practice for character limits on the Display Name is 11 characters including spaces. After 11 characters, the name can be truncated with an ellipsis, throwing off the look of the app name on the user’s device.

Truncation limits are pretty firm on iOS and more variable in Android because of the greater diversity of screen sizes and font settings. App Display Names can be tested for length by installing a beta build of the app or by creating a custom folder on a test device.

Many developers make the mistake of thinking that the display name and App Title have to be exactly the same. Using only a brand name as an official App Title is a missed opportunity in terms of keyword rankings and conversions. Users are less likely to download a branded app if the title does not clearly explain the purpose or core functionality of the app.

If you have an app in either of the stores, you should make sure that it has a descriptive and keyword rich App Title. Ideally, searchers should have a very strong understanding of the value and functionality of the app, just from the title. If not, you can update the App Title to be more compelling and clear. It is not a good idea to change the App Title with every update, but it is fine to make strategic changes to the App Name every once in a while.

Here are a few examples of popular apps with descriptive, keyword-rich titles and abbreviated display names:


App Category & Sub-Categories

After selecting the App Title, it’s important to choose a category or categories for the app. App categories are essential for people who are browsing the stores, perhaps looking for apps in a certain group or theme without having a particular app or functionality in mind.

App categories can also behave like keywords in app store algorithms and improve the app’s rankings for the category keywords. In Google Play, most apps can only be submitted to one category, but in the iTunes App Store, apps can be submitted to an additional “secondary category.” The additional category allows the app to target additional relevant keywords, which can be very advantageous, so it should not be skipped.

The category decision can also be strategic. Submitting apps in aggressively competitive categories does not provide much visibility over the general rankings, so it might be more strategic to submit the app to a less competitive category where it is easier to achieve top rankings.

There are a few different ways to analyze the level of competition within a category. Companies like App Annie and Sensor Tower publish app statistics for each store, and a simple Excel chart and graph can help you visualize the data and decide.


To do your own evaluation, use a data source like App Annie’s free Top Charts reports. Pick the top categories that you are considering, and plot the top 25 apps in each of those categories on a grid. The overall store ranking of each app should be on the Y-axis, and each app’s category ranking on the X-axis. Steeper lines represent less competitive categories — in these, it is possible to rank well in the category (the left of the X-axis) while not ranking as well in the overall store (Y-axis).

Categories with shallow lines indicate more competitive categories — apps have to rank very well in the overall app store to get any top visibility in the category (the “Games” category is consistently like this in both stores).

In some cases, apps may also be submitted to special editorial categories where apps are hand-selected by human staff. For instance, in the Google Play Store, qualifying apps can be submitted to the “Family” category in addition to the normal category selection. In the iTunes App Store, qualifying apps can be submitted to a similar “Kids” category in addition to the primary and secondary categories.

This can be particularly advantageous because these editorial groupings are more exclusive and often featured prevalently in the app stores UX. They also act as a “bonus” keyword, adding to the normal impact of your category selections on the app’s keyword relevance.

Keyword Field (iTunes App Store Only)

Beyond the App Title and App Categories, there are a few other pieces of meta data that SEOs can keyword optimize. The iTunes App Store evaluates a special “keywords” field to drive rankings in its algorithm.

The keywords field is not public-facing, similar to the meta keywords tag in early web SEO. The iTunes App Store algorithm currently gives the keyword field slightly less algorithmic weight than it has in the past, but it still contributes significantly.

The keyword field can contain up to 100 characters of comma-separated keywords that are relevant to the app. This is not very much space, so it is important to optimize strategically. Tools like SensorTower and MobileDevHQ can report on the relative search volume and level of competition for each keyword in the iTunes App Store.

Keywords with the highest traffic and lowest competition should be included in the keyword field to maximize the potential visibility for the app. To take full advantage of the characters available, do not use spaces in between words (for example, use “banana,orange,grape” instead of “banana, orange, grape” or “banana orange grape”). Even if you are targeting a keyword phrase, each word in the phrase will also need to be separated with a comma and no spaces (for example, use “fruit,salad” instead of “fruit salad”)

In the past, the iTunes App Store algorithm couldn’t understand synonyms, tenses, plurals or contextual keywords, so this keyword field had to include any and all variants of a keyword that an app wanted to target. Now that the iTunes App Store’s algorithm is more sophisticated, SEOs no longer need to waste space with excessive synonym or plural variants in the Keyword Field. (For example, an app that used to submit “jump,jumping,jumped,jumps” could now address all these keyword variants with just “jump.”)

The App Store’s new, better understanding of keyword variants and context has made it easier for iOS apps to target a larger number of keywords and keyword phrases. Unfortunately, the iTunes App Store algorithm does still not understand all synonyms and semantics, so you should monitor the app’s rankings for important synonyms.

It is a good idea to review and update your keyword list each time you make an update to an app. The easiest way to do this is to order the keywords from most to least important. At each update, you should review how the app is ranking on the various keywords.

If the app is struggling to rank on particular keywords, especially ones that are less important, then it might be a good idea to switch those words out for words that might allow the app to perform better. Track how the app performs on the new keywords, and ideally you’ll see incremental improvement in overall rankings with each update.

App Description

The next piece of meta data that needs to be optimized is the App Description. The App Description is an app listing requirement that is used to explain the value and functionality of the app. It can also add supporting keyword optimization to bolster app rankings.

Until recently, only Google Play was using the App Description for keyword relevance, but now, both Google Play and the iTunes App Store are using it to inform their app ranking algorithm.

UPDATE: We have recently heard from some ASOs that they have still not seen a correlation between keywords in their iOS description and their app’s rankings. Their data only shows the apps ranking for contextual keywords from the title, categories, and keyword field, so descriptions may not be impacting all iOS apps at this time. Our apps have started to rank for some keywords only available in the app description that are not otherwise contextual with the app’s title or keyword field. These rankings are shown in the graph below.


In the Google Play Store, you can submit a short description and a long description, but in the iTunes App Store, you can only submit a long description. The long description can be up to 4,000 characters in both stores, while the Google Play short description is limited to just 80 characters.


The keywords used in the long description(s) should mirror and support keywords selected for the App Title and App Categories, including reasonable use of synonyms and related terms, like traditional on-page SEO.

Tools like Sensor Tower and MobileDevHQ can estimate the search volume and the level of competition for each keyword in the iTunes App Store and Google Play Store. Keywords with high traffic and low competition are ideal.

Keywords used in the Google Play short description have an even stronger correlation to keyword rankings and are also highly correlated with App Pack rankings, discussed above. The most important keywords should also be referenced here.

It is a good idea to review your description each time you update your app. Make sure that it is accurate and informs readers about any significant updates, improvements or benefits. You should also make sure the description is formatted in a way that is easy to read on a mobile phone.

The Google Play Store allows for more rich text in the long description than the iTunes App Store, but simple text formatting can still go a long way. Including meaningful bullets, headings and paragraph breaks can make your App Description much easier to read and more compelling. This helps drive downloads and prevent uninstalls.

Developer Name

The Developer Name is another piece of meta data that you can optimize. The app store algorithms consider keywords used in the name of the developer account that submits each app.

This means that you don’t always need to repeat keywords used in your developer name in other areas of your app meta data in order to rank for them in the OS-specific app stores. For example, if the Developer Name for your app is “GlitterPony LTD,” you don’t need to optimize your description or title for “GlitterPony.”

That said, it may make sense to repeat a keyword from the Developer Name in the App Title if it is especially competitive and relevant, because keywords used in the title are given additional algorithmic weight.

For example, if you’re targeting a highly competitive keyword like “Photo,” and your Developer Name is “Photo Business LLC,” you’d still want to make sure that “photo” is repeated in the App Title to have a better chance at ranking.

At this point, you may have already committed to a Developer Name by setting up a developer account in iTunes Connect or the Google Play Console, but if you have the opportunity or flexibility to change it, a strategic name change could help drive rankings.

In the App Store, developer account names are strict, and once they are in place, they are hard to change without intervention from Apple’s Developer Support Team. It’s much easier if you can choose an accurate and keyword-relevant Developer Name from the start.

Apps can be transferred to a new Apple developer account, but certain features – like in-app purchased subscriptions – may be lost in the process. In the Google Play Store, developer names are easy to change, and the process is documented here.

Dynamic Success Metrics

Dynamic Success Metrics are the other half of the app store search algorithms. They are based on user behavior in the app stores, and they are constantly changing and being updated. While we can’t directly determine these metrics, we can influence them.

Apps that can create an active and positive influence on these Dynamic Success Metrics will have an easier time ranking well for a broader range of keywords over time. Dynamic Success Metrics differ between the OS-specific app stores, and not all of them are entirely known or described overtly by either store.

From what we know, they include: Download Volume, Download Velocity, Ratings/Reviews Volume, Ratings/Reviews Quality, Freshness (how recently the app was updated), Links (Google Play Only) and +1s (Google Play Only).

A summary of the Dynamic Success Metrics and their impact on rankings in the two app stores is included below. You can see that the Dynamic Success Metrics in the iTunes App Store are fairly simple and straightforward, focusing mostly on download volume and velocity and only somewhat on Review Volume and Sentiment.

Google Play has a slightly more complex evaluation that also includes metrics like “links” that are more traditionally associated with web-based algorithms.


Optimizing for this dynamic part of the algorithm will be different from what most SEOs are used to, but don’t let this deter you, because these elements are extremely powerful.

App Download Volume And Velocity

Download Volume and Velocity are two of the biggest determinants of an app’s ranking in the OS-specific app stores. “Download Volume” is the total number of times an app has ever been downloaded, and “Download Velocity” is the number of times an app is downloaded in a given period of time.

Driving app downloads is especially important at the launch of a new app, because a strong launch will indicate that the app is particularly sought-out or popular. When launching a new app, marketers should leverage all normal digital marketing channels to help drive download volume and velocity. This includes using email, PR, social media and on-site promotion to notify your most loyal users and the interested public about the launch or update.

Most seasoned app marketers will also invest in paid ads to drive app downloads, especially during a launch or an update. This is because the app store algorithms do not distinguish between downloads generated from paid ads and downloads generated from organic search search — the two combined will contribute to an app’s ability to rank organically.

Here, the velocity generated by paid downloads helps the app rise in the app rankings, which, in turn, drives overall Download Velocity and Volume. It has a compounding effect. Ian Sefferman from Mobile Dev HQ says that apps can gain as many as three organic downloads for every two paid downloads.

One of the toughest questions app marketers face is when to stop paying for app advertising, especially if you are working with an app that has an aggressive and frequent update schedule. Making this decision can be more of an art than a science, but generally, campaigns for free apps can be turned down or shut off when top rankings have been achieved on all the core branded and unbranded keywords. Even then, the keyword rankings and app downloads should be monitored closely for a drop.

If either metric falls outside of the normal performance for the app, restart or increase the campaigns. Obviously, more sophisticated calculations and arbitrage are needed to determine when (if ever) ads should be stopped for paid apps.

NOTE: While running ads is OK, purchasing app downloads through click farms that use bots or even people to download and install apps on thousands of phones is not okay. Apple and Google have both spoken out against this practice.

They are working to develop methods of identifying and penalizing apps or developer accounts that do it. Both stores actively gather engagement data, so apps with an unusual download-to-engagement ratio could easily be flagged as suspicious and penalized or banned in the near future.

App Star Ratings Sentiment & Volume

Star ratings and reviews are another important Dynamic Success Metric that marketers can influence. Both the quality and volume of star ratings and reviews contribute to an app’s ability to rank.

Activities that help minimize negative star ratings and reviews and maximize positive star ratings and reviews can make your app more appealing to potential users while also making it more algorithmically likely to rank.

The best way to encourage positive star ratings and reviews is by adding a review dialogue into the user-flow of the app. The review dialogue asks people if they like the app or not.

People who respond that they like the app are linked to the app store landing page and encouraged to leave a positive review. People who respond that they do not like the app are linked to a bug-report form in the app to provide feedback directly to the development team.

There are a variety of tools and custom solutions that developers can use to initiate a review request dialogue when someone is using an app. If you use a tool or develop your own custom review dialogue, these are the core Best Practices to keep in mind:

  • Send happy people to review your app; send unhappy people to your support/help center. Try to determine how someone feels about your app before asking for a review. This will help keep negative reviews out of the store (so they can’t negatively impact rankings). This feedback can also help your QA team generate a great support queue full of tickets.
  • Don’t interrupt a user to ask for a review. Never ask a user to review your app right when they launch the app. This prevents them from doing the very thing that they opened your app to do, so they will likely leave a negative review if they choose to participate at all. It is best to trigger reviews when there has been a clear success in the app, like after the user has won a game or completed a task. This will make it more likely that they have time to provide a review and more probable that the review will be positive.
  • If a user says they don’t want to review your app, don’t ask them again. Repeated requests that ignore user input generally lead to more negative reviews than positive reviews, which can hurt rankings. It is okay to let users to choose “remind me later” in the review dialogue, but the most you should ask for a review is about once a month. Even then, you should include the “never ask me again” option in the dialogue, so that you do not hurt the experience for an enthusiastic user who would prefer not to leave a review.

Most low star ratings and negative reviews are caused by actual technical difficulties in the app, so those should be addressed as quickly as possible.

Eliminating major roadblocks to successful use of the app can have a dramatic impact on star ratings, and thus the overall ranking of the app. An example of a technical change that lead to a significant rankings increase in late 2013 is shown in the graph below.


Beyond this, a great way to keep bad reviews out of the app stores is to include a “Help” and “FAQ” section in the app, and make those screens indexable in Google search. This provides struggling users with immediate feedback and assistance.

You should also strive to accept and solicit feedback in all the channels where you communicate with customers, including social media, email and on your primary website. Negative feedback issued in these channels does not affect app rankings and is usually more productive than app store reviews.

When you make it easy for app users to provide feedback, you remove frustration from the path of someone who already wants to complain. You also make it easier to facilitate a two-way dialogue in the event your development team has questions or cannot recreate a problem. If you can fix the problem, you may convert someone who otherwise would have been a detractor into a potential advocate.

Any company with an app should actively monitor their app star ratings and reviews, and the best tool for the job is usually AppAnnie.

Even without a paid subscription, this tool can chart and graph the star ratings and reviews and aggregate them for you by version number or country. This is a great way to get a sense for the successes or concerns with a recent launch and to create a punch list of things that must be addressed in the next update.

The Google Play Store even allows developers to respond to positive and negative reviews. You can use App Annie to prioritize the reviews that need a response.


If you’ve increased your downloads and improved your ratings and reviews, the next thing you’ll want to evaluate is the app’s update schedule. Both Apple and Google want to show current apps in their app stores, so apps that are more frequently updated tend to perform better.

This Dynamic Success Metric is not as strong a ranking signal as the other previously mentioned factors but can be seen as more of a “booster.” If the app has other strong signals, recent updates may help it improve in the rankings. If the app is already performing poorly across the board, an update will not generate a significant increase in rankings, if any. This is why it’s easiest to see the correlation between updates and rankings on high-download volume apps.

App updates may also be an indirect ranking factor. App stores will typically only display ratings and reviews for the current version of the app, so a strategically timed update can “over-write” the visual representation of historically bad app ratings and reviews in the app stores.

Users are more likely to download an app that does not appear to have bad reviews, so an update that resets the star rankings and reviews could encourage more downloads, which is a direct ranking factor.

Links & Google +1s

Google has spent more time building out search algorithms than Apple. Since Google has a deeper understanding of search and their users’ cross-device behavior, they also include some web-style signals as light ranking factors in Google Play.

The number of links an app landing page receives will help drive rankings in Google Play. It is important to link from your website to your app store’s landing page in both the Android and iOS world. But for Android, there may be an additional benefit from driving links from app review sites, YouTube videos, editorial aggregated lists and the like. At some point in the future, when app screen crawling becomes more sophisticated, deep links from one app screen to another may also help contribute to Google Play rankings.

Similarly, Google Play incorporates the +1 system from Google Plus, to allow users to indicate that they like a particular app. This also has a slight algorithmic ranking in Google Play rankings. When users “+1” an app, Google may promote the app to that user’s Google Plus “friends” network in the Google Play Store.

This social endorsement can incentivize more downloads. Sharing information about your app on Google Plus — including reviews, tutorials, videos and update information — can help drive +1s from the audience that is most likely to engage with the app.


Apps are becoming more and more accessible in search, and this represents a truly pivotal moment in search marketing. Users can now discover apps in more ways than ever before — they have the potential to rank well in the OS-specific app stores or directly in Google.

Both specific app screens and apps as a whole can rank, depending on the context. With that, SEOs have many growing opportunities to improve app visibility through different kinds of search engines and stores.

New technologies like App Streaming will soon allow users to preview app content without a need for editorial text and screenshot “previews” in the app stores. This new way of showcasing apps threatens to make app meta data inefficient, or even entirely obsolete. The user benefit of app meta data may soon diminish or be retired, like the meta keywords tag in early SEO.

Now that Google is also testing app installs directly from search results, will App Stores be able to survive? Will they dissolve or linger only as relics, like so many website directories in the early dot-com days? Or will they evolve to surface apps based on more sophisticated algorithmic signals?

Especially as Deep Linking and App Indexing become more common, app discovery may continue to shift from the app stores to more traditional search engines, but for now, app stores still drive the bulk of app downloads.

An optimization strategy that combines app meta data optimization, dynamic success metric optimization, App Pack optimization and tactical app indexing will ensure the app is optimized for current marketplaces while also preparing for the future.

With the rise of new wearables and internet-connected devices, ASO will continue to evolve as new app stores and marketplaces emerge. SEOs investing in strategies to optimize content beyond websites and traditional Google search will reap the early-market rewards in this new era.

The post App Indexing & The New Frontier Of SEO: App Packs & App Store Search appeared first on Search Engine Land.

App Indexing & The New Frontier Of SEO: Google Search + Deep Linking /app-indexing-new-frontier-seo-google-search-deep-linking-226517 /app-indexing-new-frontier-seo-google-search-deep-linking-226517#respond Wed, 12 Aug 2015 13:12:47 +0000 http:/?p=226517 In part two of a three-part series on app indexing, contributors Emily Grossman and Cindy Krum explore how Google indexes deep app content and explains what marketers can do to promote their app content in Google search.

The post App Indexing & The New Frontier Of SEO: Google Search + Deep Linking appeared first on Search Engine Land.


In this article, you’ll learn how Google is surfacing deep app content and how SEOs can prepare iOS and Android deep app screens for Google’s index. Google is making significant moves to close the gap between app and Web content to make mobile interaction more seamless, and that theme will reappear throughout the analysis.

This is the second installment in a three-part series about app indexing strategies and deep linking opportunities. The first article focused on Apple’s new Search API for iOS 9, which encourages and incentivizes an app-centric mobile experience.

Today’s column, co-authored with Cindy Krum, will focus on how Google indexes deep app screens and what marketers can do to promote their app content in Google search. Google’s app indexing strategies differ significantly from Apple’s, and it’s important for marketers to understand the distinctions.

The third article in this series will focus on future app indexing challenges we will face with the growth of wearables and other non-standard device apps and device indexes.

App Indexing In Google

Historically, app landing pages on websites have been in the Google index — but actual apps and internal app screens have not. Because crawling and indexing in-app content was impossible until recently, users had to discover new apps via an app store (Google Play or iTunes), which surfaces apps according to app meta data and editorial groupings instead of in-app content. For digital marketers, internal app content has been unavailable for search — part of what Marshall Simmonds calls “dark search.”

This situation has created a two-fold problem for Google:

  1. App stores had trained users away from using Google for app discovery; and
  2. App developers were historically not incentivized to optimize internal app data for search. This limited Google’s mission to collect and organize the world’s data, which in turn limited its ability to make money.

Now that Google is indexing both app landing pages and deep screens in apps, Google’s app rankings fall into two basic categories, App Packs and App Deep Links. App Packs are much more like the app search results that SEOs are used to, because they link to app download pages in Google Play or the App Store, depending on the device that you are searching from. (App Packs will only show apps that are compatible with your device’s OS.)

Ranking in an App Pack (and also in the Apps Universal, under Google’s top-navigation drop-down in the mobile search results) relies heavily on the app title, description, star ratings and reviews, and it will differ greatly from the internal app store rankings, as well as in-app indexing strategies described in the rest of this article.

Deep links are different because they link to specific deep screens within an app. Google has displayed deep links in search results in a variety of ways since it started app indexing, but there are a couple of standard deep link displays (shown below) that seem more common than others. Some deep-linked results look no different from traditional blue links for websites, while other deep link search results contain more attractive visual elements like colored “install” buttons, app icons and star ratings.


[click to enlarge]

We believe that the most common deep link in the future will display the app icon and a small “open on domain.com” button because that allows users to choose between the deep app link and the Web link without an additional dialogue screen. (Currently, the dialogue screen from other types of deep links comes from the bottom of the browser window and says, “Would you like to open this in Chrome or in the [Brand Name] app?”)

It is important to note that aspects of the search context, like the mobile browser, can limit the visibility of deep links. For example, Google only supports app indexing on iOS inside the Google and Chrome apps, not in Mobile Safari, the default Web browser on iOS. It seems likely that Safari will be updated to allow for Google’s deep linking behaviors as part of the iOS 9 update, but it is not confirmed.

Similarly, Google has been experimenting with a “Basic” mobile search results view that omits rich content for searchers with slow carrier connections. “Basic” search results do not include App Packs at all (since downloading an app would not be attractive to people with slow connections), and deep link results will only show as inline blue links, without images, star ratings, icons or buttons.

These are important stipulations to keep in mind as we allocate time and budget to optimizing app indexing, but the benefits of Google app indexing are not limited to surfacing deep app screens in Google search results.

Why Is App Indexing Important For SEO?

Without apps in its index, Google was missing a huge piece of the world’s data. The new ability to index iOS and Android apps has fundamentally changed app discovery and dramatically changed mobile SEO strategies.

Now that Google’s search engine can process and surface deep app content in a similar fashion to the way it does Web content, Google search has a significant advantage over the app stores. It is still the #1 Search Engine in the world, so it can easily expose content to more potential customers than any app store could, but it can also integrate this new app content with other Google properties like Google Now, Inbox/Gmail and Google Maps.

This change has also added a whole new host of competitors to the mobile search result pages. Now, not only can app landing pages rank, but internal app screens can also compete for the same rankings.

Google’s official position at the moment is that Web parity is necessary for deep app indexing (i.e., crawlable Web content that matched the indexable app content), but at Google I/O, the company clarified that they are working on a non-parity app indexing solution. They have even started promoting an “app only interest form,” and recent live testing has reinforced the idea that apps without parity will soon be added to the index (if they haven’t been already).

Hotel Tonight App Only Indexing
This is a big deal, so SEOs should be wary of underestimating the potential market implications of Google indexing apps without Web parity. For marketers and SEOs, it means that mobile search results could soon be flooded with new and attractive competition on a massive scale — content that they never have had to compete with before.

Let’s do a bit of math to really understand the implications.

We’ll start with a broad assumption that there are roughly 24,000 travel apps, a third of which lack Web parity. If each app contains an average of just 1,000 screens (and travel apps often include many more than that), we’re looking at roughly 8,000,000 new search results with which travel websites must compete — and that’s in the travel industry alone. That is huge!

Games, the biggest app category in both stores, promises to create an even bigger disruption in mobile search results, as it is a category that has a very high instance of apps without Web parity.

Another subtle indication of the importance of app indexing is the name change from “Google Webmaster Tools” to “Google Search Console.” Historically, webmasters and SEOs have used Google Webmaster Tools to manage and submit website URLs to Google’s index. We believe the renamed Google Search Console will eventually do the same things for both Web and apps (and possibly absorb the Google Play Console, where Android apps have been managed). In light of that, removing the “Web” reference from the old “Webmaster Tools” name makes a lot of sense.

A similar sentiment by John Mueller, from Google, is noted below, and possibly hints at the larger plan:

John Mueller on Google Plus

How Does Google Rank Deep Links?

Like everything else, Google has an algorithm to determine how an indexed deep link should rank in search results. As usual, much about Google’s ranking algorithm is unknown, but we’ve pieced together some of the signals they have announced and inferred a few others. Here’s what we currently believe to be true about how Google is ranking deep links in Google Search:

Known Positive Ranking Factors

  • Installation Status. Android apps are more prominently featured in Google search results when they are installed on a user’s device or have been in the past. Rather than checking the device, Google keeps track of app downloads in their cloud-based user history, so this only affects searchers when they are signed into Google.
  • Proper Technical Implementation. The best way app publishers can drive rankings, according to Mariya Moeva of Google, is to “ensure that the technical implementation of App Indexing is correct and that your content is worth it.” She later elaborated in a YouTube video, explaining that app screens with technical implementation errors will not be indexed at all. (So start befriending the app development team!)
  • Website Signals (title tags, description tags). Traditional SEO elements in the <head> tag of the associated Web page will display in deep link search results, and thus are also likely ranking factors for the deep links. In fact, good SEO on corresponding Web pages is critical, since Google considers the desktop Web version of the page as the canonical indexing of the content.

Known Negative Ranking Factors

  • Content Mismatch. Google will not index app screens that claim to correspond with a Web page but don’t provide enough of the same information. Google will report these “mismatch errors” in Google Search Console, so you can determine which screens need to be better aligned with their corresponding Web pages.
  • Interstitials. Interstitials are JavaScript banners that appear over the content of a website, similar to pop-ups but without generating a new browser window. The same experience can be included in apps (most often for advertisements), but this has been discouraged by both Apple and Google. In her recent Q&A with Stone Temple Consulting, Mariya Moeva implied that app interstitials are a negative ranking factor for deep links (and said to stay tuned for more information soon). Interstitials can also prevent Google from matching your app screen content to your Web page content, which could cause “Content Mismatch Errors” that prevent Google from indexing the app screen entirely. In either case, app and Web developers should stay away from interstitials and instead, opt for banners that just move content down on the screen. Both Apple and Google have endorsed their own form of app install banners and even offer app banner code templates that can be used to promote a particular app from the corresponding mobile website.

Apart from ranking on their own, app deep links can also provide an SEO benefit for websites. Google has said that indexed app deep links are a positive ranking factor for their associated Web pages, and preliminary studies have shown that Web pages can expect an average site-wide lift of .29 positions when deep link markup is in place.

Also, App Packs and App Carousels tend to float to the top of a mobile SERP (likely ranking as a group rather than ranking independently). Presence in these results increases exposure and eliminates a position that a competitor could occupy lower down in the organic rankings, since these “Packs” and “Carousels” take up spaces that would be previously held by websites.

Indexed Android apps will also get added exposure in the next release of the Android operating system, Android M. It includes a feature called “Now on Tap,” which represents a deeper integration of Google Now with the rest of the Android phone functionality. Android M allows Google to scan text on an Android user’s screen while in any app, then interpret a “context” from the on-screen text, infer potential queries and automatically display mobile applications that could assist the user with those inferred queries.

For example, a WhatsApp conversation about dinner plans could pull up a “Now on Tap” interface that suggests deep links to specific screens in OpenTable, Google Maps and Yelp. This only works for deep-linked app screens in Google’s index, but for those apps, it will likely drive significantly higher engagement and potentially more installs. From a strategic perspective, this adds another potential location to surface your content, beyond the mobile search results.

While Google will only surface apps they have indexed, they plan on crawling on-screen text in all apps, trying to perceive context for “Now on Tap.” Google doesn’t provide any opt-in mechanism, so Android apps that are not indexed for Google search can still be crawled to trigger a “Now on Tap” experience. This means that Google is essentially reserving the right to send users away from your app to a different app that has relevant screens in the index, but also that Google is allowing your app to “steal” users away from other apps if your app screens are in the index.

This could provide nearly limitless opportunities for “Now on Tap” to suggest apps to Android users, and the “rogue crawling” aspect of it reinforces our prediction that Google will soon be crawling, indexing and surfacing app screens that don’t have Web parity. This will make Google’s app indexing an even more important strategy for Android apps, especially once Android M is widely adopted.

The app rankings advantage is pushed to the next level when you understand that Google is intentionally giving preference to app results for certain queries. In some cases, being an indexed app may be the only way to rank at the top in mobile Google search. Keywords like “games” and “editor” are a common trigger for App Packs and App Carousels, but Google is also prominently surfacing apps for queries that seem to be associated with utilities or verbs (e.g., “flight tracker,” “restaurant finder,” or “watch tv”). And when the App Packs or Carousels appear, they often push the blue links below the fold (and sometimes way below the fold).

At the end of the day, for some queries, a blue link may not ever beat the “Packs” — in which case, the best strategy may be to focus on App Pack listings over deep links.

How Can I Get Deep App Screens Indexed For Google Search?

Setting up app indexing for Android and iOS Apps is pretty straightforward and well-documented by Google. Conceptually, it is a three-part process:

  1. Enable your app to handle deep links.
  2. Add code to your corresponding Web pages that references deep links.
  3. Optimize for private indexing.

These steps can be taken out of order if the app is still in development, but the second step is crucial; without it, your app will be set up with deep links but will not be set up for Google indexing, so the deep links will not show up in Google Search.

NOTE: iOS app indexing is still in limited release with Google, so there is a special form submission and approval process even after you have added all the technical elements to your iOS app. That being said, the technical implementations take some time. By the time your company has finished, Google may have opened up indexing to all iOS apps, and this cumbersome approval process may be a thing of the past.

Following are the steps for Google deep-link indexing. (For a PDF version of the instructions, click here.)

Step 1: Add Code To Your App That Establishes The Deep Links

A. Pick A URL Scheme To Use When Referencing Deep Screens In Your App

App URL schemes are simply a systematic way to reference the deep linked screens within an app, much like a Web URL references a specific page on a website.

In iOS, developers are currently limited to using Custom URL Schemes, which are formatted in a way that is more natural for app design but different from Web.

In Android, you can choose from either HTTP URL schemes (which look almost exactly like Web URLs) or Custom URL Schemes, or you can use both. If you have a choice and can only support one type of URL Scheme on Android, choose HTTP.


B. Support That App’s URL Schemes In The App

Since iOS and Android apps are built in different frameworks, different code must be added to the app to enable the deep link URL Schemes to work within the specific framework.


See PDF for clickable links.

C. Set Up CocoaPods

CocoaPods is a dependency management tool for iOS. It acts as a translation layer between iOS apps and the Google SDKs, so it is only necessary in iOS apps. Google has moved all its libraries to CocoaPods, and this will now be the only supported way to source them in an iOS app.


See PDF for clickable links.

NOTE: Developers who have never worked with CocoaPods may have to rework how they currently handle all dependent libraries in the app, because once CocoaPods is installed, it is harder and more complicated to handle other non-CocoaPods libraries. There are some iOS developers who favor CocoaPods and have been using them for some time, so your app may already be working with CocoaPods. If that’s true, prepping for iOS app indexing will be much easier.

D. Enable The Back Bar

iOS devices don’t come equipped with a hardware or persistent software “back” button, so Apple and Google have built workarounds to make inter-app back navigation easier. Google requires that iOS apps recognize an additional GSD Custom URL Scheme (that was set up in Step 1B). Google only uses this to trigger a “back” bar in the iOS app.

Google will generate the GSD Custom URLs automatically when someone clicks on an iOS deep link from a search result page, so we don’t need to generate new GSD deep links for every screen; we just need to support the format in the Info.plist file and add code that will communicate with the “GoogleAppIndexing” Pod when a GSD link is received by the app.


NOTE: Google’s solution is similar to Apple’s iOS 9 “Back to Search” buttons that display in the upper left portion of the phone’s Status Bar, but when it is triggered, it appears as a blue “Back Bar” that hovers over the entire phone Status Bar. The Back Bar will disappear after a short period of time if the user does not tap on it. This “disappearing” behavior also represents a unique experience for iOS deep linking in Google, since after a certain period of time, there won’t be a way for iOS users to get back to the Google Search results without switching apps manually, by clicking through the home screen. Developers compensate by adopting more tactics that pull users deeper into the app, eat up time, and distract the user from going back to Google Search until the bar disappears.

E. Set Up Robots & Google Play/Google Search Consoles

In some cases, it may make sense to generate deep links for an app screen but prevent it from showing up in search results. In Android, Google allows us to provide instructions about which screens we would like indexed for search and which we would not, but no similar mechanism is available for iOS.

Digital marketers and SEOs should use the Google Play Console and the Google Search Console to help connect your app to your website and manage app indexation. Also, double check that your website’s robots.txt file allows access to Googlebot, since it will be looking for the Web aspect of the deep links in its normal crawls.


Step 2: Add Code To Your Website That References The URL Schemes You Set Up In The App

A. Format & Validate Web Deep Links For The Appropriate App Store

Google’s current app indexing process relies on Googlebot to discover and index deep links from a website crawl. Code must be added to each Web page that references a corresponding app screen.

When marking up your website, a special deep link format must be used to encode the app screen URL, along with all of the other information Google needs to open a deep link in your app. The required formatting varies slightly for Android and iOS apps and is slightly different from the URL Schemes used in the app code, but they do have some elements in common.

The {scheme} part of the link always refers to the URL scheme set up in your app in Step 1, and the {host_path} is the part of the deep link that identifies the specific app screen being referenced, like the tail of a URL. Other elements vary, as shown below:


See PDF for clickable links.

B. Add Web Deep Links To Web Pages With Corresponding App Screens

Internal app screens can be indexed when Googlebot finds deep app links in any of the following locations on your website:

  • In a rel=”alternate” in the HTML <head>
  • In a rel=”alternate” in the XML sitemap
  • In Schema.org ViewAction markup

Sample code formatting for each of those indexing options is included below:

rel-alternate-sample-code xml-sitemap-sample-code schema-sample-code

Step 3: Optimize For Private Indexing

Both Google and Apple have a “Private” indexing feature that allows individual user behaviors to be associated with specific screens in an app. App activity that is specific to one user can be indexed on that users’ phone, for private consumption only (e.g., a WhatsApp message you’ve viewed or an email you’ve opened in Mailbox).

Activities that are Privately indexed do not generate deep links that can surface in a public Google search result, but instead generate deep links that surface in other search contexts. For Android apps, this is in Chrome’s autocomplete and Google Now; for iOS, this is in Spotlight, Siri, or Safari’s Spotlight Suggest results.


See PDF for clickable links.

NOTE: Google’s documentation seems to indicate that Activities are only used for private indexing, but Google may also use them as a measurement of engagement for more global evaluations of an app (as Apple does with NSUserActivities in Apple Search). Google has not highlighted their private indexing feature as vocally as Apple, and a user’s private index can be accessed from the Phone icon in the bottom navigation of the Google Now app on Android and iOS. Currently, only Google’s apps (like Gmail) are able to surface privately indexed content in organic Google search results, but we suspect this will be opened up to third-party apps in the future.

Concluding Remarks

App indexing and deep linking are changing the digital marketing landscape and dramatically altering the makeup of organic mobile search results. They are emerging from the world of “dark search” and becoming a force to be reckoned with in SEO.

Marketers and SEOs can either look at these changes as a threat — another hurdle to overcome — or a new opportunity to get a leg up over the competition. Those who wish to stay on the cutting edge of digital marketing will take heed and learn how to optimize non-HTML content like apps in all of the formats and locations where they surface.

That being said, relying on app deep links alone to drive Google search engine traffic is still not an option. Traditional SEO and mobile SEO are still hugely important for securing a presence in Google’s mobile searches. Google still considers desktop websites the ultimate canonical for keyword crawling and indexing, and the search engine relies heavily on website parity because its strength is still crawling and indexing Web content.

The next big app indexing questions are all about apps that lack Web parity. Google does not currently use a roaming app crawler to discover deep links themselves, but we feel confident that this will change. Google’s App Indexing API currently only helps surface Android apps in autocomplete, but we believe in the future, it will help surface apps that don’t have Web parity.

Calling the system an “App Indexing API” seems to allude to a richer functionality than just adding app auto-complete functionality — and Google’s original app indexing documentation from April also indicated a more robust plan.

As shown in the diagram below, the original documentation explained that developers could use the App Indexing API (also referred to here as “Search Suggest,” which is different from the Search Suggest API) to notify Google of deep links “with or without corresponding Web pages.” That line has since been removed from the documentation, but the implication is clear: Google is paving the way for indexing apps without Web parity. Until that happens, traditional website optimization will remain a key component of optimizing app content for Google search, but when app screens can be indexed without Web parity, there will be a whole new set of ranking factors to consider and optimize for.

App Indexing API Verbiage

As we charge into this new frontier, the immediate benefits of app indexing are clear, but the newness may require a small leap of faith for more traditional marketers and SEOs.

Some may be left suspicious, with many questions: How long will Google provide a ranking benefit for deep-linked content? Will this be perceived as a “bait and switch,” like the Mobile Friendly update? Will app ranking factors evolve to include more traditional Web page ranking factors (like links and social signals)? Will Google begin to crawl app content more indiscriminately, using deep app links like Web links? Will Google develop a new app-specific crawler, or was the algorithm change on April 21 (aka “Mobilegeddon“) really this — that apps are already being crawled, rendered and evaluated by the smartphone crawler, just the same as Web?

Let us know what you think in the comments.

The post App Indexing & The New Frontier Of SEO: Google Search + Deep Linking appeared first on Search Engine Land.

/app-indexing-new-frontier-seo-google-search-deep-linking-226517/feed 0
App Indexing & The New Frontier of SEO: Apple Search + iOS App Indexing /app-indexing-new-frontier-seo-apple-search-ios-app-indexing-223880 /app-indexing-new-frontier-seo-apple-search-ios-app-indexing-223880#respond Mon, 06 Jul 2015 13:45:19 +0000 http:/?p=223880 In the first of her 3-part series on app indexing, contributor Emily Grossman discusses what Apple's new search API means for search engine optimization (SEO) professionals looking to surface deep app content for iOS users.

The post App Indexing & The New Frontier of SEO: Apple Search + iOS App Indexing appeared first on Search Engine Land.


Every year in June, Apple and Google hold conferences to announce their latest technology. With each announcement, both companies seem to be reaffirming their larger company goals and values — Apple asserting its commitment to designing and selling quality products, and Google bolstering its mission to collect and organize the world’s data with the ultimate intent of monetizing the results with advertising.

These goals resurface through many of the company’s business decisions, most recently through the divergent app indexing frameworks promoted by the two companies. For a long time, deep app content has been locked in app code, largely un-indexed and inaccessible to search engine crawlers. The only content that crawlers could get was app titles and descriptions from the various app stores, and from company websites.

Now that both Apple and Google have announced methods for indexing deep content within apps, the situation has dramatically and irreversibly changed. For those interested in the most cutting-edge digital marketing strategies, the concept of SEO will have to expand to include optimization of deep app content for inclusion in the Apple and Google indexes.

Apple’s overall focus on “products” positions the company to gain the most from a primarily app-based world. In Apple’s ideal scenario, the web is only used as an invisible layer that links apps together and allows apps to become their own uniquely-controlled display-layers for private and public content.

Conversely, Google stands to gain the most from a web-based world where data can be most easily collected, organized, and distributed so Google can become the presentation layer of the Internet. While apps are part of their data collection strategy, Google has invested heavily in programs that allow developers to create HTML5 web content to rival apps and thus return users to a web-based ecosystem.

This article is the first in a three-part series about new strategies and opportunities for app indexing in Apple, Google, and other ecosystems.

This first article focuses on the ways in which Apple’s new Search API for iOS 9 encourages and incentivizes an app-centric digital ecosystem and what that means for marketers looking to surface deep app content for Apple users. This is a comprehensive guide of what you as an SEO need to know about Apple’s foray into search engineering, what it means for your company’s app strategy, how it impacts your company’s SEO strategy, and how to take advantage of these new opportunities to surface your company’s app and website in Apple Search.

The subsequent articles in the series will focus on Google’s app indexing opportunities and the associated strategies, and on future app indexing challenges we will face with the growth wearables and other non-standard device apps and device indexes.

What Is Apple Search & Why Does It Matter For SEO?

If you want to surface your app content for iOS users, Apple Search could become a key part of your SEO strategy. Like Google, Apple Search relies on an index (or more accurately, multiple indices) to organize the set of app screens that can be ranked in a search result. Apple refers to their indexes and the software that interfaces with those indexes collectively as “Apple Search.”

Indexed app screens can be surfaced by executing a search in Spotlight or Siri, or through a Spotlight Suggest result that appears when a user types in a query in the address bar of Safari (before hitting “enter”). This means that a user can start a search on Safari and end up being directed to a deep link without ever seeing a single Google result — even where Google is the “default” search engine.

To accomplish this, Apple has introduced the concept of public and private indexing, and three methods for iOS developers to get their app screens indexed for Apple Search: NSUserActivity, CoreSpotlight, and Web Markup.

Despite being limited to iOS app indexing (sorry Android buddies, your apps can’t play here), Apple’s new Search and indexing framework will be an important traffic channel, especially for Apple users who sometimes bypass Google’s algorithms entirely. Unlike Google, Apple has come up with two indexing methods that do not require corresponding web pages to drive app indexing:

1. NSUserActivity Indexing

In this indexing method, Apple indexes “user activities,” which you can think of as a sort of “bookmark + JsessionID + cookie” snapshot of a app screen, complete with the navigational understanding of how a user got there and how they have interacted with that screen in the past. Apple calls these snapshots “NSUserActivities,” and they can be indexed by Apple when a developer adds search eligibility markup to the app’s code itself (no website needed), and a user accesses a screen with the markup.

Each NSUserActivity can also be associated with a contentAttributeSet which includes relevant meta data like titles, keywords, and descriptions. This information is used to create the appearance of the search result and to help determine rankings. Each NSUserActivity should have a uniqueIdentifier and/or include a URL link to its corresponding web content.

2. CoreSpotlight Indexing

The CoreSpotlight API has historically allowed native iOS components like the Calendar and Mail apps to include items in Spotlight search results. This is now being opened up to all apps in the App Store. This indexing method is somewhat analogous to submitting an XML sitemap in SEO, but the index file is submitted with your application manifest, and it is a different, iOS-specific code, created in a file called a “CSSearchableIndex.”

In this indexing method, the app screens to be indexed are called “CSSearchableItem(s),” and each one is associated with a label called a “uniqueIdentifier.” Each CSSearchableItem can be associated with a “CSSerchableItemAttributeSet” that includes relevant metadata like titles, keywords and descriptions. The CSSerchableItemAttributeSet is used to determine algorithmic relevance and populate the search result.

Each CSSearchableItem/uniqueIdentifier combo can also be associated with “domainIdentifier” to help group certain types of app screens in the database, so that they can be added or removed from the CSSearchableIndex as a group. For example, a uniqueIdentifier might be associated with a specific photo screen while a domainIdentifier might indicate all of the photos within an album.

The important thing to note is that NSUserActivity and CoreSpotlight source their search result meta data from code within the apps themselves (not from a website). This means that SEOs need to be more involved in the app development process earlier than ever before in order to ensure that Apple Search optimized title, description, and keyword markup is included in the app at launch (just like you would for a new web page launch back in 1999).

In addition to NSUserActivity and CoreSpotlight, Apple also allows you to get your deep app content indexed using a web crawler and deep link markup, similar to Google. Deep linking is a process in which web markup is used to link web URLs to their corresponding app screens (called URIs), so that a crawler can understand the connection between the URLs and the URIs. This option does require app content to have crawlable corresponding web content:

3. Web Markup Indexing

In this indexing method, Apple’s new web-crawler, “Applebot,” indexes app content from the marketing and/or support URLs that are submitted with the app manifest. Applebot can crawl your website and index corresponding app screens based on the following markup protocols:

    • Twitter Card Markup: Twitter Card markup can include a protocol to reference deep links to app screens.
    • App Links Protocol: App Links is an external deep linking standard that is also used by Facebook and Bing (and works on iOS and Android).
    • Apple’s Smart App Banners: A protocol created by Apple that displays a special Apple banner on websites when they are accessed from iOS devices. The banner either prompts the user to open the app (if installed) or download it from the App Store.

Additionally, though it won’t help you get new app screens indexed, Applebot can crawl two other protocols, looking for metadata to display in search results:

    • Open Graph: Facebook’s protocol that makes web content easier to share. Apple supports the full protocol and if OG tagging is already in place, Applebot can crawl it.
    • Schema.org: An external markup standard widely embraced across the web. Apple Search is launching with limited support, including the following schemas: AggregateRating, Offers, PriceRange, Interaction Count (likes, views, comments), Organization (phone numbers), Recipes, SearchAction (landing page for search), ImageObject and Actions, limited to: dialing a phone number, getting directions, playing audio or video file.

Web Markup is great for SEOs, because SEOs can enable and control indexing and metadata by adding markup to the website as we are used to doing. iOS app developers need only generate and share the URI deep links with the SEO team. If app URIs are already in place, this can be a very fast and simple implementation that doesn’t require any development resources or an app update.

IMPORTANT REMINDER: When iOS deep links on a web page are clicked (be it from your web page or even Facebook or Twitter), they initiate an “openURL” command that tells the phone Operating System to switch from the browser to an app — openURL must be enabled in your app code for deep links to open in the app.

Make sure your app can actually open deep links before you include them in your web markup. If you are relying exclusively on the Web Markup method for app indexing, you will still need to make this change to your app and submit the update. It’s a small detail, but an important one.

How Does Apple Rank Apps In Apple Search?

In light of an increased global sensitivity to privacy issues (think the “Right to Be Forgotten” in the EU), Apple has begun to focus on privacy concerns as a key differentiator, and selling point for their products and services. Apple’s new app indexing framework showcases a distinct effort to protect users’ personal information by introducing multiple app indexes:

  • A private ‘Device Index,’ which is a personal index that is only accessible by the specific user ID, like a small individualized database for each Apple user
  • A public ‘Cloud Index,’ which holds content that is accessible from any Apple device through Spotlight, Siri, or Spotlight Suggest in Safari

Because of this architecture, developers can (and should) allow a user’s private app screens to be saved to a private Device Index. Private screens in any app, such as direct messages and user dashboards, are now theoretically indexable.

NOTE: A similar personalized search history is used by Google, but has never been publicly described as a separate “index” or opened up for developer access. Google tested offering ‘desktop search’ years ago, and has recently been experimenting with indexing personal email results from Gmail. We expect this trend to continue and expand for both Google and Apple into the future.

Like Google, Apple has not disclosed the exact details of their search algorithm, but they have described some key ranking factors that should be considered. Many of Apple’s search ranking factors focus on determining how content should rank in a private Device Index vs. the public Cloud Index. SEOs need to be measured and responsible to have a positive impact on rankings because Apple has said that “malicious or poorly considered [app indexing strategy] implementations” will be penalized “or suppressed entirely” (put those black hats away).

A more comprehensive list of Apple Search ranking factors is included below:

Positive Ranking Factors

  • App Installation Status. Is the app is installed on the device? (installed apps seem to get preference)
  • Personalized App Engagement. Does the individual engage with the screen in the app? This is based on time spent with result that Apple determines from session analytics.
  • App Result Click-Through Rate. Do users frequently click through the search result vs. picking another result or searching again?
  • Keywords/ Title. Do keywords from the “keywords” and “title” designations in the app markup match up with the user’s query?
  • Aggregated Engagement. How many users engage with the app screen?
  • Structured Data on Web. Is structured data correctly implemented?
  • Canonical App IDs. Is the same screen associated with one unique ID or URL across multiple indexing methods (NSUserActivity, CoreSpotlight, and Web Markup)?
  • Strength/Popularity of Web URL. How popular is the website associated with the app deep links? (Presumably, this is based on Applebot’s crawl.)

Negative Ranking Factors

  • Low Engagement. Do very few users engage with the app screen? (engagement determined by session analytics)
  • Over-Indexing. Does the app have many screens in the index with low or no engagement?
  • Returns. Do users return to search results right after looking at the app?
  • Keywords Spamming. Are developers stuffing too many irrelevant keywords into the keyword field?
  • Interstitials. Is something covering the content in the app or preventing users from accessing it?
  • Javascript (web only). Is Javascript preventing Applebot from crawling your site to find new app deep links?
  • Low Star Ratings, Low Review Volume, Poor Reviews. Apple has not explicitly called these negative ranking factors for Apple Search, but they are negative ranking factors for the App Store, so we expect Apple to treat them similarly here.

Apple recommends pursuing multiple indexing methods to optimize app visibility, but the overlapping methods will inevitably create duplication across the various indexes. For example, private content could have both a NSUserActivity and CSSearchableItem indexed, and public content could have both a NSUserActivity and a Web Markup deep link indexed.

This is obviously not ideal for controlling Applebot’s efficiency, so Apple strongly recommends associating each NSUserActivity, CSSearchableItem, and Web Markup deep link with the same uniqueIdentifier and/or URL. This is Applebot’s version of a canonical, and it’s so important to Apple that they’ve even made it a ranking factor in the Apple Search algorithm.

How Do I Decide Which Indexing Option Is Most Strategic For My Company?

iOS developers can indicate which indexes they think their app content should be included in. Not all app content must be indexed, so the first question your company needs to answer is: Which content should be included in Apples index and which should not?

Then, since not all indexing methods can assign content to both the public and private indexes, ask: Of the content that should be indexed, which content should be publicly accessible, and which content should be private? The answers to these questions will be the beginning of your app indexing plan.

Generating a list of all app screens and their associated NSUserActivities, then mapping out the public or private nature of the content is an organized way to document this process. Once the private or public nature of app content is determined, the appropriate indexing method can be selected to meet those needs. The NSUserActivities and/or the CoreSpotlight indexing methods can both be used to index content that is intended for the private Device Index while NSUserActivities and or Web Markup can both be used to index content that is intended for the public Cloud Index.

SEOs who are used to Google’s somewhat straightforward and open standards for indexing may have a hard time understanding the 3 different ways that app content can be added to Apple’s Search indexes and how those methods interact.

We created the chart below to help — it outlines the basic functions and limitations for each Apple Search indexing method, described in the previous section, so that the comparison becomes clearer:

iOS-9-Apple-Search-Indexing-Methods-800x553 How-Apple-Search-Works

NSUserActivity is the only indexing method that has the capability to privately and publicly index content. Engagement statistics from the NSUserActivity session analytics are part of the ranking algorithm, so Apple recommends focusing on the NSUserActivity indexing method first.

Developers can indicate whether a NSUserActivity should be privately or publicly indexed. However, Apple doesn’t automatically publicly index NSUserActivities that are marked for public indexing. Apple still indexes the NSUserActivity to the private Device Index first, and later “promotes” it to the public Cloud Index once a certain number of people have accessed it.

One of the most unique aspects of this new framework is when and how specific NSUserActivities can be promoted to the Cloud Index. Apple’s representative didn’t get into the details, so this aspect of the framework may be a bit unclear until launch. Luckily, he did share a diagram that seemed to indicate that each screen within an app can have a variety of NSUserActivities, some privately indexable and some publically indexable. The developer must associate each indexable NSUserActivity with eligibility code: “var eligibleForSearch” (private indexing) and “var eligibleForSearch” + “var eligibleForPublicIndexing” (public indexing).

In most cases, something like a user dashboard screen will have a publicly indexable default NSUserActivity — an ideal public search result for anyone who has never accessed this screen before. User-specific NSUserActivities that represent the non-default status of the screen should only be privately indexable because they are only appropriate for the specific user that triggered them.

Since both default and customized NSUserActivities are associated with the same app screen, anyone who accesses the screen (public and private) generates engagement data to benefit the publicly indexable, default version of the screen. As a result, the default public version of the screen is a stronger candidate for promotion to the public Cloud Index. Furthermore, because engagement metrics are a positive ranking factor, the default public version of the screen will also likely rank better in all searches, regardless of the user’s historical interactions with the app.


How Can The Different Apple App Indexing Protocols Be Used Together To Benefit SEO?

Developers can use the NSUserActivity indexing method alone, but following the Web Markup indexing method in addition to the NSUserActivity indexing method has some significant advantages (that Apple can’t infer from NSUserActivity alone):

  1. When Web Markup is in place, deep linked app screens are automatically added to the public Cloud Index. (No waiting for a certain number of users to discover your content before you can cross the Apple NSUserActivity promotion “threshold.”)
  2. When Applebot finds appropriate Web Markup on your site, the web pages can also be added to Apple’s index. A web page may rank in Spotlight Search, instead of the app, if the app is not installed. (Note: This means the Web Markup indexing method gives you two chances to rank: app and web. This is a huge competitive advantage because Apple only indexes web pages that have been submitted to iTunes connect or web pages that contain this app deep link markup. Applebot isn’t a roaming crawler like Googlebot.)
  3. “Website Popularity” helps increase your app’s “Relevance Score” in Apple Search, which is a central aspect of the Apple search algorithm.
  4. Structured data from the website is an independent ranking factor in the Apple Search algorithm.
  5. Action Schema from your website can be pulled in to give your app’s search result additional visual elements (#pizzaz) that make it more appealing to users and drive click-through from the search result, another Apple Search ranking factor.
  6. BONUS POINTS: This gets you halfway to getting your deep links indexed in Google Search as well (this will be discussed at length in the next article in this series).
Source: https://developer.apple.com/videos/wwdc/2015/?id=709

Source: https://developer.apple.com/videos/wwdc/2015/?id=709

Deep links and user activities — whether private or public — only show up as results when the app is installed on the user’s device (or has been in the past). When the app is not installed on a user’s device, Apple will show either an App Store result or indexed web content (discovered by Applebot crawling a site’s Web Markup).

When a user gets the website result, Apple is counting on web developers to have implemented Smart App Banners to refer users from the website to the app download page in the App Store. Apple’s Smart App Banners are great for driving downloads from web traffic that approaches the website from a traditional web referral; but if Apple Search’s ultimate goal is to navigate people away from websites and into an app-only digital space, this strategy misses the boat.

NOTE: This is a notably less direct experience when contrasted with Google. A user without the app installed who taps a Google deep link from a Google search result is immediately delivered to the app download page in Google Play or the iOS App Store.

Apple has previously tested sending these clicks directly to the App Store, but received pushback from users who wanted a website option. While the new solution satisfies those users, it may fail to convert as many searches into app downloads. It’s especially tenuous if users don’t feel compelled to tap on the Smart App Banner or (more likely) if web developers have not enabled the Smart App Banner on their website at all.

Concluding Remarks

SEO practitioners must evolve to keep up with the expanding definition of what constitutes “SEO.” With the new iOS 9 app indexing announcement, SEOs also must evolve to work with Apple’s new understanding of search engineering.

Apple now offers deep app indexing that is significantly different from the app indexing opportunities provided by Google. This is largely due to its public and private indexing frameworks and the methods that marketers can use to get their deep app content indexed.

Apple’s ability to mine iOS user engagement metrics allows them to make engagement a central part of the ranking algorithm, putting less emphasis on traditional ranking factors like titles and descriptions. This is a notable evolution from how Apple currently handles search in the iOS App Store, which relies heavily on titles and keywords to determine app ranking.

The growing opportunity to target more keywords with deep app content should create incentive for app developers to focus slightly more on marketing at earlier stages in app development and force a more strategic and ongoing partnership between SEOs and app developers.

In all the discussion of the new Apple Search and app indexing, the big question that some say has not been adequately addressed is about search volume and tracking. It is unclear how much total search volume and engagement the new Apple Search utilities will get, especially when compared to Google search (and Google’s new ability to surface iOS app deep links in their search results).

Will users be drawn to app deep links over traditional web content, or will they even know the difference? Will users begin to prefer a Spotlight Search to find new apps and app content? Will they still prefer App Store searches, or will the lines between Apple search utilities continue to blur, leading to a single, app-centric Spotlight-Safari-Siri dashboard interface that can fast track app total domination over the web?

For some companies whose apps lack website parity and others whose apps have extensive private or personalized content, Apple Search currently represents the only opportunity to get their app content indexed, but the overall impact of Apple Search remains to seen.

While Apple Search presents many opportunities for new exposure on Apple devices, developers will have to work within Apple’s new app indexing framework, and optimize for a variety of indexes, using new proprietary Apple methods. Success will be limited by the volume of search that Apple Search outlets can carve out from their loyal audience, and the impact of search optimization initiatives will be much more challenging to measure.

Since Apple’s push for privacy is something Google won’t match (at least, not yet, and not without completely changing the company’s data-collection practices), we expect Apple to make more key investments in privacy-focused features. Remember, Apple’s business model is based on turning a profit on their own products, not based on helping marketers turn a profit on theirs. If Apple believes users will pay more for privacy (or the illusion of privacy), they will have no problem restricting data from marketers.

Conversely, if Apple believes they can turn more of a profit by selling access to Apple Search data, we may see new products targeted at marketers in the future — for a price. (Remember how expensive those iAds were?) Apple has historically been late to provide even basic analytics to marketers, so Apple Search could provide little to no access over many of the metrics we already enjoy in Google Analytics.

While we appreciate Apple’s video explanation of what they’re doing with Apple Search and the amount of time they are giving SEOs and developers to prepare for these changes, many questions about the technology remain unanswered. We are left wondering: Does Apple plan to use some version of QDF to determine NSUserActivity promotion into the public Cloud Index?

In other words, will a sudden increase of people engaging with a publicly indexable NSUserActivity (like a Bruins game in the NHL app) cause the activity to get promoted to the public Cloud Index before activities with more total views but less recent traffic (such as a Bruins team roster screen)? Will the fresher activity rank higher because of its timeliness? Conversely, when people stop engaging with fresh user activities, will they get “demoted” back down to the private Device Index (or, say, replaced with a more recent Bruins game)?

What questions do you have? Let us know in the comments.

The post App Indexing & The New Frontier of SEO: Apple Search + iOS App Indexing appeared first on Search Engine Land.

/app-indexing-new-frontier-seo-apple-search-ios-app-indexing-223880/feed 0