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 offers advice on how to get ready for the mobile-first index

Image Credit: Denys Prykhodov / Shutterstock.com

Google has posted on the webmaster blog more advice around getting ready for the mobile-first index.

Google confirmed it has rolled out the mobile-first index “for a handful of sites” and said the search team is “closely” monitoring those sites for testing purposes.

You will know when your site moved over by checking to see a significantly increased crawling rate by the Smartphone Googlebot in your log files and the snippets in the results, as well as the content on the Google cache pages, will be from the mobile version of your web pages. Again, Google said only a small number of sites have migrated.

Gary Illyes from Google posted several tips to get ready for the mobile-first index:

Make sure the mobile version of the site also has the important, high-quality content. This includes text, images (with alt-attributes), and videos — in the usual crawlable and indexable formats.Structured data is important for indexing and search features that users love: It should be both on the mobile and desktop version of the site. Ensure URLs within the structured data are updated to the mobile version on the mobile pages.Metadata should be present on both versions of the site. It provides hints about the content on a page for indexing and serving. For example, make sure that titles and meta descriptions are equivalent across both versions of all pages on the site.No changes are necessary for interlinking with separate mobile URLs (m.-dot sites). For sites using separate mobile URLs, keep the existing link rel=canonical and link rel=alternate elements between these versions.Check hreflang links on separate mobile URLs. When using link rel=hreflang elements for internationalization, link between mobile and desktop URLs separately. Your mobile URLs’ hreflang should point to the other language/region versions on other mobile URLs, and similarly link desktop with other desktop URLs using hreflang link elements there.Ensure the servers hosting the site have enough capacity to handle potentially increased crawl rate. This doesn’t affect sites that use responsive web design and dynamic serving, only sites where the mobile version is on a separate host, such as m.example.com.

For more information, check out our mobile-first index FAQs.

The lowdown on driving app downloads with Universal App campaigns

Universal App campaigns (UAC) help you find new app users across Google’s largest properties: Google Play, Search, YouTube and Gmail, as well as millions of websites and apps across the Google Display Network. Back in August, Google (my employer) announced that all app install campaigns in AdWords are becoming UACs.

Whether you’re starting UACs for the first time or are looking to get the most out of existing UACs, here are some best practices that I’ve discovered from talking with a bunch of other Googlers.

Getting up and running with UAC

The first key step is defining your goal. You’ll need to set a target based on one of these key performance indicators:

If you care about different metrics in different situations, create separate campaigns for each desired outcome.

From there, you’ll need to set up a few more items:

A daily budget. When you’re driving installs, this should be your target CPI multiplied by the number of daily installs you want (shoot for at least 50 to get enough data). When you’re driving in-app actions, it should be your target CPA multiplied by desired daily actions, shooting for at least 10.Your desired user action, which includes stuff like the first install or first open. This could also be your desired in-app action, like making a purchase or completing a game level.Creative assets, which is where you have some real flexibility. If you’re on a smaller budget, AdWords creates those ad assets on your behalf. Bigger advertisers can add a bunch of images and advanced creative assets (we’ll talk about those a bit later).And one final, crucial component: measurement. Do what you need to do to ensure that you’re measuring all of those actions.

How AdWords knows where to serve ads

So, how does AdWords know where to reach those potential new users without keywords, data feeds or any other targeting? Starting with the info about your app itself (its App Store or Play Store description), it examines signals like search queries on Google.com and Google Play, web crawl data and more. This data is mapped across all of the channels where we place ads and updated multiple times per day. That’s how AdWords can quickly pick up on new trending keywords like a sports event or an upcoming holiday and make sure it serves your app in the relevant context, across different properties.

Looking at users who’ve completed your selected action along with those who haven’t, AdWords evaluates a user’s auction signals. This is stuff like device type, the network they’re currently on, which apps they already have, and plenty of other insightful info. From there, patterns from converting users are identified. These patterns are then used to predict future auctions, where and how to bid, and what creatives to serve to other users who fit similar characteristics.

So it’s like DSA + Smart Bidding + similar audiences + a bunch of other stuff, all at the same time, across networks. Plus, it gets better the more it does it.

How you should manage UACs

Although UACs are more automated than other AdWords campaign types, you still have important levers at your disposal.

Update your bids

The target CPI/CPA/ROAS bids you set and modify have a strong influence on how your campaign performs. I definitely recommend staying on top of those targets. As you make any changes, it’s a good idea to adjust targets or budgets up or down 20 percent at most to avoid any drastic changes in performance. Once you’ve made a change, try to wait for at least 100 conversions before making another update. It takes time for automation to respond to new inputs, so be patient. If you’re curious about what impact a bid change might have for you, check out the bid simulator tool.

Provide great ad components

AdWords optimizes what content will show in your ads across channels. It’s best at doing that when it has a bunch of stuff to choose from in your Universal App campaigns.

When it comes to ad text, include a clear call to action. Write standalone sentences. AdWords automatically combines them to create the best text ad. And keep these short, sweet and focused on one unique selling point.

And when it comes to videos and images, don’t be shy. Add what you’ve got. You can (and should) upload 20 images and 20 videos to your campaigns. Plan to add multiple landscape images so AdWords can mix and match different backdrops across different types of users.

I mean what I said about videos, too. Adding videos gives you a lot more opportunity for your app to get noticed. Focus on different video assets in different ratios, like landscape, portrait and square, so AdWords can maximize reach across all properties, including rewarded, YouTube and native ads. After your creatives have time to run, check out the Creative Asset Report in your account to see how each of your creatives is performing.

Steer your automated campaign

Along with bidding and creative options, there are some considerations that might pop up as you get used to managing these campaigns.

Don’t worry about account structure

While countless articles on SEL have been written about how you should structure ad groups and keywords within your campaigns (including by yours truly), don’t worry about that for UAC. Query-level data is leveraged across campaigns and ad groups for search, and impression-level data is leveraged across GDN (Google Display Network) and YouTube.

Protect your brand

I love that Universal App campaigns are about driving conversions. And brand sensitivity is an important consideration as well, which I also love. By default, there are four brand safety filters enabled: not yet labeled (video and content), mature audience (video and content), tragedy and conflict (video) and sensitive social issues (video and content).

On top of those defaults, you can exclude mobile app categories, topics and autodirector videos. And, of course, you can use negative keywords. Negative keywords in UAC apply to all properties, from Google search to YouTube and everything in between. They’re a great way to protect your brand, but they could also blot out some of your traffic. Use negatives with care.

Don’t worry about cannibalization

While your standard search, GDN or YouTube campaigns and UAC will at times be eligible for the same auctions, only one campaign per account (or linked accounts) enters the auction. You aren’t going to bid yourself up with overlap (a common myth in search that I’ve been trying to quash for years).

AdWords chooses which ad to enter into a particular auction based on your active bids and past campaign performance. What’s in your best interest, auction-wise, should be chosen to show. One consideration: If you’re finding that your campaign isn’t getting the traffic you want it to, you might need to raise your bids to make it more competitive in those auctions.

Conclusion

It’s important to understand how to set up Universal App campaigns for success. It’s also important to know what you should be doing to ensure that these campaigns reach their full potential.

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

Have a question about Will Ferrell? Google may show you a video response directly from him

Curious if Will Ferrell can actually play the drums? Or if Tracee Ellis Ross can sing? Now, when you ask Google a question about a specific celebrity, you may get a self-recorded video from them answering your question.

“When you search for your favorite personalities, whether they’re rising stars or well-known celebs, their answers will appear in the form of selfie-style videos with a uniquely personal, authentic and delightful touch,” according to Google’s The Keyword blog.

Google has taken the most often asked questions about a select number of celebrities and had the celebrities record their answer so that they can now be served up for mobile searches related to the query.

The new feature is currently only available in the US and only works on mobile. It also applies to a very select list of well-known personalities. Google says it is piloting the feature with self-recorded video answers from the following list of celebrities:

Priyanka ChopraWill FerrellTracee Ellis RossGina RodriguezKenan ThompsonAllison WilliamsNick JonasMark WahlbergJames FrancoSeth MacFarlaneJonathan YeoDominique Ansel

According to the announcement, this new feature is a “snapshot of what’s to come,” and more videos are likely to be added during the upcoming months.

Google's latest search updates brings more content to Featured Snippets & Knowledge Panel info

Google has announced three new search updates around featured snippets, knowledge panel information and suggestions for related topics.

According to a post on Google’s The Keyword blog, a selection of featured snippets will now include more images and related search suggestions within the box displaying the featured snippet content.

It is also expanding the information displayed in the Knowledge Panel to include related content.

“For example, while looking at the Knowledge Panel about skiing, you’ll see related searches for sports such as snowboarding directly inside the result,” writes Google product manager, Michael Galvez.

Google says the expansion of related topics has not only been updated within knowledge panel information, but at the top of search results as well.

Using an example of searches for the famed soccer players Neymar and Messi, Google says searchers will see suggestions for related topics, “… to discover other athletes during your search session.”

In addition to these confirmed updates, it appears Google is also testing a new feature that displays a carousel with a list of answers directly within the search results snippet, as we reported earlier today.

“Search is not just about answering your questions — it’s also about discovery,” writes Galvez, who goes on to say the updates are meant to help searches further explore the topics they are researching.

Google beefs up mobile shopping results for the holidays, adds more product info & buying guides

Google is beefing up its mobile shopping experience to prepare for the holidays, now showing buying guides for broad categories like “sewing machine” and “coffee grinder” searches and adding more product-related information for specific product searches.

“When you search for a specific product, Google.com now shows you other helpful information, like related items, and allows you to compare reviews, prices and other specs, side by side,” writes Google product management director for Google Shopping, Jennifer Liu on Google’s The Keyword blog.

Google says it has added a “newer model available” label to tech-gadget product listings so searchers know if they’re browsing the most recent version of tech products.

According to the announcement, Google’s recently redesigned mobile shopping experience has helped bring more product information to the forefront with features like a “Quick View” button in Google Shopping ads that lets users preview detailed product information.

Google also noted its recent knowledge panel updates that quickly surface product photos, videos, reviews and descriptions for product-related searches.

For the announcement, Google pulled search trends for product searches happening in advance of Black Friday and Cyber Monday. According to its data, some of the more popular product searches occurring as we head into the biggest shopping weekend of the year include:

apparel brands like Vans, Canada Goose, and Nike Air Jordan Retro 11.celebrity-endorsed products like Kevin Durant’s Nike KD 10, Pharrell x Adidas and Rihanna’s Fenty Beauty makeup line.gamer gifts like Razer phones, Nintendo Switch and Call of Duty WW2.

On the Google Home device, Google says voice searches are trending toward everyday essentials such as paper towels or pet food — things people are likely to add to their grocery lists.

“We’re also seeing people using voice to find other types of products to prep for the holidays,” writes Liu, listing kitchen utensil products, toys “Or fuzzy blankets to keep warm by the fireplace.”

Google expanded on its trends data on the Think with Google blog, confirming that Black Friday-related searches have increased by 80 percent over the past two years.

“Mobile watch time of Black Friday haul videos grew by over 120 percent since 2014,” writes Google’s head of shopping ads, Emily Eberhard.

Google says it begins seeing “generic, non-branded” searches outpacing branded queries attached to Black Friday-related searches early in November. Approximately 2 1/2 weeks out from the Black Friday-Cyber Monday four-day shopping weekend, searches switch to more brand-specific searches.

“There is a switch to searches for Black Friday becoming mostly branded (e.g., “ashley furniture black friday” and “sephora black friday 2016″) as shoppers narrow down their options and begin laser-focusing their research on the specific items they want to buy,” writes Eberhard.

Branded versus non-branded search trends

Google says that in 2016, mobile searches for “black friday” peaked on Thanksgiving Day: “Overall, there were 2.5x as many searches for ‘black friday ads’ as there were for ‘how to cook a turkey.’”

It also notes that many Black Friday-related search queries center around shoppers trying to determine the best time to shop, with top Black Friday-related searches including queries such as: “cyber monday vs black friday,” “which is better black friday or cyber monday” and “is cyber monday as good as black friday.”

Google’s data showed that online conversions remain steady throughout November, with spikes on both Black Friday and Cyber Monday. Google says it sees mobile transaction rates increase 40 percent during the Thanksgiving weekend compared to the rest of the year.

“It’s a sign that mobile researchers [people researching product purchases on their phone] are likely to become mobile buyers over the four-day holiday break,” writes Eberhard.

Google searches now correspond to user location instead of domain

Google announced today that it is changing the way it labels country services on the mobile web, Google app for iOS and desktop Search and Maps.

According to Google, one in five searches is now location-related. To make search results more relevant, Google says the country of service will no longer be indicated by the country code top level domain name (ccTLD) such as “google.co.uk” for the UK or “google.com.br” for Brazil, but instead will default to the country where the user is performing the search.

From the Google Search Blog:

So if you live in Australia, you’ll automatically receive the country service for Australia, but when you travel to New Zealand, your results will switch automatically to the country service for New Zealand. Upon return to Australia, you will seamlessly revert back to the Australian country service.

Google says that typing the relevant ccTLD into a browser will no longer return various country services. Instead, users must go into their settings and select the correct country service if they don’t see the country they want while browsing.

“This preference should be managed directly in settings. In addition, at the bottom of the search results page, you can clearly see which country service you are currently using,” writes Google.

Google says this latest update will improve the search experience by automatically providing users “… the most useful information based on your search query and other context, including location.”

Mobile-first updates from SMX East

As every SEO knows, the rise of mobile searches has prompted Google to prioritize mobile signals in determining search results. To that end, the search giant is in the slow-going process of rolling out its mobile-first index, which is expected to be fully implemented sometime next year.

In the meantime, getting sites ready is a high-priority item on SEOs’ to-do lists, which is why the topic was addressed at this week’s SMX East conference in a panel discussion titled, “SEO For Google’s Mobile-First Index & Mobile-Friendly World.” The speakers included Leslie To, director of SEO for 3Q Digital; Ashley Berman Hale, director of SEO at Local SEO Guide; and Gary Illyes, webmaster trends analyst for Google.

Today’s post will cover the key points presented in this panel.

Leslie To: Is it the year of mobile yet?

Leslie To breaks down the process of preparing for the mobile-first index into two major categories:

    Configuration-agnostic auditingConfiguration-based auditing

Configuration-based auditing would involve those things you need to do that are specific to your mobile configuration (whether that’s a mobile subdomain, dynamic serving or responsive web design).

Configuration-agnostic auditing, on the other hand, involves items you need to address regardless of your mobile configuration, and this is what To covered first.

Configuration-agnostic auditing

Let’s start with a summary look at what matters regardless of mobile configuration:

Tips:

Use HTML for rich media and video content, and use the video element to download and decode the content.Avoid interstitials. If you want to promote your app or email list, use banners rather than full-screen overlays or interstitials. Users don’t like them, and neither does Google.Consistently test your global navigation and mine internal search data to refine that navigation (based on what you see users aren’t finding). Further, remember that mega menus don’t always work well on mobile. Simply put, don’t overwhelm users with menu options when you have limited screen real estate.Do allow content and media to scale to fill device screen size, as that provides a good user experience. To help with this, stay away from absolute declarations in your CSS.Do allow all font sizes to scale, and use 16px as your base font size. Don’t require users to zoom to read, interact with or consume content. No one likes to do that.Make your tap targets at least 48 pixels wide to make them easy to hit. In addition, space your tap targets 32 pixels (or more) apart. Don’t require users to zoom to tap buttons, links or form fields.Allow common gesture features on your e-commerce site, especially pinch/double-tap to zoom. Don’t use low-resolution images that become pixelated when you zoom.Configure internal site search to make content easier to find, and actively harvest site search queries to learn more about what users are looking for on your site so that you can make navigation, layout and content improvements over time.Enable contextual keyboards that change based on required input types. Using one standard keyboard layout for all input can be difficult for users to deal with. Don’t assume the limitations of physical keywords. For example, if you’re looking for someone to enter a domain name or email address, have a “key” that they can tap to enter “.com” — these types of contextual features will save them time.Make it easy for users to convert, whether it’s via a form fill, a phone call or your shopping cart. Enable click-to-call by wrapping phone numbers with telephone schema. Don’t require more than three clicks to complete a conversion.Implement all the basics of page speed. This means things like enabling gzip compression, leveraging browser caching and getting server response time under 2oo milliseconds.Don’t use render-blocking JavaScript, especially for external scripts. Don’t use inline CSS attributes and/or a large CSS file.Don’t make the language on your site too complex. Readability is a big concern (and not just for mobile sites). To give you some perspective, here is a look at how well US adults read:

Leverage readability indexes, such as:

Flesch reading easeFlesch-Kincaid grade levelGunning Fog indexSMOG Readability formula

You can get readability measurements for your content within Microsoft Word. There are two paths to navigate to it, shown below:

Configuration-dependent auditing: Mobile subdomains

If you’re using a mobile subdomain, you will need to implement bidirectional linking, with a rel=alternate tag on your desktop pointing to your mobile site, and a rel=canonical tag pointing from your mobile site back to your desktop site. These are sometimes called switchboard tags.

A common question that many people ask is whether or not Google will want publishers to reverse the direction of those tags with the advent of the mobile-first index. To date, Google’s answer to that has been no, that this is not necessary. They will simply assume the reverse. From Google’s perspective, if they tried to get everyone to switch them, a certain amount of chaos would be likely to result.

Do minimize cross-linking, so that your default links in the mobile experience should be to other pages in the mobile experience. But you should also provide the alternative desktop experience for users who want it. One benefit is that you can monitor clicks and, if there are lots of them, it may indicate problems in your mobile experience that you need to debug.

Do say no to blanket redirects, and try to make them all one-to-one. If you have no corresponding mobile content, leave users on the desktop page.

Configuration dependent auditing: Dynamic serving

For those using dynamic serving, you will need to implement the Vary HTTP header. This will help prevent problems with users being served the wrong versions of your pages due to ISP-caching. Without this header, ISP caching may cause mobile users to get your desktop page, and vice versa.

Watch out for, and avoid, unintended content differentiation between desktop and mobile because both sites are maintained differently.

Configuration dependent auditing: Responsive

With responsive sites, make sure you’re not blocking CSS or JavaScript files from being crawled. Check for the Meta viewport tag, as it gives directions on dimensions and scaling:

Width-device-width: matches content to the physical width of the device.Initial-scale: initial zoom when visiting a page.User-scale: allows for zooming (values are “yes” and “no”).

Use a comma to separate attributes so that older browsers can parse different attributes.

Do make sure that images and videos are also responsive, but don’t allow video to scale beyond the viewport size.

Last but not least, don’t base breakpoints on specific devices. Leverage Google Analytics’ Device Report to determine whether your breakpoints are properly serving your customers most of the time.

View Leslie To’s full presentation here:

Is It the Year of Mobile Yet? By Leslie To from Search Marketing Expo – SMX

Ashley Berman Hale: Mobile Friendly IRL, Beyond Best Practices

Ashley’s focus is on how you deal with the problem if you can’t get the budget or approval to proceed with making a site mobile-friendly.

When trying to get buy-in from stakeholders, Berman Hale suggests leaning on Google documentation and sharing relevant case studies. She also suggests showing desktop vs. mobile traffic over time — even in industries that are slow in moving to mobile, your analytics data is highly likely to show a strong trend in favor of mobile over time. Related to this is the idea of looking at competitor sites in SEMrush and showing their mobile traffic over time.

For some businesses, the issue may be that they only have a small budget. If that’s your situation, consider starting small. For example, you can break down your mobile friendliness action items into more manageable parts, including:

by site section.by product.by customer.by element.

Another practical tip is to focus on getting people on board one at a time. These kinds of approaches can help you build momentum in a positive way.

In other cases, the challenge might be that the code is a hot mess, and everyone is afraid to touch anything. The incremental approach can work well here, too. For example, you can:

compress your images.figure out how to strip some CSS.implement AMP on just a few elements.

Or perhaps your role is such that you only have control over the content on the site, and not the coding side of things. You can still make a difference. You can accomplish this by thoroughly understanding the intent of people who are reading your content on mobile and making it easy for them to find what they want.

This starts with upfront research, including your keyword research. Use this to help you understand the likely user intents, and then form your content around those concepts. Structure your content to make it easy to find, and create snackable, modular elements. In addition, modify your metadata and markup to communicate what users will get by engaging with your content.

You may have people in your business who care only about brick-and-mortar sales. But local search is typically a huge driver for that, and local search often is mobile search.

The key to unraveling this is learning how to track the progression from local searches to your site and business. Setting this up can help you get what you need to show people that local (and mobile) is critical to your business.

Or, if you’re in the right business, you may be able to call in legal. Your industry may have accessibility requirements, and a solid mobile experience may simply be something that you’re required to do.

Lastly, you should always pick your battles and “choose what hill to die on.” Make sure you are making steady progress over time; the path to maximum mobile-friendliness is definitely a marathon, and not a sprint.

View Ashley Berman Hale’s full presentation here:

Mobile Friendly IRL: Beyond Best Practices By Ashely Berman Hale from Search Marketing Expo – SMX

Gary Illyes: Google’s perspective

Illyes explains that, traditionally, the Google index is based on crawls of desktop content. However, the problem Google has had is that on many sites, the desktop site would have more content on its pages than the corresponding mobile pages. This was leading to problems in search because Google would return pages to mobile users based on the content they found on the desktop pages, but the users would then get served the mobile page and the content wasn’t there.

This created frustration with the quality of Google’s results, and this ended up driving the idea of switching to a mobile-first index. What this means is that Google will crawl mobile sites and base their search index off of the content they find from that crawl.

Illyes’ message on this is: “Don’t freak out.” Google is approaching this very carefully, and they don’t yet know when a full mobile-first index will go into effect. They started experimenting with it two years ago, and it did not go well at all.

Currently, they have moved a small number of sites into a mobile-first index, and they have been monitoring those to make sure they’re not being hurt in terms of traffic and ranking as a result.

Eric’s note: Google has to be very careful about these types of changes. While they may be desirable at some level, searchers often have pretty specific things they want and need, including specific brands, and if they’ve been artificially demoted, this will also result in user frustration. This is the same reason that things like HTTPS and page speed are such weak ranking factors.

Illyes next notes that if your site is responsive, you’re good to go! But many of the sites that have other mobile configurations are not good to go.

Common issues with mobile sites are:

Some of the content and links from the desktop site may not be present.Rel=annotations may not be there (e.g., hreflang).Structured data may be missing.Some of the media and images may be missing.

Illyes then shared the example of one site that did not move over their hreflang tags, and they lost 50 percent of their traffic. This is exactly the type of thing that Google wants to avoid.

Here are the things you should do to prepare for the mobile-first index:

    If your site is responsive, you’re already ready to go.Make sure your mobile pages have all the same videos and images as your matching desktop pages.Make sure your mobile site has all the content and all the links that show up on the matching desktop pages.Make sure to implement hreflang tags on the mobile pages.Make sure to carry over the structured data from your desktop pages.

Last, but not least, don’t panic!

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

Google's mobile-first index has rolled out for some sites & will be implemented very slowly

The mobile-first index has started to slowly roll out, at least for a “few sites,” Google Webmaster Trends Analyst Gary Illyes told an audience last night at the SMX East conference in New York City.

It is unclear how many sites have already switched over to the mobile-first indexing process, but, when I asked Illyes to clarify what he meant by “a few sites,” he said a few relative to the Google index. So that could be quite a large number of websites.

He said there is no reason to panic about the rollout because Google is still testing it and will be rolling it out incredibly slowly. He added that there is no foreseeable time when the mobile-first index will be fully implemented.

The admission came as a surprise as we did not expect the rollout to begin until next year, but it seems positive test results have encouraged Google to move forward.

In selecting sites to be switched over, Google has set up “classifiers” to define how ready a site is for the mobile-first index. Classifiers determine how equal or comparable the desktop site is to the mobile site when it comes to content, links, schema, multimedia, etc.

If the content, links, schema and so on all match at a 100 percent level, Google is more likely to take that site to the mobile-first indexing stage. If they are at an 80 percent level, Google might wait and communicate to the webmaster that there are specific changes that need to be made to the mobile site to get it closer to being 100 percent comparable.

In any event, Gary Illyes said the purpose of rolling it out to a limited number of sites is to test it more. The tests seem to be going very well, and it will gradually roll out to more sites over time. He said the rollout will go incredibly slowly, and Google will communicate the process to webmasters along the way.

Google also has a blog post in the works that will be published at some point helping webmasters and SEOs understand the process. The company won’t provide a timeline or ETA for the rollout or the blog post, but Illyes confirms they are on the way.

Accelerated Mobile Pages (AMP) conquer the competition for shoe retailer

In the highly competitive footwear vertical, no season matters more than late summer, when shoppers spend $27 billion on supplies and clothing for the coming school year.

According to the Deloitte back-to-school survey for 2017, some 55 percent of that spend, about $15 billion, is devoted to clothing and accessories. Late summer may be only the second-biggest shopping season of the year in the United States, but for verticals like footwear, it’s number one.

A top shoe retailer came to Brandify (disclosure: my employer) for a solution to boost local store visibility online. To achieve the retailer’s goal, we worked in collaboration with SEO consultant Steve Wiideman to implement Accelerated Mobile Pages (AMP) for the retailer’s nearly 500 US stores.

The open-source AMP Project, led and heavily promoted by Google in collaboration with Twitter, WordPress, Pinterest and LinkedIn, defines a lightweight standard for publishing web pages that makes them load very quickly on mobile devices. The standard includes special implementations of HTML and JavaScript, as well as the concept of an AMP Cache, which is a repository for serving pages converted to AMP.

Google’s AMP Cache is by far the biggest, and since early 2016, Google has been featuring AMP results prominently, first at the top of the mobile SERP in “zero position,” and later in the year as part of the ordinary list of search results. Google has reported that pages converted to AMP typically load in less than half a second and use one-tenth of the data used by the same page in non-AMP format.

It would seem like a no-brainer to use AMP for local store pages, and yet the local search industry has been slow to adopt the standard. During the first phase of the AMP Project’s rollout, it was believed that AMP, with its stripped-down publishing format, was only suited to news sites and blogs, where presentation of text content is the main point of the web page.

This began to change when eBay launched 8 million AMP product pages last summer, proving that e-commerce sites could benefit from fast page loads and simplified presentation. As Brafton’s Ben Silverman wrote on his company’s blog, “The auction site’s confident leap into the world of the accelerated mobile experience proves that fast-loading, neatly formatted, easy-to-use content is the best way to drive conversions and sales.”

.mktoButton{background:#000!important;}

Keep up on the latest developments with AMP and more. Get regular updates in your inbox.

We were eager to bring the benefits of AMP to our multilocation brand clients, and the shoe retailer’s request for a boost in traffic created a good opportunity. The switch to AMP involved a modest redesign of the local page layout for the brand, though because the retailer already preferred simplicity and utility in its web pages, the changes did not need to be dramatic.

The possibilities for interactive content are limited with AMP, and the presentation must remain simple, but developers and brands should not shy away from AMP for that reason. After all, quick access to relevant information is what mobile searchers want.

This supposition was borne out by the results for the shoe retailer. Even though AMP implementation by itself is not considered to be a ranking factor, the improvement in page design and load time correlated with a notable increase in session traffic.

Comparing the 20-day periods before and after the launch of pages converted to AMP on July 27 of this year, we saw an increase, period-over-period, of 32 percent in overall session traffic. What’s more, the impact was noticeable almost immediately on July 28, one day after launch.

Screenshot of Google Analytics showing AMP deployment on July 27 and subsequent spike in sessions.

The year-over-year results were even more dramatic, with sessions increasing 45 percent between July 28 and August 17, 2017 over the same period in 2016. Other factors may have contributed to this increase, but the immediate jump in traffic upon AMP launch is hard to deny as evidence of AMP as an isolated and significant contributor.

We also examined the retailer’s Google My Business (GMB) Insights and found a possible add-on effect. Greater prominence of local pages for the retailer seems to correlate with increased views and actions on Google listings for the brand.

Comparing the 20 days before and after launch, we saw a 9.4 percent increase in customer actions for the retailer’s Google listings, such as clicking to visit the brand website, requesting directions and clicking to call. Moreover, comparing the first 20 days after the launch of pages converted to AMP to the same period one year before, we measured a 21.3 percent increase in customer actions.

GMB Insights for shoe retailer shown in the Brandify dashboard

The implication of this result is that Google can connect pages hosted within its own AMP Cache with their corresponding website links in a store’s GMB listing. Performance of one’s business website is a known ranking factor for local listings, and AMP appears to be a great weapon for boosting local as well as organic results.

The retailer benefited significantly from the switch to AMP over a remarkably short period of time, ensuring the brand would remain at the forefront of consumer attention during the competitive back-to-school season. During the time period of the AMP campaign launch, no other significant changes were made to the retailer’s local campaign, so we feel we can claim with confidence that barring any external factors, AMP was the major driver of the positive results we measured.


Want to learn more about this case study and others related to AMP? Join us in New York for our SMX East search marketing conference, and be sure check out the “AMP: Do or die?” session, featuring the author.

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