Mobile SEO: How to Rank in Mobile Search, Following Google’s Mobile Update

Written by Emma Phillips on 28/01/2015. Posted in GOOGLE, SEO.

Google is widely expected to soon roll out a major update to its ranking algorithm that will impact results for searches carried out on mobile devices.

Edit: Google has now confirmed that a mobile ranking algorithm will roll out on the 21st April.

This guide will take you step by step, through all of the actions necessary to become fully compliant with all of Google’s Mobile SEO and Mobile Usability requirements.

According to Stat Counter, in December 2014, mobile searches accounted for 32% of all searches made globally.

This update is therefore likely to have a major impact on most websites and on the search engine landscape.

This guide will:

Explain how we know that this update is coming
Show you how to determine which mobile configuration your site uses
Show you how to ensure that your site allows Google to access your site and all the required resources for indexing
Show you how to signal your mobile configuration to Google so that it can understand your site structure
Show you how to identify and fix mobile usability issues
Show you how to identify and fix smartphone crawl errors

How do we know an Update is coming?

Edit: Google has now confirmed that a mobile ranking algorithm will roll out on the 21st April. Given then 8 week notice of this update, the impact is likely to be very significant.

First of all, Google has already announced those sites that have mobile configuration errors such as faulty redirects receive a demotion in mobile search results.

Towards the end of 2014, Google has invested considerable effort educating webmasters about mobile SEO and has produced a number of tools to help webmaster implement its requirements.

In October 2014, Google released the Mobile Usability reports in Webmaster Tools.

In November 2014, Google announced that mobile friendly sites would receive a mobile friendly label in search results and gave webmaster a mobile friendly testing tool.

In this announcement, Google stated:

We are also experimenting with using the mobile-friendly criteria as a ranking signal.

Furthermore, within Google’s Mobile Usability Guidelines it states:

Because global web traffic from mobile devices is on the rise, and recent studies show that mobile visitors are more likely to revisit mobile-friendly sites, mobile usability is now relevant for optimal search results

Most recently, since the 16^th January 2015, Google began sending out mass emails to webmasters informing them that they have mobile usability issues on their sites. Within these messages it states,

These pages will not be seen as mobile-friendly by Google Search and will therefore be displayed and ranked appropriately for smartphone users.

Google has stated several times that they are working on an update affecting mobile rankings so we know an update is likely. Recent activity from Google indicates that this update is due soon and the amount of effort Google has invested in educating webmasters suggests that the impact of this update is going to be significant.

Determine what type of mobile configuration your site uses

Determining the mobile configuration that your sites uses will allow you to identify the configuration specific requirements necessary to optimise your site for Google mobile searches.

Accepted Mobile Configurations

There are three mobile configurations recognised by Google:

Responsive Web Design
Dynamic Serving
Separate URLs

With responsive web design, the server sends the same HTML to all devices and CSS is used to alter the rendering of the page based on the device or screen size.

Dynamic serving is a setup where the server responds with different HTML (and CSS) on the same URL depending on the user agent requesting the page.

For the final configuration, each desktop URL has a corresponding URL serving mobile-optimized content. For example, the site example.com might have a corresponding m.example.com page for each of its desktop pages.

How to Identify Your Mobile Configuration

The best way to determine which configuration your site uses is to ask your developer.

Mobile web design however, lacks standard definitions for all of the different methods of creating mobile website.

As such, while your developer might think that you have a responsive site, it may in fact fall under Google’s definition of a dynamic serving configuration.

The question below will help you to determine which configuration your site uses as per Google’s definitions.

When resizing your desktop browser, does the layout of the page change?

Yes – Responsive web design (examples of sites using this configuration are currys.co.uk or hubspot.com)

No – Answer next question

When loaded on a mobile device, are you redirected to another URL e.g. m.example.com?

Yes – Separate URLs (an example of a site using this configuration is m.bbc.co.uk)

No – Answer the next question

When loaded on a mobile device, does the URL stay the same and is the page layout different to how it appears on the desktop?

Yes – Dynamic Serving (an example of a site using this configuration is amazon.co.uk)

Note: the first question should have already been answered by this point and as such, for it to be dynamic serving, the layout should not change when you resize your desktop browser.

No – your site is not configured for mobile devices. In order to be able to rank well in mobile search and to provide a good user experience, you will need to implement one of the mobile friendly configurations shown above

You may find Google’s white paper for sites deciding to go mobile friendly for the first time useful as it provides pros and cons of each configuration.

If you use a content management system, you may be able to go mobile friendly simply by updating to the latest version of your CMS or theme. Google has provided a guide of how to do this safely for many of the more popular CMS’ which you can find here.

Check that all of Google’s bots can access your site and that you are not restricting key resources

Google will not be able to access, and therefore index your site, if:

It cannot connect to your domain name server, i.e. the server is down or there is an issue with the DNS routing to your domain name
It is unable to connect to the server that hosts your website, i.e. it is too slow to respond, or because your site is blocking Google
You have errors with your robots.txt file, i.e. you are blocking your entire site from being crawled, you are blocking certain user-agents from accessing your site, or if your robots.txt file is unreachable due to it producing a status code other than 200 or 404

Since May 2014, Google’s indexing system renders web pages more like a typical modern browser. Therefore, in order for Google to be able to optimally render and index web content, it must be able to access the site’s web assets, namely, the site’s CSS, JavaScript and image files. This requirement is not explicitly stated in Google’s updated technical Webmaster Guidelines.

Furthermore, all of Google’s bots must be able to access your site and these resources. If you use the separate URL configuration, all of Google’s bots must be able to access both the mobile and desktop versions of your site, as well as these resources on each version.

Check that Google can access your site

If you have any issue preventing Google from accessing your site, this will be displayed in the first panel of your site dashboard in Webmaster Tools.

If Google suddenly encounters any major site errors that are preventing it from accessing your site, it will notify you via a direct message in Webmaster Tools.

Diagnose and Fix Site Errors

If there are any issues shown in Webmaster Tools, go to Crawl > Crawl Errors, and under the Site Errors heading you will see more details on what is causing these issues.

Any issues found here need to be addressed. While Google does provide some basic information on how to fix these issues, it is only if you receive a notification of a severe issue that they will provide you more detailed instructions.

For your reference, you can find copies of these instructions using the links below.
[sociallocker id=”4254″]

[/sociallocker]
Update these links to point to the image files saved on the server when the post goes live and embedded within social locker.

Check that All Googlebots can Access Your Site and that Key Resources Are Not Being Blocked

You now want to check that all of Google’s bots can access your site and that any images, CSS and JavaScript are not being blocked for any user agent.

In Webmaster Tools, navigate to Crawl > Fetch as Google

Within this tool you will be able to fetch as Google using a number of Google’s user agents

Fetch and render a sample of pages using both the Desktop and Mobile: Smartphone Option. The sample that you use will depend on the site but an example of the pages you might want to fetch is the homepage, a category page and a product page.

Resolve Accessing, and Fetch and Render Issues

Any issues that you find will need to be resolved for both user agents. A list of issues that may be returned, and the actions necessary to fix these issues, can be found here.

In particular, you want to make sure that Google can access these pages, and that you are not restricting Google from accessing any resources (CSS, JavaScript, images).

In some instances, blocked resources will reside on another domain. Where possible this should be avoided but it is common to see things such as Google fonts being blocked and this is not an issue.

Signalling Your Mobile Configuration to Google

This section details the signals necessary for Google to understand your mobile set up. This section is laid out so that for each configuration, the requirements for the previous configurations should also be adhered to.

All configurations – Viewports

Pages optimised for mobile devices must include a meta viewport element in the head of the document.

This element should therefore be used on responsive and dynamics webpages and for mobile specific pages of sites using the separate URL structure.

The meta viewport tag gives the browser instructions on how to adjust the dimensions and scaling of a page to the width of the device. When the meta viewport element is absent, mobile browsers default to rendering the page at a desktop screen width (usually about 980px, though this varies across devices).

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Below is a screen shot of the source code for currys.co.uk which has correctly implemented this meta tag.

Without the viewport tag, a mobile browser will typically render a page at desktop screen width (usually 980px) and then attempt to make it look better. For users, this often means that they have to double-tap or pinch-to-zoom in order to be able to see or interact with the content. The width=device-width part of this tag instructs the page to match the screen’s width. The initial-scale=1 part, allows the page to resize when a mobile device is turned landscape.

Responsive Web Design

For this configuration, as long as all of the previous steps have been taken, there are no additional signals that Google requires to understand this configuration. However, for clarity the requirements for this configuration are listed below:

Allow all of Google’s bots to crawl the site
All access to CSS, JavaScript and image files
Ensure that every page employs the viewport meta tag

Google’s support pages for correctly signalling this configuration can be found here.

Dynamic Serving

Vary HTTP Header

When employing dynamic serving, the vary HTTP header is required on every page dynamically served, to show that depending on who accesses the page, the content provided will change. The reason that this is necessary is that a webpage’s content is often cached in various places such as CDNs, ISPs, web browsers and Google’s own index. Due to this, when a request is made for one of your webpages, components or even your entire page may be delivered without it being requested from your server. With the vary http header, browsers and Google will understand that the content will vary dependent on the user agent that requests it. This means that Google is able to correctly understand your content and therefore rank each version of your page separately for desktop and mobile searches. The vary HTTP header necessary is:

Vary: User-Agent

For example, the header for amazon.co.uk contains “vary: user-agent”.

You can check the header of a webpage using a tool such as SEO Book’s Server Header Checker.

Correctly Detect User-Agents

Detecting user agents can often results in errors, as all browsers do not indicate that they are running on a mobile device in the same way. Things to avoid whilst identifying the user agent are

Detecting the user agent depending on a list of user-agents as this will require constant maintenance and updating
Mismatching a user agent and therefore returning the wrong version of the page. A common mistake is to send tablet users to the mobile version of the page rather than the desktop
Specifically identifying Googlebot. Googlebot user agents identify themselves as mobile specific devices so should be treated in the same way that you would these devices. Specifically identifying Google can be classed as cloaking, which is against Google Quality Guidelines

While user detection can be challenging, Mozilla recommends looking for the string “Mobi” anywhere in the user agent to identify mobile users. At the time of writing this, this method appears to work for all major mobile browsers.

Along with vary HTTP header, all other previous requirements should be met. For clarity the requirements for this configuration are listed below:

Allow all of Google’s bots to crawl the site
All access to CSS, JavaScript and image files
Ensure that every page employs the viewport meta tag
Ensure every page employs the vary HTTP header
Detect mobile users via their user agent and treat Googlebot just like any other user

Google’s support pages for correctly signalling this configuration can be found here.

Separate URLs

The separate URLs structure is the most complicated and technically demanding mobile configuration. Without the correct signalling in place, Google will not be able to understand that your mobile pages are different versions of your desktop pages. This can result in duplication issues and your mobile and desktop pages competing with each other in search results.

Annotations

To indicate to Google that you have two different URLs – one for mobile and one for desktop – you will need to annotate the head of your pages to show the relationship between these pages and when it is appropriate to use each version.

To do this, the following is required:

On the desktop page, add a rel=”alternate” tag pointing to the corresponding mobile URL.
On the mobile page, add a rel=”canonical” tag pointing to the corresponding desktop URL.

So for example,

Desktop page:

<link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.example.com/page-1" >

Mobile Page:

<link rel="canonical" href="http://www.example.com/page-1" >

Below you can see how this method is implemented on airbnb.co.uk

In this example, the annotation to the desktop pages informs Google that there is an alternative version of this page, that will be returned when a user’s screen is less than 640px wide, and it provides the URL of that alternative page.

The mobile annotation tells Google that there is a master version of the mobile page and where it can be found. With the mobile version correctly canonical-ing to the desktop page, any issues of duplication are removed and all ranking signals are consolidated.

Sitemap Mehtod

It is also possible for the rel=”alternative” annotation to be contained within a site’s XML sitemap rather than the head of the page. The rel=”canonical” part however, must still be present on the mobile URLs.

While this method is supported by Google, it is not recommended as it is much easier to identify any issues with your setup when the annotation is contained within the head of the page.

Below you can see how a sitemap should be structured to include this annotation.

<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"

xmlns:xhtml="http://www.w3.org/1999/xhtml">

<url>

<loc>http://www.example.com/page-1/</loc>

<xhtml:link

rel="alternate"

media="only screen and (max-width: 640px)"

href="http://m.example.com/page-1" />

</url>

</urlset>

Automatic redirects

When using this configuration, you will typically want to automatically redirect users to the URL that best serves them.

Some website will only redirect mobile users visiting a desktop page to the mobile page (“unidirectional” redirects), whilst others redirect both mobile and desktop users to the respective mobile or desktop page (“bidirectional” redirects).

Either method is fine but it is recommended, although it is not a strict requirement, that users are given a way to override the redirect if they should choose to do so, e.g. through a link in the footer.

You should also ensure that the redirects are consistent with your rel=”alternate” and rel=”canonical” annotations.
If your website uses automatic redirects, it is essential that you treat all of Google’s bots just like any other user-agent and redirect it appropriately.

Since the automatic redirects should treat Googlebot the same as any other user, it is recommended that the redirects be triggered by the user-agent. Details on detecting can be found in the previous, Correctly Detect User-Agents section.

If a page on your site does not have a mobile equivalent, you should keep users on the desktop page rather than redirecting them to any other mobile page.

Setting up Automatic redirects

The only methods for automatic redirection supported by Google are:

HTTP redirects
JavaScript redirects

HTTP redirects

It is recommended that the server redirects with a 302 status code where possible but a 301 is also acceptable.

JavaScript Redirects

If HTTP redirection is difficult to implement, you can use JavaScript to redirect users to the correct URL. If you choose to use this technique however, be aware that this will result in additional load times as the page will need to be downloaded, parsed and the JavaScript executed, before the redirect is triggered.

Along with the annotations and automatic redirects, all other previous requirements should be met. For clarity the requirements for this configuration are listed below:

Allow all of Google’s bots to crawl the site
All access to CSS, JavaScript and image files
Ensure that mobile page employs the viewport meta tag
Ensure every page employs the vary HTTP header
Detect mobile users via their user agent and treat Googlebot just like any other user
Signal the relationship between two URLs using the rel=”canonical” and rel=”alternate” elements.
Ensure that that automatic redirects are consistent with your annotations
Ensure that automatic redirects treat all of Google’s bots just like any other user-agent

Google’s support pages on correctly signalling a separate URL configuration can be found here.

Check and Fix Mobile Usability Issues

The next step is to check for mobile usability issues. To do this, in Webmaster Tools, navigate to Search Traffic > Mobile Usability.

This will show a report on all of the pages crawled by Google that have mobile usability issues, along with the specific issue for each page.

There are a number of issues that this report will highlight.

Viewport not configured
Fixed-width viewport
Content not sized to viewport
Small font size
Touch elements too close
Flash usage

As this report is based on the data obtained when Google crawls your website, there will be some lag between when you fix an issue and this report updating. You should therefore use Google’s Mobile Friendly Test to confirm that you have correctly fixed the issue.

As well as the information provided below, Google’s guidelines on fixing these issues can be found here.

Viewport Not Configured and Fixed-Width Viewport

Both of these issues are resolved by correctly implementing the viewport meta tag. This has been covered in the first part of the Signalling your Mobile Configuration section of this guide, so be sure to review that section if you have any issues related to these problems.

Content Not Sized to Viewport

This error indicates that there are pages of your website where there is content larger than the viewport. This means that mobile users have to scroll horizontally to see this content. To remedy this issue, when styling your page, use relative positioning and width values rather than absolute values.

Small Font Size

This error shows pages where the text on a page is too small to be legible and the user would therefore have to pinch to zoom to be able to read it.

Google recommends that in order to maintain legible text you should:

Use a baseline font size of 16px (this may need to be adjusted to account for the specific font being used)
Size all text relative to this baseline
Use a line-height of 1.2em to add spacing between each line of text (this may need to be adjusted to account for the specific font being used)
Restrict the number of fonts and the size of fonts to avoid a messy and complicated layout

Below we can see an example of how this is implemented:

body{font-size:16px; line-height:1.2em;}
p{font-size:120%;}
h1{font-size:250%;}
h2{font-size:200%;}

In this example, the font size, 16px is applied to the entire page as a baseline. All other text elements are sized relative to this baseline. This ensures that regardless of the size of the screen, the font size relationship is always maintained.

The required line height of 1.2ems has also been set so that there is sufficient spacing between each line of text so that it is easier to read.

Please note that this is just an example to illustrate Google’s recommendations in the strictest sense and, as such, this styling is most likely not appropriate for your site.

Touch Elements Too Close

This error occurs when links and buttons are so close to each other, that on a mobile device, a user might struggle to tap one element without tapping another. For touch elements such as menus and buttons, Google recommends that they should be at least 48px (7mm) tall and wide. For links within text, if you follow Google’s recommendations for font size (outlined above) your links should be fine.

Now, it is not always possible to make touch elements 48px wide and as such, if an element is less than 48px, Google recommends that there should be at least 32px space between touch elements. More often than not, this error is caused by touch elements being too close together rather than the element itself being too small.

Flash Usage

Flash-based content cannot be rendered on most mobile browsers. As such, any content, navigation or animations on your site that uses flash will not be displayed to mobile visitors. Flash should therefore not be used where possible. Instead, more modern web technologies such as CSS and JavaScript should be used.

Mobile Crawl Errors

Mobile optimised websites are often misconfigured so that the site will result in searchers not being displayed the content that they were looking for. Google identifies many of these issues and displays them as Smartphone crawl errors in Webmaster Tools.

To identify these issues, in Webmaster Tools go to Crawl > Crawl Errors and select the smartphone tab.

Details of how to address these issues are given below.

Server Errors

A smartphone server error is when mobile Googlebot receives a 500 status code when it crawls a page. While Google does provide some very basic information on how to fix these issues, it is only if you receive a notification of severe issue that they will provide you with more detailed instructions. For your reference, you can find screen shots of these actions using the links below.
[sociallocker id=”4254″]

[/sociallocker]

Not Found and Soft 404 Errors

This error is primarily for sites using dynamic serving or separate URLs to deliver mobile content, as pages using responsive web design, a 404 or soft 404 are not unique to mobile users. To fix these types of issues:

Ensure your user-agent detection is correctly configured. See the Correctly Detect User-Agents section for more details.
If you use mobile specific URLs, ensure that it redirects mobile users to the correct equivalent URL on your mobile site.
If a page on your site does not have a smartphone equivalent, keep users on the desktop page rather than redirecting them to any other mobile URL.

Faulty Redirects

This crawl error is only relevant to sites using the separate URL configuration and is a result of not redirecting mobile users to the correct mobile URL. Common causes of this error are:

Redirecting mobile users to the mobile homepages regardless of which URL they requested
Your desktop page URL contains parameters that do not map well to an equivalent mobile page.
Your redirects are only redirecting some mobile devices but not others, i.e. android phones but not iPhone.

To resolve these issues ensure that:

Mobile users are redirected to the correct equivalent mobile URL.
If an equivalent URL does not exist, keep users on the desktop page rather than redirecting them to any other mobile page.
Ensure your user-agent detection is correctly configured. See the Correctly Detect User-Agents section for further details.

Blocked URLs

This error occurs when you block the mobile Googlebot from accessing your site via your robots.txt file. To resolve this issue you will need to modify your robots.txt file to allow Smartphone Googlebot access to your site. This may not be a smartphone specific error, so whilst checking your robots.txt file, ensure that all of Google’s bots can access your site. There are times when you may want to block Google from specific sections of your site, so carry out this action bearing that in mind.

Other considerations

As well as all of the major requirements outlined in this guide, there are several other considerations you should be aware of.

Avoid content that is unplayable on mobile devices
Make sure your mobile site loads quickly to avoid frustrated users (Google Page Speed Tool)
Avoid irrelevant cross-links – When providing a link to your desktop version on a mobile page, or vice versa, ensure that the crosslink is for the equivalent page and not any other page such as the homepage
Ensure that internal links remain consistent to their device specific versions to prevent unnecessary redirects, e.g. the navigation links on your mobile site should link to your mobile pages and not your desktop pages

Still confused?

While we have gone to great lengths to provide you with as much information as we can on optimising your site for mobile devices, mobile SEO is a very technically demanding undertaking.

WMG has helped numerous sites and businesses integrate mobile into their online strategy. Our team of technical consultants can assist you with:

Meeting all of Google’s technical requirements so that you rank in mobile search
Selecting the best mobile configuration to meet your business needs
Improving your mobile experience to increase conversions
Redesigning your websites for the mobile user

Check out our mobile SEO services page and let us help you take your business mobile!