What to watch for in 2018: Mobile SEO predictions

As we wrap up 2017 and look forward to 2018, many SEOs will speculate about what to expect in the year to come. Since my focus is mobile, I wanted to share my unique expectations for 2018 by outlining what we know and what we suspect on the mobile SEO front.

This past year brought a lot of changes to the mobile ecosystem, though we are still waiting expectantly for the launch of Google’s mobile-first index. We have been assured that it will launch sometime in 2018, and we hope this is true.

For this article, I plan to focus on a few of my key predictions for 2018: the blurring of the lines between app and web, cross-device convergence and the increased reliance on schema markup in HTML, JSON and databases. I will then tie all the trends together with unique speculation about what mobile-first indexing will actually be and what strategies you can start incorporating now to create an immediate SEO benefit.

This background information about mobile trends and the long-term expectations about mobile-first indexing should help you prioritize and plan for a more successful 2018.

Blurring of the app/web lines

The biggest trend in 2017 that will continue to grow in 2018 is a movement toward Progressive Web Apps, or PWAs. You can expect them to be an even bigger focus in 2018.

Just as a refresher, Progressive Web Apps are websites that enable an app shell and configuration file to be downloaded to a phone, which allows it to take on all the best characteristics of a native app while living on the web. Remember, “web apps” are basically just JavaScript-heavy websites that look like native apps, so making them function as a PWA just entails adding a couple of extra files and a little more functionality.

The great thing about PWAs is that they allow for an app icon, full-screen display without an address bar, speedy on- and offline functionality and push notifications. They are a good way to help companies build a bridge between the discoverability of the web and the engagement and satisfaction that users experience with apps, all while minimizing overhead. They can be used directly on the web or installed like a native app on Android devices (and iOS devices soon, too). That means there is a lot less to maintain, optimize and promote, so they are incredibly attractive to savvy companies of all sizes.

The app development trends will start to shift away from native apps and toward PWAs as more companies begin to understand the value that PWAs can provide. The Android OS now treats PWAs almost exactly like native apps, showing their resource consumption and specs in the exact same places, displaying them in the app tray, and soon, adding them to the Google Play Store. Google has also begun to transition many of their specific-interest web resources into PWAs, including Traffic, Sports, Restaurants, Weather, Google Contribute, Maps-Go and Weather PWA.

You can see this trend in action below. The first screen shows a web search result for the local weather. The next screen shows the same search result with a different presentation and the option to add it to the home screen. The third screen shows the dialogue where you accept addition of the PWA icon to your home screen. The final image shows Google’s native weather app and its weather PWA app icons side by side. The two apps do the exact same thing and have the exact same interface.

[Click to enlarge.]

PWAs are also important because they remove the need for companies to set up deep links from their websites into their apps and vice versa — a process that has proven complicated and sometimes impossible for large companies that don’t have exact parity between their app and website content. Google always prefers to recommend and reward the least error-prone options, and in our experience, deep linking the old fashioned way is very error-prone. Every time something changes in the app or content moves on the website (individual 301 redirects or a full migration), app indexing and deep linking is at risk of failing or completely breaking down.

And even when your deep links are working correctly, referral touch points and attribution can be nearly impossible to track without the assistance of third-party services. This is a stark contrast to the simplicity of linking on the web. PWAs are self-contained apps that are already indexed on the web, eliminating all that complexity.

If everything that happens in your company’s app can be achieved in a PWA, it makes sense to focus efforts on the PWA — especially if the company is struggling with deep linking. As long as your PWA is well indexed and delivering a great user experience, Android deep links will be irrelevant.

Since PWAs will be in Google Play with native apps, Android users likely won’t be able to tell the difference between a native app and a PWA. On Android, it is important to note that Google may eventually change how they treat deep links when a PWA is available. Google may begin to prefer PWA content over deep links (especially if the app is not installed), just as they have done for AMP content.

This is less of a concern for iOS, especially if deep linking is happening through iOS Universal links rather than any Firebase implementation. Since Universal Links are executed with the iOS operating system rather than the browser, it seems likely that iOS will continue to honor Universal Links into apps, even if a PWA is available.

Just remember that, in both cases, if the PWA is replacing the website, the app deep links will need to match up with the URLs used in the PWA. If the PWA is in addition to the main website, only the web URLs that are associated with app URIs will trigger the deep links.

As Google begins adding PWAs to Google Play and indexing them on the web, this could make it easier for it to add app logos to SERPs for both Android and iOS, improving the appearance, CTR and engagement of the PWA links. Regardless, there may still be a push for all app deep links to be moved into its Firebase system, to help Google improve its cross-device, cross-OS reporting and attribution. Depending on how quickly Google is able to finish launching mobile-first indexing, this is something that may be a big push for the company in the second half of 2018.

We are seeing similar changes on the app store optimization (ASO) front as well. The Google Play algorithm is historically much less sophisticated than the Google search algorithm, but recent changes to the Google Play app algorithm show a much larger focus on app performance, efficiency, engagement and reviews, and a relative decrease in the importance of app metadata. This could be considered a signal of a potential impending merge between Google Play and regular SERPs, since we know performance is an important ranking factor there. When PWAs are added to the Google Play Store, native Android apps will be competing against PWA websites in terms of performance. Conversely, this will likely mean that PWAs may also be subject to ranking fluctuations based on user reviews and star ratings.

Though it is less prominent for SEO, the same may be true in the Apple world of technology. Historically, Apple was resistant to allowing their Safari browser to support PWAs, but recent announcements make it seem as though the company’s perspective has flipped. In 2017, Apple finally made it clear that Safari would soon support the Service Worker files that make PWAs so useful, and just this month (Dec. 12, 2017), in its quest to eliminate the use of app templating services, Apple seemingly endorsed PWAs as a better option for companies with limited budgets than templated native apps!

Apple’s sudden and emphatic endorsement of PWAs is a strong indication that PWAs will be supported in the next Safari update. It may also indicate that Apple has developed a scheme to monetize PWAs. Apple could also plan on adding them to its App Store (where they can exercise more editorial control over them). This is all yet to be seen, of course, but it will be interesting.

Cross-device convergence

The next major theme to expect in 2018 is cross-device convergence. As the number and purpose of connected devices continues to expand, mindsets will also need to expand to take on a wider view of what it means to be “cross-device.” Historically, cross-device might have meant having apps and a website, or having a responsive design website that worked on all devices. But in 2018, people will start to realize that this is not enough. As the line between app and web merges on mobile, it will also merge on desktop and the Internet of Things (IoT).

As more information moves to the cloud, it will be easier to seamlessly move from one device to another, maintaining the state, history and status of the interaction on all devices simultaneously. The presentation layer will simply include hooks into a larger API. Developers will be more focused on testing data integrations of one app across many different devices, rather than testing multiple, device-specific apps on multiple devices (somewhat similar to the transition to responsive design on the web).

There is a store for Google Home and a store for Google Actions, Google’s Voice-First and Voice-Only channels, but these will probably merge into the same store — possibly when the mobile-first index fully launches, but more likely soon after. You can expect an eventual convergence of mobile and desktop app stores, operating systems and search utilities, though this won’t all be completed or even initiated in 2018. It is just the direction things are going.

We have already seen this happening in some places. The convergence between mobile and desktop is most obvious when you look at the changes that happened in Windows 10. The desktop OS incorporates an app store and looks much more like an Android phone, even including customizable widgets in the “Start” screens. Microsoft announced just this month that Service Workers, push notifications and local cache will all also be enabled by default in Microsoft’s new Edge browser, which is intended for both desktop and mobile.

PWAs and Android apps are already available in the Windows app store, which means that PWAs are already available and partially usable on desktop. In that same vein, Microsoft has now made a point of making some of the top software, like Outlook, Excel and Word, available on Android devices, without a license.

There are also indications that Google may begin to test sponsored App Pack rankings. Since App Pack rankings happen in the regular SERP rather than an app store, this could be important for desktop, too. As companies begin to realize how useful PWAs are, they will have a visual advantage over other sponsored results on both mobile and desktop.

Google and Microsoft/Windows have always been more willing to coexist without walled gardens, while Apple has always leaned toward proprietary products and access. If Safari mobile will support PWAs and Service Workers, then it may also be true for the desktop version of Safari, meaning that the line between mobile and desktop will be merging in the larger Apple universe, too. The MacOS has had its own app store for a long time, but the Apple teams, like the Android and Windows teams, have also reported that they will be merging the MacOS and iOS stores into one in 2018.

This cross-device, voice- and cloud-oriented model is already being pursued with Cortana’s integration in Windows 10, where the mobile and desktop app stores have already merged. Similarly, Siri, Safari and Spotlight work cross-device to surface apps and websites, and Google has added voice search to desktop — but they have both yet to really push the assistant to the front and center as a means of surfacing that app and web content on all devices.

There were rumors that iOS apps would also be available in the Windows app store, but that looks like it has fallen through, at least in terms of 2018 planning. Instead, Apple may have decided to extend or merge its own iOS App Store with the desktop version of the store and could also have decided to include PWAs for the desktop experience.

The last thing to watch out for in this trend is changes with Accelerated Mobile Pages (AMP). AMP was designed to make webpages fast and mobile-friendly, and even though these enhanced pages can work on desktop and probably could integrate easily with voice, Google has reportedly struggled to integrate them into the mobile-first index. While it does provide a lot of advantages, AMP will probably have to make major changes or face a reckoning in 2018. There are still significant problems that need to be resolved in terms of UX and measurement.

Increased reliance on structured data markup in more places

The final thing to watch for in 2018 is Google’s push for webmasters to mark up everything with structured data, including social profiles, corporate contact information, books, events, courses and facts. Structured data, and specifically markup that is formatted in JSON-LD to provide semantic understanding, is what allows Google to understand “entities.” (The “LD” in JSON-LD stands for Linked Data.)

We know that structured data will be a big deal because it helps Google figure out what is going on without having to rely so heavily on crawling and parsing all the content on the web — which has become quite a monumental job with no end in sight. This is why Google has switched to requesting most data-rich assets in the JSON-LD format, including Google Action markup, Web-app manifests, and the files saved by Service Workers.

Last year, before Google I/O, Google made a big point of creating a structured data testing tool that gave specific implementation instructions for a variety of different kinds of markup. The kinds of schema included there, not surprisingly, are specifically good for interactions with Google Home, Google Assistant and Chromecast — things like restaurants, reservations, travel plans, music, TV, movies and recipes.

Content that is well marked up with structured data can be easily parsed and presented on non-traditional devices through voice search and interaction (like with Google Assistant, Google Home, Android Auto). This is also a big deal for non-Google products like Amazon Alexa, Siri, Fitbit (which launched its own OS-specific partner apps) and voice-enabled TV remotes.

The one thing in Google’s structured data documentation that has not gotten due attention is the database or data set markup (i.e., instructions for how to add structured data markup to your database). Databases don’t necessarily have URLs or need websites, and this is core to the theory that the mobile-first index will not require URLs for indexing and that it will rely on schemas and entity understanding.

Let’s look at an example of how markup is creating “entity” understanding. Below, you can see a search result for a specific boot. Rather than showing all the web locations where you might find that boot, Google has aggregated it into a utility that can give users a lot more information directly from the SERP.

The result shows the full name of the boot, as well as what stores have it in stock and at what prices. It also shows the star ratings for the boot and lets me toggle to different sizes and colors. If I click the tabs, I can see more details about the boot and read reviews that have been aggregated from all the places that sell it. Since this information is an aggregation of information from all over the web, it actually does not have a static URL, so Google includes a triangle “share” link so that the aggregation itself can be shared.

This sharing functionality is something that you can expect to see much more of in mobile-first indexing. It is an indication that Google views a topic as an entity and thus has stored, aggregated or assimilated information on the topic as a whole (the entity). Dynamic links are links that Google generates on the fly, for content that it understands, but that does not naturally have a URL.

It is important to remember that Google’s very first (unsuccessful) attempt to encourage app deep-linking used Dynamic Links, as part of Google Now On-Tap. Then, they were used as a unified link that united the same piece of content on the web, in an iOS app and in an Android app. They allowed one link to trigger the right experience on any device, and if the appropriate app was not installed, the link would fall back to the web version of the content. Now, Dynamic Links are still included as an important part of Google’s app indexing platform, Firebase.

In the next example below, you can see how the linked data helps support entity understanding in a search result. The query is for a popular author, so the result shows pictures and a brief biography at the very top. There are only minor differences between the Google Now result and the Google Web result — one has a dynamic share link, and the other offers the ability to “follow” the entity or concept.

In both, the result aggregates information such as quotes and movies attributed to the author, lists influences and links to a Wikipedia page. Below that, Google displays a carousel of his most popular books, with pictures of the cover and the date they came out. Below that, it shows a “People Also Searched For” carousel, which is full of authors who write in the same genre.

We believe Google is using clicks on these bottom two carousels to verify and vet the linked data that it has assimilated about this author. The more clicks a carousel item gets, the more likely it is linked to the topic of the query.

A new way to think of mobile-first indexing

Knowing these trends should help you understand how mobile-first indexing fits into the larger SEO picture. Inclusion of the word “indexing” in Google’s official title for the update is telling. It indicates that this is not just an algorithm update, but an update to the fundamental architecture and organization of the system. Remember, an “index” is just a repository of ordered information that is easy to query or search. Indexes can be created for all different kinds of information and ordered in a variety of ways: alphabetically, numerically, or in Google’s case, historically based on URLs.

Since native apps and progressive web apps don’t require different URLs to show different content, we believe the method of indexing and organizing content has to change. Forcing URLs into those new technologies has proved untenable, so Google needs a new index — and it will be one that prefers “portable” content that lives in the cloud and is well marked up with structured data. It will probably be an “entity index” based on unique “entity concepts” that include domains (with URLs), native app entities and their content, PWA entities and database entities that need no design elements at all.

Use of the phrase “mobile-first” in the name is also interesting. With both the mobile-friendly update and mobile-first indexing, Google repurposes phrases that were previously used to describe design elements — but in both, Google mainly focused on the technological back end that made the design changes possible. For the mobile-friendly update, Google did provide guidelines on how content should look on the page, but based on their testing tool, their main focus was really on the crawlability of dependent files on the site (specifically, the CSS and JavaScript).

The mobile-friendly update was an important precursor to mobile-first indexing because it gave Google what it needed to feed and train its machine learning programs about how they should ingest and interpret JavaScript. As SEOs, we all endured the mobile-friendly update, which preferred sites that qualified as such and awarded them with a mobile-friendly icon when they appeared in search results.

Similarly, the phrase “mobile-first” was originally used to describe a design principle in which responsive design website frameworks were established with the most essential elements of functionality first, and these were meant for mobile devices with the smallest screens. Only later were designers able to add in other, less necessary elements of the design and UX for larger-screened devices that had more room.

It now appears that Google has also co-opted the term “mobile-first” to mean something slightly different, with implications that are much larger than just design. Rather than focusing on mobile devices and screen sizes, Google will put the focus on content accessibility and the cloud and focus much less on the presentation.

This is an important trend because “the cloud” is where Google has been focusing most of their time and innovative energy. Content that is hosted in the cloud, without being formatted specifically for any one device, is exactly what they are after; it is the easiest for them to process with AI and the easiest for them to redisplay on any screen (or read out loud, in voice-only contexts). That is where Google Now and Google Assistant come in.

Google Now was Google’s first attempt at a predictive search engine that anticipated queries before a user even submitted them. It used all the information it knew or could detect about your habits to anticipate information you would want and displayed it in an interface to the left of the home screen on Android phones. It was also available as the Google App on iOS, but it was never as good since they weren’t able to aggregate as many personal habits and preferences from iOS users. Google Now included a voice search capability, but it just translated voice queries into text.

There are minimal differences in most search rankings when you compare regular search in Google.com and a search in Google Now. The primary differences happen when there is a PWA available (like the Weather PWA). There are also some minor variations in the “share” and “follow” functionality, which probably also hint at what to expect in mobile-first indexing. You can see the differences below.

Google Assistant is a bit more sophisticated in that it can sometimes answer simple questions directly rather than just returning a search result. It also uses passive and active signals about a user to ensure that it is giving the most accurate and useful information possible. Google Assistant is the critical element of a Google Home device, which operates primarily with voice but can cast results to connected TVs or phones if visual review is required.

Google Now and Google Assistant are obvious precursors for mobile-first indexing and give us a great deal of insight into what to expect. The two utilities are very similar and may simply be combined for mobile-first indexing. One of the strongest endorsements of this idea is that Google has recently gotten much more aggressive at pushing Android users into the Google Now/Google Assistant world. They moved the query bar from the Google Now interface (one swipe left of the main phone screen) to the standard layout (accessible on all versions of the home screen).

The new search bar just says “Google,” so most users won’t realize that they are accessing a different experience there than in the web-oriented version of Google (google.com).

Google’s most recent blog post about the mobile-first index didn’t really add anything new to the equation, so our best guess is still that the new index will probably also lean heavily on Google’s existing semantic understanding of the web (which is based on Knowledge Graph and its historical incorporation and build-up of Freebase). It will also use cards and AI, like we are used to seeing in Google Now. This concept is backed up by Google’s retirement of the term “rich snippets” and the launch of the new Rich Results Testing Tool on December 19.

The image below shows the different methods Google is using to inform the Google Assistant about an individual user’s preferences, which will help further personalize individual search results. But this data could also be aggregated — in a “Big Data” way — to determine larger patterns, needs and search trends so that it can adapt more quickly.

On the left, you can see a Google Cloud Search, which draws together information about assets on all of my devices that are logged into a Google Account. This includes emails, calendar entries, Drive documents, photos, SMS and apps. Though this has not been the focus of any Google marketing, it is part of Google’s Business GSuite package, which is turned on by default for all GSuite users.

On the right, you can see the Google My Activity tracker. This is another feature that is turned on by default. It is similar to the Cloud Search function, but instead of just being a searchable database, it organizes the information in chronological order. It breaks out my daily activity on a timeline and a map. The data includes the amount of time I spent walking and driving. It also shows the businesses that I visited and the times I was there. It also places pictures that I took on the timeline and associates them with the locations where the pictures were taken.

Elements like this are meant to help Google Assistant have a greater understanding of personal context so that it can respond when surfacing search results, either to an explicit search or to an anticipated want or need (e.g., Google Now).

In the long run, Google Assistant may be the new entry to Google search on all devices, forcing people to log in so that their state and history can be maintained across different devices, and so that a personal history and index can be developed and built out for each user. The beginning of this personal history index is already in Google Now for Android users. It uses active and passive machine learning to track and compile all of a user’s cross-device activity in Google Cloud, then translates that information into predicted needs in Google Now.

Google has already begun promoting a “one-click register and form “complete” and “one-click sign-in” that works and transfers credentials across different devices. This functionality is all currently made possible by Google’s Credential Management API, which means that it relies on a cloud-hosted shared “state” managed by coordination of local Service Workers that pass state changes to the cloud-hosted Google Account. If and when this takes off, it will be a huge boon to engagement and e-commerce conversion because it eliminates the main friction.

Conclusion

From a search prospective, data that lives in one state, regardless of the device, is great — but assimilating all the different types of potential search results into an index is hard. The new mobile-first index will mix together websites with apps, PWAs and other data sets that don’t all have URLs, so this is where structured data markup will come in.

Just as advertising systems profile individual users with device fingerprints, Google will have to organize the new index with similar unique identifiers, which will include web URLs and app URIs. But, for content that does not have an existing unique identifier, like a page deep within a PWA experience or an asset in a database, Google will allow “Dynamic Links” to stand in as their unique identifier so that they can be indexed.

Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

Google shuts down Fetch As Google for mobile apps

Google has quietly announced on Google+ that it will be killing off some of the App Indexing features within the Google Search Console. Specifically, Google is turning off the Fetch As Google for Apps feature to “avoid unnecessary duplication” with what is available within the Firebase help documentation.

Google added Fetch As Google for mobile apps back on May 22, 2015, only a little over two years ago, and is now removing the feature. A year after Google launched the tool in Google Search Console for mobile apps, Google renamed Google App Indexing to Firebase App Indexing.

Soon enough, I suspect all the features available for those deploying app indexing and using Google Search Console tools will be removed. Google has been focusing more of their attention on AMP, PWAs, responsive and other technologies over mobile apps within search and Google Search Console.

Here is Google’s statement today:

In May 2016, we announced Firebase App Indexing, together with neat testing tools for apps. To avoid unnecessary duplication, we’ll be turning off the old “Fetch As Google for Apps” feature in Search Console.

Making your apps’ content indexable has gotten much easier over the years. If you’re making smartphone apps now, please check out Firebase App Indexing at https://firebase.google.com/docs/app-indexing/ for more information.

Simple tips to get your app indexed, ranked & installed

Do you have an app that you’d like to rank in mobile search engine results? If so, you’re going to need to make room in your SEO strategy for app optimization.

For apps, there are distinct ranking factors. Although they are similar to ranking factors for a standard web page, there are differences that you need to know about.

Here’s how you can optimize your app to get the best possible rank.

Yes, you need to optimize

According to a recent Google report, 27 percent of users find apps through a search engine. That’s up from 2 percent to 3 percent in 2014.

That trend will likely continue. Why? Because Google is emphasizing app downloads from search results while brushing aside Google Play as a search engine. Google has also become better at ranking apps, a trend we can expect to continue.

Even though 40 percent of people still find apps by searching in an app store as of now, it’s still a great idea to plan for the future and optimize your app so people can find it with a search engine.

Get in the app pack

Although the word “app” can include web-based applications offered as a service, most people think of apps as mobile applications that people download and install. Google understands that.

As a result, Google now includes an “app pack” at the top of the mobile search results. You can see it if you open up the browser on your mobile device and search for something like “photo editor.”

The app pack will include between one and six apps. If more than six apps match the search query, Google will display an arrow at the bottom of the pack so that users can view the rest of the results.

Google also offers a decent amount of info about each app in the pack. In addition to displaying the app image and title, the app pack also shows the app rating and price. Users who click on the app square are taken to the store where they can download and install the app.

Another nice feature: apps displayed in the app pack are specific to the underlying platform. In other words, Android users will never see an app that’s only available on iOS, even if that app matches the search term.

There’s a downside, though

At this point, you might think it would be great if your app showed up in the app pack. While there’s an obvious benefit to appearing at the top of the mobile search results, there’s also a downside.

The bad news is that for every app that appears in the app pack, one web ranking is pushed off the page.

For example, if your website is ranking at the very top of the organic mobile results for a keyword (or your brand name) and you optimize your app to appear in the app pack for the same keyword, this could push your organic listing down the page — possibly below the fold. That could have an impact on your search marketing efforts, especially if there was no app pack appearing for that search query before your app optimization efforts.

So, if you effectively optimize your app, there are instances where you could find yourself robbing Peter to pay Paul. However, if there’s already an app pack appearing for your target queries, it’s worth pursuing visibility within this space since this is already impacting organic positioning.

Use the right keywords

The first thing to do to optimize your app for search engines is to take a page out of the SEO 101 playbook: gather the right keywords.

In my experience with keyword research, I’ve seen people who search for an app usually do so with a noun. They might search for something like “photo editor” or “travel planner.”

So start your optimization efforts by thinking more about what your app is than what it does.

“Edits photos” is what your app does. People won’t search for that.

“Photo editor” is what your app is. People will search for that.

Optimize the title and description

You can think of the title of your app much like the title tag of a web page. It’s very important for SEO purposes.

Also, Google evaluates app descriptions as text on a web page.

That’s why you should optimize the app title and description just as you would optimize a web page title and its content. Use the keywords that you gathered from the first step and sprinkle them appropriately throughout the description. Put the most important keyword in the title.

Keep in mind, though, that you’ll also want a branded title. For example, “SnapHelper — A Photo Editor” includes both the name of the app and an explanation of what it is.

Of course, you’ll face limitations on how many characters you can include in the app title (50 characters for app store, 30 for Google Play). In that case, you’ll have to get creative about what you’ll include and how you’ll include it.

You need reviews

Here’s where app SEO parts company from more traditional SEO efforts: you need reviews.

For starters, your app might rank based on keywords included in reviews on the app page. It’s often the case that keywords toward the top of the page are given more weight than keywords farther down.

The star rating will also affect how your app ranks. You might notice that some apps with better ratings outrank other apps that have better keyword optimization. That’s because Google pays attention to ratings.

Undoubtedly, the star rating will also affect the click-through rate. That will likely impact its rank as well.

Use app-specific keywords

You’re ranking for an app. Why not use the word “app” in your title and/or description?

Keep in mind that people who search for an app in the app store probably won’t use “app” in their search query. However, people who search for an app with a search engine are much more likely to use it.

Optimize for the word “app,” and you’ll likely stay ahead of your competition.

Also, use the name of the operating system in the app title and description. People using search engines to find an app will likely include their platform in the search query.

Wrapping it up

Optimizing an app for the search engines is different from optimizing a web page. However, with the right know-how and a little bit of effort, you can boost your app to the top of the search results.

Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

Google: AMP will override app deep links for the foreseeable future

At SMX East yesterday, Adam Greenberg, head of Global Product Partnerships at Google, gave a talk about AMP. He said during the question and answer time that AMP pages will override app deep links for the “foreseeable future.”

Last week, we covered how when Google began rolling out AMP to the core mobile results, Google quietly added to their changelog that AMP pages will trump app deep links. In short, that means when a user installs an app of a publisher, does a search on the mobile phone where the app resides and clicks on a link within the Google mobile results that could lead to the app opening up, instead, Google will show the AMP page — not the content within the app the user installed.

Google has made several large pushes with App Indexing through the years. These were incentives to get developers to add deep links and App Indexing to their apps — such as installing apps from the mobile results, app indexing support for iOS apps, a ranking boost for deploying app indexing, Google Search Console reporting and so much more.

But now, if your website has both deployed app indexing and AMP, your app indexing won’t be doing much for you to drive more visits to your native iOS or Android app.

Google told us they “have found that AMP helps us deliver” on a better user experience “because it is consistently fast and reliable.” Google added, “AMP uses 10x less data than a non-AMP page.” Google told us that “people really like AMP” and are “more likely to click on a result when it’s presented in AMP format versus non-AMP.”

Google also told us that they “support both approaches,” but “with AMP — and the ability to deliver a result on Google Search in a median time of less than a second — we know we can provide that reliable and consistently fast experience.”

Personally, as a publisher who has deployed virtually everything Google has asked developers to deploy — from specialized Google Custom Search features to authorship, app indexing, AMP, mobile-friendly, HTTPS and more — I find this a bit discouraging, to say the least.

I think if a user has downloaded the app, keeps the app on their device and consumes content within the app, that user would prefer seeing the content within the publisher’s app versus on a lightweight AMP page. But Google clearly disagrees with my personal opinion on this matter.

Google will show AMP URLs before App deep link URLs in mobile results

Google will now have AMP trump App URLs in the Google mobile search results. That means if a website has both AMP URLs enabled and also has a mobile app with Firebase App Indexing (formerly Google App Indexing), Google will show the user, even if they downloaded your app, the AMP URL over the deep link to the page within your app.

Google quietly posted this in their data anomalies page, where they wrote:

Search results on mobile devices have begun to direct users to the equivalent AMP page, in preference to the equivalent app or web page. This might result in a decrease of traffic to your app pages when an equivalent AMP page exists.

Google’s John Mueller confirmed this for me on Twitter saying, “Yes, at the moment if an AMP exists for a given URL then we will send the user to that AMP not the deep link.”

Again, if your website visitor downloaded your app and you deployed Firebase App Indexing, yesterday, Google would have sent the user to your app. Now, since AMP is rolling out to the core Google mobile search results, that user will be taken to the AMP URL instead.

SMX Advanced recap: Advanced Google App Deep Linking

Smartphone usage of apps continues to soar. Recent data from comScore show that 44 percent of all digital media time is spent using smartphone apps. That makes the world of apps a critical one for marketers to understand and embrace.

At the most recent SMX Advanced, both Tam Phan, Organic Growth Specialist on the App Store Analytics team at TUNE, and David Iwanow, the former SEO Product Manager at Marktplaats (ebay classifieds group) and current operator of Travel Network, spoke about app indexing. (As Iwanow noted, what was once called Google App Indexing is now called Firebase App Indexing. The purpose in renaming it was to let it become more of an industry standard.)

During the session, Tam Phan started with a basic overview of deep linking in apps and also shared some data based on the experiences of mobile marketing platform provider Tune. David Iwanow followed with a detailed look at how to implement app indexing, providing a case study of his own.

In today’s post, I’m going to review what they had to say, as they had a great deal of insightful case study data and information on how to properly implement app indexing.

Basic overview

The first question to answer is, “What are the benefits of app indexing?

Per Iwanow, according to Google, the average app user has just 36 apps installed on their phone, and only 26 percent of those apps are used daily. When you combine this with the fact that one in four smartphone apps installed are never used at all, it’s not a stretch to assume that user exposure to your app is probably fairly limited.

App indexing offers two major benefits in helping your app become more successful. The first of these is that if a user has your app installed, Google can surface “pages” from your app in search results. When the user clicks on these listings, the app is launched and the corresponding content is loaded. This is powerful because it gets users back into your app.

The second major benefit is that, in certain selected scenarios, app indexing can lead to Google surfacing an install button in the search results. This happens when users enter what Google calls “app seeking queries.” You can see an example of that here:

David Iwanow also makes a strong point about the user experience. Users don’t always know the capabilities of the apps they already have installed. This can lead to their visiting the Google Play store, where they often have trouble discerning which app will address their need. App indexing can cut several steps out of this process, particularly if the user already has an appropriate app installed on his or her phone, as that app will get surfaced in the search results.

The majority of apps don’t implement deep linking. In addition, per data shared by Tam Phan, it appears that deep linking is more prevalent on Android apps:

From “App Indexing TOP 100 DOMAIN ANALYSIS” by Searchmetrics

Summary of pluses and minuses from Tune’s customer base

Here is a summary of the negative feedback:

    Still too early to see any benefits.Hard to understand how universal links and app indexing work together.Saw lots of errors when the API launched.Google Search Console reported data isn’t accurate (tried to replicate ranking data, but couldn’t).Can’t capture meaningful analytics, and proper attribution to app indexing not possible.

Here is a summary of the positive feedback:

    Saw an increase in daily app traffic of 7.3 percent.Increased rankings in search (This observation was confirmed by David Iwanow as well).Universal links provide a great experience.

Tam Phan also shared data showing the relative levels at which different verticals implement deep links:

The categories that implement deep links the most are food and drink, lifestyle, shopping, then travel and music. This may be because these categories get such a high volume of searches, leading to a more clearly perceived benefit.

Implementing deep links

According to Iwanow, the process for users is quite simple. Once they download an app, it will take about 48 hours for them to see the deep links show up for that app.

One of the key benefits for brands is that app indexing can help capture branded search traffic; showing your app in the results in response to branded queries will push down affiliates and aggregators, so you’ll lose less of that traffic to those types of sites. It also provides a great branding benefit visually in the SERPs (search engine results pages).

Here’s a summary of the benefits for app creators, according to Iwanow:

    Branding (as just outlined above).Personalization (due to the showing of app deep links in the SERPs).Ranking improvement.

Implementing app indexing

One path to implement app indexing is to use meta tags. Your tag might look like this:

There are two advantages to this: You can implement them without requiring app updates, and it makes it easy to check pages you’re trying to index. On the downside, there is a two-week delay related to crawling and having them show up in the SERPs. In addition, competitors can see what pages you’re trying to index.

The second method you can use is the App Indexing API. This has several benefits, as follows:

    It’s linked to user actions within your app.Unlike the meta tags, competitors can’t easily see all the pages you’re trying to index.Your app can show up in Google autosuggest.Your app can be included in Now on Tap.

The major downside is that this requires your app developers to get involved to implement or modify it.

The third available method is to add deep links into your XML Sitemap. This puts all your URLs in one place for Google to crawl, but it also exposes all the URLs to your competitors. In addition, you may have to rebuild your sitemaps, and it does make your sitemap file that much bigger.

Google recommends that you implement at least two out of the three methods to get the best impact. Iwanow’s personal preference is to use meta tags and the App Indexing API together.

One of the issues with app indexing overall is that it will likely lead to 404 errors in your app, as you probably don’t have pages in your app for every single page on your desktop site.

Once you have an implementation complete, make sure to use the “Fetch as Google” functionality in Search Console to test your implementation. You can do this in one of two ways: either using the Google Play APK or uploading it.

You’ll be able to drill into each URL to see the details of what happened. Just be aware that pop-ups create crawling issues for Google, so you’ll want to avoid those.

In addition, you may want to have some pages in your app for which you don’t permit indexation. You can list those in a noindex.xml file and refer to that file in your app’s AndroidManifest.xml file.

You can also use crawl status reports to see how your implementation has fared, as they will show the number of pages found with errors. Tracking and addressing these failures is important for two reasons:

    The number of app indexed pages impacts overall app indexing performance.The number of pages with errors has a negative impact on performance.

One more case study

According to Iwanow, good app indexing results can lead to a lift of 1.01 to 1.52 positions in the search results, but great app indexing results can range from a jump of 2.51 to 3.88 positions. That’s a serious ranking gain that’s worthy of notice.

He also states that there is a myth out there that iOS users never click on deep links in the SERPs, but this isn’t true. The click-through rate is indeed a bit lower, but the average position where the results appear to be shown is lower as well.

As mentioned above, while there are some app install buttons that show in the SERPs on “app-seeking queries,” the install buttons show up most often for brand-related terms. Iwanow also provided us with a snapshot of how this impacted overall CTR (click-through rate) (data pulled from Search Console) for two brands:

The y-axis scale wasn’t on the original chart, but according to Iwanow, it runs from around 20 percent to 90 percent for the Brand CTR.

Summary

With the continuing growth of apps, and the high value of getting users into your app once it’s installed, Firebase App Indexing is important to your overall app’s success. As shown in the case study data outlined in this post, implementing this brings numerous benefits.

In addition, you’ll want to do a great job of helping users discover your app in the Apple App Store and the Google Play Store. You can find a great article on App Store Optimization here.

See David Iwanow and Tam Phan’s full SMX Advanced presentations below:

What You Need To Know About Firebase App-Indexing By David Iwanow from Search Marketing Expo – SMX

The Future of Search By Tam Phan from Search Marketing Expo – SMX

Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

Google App Indexing becomes Firebase App Indexing

It looks like Google may be changing the name of their app indexing protocol from Google App Indexing to Firebase App Indexing. Last night, I captured screen shots of Google changing the Google search developer page from saying “Google App Indexing” to “Firebase App Indexing.” But it seems Google changed it back this morning to just “App Indexing.”

Here is a screen shot from last night where it showed “Firebase App Indexing.”

In fact, the link to learn more about this was set to go to firebase.google.com/docs/app-indexing.

Yes, Firebase is a company Google acquired back in October 2014. It is a company that helps developers create mobile applications. So it is possible Google would renamed their mobile efforts Firebase and bring App Indexing into that.

Maybe this is something Google is going to announce today at Google I/O; we will be on the lookout for that.

Postscript: As expected, at Google I/O today, Google announced they have renamed Google App Indexing to Fireside App indexing. They also announced more features around this that we covered over here.

Google launches Trial Run Ads for apps in search results to let users play before installing

It was only a matter of time before Google brought app streaming to search ads. In the next few weeks, ads in Android search results will allow users to take games for a test drive before choosing whether to download them. The announcement was among several Google is unveiling on Monday during its Developer Day at Game Developer Conference in San Francisco.

AdWords Search Trial Run Ads will start appearing in Google search results within the next few weeks. The ads will have a “Try now” button, in addition to a download button. Users who opt to try the app will be able to play the game for up to 10 minutes before deciding whether to download it from the Google Play store.

Google began rolling out app streaming in organic search results more widely on Android devices earlier this year, with the “Try now” option to preview an app before downloading it. With so few apps ever used after being downloaded (Google says it’s just one in four), the teasers are aimed at increasing the odds that users will stay engaged after the install.

In December, Google began testing Trial Run Ads through AdMob. The test-drive period in those in-app ads is just 60 seconds, however, compared to the 10 minutes of trial time available to users in the new search trial ads. While initially aimed at game developers, Trial Run Ads will be available to a wide range of apps.

There were a couple of other announcements for developers using AdWords to promote their apps at the conference Monday:

Portrait Video Ads in mobile apps will launch in a few weeks. Google says that than 80 percent of video ad views in mobile apps on the Google Display Network are watched vertically — whether the video was created for landscape viewing or not. Early testing has shown significant improvement in both click-through and conversion rates, resulting in lower cost per install and more installs from Portrait Video Ads, the company says.

Developers will also soon be able to target ads to users who have spent more than 30 minutes playing games or played an app that’s integrated with Google Play Games within the past 30 days.

Searchmetrics study shows most apps are not utilizing Google App Indexing

Searchmetrics published a study on App Indexing showing that of the top 100 sites they monitor, very few actually deploy App Indexing in their apps.

The study showed that while 84 percent of the top 100 domains offer an Android app, and 88 percent of those web sites have an iOS app, only 30 percent of those Android apps deploy App Indexing and 19 percent of those iOS apps deploy App Indexing.

“Many companies have invested heavily in apps, yet on average 20 percent of the apps a person installs on their device are only ever opened once,” said Marcus Tober, CTO and founder of Searchmetrics. “App indexing is a fantastic opportunity to maximize the investment in your app — by helping to drive more traffic and interaction and potentially even conversions. On top of this, if your app supports app indexing, Google has indicated that it could potentially appear more prominently in searches.”

This is potentially a huge missed opportunity for these companies that already have apps.

Marcus Tober says App Indexing leads to more customer loyalty within the app, more app installs, a ranking boost for your app and potentially more conversions. Google also released case studies on the benefits of deploying App Indexing.

Here is a chart from the study showing the breakdown of these top web sites that have apps:

Here is the breakdown of those apps that have deployed App Indexing by iOS and Android platforms:

To download the full study, go here.

Postscript: A Google spokesperson sent us the following statement:

Getting app content indexed can be a great move for most apps and we encourage app owners to consider how implementing it could bring them additional benefits in discovery and re-engagement. The implementation method tracked in the study (adding rel=alternate elements in the <head> section of the corresponding webpage) is only applicable for custom schemes. App developers have a much easier way to implement app indexing by supporting HTTP links and adding the App indexing API.

App Indexing & The New Frontier Of SEO: App Packs & App Store Search

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 NameApp TitleApp CategoryKeyword FieldApp DescriptionDeveloper Account NameApp StoreYESYESYESPOSSIBLY (NEW?)YESGoogle PlayYESYESN/AYESYES

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.

Updates/Freshness

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.

Conclusion

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.

Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.