Epic Mobile SEO Guide for Google's mobile-first index

Deliberate Digital's Epic Mobile SEO Guide

Google announced it’s moving to a mobile-first index back in November 2016. This guide covers a lot of ground about what this means and what you can do to prepare for this shift to a mobile-first world. As is the case with all such guides, it can only offer you a generic starting point, and you need to apply what you learn to your business.

If you need help or have questions, please get in touch.

Note this guide is based on the talk I gave at Search London in January 2017.

What’s all this fuss about?

Googlebot user-agent switch illustration

Googlebot uses several user-agent strings to crawl the web. The key user-agent that was historically used for indexing is the one that did not specify a device, meaning it got content usually designed for desktops. In contrast, another user-agent string used by Googlebot says it’s an Android phone, and that has been used to index mobile` content.

The change is that Google will start using the content fetched using the smartphone Googlebot for indexing, not the “desktop” one.

Simple change with huge implications.

Why make this change?

With more than half of Google searches happening from mobile devices, Google is updating its indexing pipeline to use the content crawled with the mobile Googlebot. Makes sense to serve the most common use case.

This has been coming for a long time. Most websites see a large portion of their traffic from mobiles, and many have well over 50% mobile traffic. For well-operated websites, this trend is also reflected in conversion volume/revenue. Many of my clients are seeing this.

What does this mean?

Looking at this broadly, the change in the user agent string means that the content, metadata, structured data, etc, were all indexed as desktop devices received them but now will be how mobile devices receive them.

This is why there is a lot of interest from businesses and SEOs. Historically, mobile content did not receive as much attention as desktop content did. You need to review your mobile content much more carefully now in terms of user experience, and update it as needed in terms of technical SEO. I’ll now show you how.

Let’s go mobile, for real this time, OK?

This is an opportunity to not focus on just SEO, but expand your thinking to the whole customer experience in a mobile-first world.

To do this right, you need to think about two things:

  1. Customer experience
  2. Technology, both for serving and specifically for SEO

Customer experience

We start with the user, as we should, and realize that now your front door via Google is your mobile site.

My approach is to aim for equivalence, not equality, between the mobile content and desktop content. By that I mean we’re aiming for customers to be able to:

on mobile as well as they can on desktop. Why? A search engine’s role is to understand a user’s query to derive its intent, and match the intent to documents in its index. That’s why it’s critical to understand your customers at each step in customer journeys.

Many businesses skip this step, but it’s critical to get right, and now is a good opportunity to do it.

Why not equality? Mobile devices are fundamentally different devices from desktops, and we’re not actually aiming at congruence across devices. I want you to stop thinking about building mobile sites as a checklist based on your desktop sites.

Design new customer experience journeys from scratch if needed, one built for the smaller form factor, the wider range of sensors, and one that works in a much larger range of user contexts. This is fundamentally product management, not SEO or marketing or whatever, and it’s the core of what I help my clients with. It’s the correct foundation that leads to better rankings, higher conversions, better customer retention, better usability, and all that good stuff.

And because mobiles can offer a richer experience than desktops (yes they can), not only can you reach customer experience equivalence easily, you should use all the extras available to you.

Technology

We’ll break this into two parts, general technical considerations and specifics for Google.

Looking at the general considerations, there are a few important categories:

Accessibility

Users interact with the content primarily by touch on a small screen, but possibly using voice. Also, the content will be consumed in a larger range of lighting conditions that are not directly under the user’s control, unlike a desktop or laptop. This means you really need to think hard and test the accessibility of your site’s contents.

Content discoverability and interactions

Related to accessibility, your design should help users discover and interact with the content, both content to be passively consumed (read, watched, listened to) and interactive elements like forms.

Use form autofill where it makes sense, as autofill invariably improve form filling rates (i.e. conversions!) massively. Check out this animation from Google about how quickly - instantaneously! - a user fills out a form:

Form autofill on Chrome mobile

Use the device sensors where it makes sense to minimize user input; for example, ask for GPS location permission (in addition to allowing the user to enter their location manually) to save on typing. Specifically for location, think about building a customer experience that caters to the growing “near me” category of searches.

Handle network connection variability

Unlike desktops that are online consistently, mobiles move into weak coverage/slow network areas, and possibly be completely offline. Try to handle the situation where some/all page resources (CSS, JS, images) do not load, and try to handle the offline use case gracefully, or at least think about it.

For both of these, service workers are your new best friend as they are very powerful and enable a lot of functionality and user experiences. You can think of them as a caching proxy specify to your website installed in the user’s browser. As they are a proxy, they can intercept any network request to your site, and they can cache it. This means they support the offline use-case natively, and so they allow your site/webapp to be installed on a user’s device. They also allow background sync with your servers, and also to receive push notifications for user engagement. Great stuff that rivals the best native apps can offer!

Service workers and what they enable

Loading speed

The content needs to load fast, with the goal of above-the-fold content loading in less than a second. That’s the baseline goal, and you need to use Google’s RAIL performance framework to work with the browser’s rendering engine for your content to render and animate smoothly without stutter.

RAIL performance framework. RAIL is an acronym for Response, Animation, Idle, Load.

RAIL is an acronym for Response, Animation, Idle, Load. It has two benefits as a framework:

Think about the battery

You can actually build a page that kills the device’s battery, but it’s extremely rare for web developers to think about this. Of course simple blog content won’t tax the device, but games, webapps, and the like need to be careful.

Google SEO for mobile-first indexing

There are a few things to think about depending on how your current website works.

No mobile site

Technically, you don’t have to do anything for Google. You’ll not rank as highly on mobile SERPs compared to desktop SERPs (non-mobile pages get a demotion signal in mobile ranking), but the reality is that this is a terrible situation to be in as a business. If you’re getting an increasing number of users via mobile devices, you’d do well to build a mobile site, most likely a responsive website.

Responsive website

If you have a good responsive site, you may not have much work to do. The key checks are:

Dynamic serving

Dynamic serving is when the same URL serves different page content (HTML) to different devices. The key checks are:

Separate mobile URLs

Typically, these are the m.example.com and mobile.example.com websites. The key checks are:

But you’re not done. If you’re currently using separate mobile URLs:

Image indexing

Indexed images can drive a lot of good quality traffic to a website. Although responsive images have been standard for a long time, we’re still awaiting real guidance from Google about the best way to handle images.

But what works now are two options for responsive images:

In both cases, the <img> tag’s src attribute is the image that gets indexed. The downside is that the responsive images HTML tells browsers about other images too, but Google doesn’t index these as of yet.

Here are examples for both:

<picture>
  <source media="(min-width: 40em)" srcset="large.jpg 1x, large-hd.jpg 2x">
  <source srcset="small.jpg 1x, small-hd.jpg 2x">
  <img src="default_what_google_will_index.jpg" alt="Useful alt attribute for users.">
</picture>

<img src="default_what_google_will_index.jpg"
     srcset="large.jpg 1024w, medium.jpg 640w, small.jpg 320w"
     sizes="(min-width: 36em) 33.3vw, 100vw"
     alt="Useful alt attribute for users">

Video indexing

This one is easy. Use a <video> element in HTML, and add structured data about video. Here is an example using schema.org markup in JSON-LD syntax:

<div>
    <h2>Video name</h2>
    <p>This video is about...</p>
    <div>Uploaded ...</div>
    <video controls>
        <source src="foo.mp4" type="video/mp4">
        <source src="foo.webm" type="video/webm">
        <p>Fallback message for browsers that do not support the video element.</p>
    </video>
</div>
<script type="application/ld+json">
{
    "@context": "http://schema.org/",
    "@type": "VideoObject",
    "name": "Video name",
    "uploadDate": "2013-11-28",
    "description": "This video is about...",
    "contentURL": "https://example.com/videos/foo.mp4",
    "thumbnailUrl": "https://example.com/images/video_thumbnail.jpg"
}
</script>

Snippets and voice search

Voice search is growing very fast because it’s so convenient for users in so many different contexts. As a business owner, this is a wonderful opportunity to rank better and be seen as a thought leader.

How? Using featured snippets.

A Google featured example

A featured snippet is some text, list, or table that Google shows at the top of the search results as a direct answer to some queries. They are just longer snippets from the pages it ranks in the top 20, pushing this snippet above position 1. Not just that, the Google apps read out the snippet text, starting with “According to …”. That is, Google’s app speaks to the user your website or business name.

The other type of snippet to optimize for is structured snippets. These are tabular snippets about specific aspects or facets related to the user’s search.

A Google featured example

This has two benefits for the page that gets it:

As a business, you need to work hard to maximize the chances of your content being picked for featured snippets and structured snippets. How you go about doing that really depends on the type of queries that your customers care about and what you can answer. Helping Google’s algos extract high-quality snippet can be quite a bit of work, but it’s worth it.

Wrapping up

This guide is just a starting point. Clearly the devil is in the details, and you have to carefully think through every aspect of your site to make sure you don’t miss out when the mobile-first index launches.

You don’t have to do this alone! If you need any help, please email me.