Digital marketing consultants view analytics data from many websites in various industries. It is rare that we don’t see at least 30% of all traffic coming from mobile devices, and usually it’s closer to 50%. Some Marketing Directors have realized the opportunity of improving conversion rates for half of their visitors with easy wins like customized mobile messaging. Others would be happy just having a site that looked good, and worked, on a mobile phone – no customized mobile conversion optimization strategy needed. Whatever your goals are for improving the mobile user’s experience on your site in 2015 and beyond, we hope this free mobile best practices guide helps ensure proper technical implementation of your strategy.

TL;DR – Executive Summary

Inflow’s policy on mobile sites is illustrated with the image below, which is aligned with Google’s recommendations as of January 2015:

GoInflow.com Mobile Best Practices

Most sites will be advised to use a simple responsive design (left). Although dynamically adjusting content (center two boxes) could potentially provide a better mobile user experience, implementation is much more difficult/expensive, and the Vary HTTP Header response can cause issues with content delivery networks (CDNs). Share this page with your development team to open dialogue and to ensure your mobile user strategy is implemented correctly from a technical standpoint. 

 

Rather Read This As A PDF?

Table of Contents (Skip To links)

Executive Summary

The best solution for most clients will be a responsive design that scales up and down gracefully for any device.

The downside to a responsive design site with a single code base is that mobile and desktop visitors don’t always want to see the same things, and the opportunity to specifically target one or the other is not being taken advantage of. This could keep the site from reaching optimal conversion rates for mobile visitors. The upside is that there is no need of either the Vary HTTP header response, or the Rel Alternate tag. There is also only one code-base.

In order to adjust messaging, calls-to-action and design features based on device type, clients can dynamically serve different HTML and/or CSS without changing the URL. This is what we are referring to as “dynamic serving.” The Vary HTTP header response must be in place for this option in order to avoid the slight risk of being penalized for “cloaking,” and so all caches of the page will use the correct (i.e. desktop) version.

When serving different HTML/CSS based on the user agent there are two options:

  • Use the existing responsive layout code base and “adapt” page elements (messaging, CTAs…) for mobile, typically with JavaScript.
  • Keep a separate code base for the mobile site so they are essentially two different websites that get served from the same URL.
    • The downside is additional upkeep for the second code base.
    • The upside is greater freedom to customize the mobile user experience.

 Aside from doing nothing or requiring an App download, the least preferable solution is to put the content on a different URL. However, many businesses find this is their only option due to technology and budgeting issues. As long as “rel alternate” and “rel canonical” tags are properly implemented, having a separate mobile site can be a valid option.

 Some automated SaaS and Plugin solutions are also discussed near the end of the guide. 

Each Mobile Site Option in Detail

At the very least, don't make them pinch!
At the very least, don’t make them pinch! Image source: Google Developers

Although the options below are prioritized, each situation will offer reasons to weigh the various pros and cons. In the sections below, each viable option is discussed in detail.

Option 1 – Responsive Website Design

This is what we are going to recommend, if at all possible, in most situations.

 Even when “selectively serving” content based on device type, it’s typically better to use the same HTML/CSS code base and dynamically serve the adapted content using JavaScript, as opposed to keeping a separate code base. All that is to say, you should start with a responsive website design in most circumstances. 

So, What is Responsive Design?

In a nutshell, it’s having a single page/URL that adjusts itself to the size of the user’s screen using a single HTML code base, but dynamically rendering according to the CSS rules set up for that screen size. Here are some examples of CSS coding (using media queries) to adjust the page styles by common devices (e.g. Smart Phones, Tablets).

Here’s how Google puts it: 

“Responsive web design is a technique to build web pages that alters how they look using CSS3 media queries. That is, there is one HTML code for the page regardless of the device accessing it, but its presentation changes using CSS media queries to specify which CSS rules apply for the browser displaying the page.”

“Using responsive web design has multiple advantages, including:
It keeps your desktop and mobile content on a single URL, which is easier for your users to interact with, share, and link to and for Google’s algorithms to assign the indexing properties to your content.”

“Google can discover your content more efficiently as we wouldn’t need to crawl a page with the different Googlebot user agents to retrieve and index all the content.” (Source)

Is it Difficult to Implement (i.e. Expensive)?

The short answer is: it depends.
Popular content management systems like WordPress will often support a variety of easy-to-implement responsive themes. Some sites may require significant changes/additions to the CSS file and minor layout changes. Other sites may require a complete redevelopment.

 What are the Pros and Cons of Responsive Design?

Responsive design offers several powerful benefits over some of the other options, and the few drawbacks can be mitigated with the use of JavaScript to customize the user’s experience without changing the URL or code base.

The Pros:

  1. Easier for your users to interact with your site from any device
    1. They will always be copying and pasting or “sharing” the same URL
    2. Their bookmarks work equally well on each of their devices
  2. One URL makes it easier for Google’s link algorithms to apply PageRank accordingly
  3. It provides better crawl efficiency so Google can crawl more of your site more often
  4. Developers only have to update one code base when changes are made to the site
  5. Unlike with other options, such as Adaptive Design/Selective Serving (next section), a simple responsive site does not need to change code based on user agents, and therefore is not prone to mistakes made with the Vary HTTP header, including CDN issues and perceived cloaking (discussed later).

 The Cons:

  1. Compared to the other two options, responsive sites offer less ability to customize the messaging and experience for mobile users. It is essentially a desktop site that can be viewed easily on a mobile device, as opposed to a site that is specifically developed with mobile users in mind.
    1. However, even when dynamically serving mobile-specific content (as in the “selective serving” model discussed below), it is helpful to start from the base of having a responsive design so this issue can be addressed in the future with less effort.
  2. Compared to a completely separate mobile site/section (as in Option 3 below) responsive sites offer less ability to customize which resources get loaded and what gets rendered. This results in slower page loads, especially when the user is not connected to Wi-Fi.

 Does this mean the only way to succeed in mobile SEO is to go the responsive route?

Absolutely not. Google says they do also support the dynamic serving method with either the same URL or a different URL. But if you do go those routes, Google is asking for some help in understanding the dynamic device specific HTML, which will be discussed in the following two sections.

Links to learn more about Responsive Design 

Option 2 – Dynamic Serving

A lot of terminology gets thrown around in different ways when speaking about this topic. For our purposes, “responsive” and “adaptive” design are to be thought of as separate-but-similar things that are not mutually exclusive. You can have adaptive features without a responsive design, or you can add adaptive features on top of a responsive design to dynamically add, remove or change page elements by user agent.

When it comes to your creative content (i.e. Content Marketing) it may help to start from the perspective of a mobile user and adapt that to desktop, rather than the other way around. Dr. Pete from Moz wrote about Google’s internal shift to a “mobile first” policy here. As Will Critchlow and Hanna Smith of Distilled put it:

“Don’t just build things differently – build different things.”

There are two primary ways of adapting the content and experience specifically for mobile users (as opposed to making one responsive page without changing the content) that do not require changing the URL. Penn State Industries (PSI), an eCommerce site on Miva Merchant, offers a unique example because they actually do both (1/1/2015).

PSI has a completely separate mobile version of the site on the same URL. However, they are also adapting the desktop page for tablet users. When someone navigates the site with a mouse on a desktop, they can hover over the top-level category to see the fly-out navigation of subcategories and related links. Clicking the top level category link (e.g. Pen Kits) from a desktop or laptop takes you to that category page. Tablet users don’t drag their fingers around the screen like a mouse, but rather “tap” the menu they want. Therefore, the link had to be removed from the main category page label so tablet users could tap it and see the full menu. 

The image below illustrates an “adaptive” feature without responsive design… 

Peen State Industries Adaptive Design Screenshot
Penn State Industries customizes a feature on the desktop page for tablet users, while also offering a separate site on the same URL for mobile users.

However, most mobile—and some tablet—users are going to see the mobile version of the PSI site, which looks completely different, although it appears on the same URL:

Penn State Industries Mobile Site Screenshot
Without sending you to another URL, the site looks completely different on an iPhone, suggesting a separate code base, as opposed to the adaptive (but not responsive) site they show to tablet users.

 

Orkin's pest section on mobile

Combining Adaptive and Responsive FTW?

Orkin.com is a great example of how adaptive features can be applied to a responsive site. It scales responsively for desktops, tablets and mobile phones, which allows them to serve content from the same URL and code base. The full desktop site displays close-up images of common pests (below). However, notice how on tablets and mobile devices (or if you reduce the size of your desktop window) the images of all of the pests have been removed in order to show more of them on a single screen (above/left).

Essentially, the moment you get beyond simply reordering and resizing page elements, and move into the realm of changing the content and messaging for mobile users, you have begun to bring adaptive features into your responsive design. Our in-house conversion rate experts agree that this is the best way to go if your business really wants to maximize conversions from mobile devices without keeping a separate mobile website. However, it is not without its risks and drawbacks, as will be explained in detail later.

Orkin's pest section on desktop
The full desktop version of Orkin.com includes images of each pest. Mobile versions remove them. This is one step beyond most simple “responsive” design implementations because the content changes, but does it need an HTTP Vary response?

 

The Vary HTTP Header

You must use the Vary HTTP header when dynamically adjusting the content for different users. It is not necessary for simple responsive design, but becomes necessary the moment content gets added, removed or changed by user-agent, cookie or referrer.

Orkin's HTTP Header Response
Orkin’s HTTP Header Vary Response is “Accept-Encoding,” suggesting this is a case of good responsive design as opposed to dynamic serving, which would require a “Vary: User-Agent” response.

 The Vary HTTP header has two important uses:
Vary User Agent HTTP Header Example

  1. It signals to caching servers to consider the user-agent when deciding whether to serve the page from cache or not. Without the Vary HTTP header, a cache may mistakenly serve mobile users the cache of the desktop HTML page, or vice versa.
  2. It helps Googlebot discover your mobile-optimized content faster, as a valid Vary HTTP header is one of the signals they may use to crawl URLs that serve mobile-optimized content.

 The Vary HTTP header is not a meta tag. The Vary response is located in the HTTP header (like 301 redirects), not in the HTML header (like rel canonical tags).

SEOBook has a good HTTP header checker tool that will allow you to see the header response of any URL. It’s best to check with two, so I usually run it through Web-Sniffer, too.

Option 2.1 – Responsive Code Base with Adaptive Logic Via JavaScript

Websites that are not yet responsive should be advised to go responsive first. Those that are already responsive may consider dynamically adjusting mobile users’ experiences with JavaScript or some other method to detect the user agent and adjust accordingly. However, it is not without risks and should only be done by companies who have the wherewithal to address them.

Is it Difficult to Implement (i.e. Expensive)?

The short answer is: yes.

Any time a site dynamically adjusts content by user agent the difficulty, expense and risks increase dramatically. That said, there is little difference between this and what many sites are already doing for conversion optimization testing.

What are the Pros and Cons of Dynamically Altering a Responsive Code Base?

Up until now, it may seem that this is the way to go. However, some very serious issues arise when dealing with content delivery networks while using the Vary HTTP header. This is why we will typically recommend a simple responsive site for most clients. 

The Pros:

  1. If things go awry, it’s easy enough to pull out the JavaScript and Vary response in order to default back to a simple responsive design.

The Cons:

  1. It’s easy to goof up user agent detection, as Google explains here. The dangers of getting this wrong include:
    1. A poor user experience for someone being served the wrong content
    2. A Google penalty for perceived cloaking
  2. When a content delivery network (CDN) sees a Vary response in the HTTP header, they may choose not to serve the cached version of the page, which essentially renders the CDN useless. You can’t just turn off the CDN on enterprise sites, so how do you get around this? Here are some options:
    1. Give it Up. Don’t dynamically serve content. Instead, choose one of the other options discussed in this document.
    2. Take a Risk. Skipping the Vary header altogether carries a slight risk of being perceived as cloaking, but the main drawback of not including the “user-agent” attribute in the Vary header is just the lost opportunity of not sending all possible mobile ranking signals Google, and possibly showing the wrong cached version to a user.
    3. Scale it Down. Vary headers are controlled by the server, and are sent with each element of the page that is requested. Therefore, you could forgo the Vary response on the HTML page, but add it to the HTTP header for external resources (e.g. Images, CSS, Videos, JavaScripts). As Cindy Krum reports, this “is only a good idea if there are a very low number of elements that must come directly from your server—and you should still test to see the impact before site-wide deployment.
    4. Call your CDN representative. See if they have a work-around. Someone from Akamai has written in a Google Group that, but Cindy Krum wrote on SEL that she wasn’t having much luck with it. 

Option 2.2 – Separate Code Base (e.g. PennStateInd.com mobile site)

This is similar to having a completely separate mobile site, with the notable exception that both are served from the same URLs.

Is it Difficult to Implement (i.e. Expensive)?

The short answer is: yes.

 You are essentially operating two websites here, in addition to dealing with several tricky technical issues.

What are the Pros & Cons of Dynamically Switching the Code by User Agent?

This solution has all of the difficulties presented by dynamically altering content from the same HTML/CSS code base, with the added difficulty of maintaining two separate sites.

 The Pros: 

  1. Maximum ability to customize the mobile user experience without sending them to a different URL.
    1. This is a good solution for businesses with experienced in-house developers and a strong budget who want to maximize conversions from mobile traffic, while maintaining a consistent buyer’s journey from the same URL.

 The Cons:

  1. See the cons from Option 2.1 above (Responsive Code Base with Adaptive Logic).
  2. Requires maintaining of two separate code-bases (websites).

Links to learn more about Dynamic Serving 

Dynamic Serving Configuration – Google Developers
Mobile Site Configuration & The Vary HTTP Header – Search Engine Land
How Google’s Mobile Best Practices Can Slow Your Site Down – Search Engine Watch
CDN Caching Problems – The “Vary: User-Agent” Header – ./orcaman

Option 3 – Separate Mobile Site URL

 

Two Separate URLs for Desktop and Mobile
Image Source: https://developers.google.com/webmasters/mobile-sites/mobile-seo/configurations/separate-urls

Technically, there are at least three ways to have a mobile site on separate URLs: A mobile directory, mobile subdomain or a separate top-level domain (TLD). Until someone gives us a good reason not to, we’ll assume having a mobile site on a completely different domain (i.e. separate TLD) is not a viable option, which leaves us with the two discussed below:

  • Mobile Subdomain (mobile.domain.com)
  • Mobile Directory (domain.com/mobile/)

Required Meta Tags—Annotations Recommended by Google

With both options, it is important to annotate the relationship between matching desktop and mobile pages/URLs with rel=”alternate” and rel=”canonical” tags.

Rel Alternate Usage—Goes on Desktop Page

Add a rel=”alternate” tag in the HTML header of the desktop page, which alerts search engines to the corresponding mobile URL and helps define the relationship between the two pages. 

Rel Canonical Usage—Goes on Mobile Page

Add a rel=”canonical” tag in the HTML header of the mobile page, using the URL of the corresponding desktop URL. This alerts search engines to the corresponding desktop URL, and helps define the desktop URL as the canonical version to be shown in the search engine results, and to inherit any ranking signals (like external links to the page) from the mobile page.

Should you also put a self-referencing rel=”canonical” tag on the desktop page?
This is not necessary, but does not hurt either. 

Should you also put a rel=”alternate” tag pointing to the desktop page (and/or other alternatives) from the mobile page?

This is not necessary. Look at it this way: One is the “alternative” version and the other is the mainstream “canonical” version. You can have multiple alternatives, but there is only one canonical. The canonical lists all of the alternatives, and each alternative only needs to list the one canonical.

Pitfall to Avoid: Listing non-alternate URLs as alternates

When using rel=”alternate” and rel=”canonical” markup, maintain a 1-to-1 ratio between the mobile page and the corresponding desktop page. In particular, avoid annotating many desktop pages referring to a single mobile page (or vice versa). If you don’t have a complete mobile site (e.g. desktop site has 20 pages and mobile site only has 5), it’s best to only use the rel=”alternate” annotation on desktop pages that have a corresponding mobile page. Leave the rest of them alone, as they do not technically have a mobile “alternative.”

Don't do this.
Pages without a mobile equivalent should not list an “alternate” URL.

 

Automatic Redirects to the Mobile Page

In terms of SEO, it’s fine to automatically redirect a visitor to the appropriate page based on their device. As for usability, it’s important to allow redirected visitors to access the desktop version if they wish (make the button easy to see).

JavaScript is an acceptable means of redirecting here, but client-side redirects (e.g. those that occur after the page/HTML begins downloading) can slow down the process of getting a visitor to the correct page.

In many cases, a server-side HTTP redirect is advised. Google says to use a 302 (i.e. a “temporary” as opposed to a “permanent 301” redirect). But wait, won’t that mean the two pages won’t share ranking signals like external backlinks because it isn’t a 301? Normally yes, but in this case, the bidirectional relationship annotated via the rel=”canonical” and rel=”alternate” tags supposedly does the trick. Essentially, Google treats a rel=”canonical” tag to a different page as a 301 permanent redirect for the purposes of consolidating ranking signals and choosing which to show in the SERPs. Use your best judgement. Personally, I’ll be continuing to recommend 301s until convinced otherwise. But here’s what Google says:

“For this purpose, it does not matter if the server redirects with an HTTP 301 or a 302 status code, but use of 302 is recommended whenever possible.”

Source: Pure Oxygen Labs

Important Tool: Pure Oxygen Lab’s Mobile Redirect Viewer
This free tool by a great mobile optimization company allows you to easily see the different HTTP header responses served to different types of visitors.

In the screenshot to the left, we can see that TechCrunch is “302 redirecting” iPhone users, and the HTTP header response indicates that the content (and redirect behavior) varies based on cookies.

In the screenshot below, we see that Google is not taking their own advice with the YouTube domain, which “301 redirects” mobile users to the m.youtube.com subdomain, but does not indicate this with the Vary response. Take this with a grain of salt; Google typically has a “do as we say, not as we do” approach to everything.

Youtube doesn't have a Vary Response
Where’s the Vary response YouTube? And why a 301 instead of Your/Google’s recommended 302?

Pitfall to Avoid: Catch-All Redirects to Mobile Site

Don’t redirect multiple desktop URLs to a different mobile page.  As with bi-directional annotation, maintain a 1-to-1 ratio between the mobile page and the corresponding desktop page. This is a best practice for reasons pertaining to SEO, but is equally important for user experience, such as when someone on a mobile device is trying to access a page that only exists on the desktop site. Being automatically redirected to a different page without the content you’re looking for is frustrating.

Don't do this.
Don’t redirect all mobile traffic to a single mobile landing page. Keep a 1:1 ratio. If there isn’t a mobile equivalent URL do not redirect mobile traffic to a different page.


Do You Need the Vary HTTP Header?

No. Even though you are detecting the user-agent for the redirects, you do not need to use the Vary User-Agent response header in this case.

Rel Alternate Annotation/Markup in the XML Sitemap

Google supports including the rel=”alternate” annotation for the desktop