9 Things You Need to Know About Google's Mobile-Friendly Update

Rumors are flying about Google's upcoming mobile-friendly update, and bits of reliable information have come from several sources. My colleague Emily Grossman and I wanted to cut through the noise and bring online marketers a clearer picture of what's in store later this month. In this post, you'll find our answers to nine key questions about the update.

1. What changes is Google making to its algorithm on April 21st?

Answer: Recently, Google has been rolling out lots of changes to apps, Google Play, the presentation of mobile SERPS, and some of the more advanced development guidelines that impact mobile; we believe that many of these are in preparation for the 4/21 update. Google has been downplaying some of these changes, and we have no exclusive advanced knowledge about anything that Google will announce on 4/21, but based on what we have seen and heard recently, here is our best guess of what is coming in the future (on 4/21 or soon thereafter):

We believe Google will launch a new mobile crawler (probably with an Android user-agent) that can do a better job of crawling single-page web apps, Android apps, and maybe even Deep Links in iOS apps. The new Mobile-Friendly guidelines that launched last month focus on exposing JS and CSS because Android apps are built in Java, and single-page web apps rely heavily on JavaScript for their fluid, app-like experience.

Some example sites that use Responsive Design well in a single-page app architecture are:

• Hulu.com,
• Refinery29.com,
• Facebook's news feed,
• Techcrunch.com,
• The Google Play Store,
• Pinterest.com, and of course
• http://scrollsample.appspot.com/items from John Muller of Google.

Also, according to Rob Ousbey of Distilled, Google has been testing this kind of architecture on Blogspot.com (a Google property).

Google has also recently been pushing for more feeds from Trusted Partners, which are a key component of both mobile apps and single-page web apps since Phantom JS and Prerender IO (and similar technologies) together essentially generate crawlable feeds for indexing single-page web apps. We think this increased focus on JS, CSS, and feeds is also the reason why Google needs the additional mobile index that Gary Illyes mentioned in his "Meet the Search Engines" interview at SMX West a couple weeks ago, and why suddenly Google has been talking about apps as "first class citizens," as called out by Mariya Moeva in the title of her SMX West presentation.

A new mobile-only index to go with the new crawler also makes sense because Google wants to index and rank both app content and deep links to screens in apps, but it does not necessarily want to figure them into the desktop algorithm or slow it down with content that should never rank in a desktop search. We also think that the recent increased focus on deep links and the announcement from Google about Google Play's new automated and manual review process are related. This announcement indicates, almost definitively, that Google has built a crawler that is capable of crawling Android apps. We believe that this new crawler will also be able to index more than one content rendering (web page or app screen data-set) to one URL/URI and it will probably will focus more on feeds, schema and sitemaps for its own efficiency. Most of the native apps that would benefit from deep linking are driven by data feeds, and crawling the feeds instead of the apps would give Google the ability to understand the app content, especially for iOS apps, (which they are still not likely able to crawl), without having to crawl the app code. Then, it can crawl the deep-linked web content to validate the app content.

FYI: Garry Illyes mentioned that Google is retiring their old AJAX indexing instructions, but did not say how they would be replaced, except to specify in a Google+ post that Google would not click links to get more content. Instead, they would need an OnLoad event to trigger further crawling. These webmaster instructions for making AJAX crawlable were often relied on as a way to make single-page web apps crawlable, and we think that feeds will play a role here, too, as part of the replacement. Relying more heavily on feeds also makes it easier for Google to scrape data directly into SERPS, which they have been doing more and more. (See the appendix of this slide deck, starting on slide 30, for lots of mobile examples of this change in play already.) This probably will include the ability to scrape forms directly into a SERP, à la the form markup for auto-complete that Google just announced.

We are also inclined to believe that the use of the new "Mobile-Friendly" designation in mobile SERPS may be temporary, as long as SEOs and webmasters feel incentivized to make their CSS and JavaScript crawlable, and get into the new mobile index. "Mobile-Friendly" in the SERP is a bit clunky, and takes up a lot of space, so Google may decide switch to something else, like the "slow" tag shown to the right, originally spotted in testing by Barry Schwartz. In fact, showing the "Slow" tag might make sense later in the game, after most webmasters have made the updates, and Google instead needs to create a more serious and impactful negative incentive for the stragglers. (This is Barry's image; we have not actually seen this one yet).

In terms of the Mobile-Friendly announcement, it is surprising that Google has not focused more on mobile page speed, minimizing redirects and avoiding mobile-only errors—their historical focus for mobile SEO. This could be because page speed does not matter as much in the evaluation of content if Google is getting most of its crawl information from feeds. Our guess is that things like page speed and load time will rebound in focus after 4/21. We also think mobile UX indicators that are currently showing at the bottom of the Google PageSpeed tool (at the bottom of the "mobile" tab) will play into the new mobile algorithm—we have actually witnessed Google testing their inclusion in the Mobile-Friendly tool already, as shown below, and of course, they were recently added to everyone's Webmaster Tools reports. It is possible that the current focus on CSS and JavaScript is to ensure that as many pages are in the new index as possible at launch.

2. If my site is not mobile-friendly, will this impact my desktop rankings as well?

Answer: On a panel at SMX Munich (2 weeks after SMX West) Zineb from Google answered 'no' without hesitation. We took this as another indication that the new index is related to a new crawler and/or a major change to the infrastructure they are using to parse, index, and evaluate mobile search results but not desktop results. That said, you should probably take some time soon to make sure that your site works—at least in a passable way—on mobile devices, just in case there are eventual desktop repercussions (and because this is a user experience best practice that can lead to other improvements that are still desktop ranking factors, such as decreasing your bounce rate).

3. How much will mobile rankings be impacted?

Answer: On the same panel at SMX Munich (mentioned above), Zineb said that this 4/21 change will be bigger than the Panda and Penguin updates. Again, we think this fits well with an infrastructure change. It is unclear if all mobile devices will be impacted in the change or not. The change might be more impactful for Android devices or might impact Android and iOS devices equally—though currently we are seeing significant differences between iOS and Android for some types of search results, with more significant changes happening on Android than on iOS.

Deep linking is a key distinction between mobile SERPs on the Android OS and SERPs on iOS (currently, SERPs only display Android app deep links, and only on Android devices). But there is reason to believe this gap will be closing. For example, in his recent Moz post and in his presentation at SMX West, Justin Briggs mentioned that a few sample iOS deep links were validating in Google's deep link tool. This may indicate that iOS apps with deep links will be easier to surface in the new framework, but it is still possible that won't make it into the 4/21 update. It is also unclear whether or not Google will maintain its stance on tablets being more like desktop experiences than they are like mobile devices, and what exactly Google is considering "mobile." What we can say here, though, is that Android tablets DO appear to be including the App Pack results, so we think they will change their stance here, and start to classify tablets as mobile on 4/21.

Emails are also increasingly impacting SERPs—particularly mobile SERPs), since mobile email opens have grown by 180% in three years, and Google is trying to take advantage of this increased engagement on mobile devices. As of now, schema can be included in emails to drive notifications in the Google Now app, and also to let Google surface marked-up emails in a browser-based search. This all happens by virtue of Google crawling all emails that come into your Gmail account, and indexing them to your user-profile so that they are accessible and able to rank like this across all of your devices (even if you aren't currently logged into your Gmail account on your phone). Optimizing emails for mobile search is also becoming more important, and in the 4/21 update Google could do more to push the use of Schema markup in emails to drive personalized search results like the one shown to the right.

Inclusions like this mean that even if you are able to maintain your keyword rankings in mobile search after April 21, you may not necessarily be able to sustain your mobile traffic.

4. What about sites that redirect to a mobile subdomain? Will they be considered mobile-friendly?

Answer: This is an interesting question, because immediately after the roll-out of the Mobile-Friendly tagging, we actually saw significantly more mDot ('m.') websites ranking well in the mobile SERPS. It's almost like they counted the mobile subdomain as a Mobile-Friendly signal, but started the algorithm fresh, with no historical data to indicate which other sites had fewer obvious signals of mobility, like a responsive design, or an adaptive or dynamically served mobile site. It is also interesting to note that many of the Google representatives seem to have recently backed off of their strong insistence on responsive design. They still say that it is the least error-prone, and easiest to crawl and index, but they also now seem to be more willing to acknowledge the other viable mobile site architectures.

5. How do I know if my site meets Google's requirements for mobile friendliness?

Answer: Google has created a Mobile-Friendliness tool that will give you a 'yes' or 'no' answer on a per-url basis. Pages are evaluated individually, so another quick way to get a sense for how your top pages perform is to do a "site:" query for the domain in question on your phone. That will allow you to see all the pages indexed to the domain, and evaluate which ones are considered Mobile-Friendly and which are not, without having to submit them to the tool one at a time.

Google has been clear that Mobile-Friendly test results are binary, meaning that your page is either Mobile-Friendly or it is not. There is no 50% or 70% Mobile-Friendly result possible—no middle ground. They have also taken care to specify that Google's Mobile-Friendly evaluations are somewhat instant, implying that there is no proving-time or "sandbox" associated with the tag, but this could be somewhat misleading. There may be no intentional time-delay before a page is awarded the Mobile-Friendly notation, but it will only change after a crawl of the site indicates that the page is now Mobile-Friendly, so it is close to instantaneous if the pages are getting crawled on a very regular basis.

We have found that the tool result does not necessarily match up with what we are seeing on our phones. We have occasionally also noticed that sometimes two pages in the same page template will perform differently, even though the content that changes between the template is primarily text. Both of these variations could simply be an indication of real-time delay between the tool and the crawler—the tool does an ad-hoc check on the URL to assess mobile-friendliness, but if the bot has not been by the site to evaluate its mobile friendliness recently, then the page in question would not yet have the Mobile-Friendly designation in the SERP. With this in mind, remember that when you are updating a page, and pushing it live for testing, you must use the tool to see if the update has been successful, until the site is re-crawled. This also means that once you see success in the tool, the best way to get the Mobile-Friendly designation to show up in the results faster might just be to push a sitemap in Webmaster tools, and try to trigger a fresh crawl.

6. How does having a mobile app impact my mobile rankings?

Answer: There are two things to consider here. First, if a mobile search query is highly correlated with mobile app listings (the app "download pages" in the Google Play and iOS App Stores), your app could see significantly more visibility within mobile search results pages. This is because Google has started treating apps as a new kind of universal search result, returning an "App Pack" of Google Play results for certain searches on Android devices (shown at the right), and adding an Apps drop-down to the main nav-bar on iOS devices (not shown).

An "App Pack" is a group of related apps that rank together for a given query, shown together in a box separate from the inline organic search results. It has different formatting and an "Apps" header. These often float to the top of a mobile search result, pushing the second or sometimes even the first organic result below the fold. This is also discussed in Justin Briggs' article about apps. Currently, there is a high correlation between Google Play "App Pack" rankings and exact-match keywords in the app title. Google also seems to be evaluating app quality here and tries to serve only higher-than-average rated apps in the App Pack (this generally tends to be around a 3.5 – 4 star minimum for common keyword phrases).

If Google starts to serve these App Packs on iOS device searches as well, all apps that have keyword-optimized titles and have high-quality ratings and reviews could jump up to the top of the mobile web SERPs, increasing their visability and likely downloads. Conversely, mobile websites that currently enjoy an above-the-fold #1 or #2 organic ranking may get pushed below the fold in mobile SERPs, especially for queries that are highly correlated with mobile app results. This could cause a negative impact on mobile website visibility (without necessarily changing standard numeric rankings), in cases where a query returns a mobile App Pack—regardless of whether or not an app within that pack is yours.

Second, Mariya Moeva (Google Webmaster Trends Analyst) recently announced at SMX West that Google will be considering "high quality" apps to be a positive ranking factor in mobile search. We took this to mean that Deep Links between your website and your app will improve your website rankings in mobile search. Deep Links are different from app store listings in the App Store or Google Play, because they link directly to a specific screen within your app experience. They look just like regular links in the mobile search result, but when you click them, you are given the option of opening the link in on the web or in the app.

Currently, if you add Deep Links to your Android mobile app and associate your app URIs with corresponding (content-matching) webpages, Google will recognize the connection between your app content and your web content (and allow users who have your app installed to access your content directly in the mobile app). As it is now, the only way for Deep Links to your app contents to appear in search results is:

• For app screens to have a 1-1 content parity with webpages
• For those screens to have proper Deep Link coding that associates them with the corresponding pages on the website, AND
• For your app to be installed on the searcher's device. If the app is not installed or there is no corresponding web content, the links in the SERP will just behave as normal, web links.

Mariya didn't state exactly how Google will be evaluating the quality of apps, but we can guess that Google will be considering signals like star ratings, reviews, and +1s. And if what we assume about the 4/21 update proves to be true, it is possible that app URIs without corresponding Deep Linked web content may rank independently in a mobile SERP from information that Google aquired via app feeds. In this case, "app quality" could be a positive mobile ranking signal for its own URIs/ screens, and not just the website it is associated with. This would be a great boon for app descovery.

7. Do I need an app, and if so, should it be Android, iOS or both? What if I have a limited budget?

Answer: If you have the budget to develop both a mobile app and a mobile website, there can be significant value to maintaining both, particularly if you leverage the mobile app as a "value add" for your customers and not just a website duplicate (though enabling some functionality duplication is necessary for deep linking). If you have a limited budget, you will have to make a choice, but it is important to consider this a business choice and not primarily an SEO choice. Your business might be well served by a mobile website or might be better served by a mobile app with only a promotional mobile web landing page meant to send web traffic to app stores (ex. Tinder). In general, most businesses can be extremely well served by a mobile website and should focus their budget on making that experience great across many devices. We only recommend going "app-first" if you are trying to offer an experience that cannot be delivered well on a mobile website. Experiences that offer a valuable offline utilities (think photo-editing apps), or take advantage of heavy computing (like gaming apps) or rely on non-web input elements such as device accelerometers or GPS, are often better suited for an app.

Apps are generally riskier because they require more up-front investment, and have to be tightly in sync with app store guidelines and approval processes that you have no control over. There are a lot of barriers to entry; just building and maintaining an experience can cost an average of $100k per platform, so it's important that you know this is the right experience for your customers before you choose this path.

If you decide that an app experience is the best choice for your business (or you have budgeted an app in addition to your mobile web experience), you can use the operating system data in Google Analytics to help you determine which Operating System is more popular among your users. If you don't have this data because you don't have a website yet or you have too limited a mobile audience to determine a trend, you should choose the platform that best matches with your monetization strategies. iOS users tend to spend more money than their Android counterparts, but there are more total Android users around the world than iOS users. The implication is that if you plan to monetize your app with user transactions like In App Purchases (IAPs) or Subscriptions, iOS may be the way to start, but if you plan to monetize your app with advertisements, Android could be just as lucrative, if not more so. If Android app discovery is made easier with the 4/21 update but iOS app discovery is not, that could also factor into the decision process.

8. How is mobile traffic impacted by the user search query? Is there a way I can find out if my top keywords are mostly desktop or mobile keywords?

Answer: Search queries actually matter more and more for mobile, because Google is trying to do a much better job of anticipating and embracing a user's intent from the query. This means that often, Google is presenting the information a searcher requests directly in the search result above the organic rankings. SEOs are used to this for local-mobile searches, but it is now happening for all kinds of searches, so it can steal traffic that would otherwise go to the site and can skew success metrics.

Google has expanded the types of information that they scrape and pull from a site directly into an answer box, especially in mobile. They have also increased and diversified the number of aggregator-style "Sponsored" results that show up in mobile—especially on Android. The top mobile search result for most flight, hotel, music, and TV show queries are now specially designed, sponsored, aggregated results that push the old organic results below the fold. Whenever you see a little grey 'i' in the upper right hand corner of a mobile search result – especially a specially formatted list of results that Google has aggregated for you, that means that Google is probably getting a small portion of any related transaction, even if it is just the website paying for the click. Simple blue-link search results may soon be a thing of the past—especially above the fold.

Even regular, non-aggregator-style PPC results are taking up more room and looking more compelling with click-to-call, star ratings, app icons, links for directions and ad extensions, so these may be more of a threat for SEO moving forward (shown on the right). There is a long list of examples that we shared in the Appendix of Cindy's SMX Munich deck about the Future of Mobile SEO. With all the scraping, PPC may be the only way to out-rank Google and get above the fold for some queries in the mobile SERP.

If you have not seen Dr. Pete's presentation from SMX West this year about the Changing of Google SERPS, you really must! It addresses this question in the desktop format, but I think the crux of what he is saying is even truer in mobile. This Dr. Pete quote from a related interview is very telling:

"Google is essentially competing against us with our own information, and I think that's a turning point in the relationship between Google and webmasters." -Dr. Pete

In terms of which keywords are more mobile-oriented than desktop-oriented, this can be a difficult question. You can get some basic information from Webmaster Tools by filtering the keyword information to show mobile only queries, and you can do something similar in Google Analytics. Beyond that, there are some more sophisticated solutions, like those from Search Metrics and Brightedge, but those are often out of reach for smaller operations.

9. What is Google's goal with all of these mobile-friendly changes?

There are obviously a lot of goals in the mix here, but we do believe that Google is making these changes primarily to provide a better mobile experience for searchers, and give people exactly what they want. That said though, they are also in it to make money. Being able to easily surface apps in a search result will help them drive more and better app development for Google Play and monetize their other content like TV shows, books, magazines, movies, and music—all of which have been threatened recently by competitors like Hulu, Amazon, and of course iOS App Store and iTunes.

Google has been encouraging publishers to include transcripts with videos and song lyrics with songs. In the long run, those will help Google scrape and show those things in answer boxes, as shown at the right, but eventually they will probably also surface their own version of the content from Google Play, with links just below the answer box, so that you can watch the video or download the song directly to your phone on Google Play. When you think about Google's intentions on this front, and try to envision the future, it is important to note that Google is actually already offering Google Play for iOS, which currently just provides the Google Music cloud-storage and a music subscription model. We expect this to expand as well, so that Google can expand their level of competitiveness here too.