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.

The upcoming mobile app Monday: Be prepared

The season is upon us: mobile download season. Christmas falls on Monday, and if history holds true, Christmas and the day after will be the top mobile app download days of the year. With less than a week left, your app store optimization (ASO) activities should be in full swing.

Becky Peterson heads up our app store optimization at Walgreens. Becky was looking to be on the nice list, so she put together some optimization tips for new and existing apps to help you maximize the download season.

Optimization essentials

Title: Choose a title for your app that is creative but concise. If appropriate, take advantage of the character limit to include relevant keywords that describe your app’s core functionality. (Just don’t overdo it — you don’t want to appear spammy!)Icon: Create an eye-catching icon that is clean and easily recognizable. A recognizable icon can make the difference when customers are searching specifically for your app.Keywords & description: Conduct keyword research to determine the most valuable and relevant terms for your app. Utilize the keyword field in iTunes Connect, and use your keywords throughout your description and in your creative assets.Video: Create a preview video (or three for iOS!) that walks through your core features and provides visitors an overview of how to use your app. On iOS 11, your previews will autoplay in search results and on your store page; in Google Play, they will underlay the Feature Graphic. Create videos that are engaging. Test, test, test to determine which video version generates optimal downloads prior to the top download days.Screen shots: Create clean and visually appealing screen shots that capture the essence of your app and encourage visitors to continue scrolling through the gallery.

Additional tips

Take full advantage of free app store intelligence platforms, such as App Annie or Sensor Tower, or invest in an app store analytics platform that will provide you with keyword ranking, competitors, Top Chart and download data.If applicable, seasonalize or incentivize your store listing! Use your description to highlight how your app is seasonally relevant and provide offers (i.e., shopping deals, products and more), and update your creative assets to showcase a holiday theme.Respond to your app reviews. Demonstrate to your users that you appreciate their feedback and are constantly working to improve your app. Some reviewers may even choose to update their original review simply because you responded in a considerate manner. Prospective users are more inclined to download an app when it is clear the app owners take feedback seriously.

Capitalizing on the top download days of the year can be the difference between an average app and a top download. Keep your content fresh, do not over-optimize, and remember that the goal is to assist customers in finding the right app for the right purpose. Put in the effort, set download goals, and allocate plenty of time to respond to the flurry of reviews that occur soon after installation and use.

Remember to document your lessons learned once the season is over. Download season will be back before you know it, and those valuable lessons can be the difference-maker next year.

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

SEO in 2018: Optimizing for voice search

Google Webmaster Trends Analyst John Mueller recently asked for feedback on why webmasters are looking for Google to separate voice search queries in Search Console. If you, like me, want to see voice searches in Google Search Console, definitely submit your feedback on Twitter as John requested.

I hear folks asking about voice search data in Search Console often. Can you elaborate on what you want to see there? What's an example of such a query that would be useful? pic.twitter.com/WOqS7aH4tP

— John ☆.o(≧▽≦)o.☆ (@JohnMu) December 7, 2017

I lived through the very beginnings of mobile SEO, where many people thought mobile search behavior would be completely different from desktop search behavior only to find that much of it is the same. So I see why Mueller and others don’t necessarily understand why Search Console users would want to see voice queries separately. Some queries are the same whether they’re typed into a computer at a desktop or spoken across the room to a Google Home.

That being said, there are some very good reasons to want voice search data. Optimizing for voice search requires some slightly different tactics from those for traditional SEO, and having insight into these queries could help you provide a better experience for those searching by voice.

Not convinced you should care about voice search? Here are three reasons I think you should:

1. More visibility on featured snippets

One of the interesting things about Google Home is that when it answers a question with information from the web, it will cite the source of the information by saying the website’s name, and it will often send a link to the searcher’s Google Home app.

Currently, Google Home and Google Assistant read snippets from sites that are ranked in “position zero” and have been granted a featured snippet. This is why more people than ever are talking about how to optimize for featured snippets. If you look at the articles published on the topic (according to what Google has indexed), you’ll see that the number of articles about how to optimize for featured snippets has grown 178 percent in the past year:

Understanding voice search queries could help us better understand the types of queries that surface featured snippets. As marketers, we could then devote time and resources to providing the best answer for the most common featured snippets in hopes of getting promoted to position zero.

This helps marketers drive credibility to their brand when Google reads their best answer to the searcher, potentially driving traffic to the site from the Google Home app.

And this helps Google because they benefit when featured snippets provide good answers and the searcher is satisfied with the Google Home results. The better the service, the more consumers will use it — and potentially buy more Google Home units or Android phones because they think the service is worthwhile.

If bad featured snippets are found because no one is trying to optimize for those queries, or no featured snippets are found and the Google Home unit must apologize for not being able to help with that query yet, Google potentially loses market share to Amazon in the smart speaker race and Apple in the personal assistant race.

So this one is a win-win, Google. You need more great responses competing for position zero, and we want to help. But first, we need to know what types of queries commonly trigger featured snippets from voice search, and that’s why we need this data in Search Console today.

2. Better way to meet consumer demand and query intent based on context

We saw two major things happen in the early days of mobile SEO when we compared desktop and mobile queries:

    Searchers often used the same keywords in mobile search that they did in desktop search; however, certain keywords were used much more often on mobile search than desktop search (and vice versa).Whole new categories of queries emerged as searchers realized that GPS and other features of mobile search could allow them to use queries that just didn’t work in desktop search.

An example of the first point is a query like “store hours,” which peaks in volume when shoppers are headed to stores:

An example of the second is “near me” queries, which have grown dramatically with mobile search and mostly occur on mobile phones:

The mode of search therefore changes search behavior as searchers understand what types of searches work well on mobile but not on desktop.

Consider this in the context of voice search. There are certain types of queries that only work on Google Home and Google Assistant. “Tell me about my day” is one. We can guess some of the others, but if we had voice search data labeled, we wouldn’t have to.

How would this be useful to marketers and site owners? Well, it’s hard to say exactly without looking at the data, but consider the context in which someone might use voice search: driving to the mall to get a present for the holidays or asking Google Home if a store down the street is still open. Does the searcher still say, “Holiday Hut store hours?” Or do they say something like, “OK Google, give me the store hours for the Holiday hut at the local mall?” Or even, “How late is Holiday Hut open?”

Google should consider all these queries synonymous in this case, but in some cases, there could be significant differences between voice search behavior and typed search behavior that will affect how a site owner optimizes a page.

Google has told us that voice searches are different, in that they’re 30 times more likely to be action queries than typed searches. In many cases, these won’t be actionable to marketers — but in some cases, they will be. And in order to properly alter our content to connect with searchers, we’ll first need to understand the differences.

In my initial look at how my own family searched on Google Home, I found significant differences between what my family asked Home and what I ask my smartphone, so there’s reason to believe that there are new query categories in voice search that would be relevant to marketers. We know that there are queries — like “Hey Google, talk to Dustin from Stranger Things” and “Buy Lacroix Sparkling Water from Target” — that are going to give completely different results in voice search on Google Home and Assistant from the results in traditional search. And these queries, like “store hours” queries, are likely to be searched much more on voice search than in traditional search.

The problem is, how do we find that “near me” of voice search if we don’t have the data?

3. Understanding extent of advertising and optimization potential for new voice-based media

The last reason to pay attention to voice search queries is probably the most important — for both marketers and Google.

Let me illustrate it in very direct terms, as it’s not just an issue that I believe marketers have in general, but one that affects me personally as well.

Recently, one of my company’s competitors released survey information that suggested people really want to buy tickets through smart speakers.

As a marketer and SEO who sells tickets, I can take this information and invest in Actions on Google Development and marketing so that our customers can say, “OK Google, talk to Vivid Seats about buying Super Bowl tickets,” and get something from Google Home other than, “I’m sorry but I don’t know how to help with that yet.” (Disclosure: Vivid Seats is my employer.)

Or maybe I could convince my company to invest resources in custom content, as Disney and Netflix have done with Google. But am I really going to do it based on this one data point? Probably not.

As with mobile search in 2005, we don’t know how many people are using voice search in Google Home and Google Assistant yet, so we can’t yet know how big the opportunity is or how fast it’s growing. Voice search is in the “innovators and early adopters” stage of the technology adoption life cycle, and any optimizations done for it are not likely to reach a mainstream audience just yet. Since we don’t have data to the contrary from Google or Amazon, we’ll have to stay with this assumption and invest at a later date, when the impact of this technology on the market will likely mean a significant return on our investment.

If we had that data from Google, I would be able to use it to make a stronger case for early adoption and investment than just using survey data alone. For example, I would be able to say to the executives, “Look how many people are searching for branded queries in voice search and getting zero results! By investing resources in creating a prototype for Google Home and Assistant search, we can satisfy navigational queries that are currently going nowhere and recoup our investment.” Instead, because we don’t have that data from Google, the business case isn’t nearly as strong.

Google has yet to monetize voice search in any meaningful way, but when advertising appears on Google Home, this type of analysis will become even more essential.

Final thoughts

Yes, we can do optimization without knowing which queries are voice search queries, as we could do mobile optimization without knowing which queries are mobile queries; yet understanding the nuances of voice search will help Google and marketers do a better job of helping searchers find exactly what they’re looking for when they’re asking for it by voice.

If you agree, please submit your feedback to John Mueller on Twitter.

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

AMP: A case for websites serving developing countries

Like Taylor Swift, Accelerated Mobile Pages (AMP) have a reputation. In a not-very-official Twitter poll, 53 percent claimed AMP was “breaking the web.”

What do you think about AMP?

— Maximiliano Firtman (@firt) March 23, 2017

The mobile ecosystem is already complex: choosing a mobile configuration, accounting for mobile-friendliness, preparing for the mobile-first index, implementing app indexation, utilizing Progressive Web Apps (PWAs) and so on. Tossing AMP into the mix, which creates an entirely duplicated experience, is not something your developers will be happy about.

And yet despite the various issues surrounding AMP, this technology has potential use cases that every international brand should pause to consider.

To start, AMP offers potential to efficiently serve content as fast as possible. According to Google, AMP reduces the median load time of webpages to .7 seconds, compared with 22 seconds for non-AMP sites.

And you can also have an AMP without a traditional HTML page. Google Webmaster Trends Analyst John Mueller has mentioned that AMP pages can be considered as a primary, canonical webpage. This has major implications for sites serving content to developing counties.

Yes, AMP is a restrictive framework that rigorously enforces its own best practices and forces one into its world of amphtml. However, within the AMP framework is a lot of freedom (and its capabilities have grown significantly over the last year). It has built-in efficiencies and smart content prioritization, and a site leveraging AMP has access to Google’s worldwide CDN: Google AMP Cache.

Source: “AMP: Above & Beyond” by Adam Greenberg

All of this is to say that if your brand serves the global market, and especially developing economies, AMP is worth the thought exercise of assessing its implications on your business and user experience.

What in the world-wide web would inspire one to consider AMP?

1. The internet is not the same worldwide

Akamai publishes an amazing quarterly report on the State of the Internet, and the numbers are startling — most of the world operates on 10 Mbps or less, with developing countries operating at less than 5 Mbps, on average.

If 10 Mbps doesn’t make your skin crawl, Facebook’s visual of 4G, 3G and 2G networks worldwide from 2016 (below) will.

Source: Facebook

The visuals show a clear picture: Developing countries don’t have the same internet and wireless network infrastructure as developed economies. This means that brands serving developing countries can’t approach them with the same formula.

2. Websites overall are getting chunkier

While all of this is happening, the average size of website is increasing… and rapidly. According to reports by HTTParchive.org, the average total size of a webpage in 2017 is 387 percent larger than in 2010.

Despite the number of requests remaining consistent over time, the size of files continues to trend upward at an alarming rate. Creating larger sites may be okay in developed economies with strong networking infrastructures; however, users within developing economies could see a substantial lag in performance (which is especially important considering the price of mobile data).

3. Mobile is especially important for developing economies

The increase in website size and data usage comes at a time when mobile is vital within developing economies, as mobile is a lifeline connection for many countries. This assertion is reaffirmed by data from Google’s Consumer Barometer. For illustration, I’ve pulled device data to compare the US versus the developing economies of India and Kenya. The example clearly shows India and Kenya connect significantly more with mobile devices than desktop or tablet.

Source: Consumer Barometer with Google

4. Like winter, more users are coming

At the same time, the internet doesn’t show any signs of slowing down, especially not in developing countries. A recent eMarketer study on Internet Users Worldwide (August 2017) shows a high level of growth in developing countries, such as India, at 15.2 percent. Even the US saw a +2.2 percent bump in user growth!

User penetration as a percent of a country’s total population shows there is still room for growth as well — especially in developing countries.

5. The divide in speed is growing

In the chart below, I choose nine developing countries (per the United Nations’ World Economic Situation and Prospects report) to compare with the United States’ internet speed (which ranked 10th worldwide in the last report). Despite the overarching trend of growth, there is a clear divide emerging in late 2012 — and it appears to be growing.

[Click to enlarge]

Why is this significant? As internet connection speeds increase, so do page sizes. But as page sizes increase to match the fast speeds expected in developed nations, it means that users in developing nations are having a worse and worse experience with these websites.

So, what should one do about it?

The data above paint a picture: Worldwide internet penetration worldwide continues to grow rapidly, especially in developing nations where mobile devices are the primary way to access the internet. At the same time, webpages are getting larger and larger — potentially leading to a poor user experience for internet users in developing nations, where average connection speeds have fallen far behind those in the US and other developed nations.

How can we address this reality to serve the needs of users in developing economies?

Test your mobile experience.

AMP isn’t necessary if your site leverages mobile web optimization techniques, runs lean and is the picture of efficiency; however, this is challenging (especially given today’s web obesity crisis). Luckily, there are many tools that offer free speed analyses for webpages, including:

Test My Site tool (via Think With Google)Page Speed Insights tool (via Google Developers)Mobile-Friendly Test (via Google Search Console)WebPageTest.org

Develop empathy through experience.

Allow yourself to step into your customers’ shoes and experience your site. As former CEO of Moz, Rand Fishkin, once aptly stated, “Customer empathy > pretty much everything else.”

Regular empathy is hard. Empathy for people you don’t know is nearly impossible. If we don’t see the problem, feel it and internalize the challenge, we can’t hope alleviate it.

Facebook introduced a 2G Tuesdays, where employees logging into the company’s app on Tuesday mornings are offered the option to switch to a simulated 2G connection for an hour to support empathy for users in the developing world. If you’re looking to try something similar, any Chrome/Canary user can simulate any connection experience through Chrome Developer Tools through the Network Panel.

Consider if AMP is right for your site.*

You should entertain the thought of leveraging AMP as a primary experience if your brand meets the following criteria:

Your site struggles with page-speed issues.You’re doing business in a developing economy.You’re doing business with a country with network infrastructure issues.The countries you target leverage browsers and search engines that support AMP.Serving your content to users as efficiently as possible is important to your brand, service and mission.

*Note: AMP’s architecture can also be used to improve your current site and inform your page speed optimization strategy, including:

Paying attention to and limiting heavy third-party JavaScript, complex CSS, and non-system fonts (where impactful to web performance, and not interfering with the UX).Making scripts asynchronous (where possible).For HTTP/1.1 limiting calls preventing round-trip loss via pruning or inlining (this does not apply to HTTP/2 due to multiplexing).Leveraging resource hints (a.k.a. the Pre-* Party), where applicable.Optimizing images (including: using the optimal format, appropriate compression, making sure images are as close to their display size as possible, image SRCSET attribute, lazy loading (when necessary), etc.)Using caching mechanisms appropriately.Leveraging a CDN.Paying attention to and actively evaluating the page’s critical rendering path.

Educate your team about AMP, and develop a strategy that works for your brand.

AMP has a plethora of great resources on the main AMP Project site and AMP by Example.

If you decide to go with AMP as a primary experience in certain countries, don’t forget to leverage the appropriate canonical/amphtml and hreflang tags. And make sure to validate your code!

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

SEO + UX = Success

In the good old days, SEO was simple. You stuffed a page full of keywords, and you ranked number one. Oh, if only it were that simple today! Now, Google (and the other search engines) literally take hundreds of factors into account when determining which pages rank high in search engine results pages (SERPs).

This new reality means that elements of user experience (UX) have been rolled into SEO best practices. How easy is your site to navigate? Do you have quality content that makes visitors want to stay and engage? Is your site secure, fast and mobile-friendly?

Think of the partnership of SEO and UX this way: SEO targets search engines, and UX targets your website’s visitors. Both share a common goal of giving users the best experience.

Here are some common website elements that impact both SEO and user experience.

Headings

Just as the headings of a printed work make it easier to find information, the headings of a web page make it easier for both visitors and search engine crawlers to understand and parse your content.

Headings (<h1>, <h2>, <h3>, <h4>, <h5> and <h6>) should tell the readers and search engines what the paragraphs/sections are about and show a logical hierarchy of the content. Headings also help users if they get lost on a page.

Only use one h1 tag on a page — that lets search engines and users know the page’s primary focus. H1s are normally the first piece of content on a page, placed near the top. (Think of h1s as the chapter title of a book.) Adding keywords toward the front of a heading can also help with rankings.

Other headers (h2 through h6) should follow h1s to structure and organize the rest of the page appropriately. The other headings can be used several times on a page, as long as it makes sense. You do not need to use all of them, either — sometimes your content may only need an h1 and some h2s.

Easy navigation and site structure

It may seem crazy that we’re still talking about easy site navigation… but we are. There are way too many sites out there that simply don’t get it. Your site structure is not only important for your users, but it’s your site’s roadmap for the search engines, too.

Remember that many of your visitors will not enter your site through your home page. This means that your site needs to be easy to navigate — no matter which page a searcher (or search engine crawler) lands on.

Your site’s navigation is not the place for fancy popups, a long list of options, hide-and-seek games or a place of dead ends where the user doesn’t know how to get back to another section of your site or get back to your home page.

Take a look at how healthcare giant Anthem’s menu overtakes the screen — on both desktop and mobile — when the menu is clicked:

With the menu literally filling the entire screen, a user can’t read the content that’s underneath the navigation. This creates a very poor user experience. When people are on mobile devices, chances are they won’t have the patience to deal with menus like this.

Additionally, a clean site navigation and structure can also lead to sitelinks appearing in Google search results. Sitelinks can help you take over more real estate on search engine result pages — which means less room for your competitors (and, hopefully, more clicks for you).

Google’s algorithm decides which sites get sitelinks (and which ones don’t). They base this decision largely on a site’s structure:

We only show sitelinks for results when we think they’ll be useful to the user. If the structure of your site doesn’t allow our algorithms to find good sitelinks, or we don’t think that the sitelinks for your site are relevant for the user’s query, we won’t show them.

User signals

I believe that user signals will increasingly become a more prominent factor in search engine rankings. Do you have Posts on Google My Business that visitors are clicking on? Are visitors on mobile devices using the click-to-call feature to dial your business? Are happy customers leaving five-star reviews for you — and are you responding to those reviews?

Although Google has denied that user signals such as time on site or bounce rate are direct ranking factors, studies have shown that there is a strong correlation between these signals and top rankings. Let’s put it this way: Google sees and knows everything. Every touch point and interaction your visitors have with you (and you have with them) shows Google that users are interested in and engaging with your content.

Site speed

Site speed has long been a ranking factor for Google search, and the company has even announced that mobile page speed (rather than desktop) will soon be used to determine this ranking factor. So not only is it important to have a website that loads quickly, but your mobile experience needs to be fast as well.

Google’s PageSpeed Insights tool allows you to enter your URL to see the issues your site might be having with mobile responsiveness. PageSpeed Insights measures how the page can improve its performance on both time to above-the-fold load and time to full page load and provides concrete suggestions for reducing page load time.

Amazingly, even the big sites with presumably large development and IT budgets have speed issues. See the poor results for the Harvard Business Review site:

Content-heavy and news sites should especially pay attention to site speed issues, since these sites are often viewed on mobile devices for the sake of convenience.

Mobile experience

When you think of “mobile experiences,” speed is definitely one consideration, but so is your mobile website as a whole — the look, feel, navigation, text, images and so forth.

Ever since Google released its mobile-friendly update in 2015, webmasters and SEOs have had to take “mobile-friendliness” into account as a ranking factor. And now, with the mobile-first index said to be coming in 2018, your mobile site will be considered your “main” website when Google’s algorithm is calculating rankings — thus making a good mobile experience all the more crucial.

Navigation is one of the most important components of a mobile experience — users and Google need to be able to find what they’re looking for quickly. Even button sizes and designs can impact user interaction on your mobile website. Every element on your mobile website impacts a user’s experience and directly (or indirectly) affects SEO as well.

In searching for an example of a local business’s mobile website, I found the one shown below. For this company’s mobile site, more than half of the above-the-fold real estate is taken up with meaningless information like huge logos and social media buttons. Plus, their menu is teeny-tiny and doesn’t even say “Menu” — it says “Go To…” and has the actual link to the menu to the far right-hand side. This does not make for a very user-friendly experience.

This company would be better off taking the clutter away from the top of the screen and making their menu, products and services more prominent for their mobile users.

Simple and smart design decisions like this will go a long way to making not only your visitors happy, but Google, too!

SEO and UX: A winning combination

Hopefully, you can see how SEO and UX go hand-in-hand in creating a successful website experience for both your human visitors and the search engines.

But what do you think? Do you think of your site’s users when you are creating content? How do you work with your design team to ensure that your site makes for a great mobile experience for your users? What is your balance between SEO factors and UX factors? We’d love to know!

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

Siri, Safari and Google Search: What does it mean for marketers?

Apple has recently made some significant changes to both Siri and Safari, with potentially far-reaching implications for digital marketers.

First, Apple has announced that results for its AI-powered digital assistant, Siri, will now be provided by Google rather than Bing. This interesting development encompasses two of the most important areas of modern search marketing: voice search and mobile. As such, SEOs will be paying close attention to how this might affect their strategies and their reporting.

The launch of the latest version of Apple’s Safari browser also brought with it controversial updates that could significantly impact the digital media industry. By introducing stringent new measures that will prevent third-party cookies from tracking Safari users for more than 24 hours, Apple has made a clear statement about the importance of consumer privacy.

Equally, it has forced some advertisers to rethink their approaches to tracking — and reporting on — digital marketing campaigns. Given the prominent positions of voice search, mobile SEO and data privacy in many industry discussions today, it would be fair to say that Apple has taken a stance.

Apple moves Siri searches to Google

Google has been selected as the default provider of search results via Apple’s voice-enabled digital assistant, Siri, although image search results will still be powered by Bing.

With voice search now accounting for over 20 percent of searches (a number that will likely increase dramatically in the near future), this move will undoubtedly bring a sizable number of queries to Google. Apple’s stated reason for switching is that it will provide a “consistent web search experience” for consumers alongside Safari results, which are already provided by Google by default. Bing and Google process queries and rank organic search results using different algorithms, so we should expect that the answers provided by Siri will change as a part of this development.

If Siri’s answer does not respond adequately to the query, Apple device users will now be sent through to a Google search results page to browse other links. Once a user clicks through to a Google results page, the data can be processed and shared as it would via any other Google SERP. While Google does not share its keyword-level organic search data with site owners, this will still provide welcome insight into other areas of the SEO traffic that brands receive via Google.

How does this affect search marketers?

There will, of course, be an inverse correlation between the number of Google searches and the number of Bing searches that marketers see in their reports, to a greater or lesser degree depending on how much of their audience uses Siri. For paid search, this may mean a re-evaluation of budgets for both Google and Bing. For organic search, the focus should be on providing the most relevant answer to a query, to increase the likelihood that Siri will select your content.

Although this could be seen to represent a seismic shift in how organic search marketers optimize for Siri, the reality is that the core principles of voice search and mobile SEO remain constant:

Micro-moments — revealed in I-want-to-do or I-want-to-go queries, for example — are vitally important.Optimize for longer, natural language queries, as consumers are more likely to search in this manner via voice than via text.Speed is of the essence; mobile users expect content to load quickly, so marketers need to incorporate this as an essential strategic consideration.Hyperlocal searches, driven by implicit location-based intent, are on the rise as consumers come to grips with the capabilities of their mobile devices.Constantly refine the approach as more data becomes available. This is still a nascent area of search marketing, and we need to be prepared to adapt based on consumer feedback.

In fact, as SEOs and content marketers strive to answer the underlying intent of a query rather than simply responding to exact queries through keyword matching, we can safely say that the days of chasing the search algorithms are coming to an end. As a consequence, Apple’s move from Bing to Google for Siri results should not require much adjustment from a sophisticated SEO strategy.

Furthermore, while this is certainly not a positive move for Bing, Microsoft’s search engine does still retain an important share of the market that search professionals cannot afford to neglect.

As mentioned above, Apple’s principal reason for switching to Google was to bring results in line with its Safari browser, which has also been the recipient of some radical overhauls of late.

Safari updates

Apple has primarily updated its Safari web browser in ways that affect the capturing, processing and sharing of user data, with the ultimate aim of improving the user experience. The three most noteworthy changes for marketers are Intelligent Tracking Prevention, Autoplay Blocking and Reader Mode. You can read more about these specific changes here.

Safari accounts for a sizable portion of web traffic, with a 14.22 percent share of the global market and a 31.5 percent share of the US market. With Google planning its own measures to tackle invasive advertising practices in the upcoming Chrome browser update, it is becoming clear that both parties want to protect consumers from irrelevant content and intrusive advertising.

Consumers are increasingly in control of what they see online and how they see it. According to Google, a majority of search traffic worldwide now comes from mobile devices. Combined with the 40 percent of US consumers that have used an ad blocker, the picture becomes clearer still. Brands and publishers are all striving to provide the best possible experience, with a mobile-first slant on everything they do.

Apple’s focus on a fast, user-friendly experience certainly does not exist in a vacuum. Pervasive ads can contribute to longer page load speeds, which is to the detriment of Safari. Apple wants to attract as many users to its browser as possible; removing elements that only detract from the user experience seems a sensible way to achieve that.

Moreover, Apple is not the only company taking measures to this effect. For example, Google’s Accelerated Mobile Pages (AMP) initiative strips back HTML into leaner source code that can be displayed faster, with an increasing amount of SEO-driven content now created for this standard.

Where Safari will not block ads, Google may go one step further with its upcoming Chrome update. Due for launch early next year, the latest Chrome has included an ad blocker in some early tests. We are therefore beginning to see browsers act as intermediaries between websites and consumers, rather than conduits for information.

How should SEOs prepare for these changes?

Apple’s recent updates serve to further consolidate the position of mobile SEO as the cornerstone of organic search marketing today. All of the recent changes have been driven by a desire to improve the consumer experience by delivering the fast, seamless loading of content. Moreover, Apple is at pains to ensure that this is content its customers actually want to see and engage with.

This will not sound revolutionary to many SEOs, who will by now be very familiar with these concepts. However, we should be cognizant of the fact that SEO affects many other marketing disciplines and understand that our work is pivotal as brands adapt to this new landscape.

Those that embrace this new ecosystem — where consumers are increasingly in control and the onus is on brands and advertisers to create experiences that draw engagement — will reap the very significant rewards. We have been taught many lessons and had to adapt to many trends over the past few years in SEO, through the many transitions the industry has seen. The focus on creating genuine connections through data-driven content is one that may soon apply to many other areas of digital marketing.

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

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.

19 technical SEO facts for beginners

Technical SEO is an awesome field. There are so many little nuances to it that make it exciting, and its practitioners are required to have excellent problem-solving and critical thinking skills.

In this article, I cover some fun technical SEO facts. While they might not impress your date at a dinner party, they will beef up your technical SEO knowledge — and they could help you in making your website rank better in search results.

Let’s dive into the list.

1. Page speed matters

Most think of slow load times as a nuisance for users, but its consequences go further than that. Page speed has long been a search ranking factor, and Google has even said that it may soon use mobile page speed as a factor in mobile search rankings. (Of course, your audience will appreciate faster page load times, too.)

Many have used Google’s PageSpeed Insights tool to get an analysis of their site speed and recommendations for improvement. For those looking to improve mobile site performance specifically, Google has a new page speed tool out that is mobile-focused. This tool will check the page load time, test your mobile site on a 3G connection, evaluate mobile usability and more.

2. Robots.txt files are case-sensitive and must be placed in a site’s main directory

The file must be named in all lower case (robots.txt) in order to be recognized. Additionally, crawlers only look in one place when they search for a robots.txt file: the site’s main directory. If they don’t find it there, oftentimes they’ll simply continue to crawl, assuming there is no such file.

3. Crawlers can’t always access infinite scroll

And if crawlers can’t access it, the page may not rank.

When using infinite scroll for your site, make sure that there is a paginated series of pages in addition to the one long scroll. Make sure you implement replaceState/pushState on the infinite scroll page. This is a fun little optimization that most web developers are not aware of, so make sure to check your infinite scroll for  rel=”next” and rel=”prev in the code.

4. Google doesn’t care how you structure your sitemap

As long as it’s XML, you can structure your sitemap however you’d like — category breakdown and overall structure is up to you and won’t affect how Google crawls your site.

5. The noarchive tag will not hurt your Google rankings

This tag will keep Google from showing the cached version of a page in its search results, but it won’t negatively affect that page’s overall ranking.

6. Google usually crawls your home page first

It’s not a rule, but generally speaking, Google usually finds the home page first. An exception would be if there are a large number of links to a specific page within your site.

No, but that's commonly the first page we find from a site.

— John ☆.o(≧▽≦)o.☆ (@JohnMu) August 24, 2017

7. Google scores internal and external links differently

A link to your content or website from a third-party site is weighted differently than a link from your own site.

8. You can check your crawl budget in Google Search Console

Your crawl budget is the number of pages that search engines can and want to crawl in a given amount of time. You can get an idea of yours in your Search Console. From there, you can try to increase it if necessary.

9. Disallowing pages with no SEO value will improve your crawl budget

Pages that aren’t essential to your SEO efforts often include privacy policies, expired promotions or terms and conditions.

My rule is that if the page is not meant to rank, and it does not have 100 percent unique quality content, block it.

10. There is a lot to know about sitemaps

XML sitemaps must be UTF-8 encoded.They cannot include session IDs from URLs.They must be less than 50,000 URLs and no larger than 50 MB.A sitemap index file is recommended instead of multiple sitemap submissions.You may use different sitemaps for different media types: Video, Images and News.

11. You can check how Google’s mobile crawler ‘sees’ pages of your website

With Google migrating to a mobile-first index, it’s more important than ever to make sure your pages perform well on mobile devices.

Use Google Console’s Mobile Usability report to find specific pages on your site that may have issues with usability on mobile devices. You can also try the mobile-friendly test.

12. Half of page one Google results are now HTTPS

Website security is becoming increasingly important. In addition to the ranking boost given to secure sites, Chrome is now issuing warnings to users when they encounter sites with forms that are not secure. And it looks like webmasters have responded to these updates: According to Moz, over half of websites on page one of search results are HTTPS.

13. Try to keep your page load time to 2 to 3 seconds

Google Webmaster Trends Analyst John Mueller recommends a load time of two to three seconds (though a longer one won’t necessarily affect your rankings).

14. Robots.txt directives do not stop your website from ranking in Google (completely)

There is a lot of confusion over the “Disallow” directive in your robots.txt file. Your robots.txt file simply tells Google not to crawl the disallowed pages/folders/parameters specified, but that doesn’t mean these pages won’t be indexed. From Google’s Search Console Help documentation:

You should not use robots.txt as a means to hide your web pages from Google Search results. This is because other pages might point to your page, and your page could get indexed that way, avoiding the robots.txt file. If you want to block your page from search results, use another method such as password protection or noindex tags or directives.

15. You can add canonical from new domains to your main domain

This allows you to keep the value of the old domain while using a newer domain name in marketing materials and other places.

16. Google recommends keeping redirects in place for at least one year

Because it can take months for Google to recognize that a site has moved, Google representative John Mueller has recommended keeping 301 redirects live and in place for at least a year.

Personally, for important pages — say, a page with rankings, links and good authority redirecting to another important page — I recommend you never get rid of redirects.

17. You can control your search box in Google

Google may sometimes include a search box with your listing. This search box is powered by Google Search and works to show users relevant content within your site.

If desired, you can choose to power this search box with your own search engine, or you can include results from your mobile app. You can also disable the search box in Google using the nositelinkssearchbox meta tag.

18. You can enable the ‘notranslate’ tag to prevent translation in search

The “notranslate” meta tag tells Google that they should not provide a translation for this page for different language versions of Google search. This is a good option if you are skeptical about Google’s ability to properly translate your content.

19. You can get your app into Google Search with Firebase app indexing

If you have an app that you have not yet indexed, now is the time. By using Firebase app indexing, you can enable results from your app to appear when someone who’s installed your app searches for a related keyword.

Staying up to date with technical SEO

If you would like to stay up to date with technical SEO, there are a few great places to do that.

First, I recommend you watch the videos Barry Schwartz does each week.Second, keep your eye on Search Engine Land.Third, jump on every blog post Google publishes on Google Webmaster Central.Finally, it is always a good idea to jump into a Google Webmaster hangout or simply watch the recording on YouTube.

I hope you enjoyed these 19 technical SEO facts. There are plenty more, but these are a few fun ones to chew on.

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

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.

Google releases a variety of Accelerated Mobile Pages Project (AMP) updates: scrolling animations, video analytics, fluid ad support

Yesterday, Google announced several Accelerated Mobile Pages Project (AMP), technical updates. These included scrolling animations, an improved responsive-navigation sidebar, support for video analytics, fluid ad support and other features to improve ad targeting.

Here’s a little more color on the list of new capabilities:

Scrolling animations: enables “parallax effects, subtle zoom or fade-in of images, and starting or stopping animations”
Responsive sidebar: “improvements to amp-sidebar enable changing display format based on the width of the viewport”
Native video analytics support in AMPImproved Client ID information to enable consistent ID recognition as users migrate between AMP and non-AMP pages Fluid-ad support for publishers: enables publishers to request ads where the ad size is unknown

The post that goes into more technical detail about each of these updates is here.

The open-source AMP project was announced by Google in 2015 to speed up the mobile web. Specifically, AMP was aimed at improving the rendering of content pages on mobile devices. Since that time, AMP has been greatly expanded to include ads and analytics. AMP for Ads (and landing pages) was introduced in mid-2016. Meanwhile, AMP-enabled content pages moved out of the “top stories” section — where news results are displayed — and into main search results in August of 2016.

AMP pages load roughly four times faster and use one-tenth the data of pages and objects not built in AMP, according to Google research. The company also says that AMP-powered mobile display ads load up to five seconds faster than traditional display ads. Many publishers on the DoubleClick exchange reported higher eCPMs on AMP pages as well.

The project is not without controversy, though, regarding the AMP URLs vs. publisher URLs. However, in iOS 11, Apple attempts to remedy that: Safari changes AMP URLs back to publisher URLs when shared.