The Guide to Mobile SEO

With just under 30% of traffic coming from mobile devices (and some sectors seeing an even higher proportion of mobile traffic), making your website mobile-friendly is a worthwhile effort, and can push you ahead of your competitors. The only problem is: how? Where do you get started? What makes a site good for mobile devices?

To help you determine the best approach to handle your mobile traffic, we’ve put together an outline some considerations you’ll need to bear in mind, along with our best practice guidelines and other tips and tricks for every stage of the process:

Choosing the right approach
Designing the mobile version of your site
Development considerations
Technical search engine optimization
Setting up and using Google Analytics
The future of mobile web

1. Choosing the right approach

There are several approaches to creating a mobile-friendly web presence. They are usually divided into three ‘types’, each of which provides a different experience for mobile users:

Responsive: the page – URL, HTML, images, everything – remains the same, but the CSS gives different rules based on browser width.
RESS/Adaptive/Dynamic Serving: the URL remains the same, but the server sends different HTML and CSS based on what type of device is requesting the page.
Separate Mobile Site: usually hosted on a subdomain (e.g. m.domain.com) or sometimes a subfolder (e.g. www.domain.com/mobile), but it can also use the same URLs as the desktop site, and simply serve different HTML (called dynamic serving) to desktop and mobile visitors based on user agent.
If the mobile site uses different URLs, they are often kept parallel with their desktop counterparts (e.g. www.domain.com/first-page and m.domain.com/first-page), which allows for smooth redirects based on user agent. But since it’s a separate set of pages, the options are unlimited. You could choose to have a completely different site structure, in which case the mobile URLs might be necessarily different.

Various considerations will determine which of these approaches is best for your site. See the flowchart below to guide your choice.

Choosing an approach is just the beginning. This guide is structured in four parts, to mirror the site creation process and to provide some considerations for each stage: design, development, and monitoring once the site is live. Taken together, these guidelines will enable you to design, build and optimize your site to be the best version possible for users and search engines alike.

A note about feature phones

These guidelines are primarily oriented towards optimizing your site for visits from smartphones.

If you have a high percentage of your mobile traffic coming from feature phones (non-smartphone mobile phones), you may want to consider targeting them as well. This may be a bigger consideration for websites targeting geographic areas outside of Europe and North America, as the ratio of smartphone users to feature phone users across geographic regions can be drastically different.

However, we will not address additional feature phone considerations in this document.

Basic option: use a CMS that does it for you

If you have a low budget or limited resources, you may want to look into using a user-friendly content management system (CMS) like WordPress. Responsive design is probably your best option here, since there are a lot of pre-made responsive designed CMS’s, and responsive design takes the least amount of content creation.

Here are some of our recommendations for good responsive WordPress themes and other CMS services. There are plenty of other options available.

WordPress themes:

Elegant Themes have several responsive themes, priced at ~$69/year. They provide updates and full support. You can renew on an annual basis.
PressCoders: We recommend the Designfolio theme, which you can download for free (with some restrictions) or purchase a full license for at $79. The paid version includes full support.
WooThemes make excellent premium WordPress themes. Some of them are free, most are about $80 – $140, all are mobile-ready and highly customisable.
Responsive theme from CyberChimps is a great option, especially for a basic site such as a personal website or blog. And it’s free.

Or, for non-Wordpress users:

SquareSpace is probably one of the best WYSIWYG (What You See Is What You Get) mobile design solutions at the moment, and priced from $8/month (for the most basic service).
Wix is another WYSIWYG service, and very reasonably priced, at around $17 a month.

But if you’re ready and able to do it yourself, let’s get started!

2. Designing the mobile version of your site

Mobile visitors want to see a version of your site with colors, themes, and content similar to the main site so they can be certain that they’re on the right site. But they expect the actual structure of the page to be fairly different: the screen should really only display one or two elements at a time, rather than the multitude of options we show desktop visitors all at once.

Organizing content

Recommended: mobile first

Mobile first is a growing movement in the design world. The basic idea is that mobile sites should be designed first, then expanded into pages for tablets and desktops. There’s nothing you can put on a mobile page that can’t be loaded on the desktop version (besides mobile-specific features, but those are less of an issue to fix). This approach is especially helpful for responsive and dynamically served sites, where the content on the mobile version of the page should be identical to the content on the desktop page.

Designing a mobile site second

If Mobile First design isn’t an option, your task will be more difficult, but not impossible.

Start by figuring out which elements of a desktop page need to be on a mobile page:

You can gather user data through your standard web analytics tools, custom tools like CrazyEgg, and UX testing. Ask the questions:
- What content is important to visitors?
- What is ignored?
- What is the typical path visitors take?
Look internally, too. If you need ads to support your site, you’re obviously not going to remove them just because you found out they were ignored in your user tests. On the other hand, if your site primarily runs on subscriptions but includes ads for a bit more profit, you may want to remove them from the mobile version of the site to speed up page loading time and optimize user experience.
Run some speed tests to identify elements that take a while to load. Find out:
- Are they important to the content of the page?
- Can they be minimized?

Use insights from this research to identify what you will and won’t have on the mobile version of your site. Some of this research may help you clean up your desktop site, too: if you’ve found content that visitors are ignoring, why is it on the desktop site at all? Next, map out the content path visitors take on the page. This will be simple on most article pages but may be complex for category pages and product pages. Some excellent examples are:

Facebook: Of course, they’re the king of mobile. The desktop version of the site has three columns: side navigation, a primary list of content, and a secondary list of trends and ads. The mobile version moves all navigation to the top of the page and just shows the primary column.
Amazon: Probably the best example of a mobile ecommerce site. Its mobile product pages display snippets of all of the information that the desktop version has, limiting the amount of content phones have to download but still giving visitors access to all the information they expect. The content is prioritized to get you to buy quickly, by putting the buy button at the top, then the product info, then the reviews.

Nordstrom: One of the better mobile sites for a primarily offline company. Product pages start with multiple images of the product that visitors can swipe through, then product selections, then reviews. Although reviews are below purchase information, there’s a link to them and a summary at the top, so mobile visitors get a lot of information at a glance.

Once you have an idea of visual flow, you can lay out your initial designs for a mobile screen and get into the nitty gritty of mobile design.

Universal mobile design concerns

Navigation on a small screen

Mobile phone screens are too small to view a large navigation menu in addition to the primary content. Rather than showing the desktop site’s navigation, mobile navigation options should be minimized.

Size variances of smartphones

Most smartphones display 320px to 400px across, (in CSS pixels, which is what matters for design) although old iPhones are only 240px across. If they’re flipped on their sides, they can be up to 640px across. Tablets are from 480px to 800px across when held like a book, but they’re more likely to be held like a television, making their maximum pixels across 1280px.

That gives you a pretty wide variance to design for: 320px to 1280px. Rather than serving everyone, find out which screen sizes people usually use on your site. If you use analytics software like Google Analytics you should be able to find this data easily (in GA it’s in the Mobile report). This is a screenshot from the Mobile > Devices report, with ‘Screen Resolution’ set as a secondary dimension:

Make sure to test your site on the top devices that up to 90% of your visitors are using.Pro tip: Since each element spans the entire screen size, you can usually set their widths to 100% in CSS, and they’ll expand or contract as the screen size shifts. Images will automatically shrink and text will stay the same size, but will wrap itself differently depending on the space available.

Designing for touch

Fingers do not have the ability to hover or right click, and they need a good amount of space between links to be sure they don’t accidentally click the wrong one. When designing for touch:

Give enough space for a finger: Fingers aren’t as precise as mice. Fingers obscure what they’re tapping, you can’t give any indication that they’re hovering over the right option before they tap, and they tap a larger part of the screen than a mouse. Make sure that you always have a space of at least 28 x 28 pixels around links on your site for clumsy fingers.
Give feedback when the screen is touched: With slow or broken connectivity, many of your visitors will have to wait awhile to get to the next page when they tap on a link or button. Let them know that the phone has recorded that they’ve tapped the button by showing the button indent or highlighting a linked box. Otherwise, your visitors will end up furiously tapping their screens, and may end up in the wrong place.
Use buttons: Buttons clearly define where users can or cannot click to activate the link. Since, unlike on a desktop display, you can’t use any signals to tell them their mouse is hovering over the right area, it’s more important to define the clickable space.
Redesign drop-down menus: They still work on mobile, and can be a great way to hide information until it’s requested, but they often open only when you hover a mouse cursor over them. Mobile drop-downs should be activated with a tap, and the menu should show clear separation between options. BridgestoneTire.com does this well:

Minimize text input: Typing is slower on a mobile phone, and necessitates an on-screen keyboard, which makes the viewable screen half as big. Cut out input that isn’t absolutely essential. Break up forms into multiple pages that only take up half of the screen, with a clear “next” button, so that visitors don’t have to scroll.
Use mobile-specific features: The difference between main sites and mobile sites adds opportunities: for example, you can make all of your phone numbers click-to-call, and turn your address into a link for navigation.

Designing for responsive sites

For those of you who are unfamiliar with responsive design, it’s the idea that you can deliver the same HTML code regardless of screen size, but use CSS to rearrange those elements based on the screen width. To learn more, you can read the article that started it all, or read a briefer, SEO-focused description on SEOmoz.

As you start designing a responsive site, it will be tempting to write one set of CSS for a mobile site, another set of CSS for a tablet or a small computer, and a final set of CSS for a large computer monitor. But the point of responsive design is to make it fit all screen sizes – not just the most common ones.

Rather than thinking of your site as one object that you need to resize, think of each element on the site differently. Open a page of your current site and slowly shrink it; at what point does an element disappear? You can use CSS to move that element into a still visible column. Can the main image on your page be shrunk and still look good, or would you rather crop it? CSS can shrink or crop based on the screen width.

Resizing websites – example

If you’re building a website from scratch, most designers recommend starting with a mobile site, then spacing the elements out as the screen gets bigger. But most people considering mobile site design now already have a desktop version of their site, so we’ve provided a walkthrough for how to take your current site and shrink it down.

Here’s an example of a desktop-sized web page template with design notes:

Shrinking content (all elements)

As the width of the page gets smaller, all of the elements, except the text, will have to get smaller as well. To make this a gradual progression rather than a jump from size to size, make the widths of the most important objects a percentage of screen size.

In this example, the banner’s width should always be 100% of the screen size. To stop the banner from being impossibly small, you should set a minimum pixel height for it as well, and then start zooming in on the picture rather than minimizing it.

The text should always be 100% of the screen size, minus the widths of the left and right navigation (if they’re still there). Text will easily rework itself to fit the box you’ve given it, so this should be a fairly simple task.

Reorganizing content (text or banner)

When you start shrinking objects, they’ll be harder to understand. For some elements, like the text floating over the banner, they’ll be more understandable on their own on a smaller screen. In this example, the text floating on the banner in the large screen size should be moved below the banner once it runs out of room.

Reorganizing content (left navigation)

Often, you’ll want the options in the left navigation to be highly visible to mobile visitors as well. Move the navigation to the bottom of the content , so that once the visitor has read the page, the next natural options will be obvious.

Removing content (right navigation)

We’ve started refitting the most important pieces first for a reason: you’ll find some of the content won’t easily fit in a mobile design. If the least important objects can’t find a place, then ask yourself, does the mobile audience really need to see this?

If the answer is no, you can set it to display:none once the screen width is too small to accommodate it.

Note: When you cut something out of your mobile site, you should also ask yourself, do you even need it on the desktop site? This could be a good opportunity for you to clean up your main site as well.

Once you’ve made all of these adjustments, the site should be able to shrink to look more like:

Moving content into a single column layout

Sites with long form content can simply be narrowed and lengthened to fit the content as is. E-commerce sites, on the other hand, tend to have multiple pieces of content separated visually, rather than through text transitions. There are a couple of design options:

Rearrange content into one column: If the separated content on the main site still flows easily from one piece to the next, simply stack it in the right order, using visual cues to show the reader where one piece starts and ends. For especially content-heavy pages, it’s a good idea to include navigation at the top that lets visitors jump to the part they are most interested in.
Hide content on load: Consider using an interactive accordion layout, which hides some of the content on load under titles, looking somewhat like buttons. For example, here’s how we show our Conference Schedule via mobile. Visitors can tap to expand sections to view more details:

With either method, test the order of the content to see what converts best. You may be surprised at what content is most persuasive to mobile visitors.

If you find that content should be deleted from the mobile version of the site, or should be included on the mobile version of the site but not the desktop version, you can write it into the HTML code but hide it for the device type that shouldn’t see it. But, if this is a significant amount of data, consider a separate mobile site instead.

Designing for a separate mobile site or dynamically served site

A separate mobile site has its own HTML, so it isn’t tied to looking like the main site, or even having the same set of content or pages.

Include most of the content from the main site

You may assume that certain product and/or other pages won’t need mobile-friendly design. But in general it’s best to include as much of the desktop content as possible in some form. It may be difficult, for example, to imagine a scenario in which someone would complete a diamond ring purchase from their cell phone, but that doesn’t mean that people won’t want to browse, build, and share their perfect ring on their daily commute to work. They might also be interested in price comparisons, reading reviews, or reading the marketing copy for their top choices. A good, intuitive way to allow them to research their diamond ring purchase on their mobile phones is to simply have a similar shopping experience to what you have on your desktop site.

In short: even if the key conversion won’t happen on a mobile phone, you shouldn’t assume that visitors aren’t interested in the same content hosted on the main website.

Look at your analytics to see what keywords your mobile visitors search for the most (if you’re using Google Analytics, that is the Search Engine Optimization report). Check keywords from organic search traffic as well as from internal site search to see what visitors look for once they arrive on your site. Make sure, at the very least, that the most popular topics are covered on the mobile version of your site.

A note about tablets

The general recommendation for tablets is that you serve them the desktop site rather than your separate mobile site. This is because the screen size of most tablets is closer to that of a laptop than a smartphone, and a mobile-specific site won’t look right. This guidance may change, however, as we see more variation in tablet sizes.

3. Development considerations

Mobile websites have to be built for mobile phones , which bring their own host of development challenges:

Intermittent connectivity: Assume that visitors will have a patchy connection and make your site as easy to load as possible. Compress images and code, buffer videos, and – if your page is especially long – load images further down the page asynchronously using JavaScript so that the page can display as quickly as possible, even if some elements take a bit longer. Google has a handy tool that will give you specific suggestions to speed up page load time.
Different devices and/or web browsers: Test your site on different devices and browsers. What looks perfectly proportioned on an iPhone might look oddly squished to one side on the wider Samsung Galaxy. For some reference tables showing screen resolutions for the various mobile devices, see the ‘Further Reading’ section.
Cross-platform issues: Sync customer information across platforms. A signed-in shopper should be able to put something in his/her cart on a mobile website and check out later on a desktop PC. (The implementation of this will depend on how the backend of your website platform is set up.)
Avoid web content that is unsupported: Specifically: Flash. Flash is supported by most desktop browsers (save IE 10 in Windows 8’s Metro) and is somewhat functional in Android browsers, but Windows phones and iPhones can’t run it at all. Ideally, HTML5 should be a good substitute. You can also use an approach called progressive enhancement, building a site that can be rendered well by all browsers, and then adding on Flash effects and other more advanced technical layers for browsers that can use them.
Touchscreen-friendly development: On a touchscreen, you can’t use drop downs that only work when the visitor hovers their mouse over the navigation, and you can’t put the only description of links or images in ‘alt’ text.

Building by screen size

As you start turning your designs into actual sites, you want to make sure that they fit the most commonly used devices out there. This graph from StatCounter shows the top 14 mobile screen resolutions in 2012 (worldwide):

[Source: http://gs.statcounter.com/#mobile_resolution-ww-monthly-201410-201412-bar]

You should base your design on the most common devices used to access your site though, because this will vary for each site. It might help to list the most common types of screen resolutions to visit your site and the percentage of your total visits from each.

Based on a sampling of our clients’ mobile traffic data, here’s an example of what that list could look like:

This list makes up about 90% of device resolutions (there are actually thousands of options). Other resolutions usually have a similar width, though, so testing these sizes should be sufficient.

Comprehensive listings of the different mobile screen resolutions:

Images

Images are generally the largest files a browser has to load to render a page (unless you have excessive code). Make sure that you’ve compressed all of the images you put on your mobile site as much as possible. There are a number of free tools out there for compressing images. We recommend smush.it.

If you have multiple small images on a page, especially as navigation symbols, use CSS image sprites. CSS image sprites are a single image that is a combination of multiple images on the page. You can divide them up and place them with CSS. Browsers have to make a call for each image, and using sprites allows them to only make that call once.

Question the need for images as well. Does the background have to be a picture, or can it be a pattern that repeats? Does the header have to be an image, or can it be text? You’ll find that many pages that look incomplete without a picture on the desktop look perfectly fine without those images on the mobile version.

These are all general considerations which apply to all three types of website. Now it’s time to look at some other recommendations, based on which approach you are using.

Development for responsive design

Once you have the design in place (discussed in the previous section), you’ll need to be able to resize and move each element through CSS, based on the screen width of the viewing device.

Change the CSS by screen width though media queries

Thanks to the introduction of W3C’s media queries in CSS3, you can apply styles based on screen width with the following code:

@media screen
and (min-width : XXXpx)
and (max-width : XXXpx)
and (orientation : landscape/portrait)
[elements that you want to follow this style] {
*/ Add your styles here */
}

Change the “XXX” to literally any width that you want this style to apply to. “Min-width” and “max-width” refer to the display area, meaning, the browser width. You might see “min-device-width” and “max-device-width” recommended online as well, but those refer to the width of the actual device screen. They’re best used to identify the device type, meaning, mobile phone vs tablet.

It isn’t necessary to include the minimum, maximum and orientation every time, just use what you need. For example, if you want some text to float over an image until the screen is 500px across, make the code:

@media screen
and (min-width : 500px)
.bannertext {
float : right;
}

As long as the device’s browser is at least 500 pixels across, the text will float to the right. If the browser is any smaller than that, the style won’t apply. It’s best practice when resizing the screen to focus on one element at a time and determine the “breakpoint” – the point at which the element no longer looks well-designed – and change the CSS there.

Viewport

Media queries will work assuming the mobile browser loads the site as if it were a very small window on a desktop screen. But many mobile browsers try to fit the entire webpage on the phone’s screen, assuming that visitors would rather see the entire thing and zoom in on the part they’re most interested in. For responsive design to work on the iPhone’s Safari, and/or any phone’s Firefox, Android, or Opera, put this in the header:

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

This can also be done in CSS, though this is a newer option and isn’t supported on as many browsers:

@-o-viewport { width : device - width ; }

“Viewport” refers to the width of the display screen on any device. Setting the width of the viewport to the actual pixel width of the screen will allow the responsive design media queries to set themselves appropriately.

Sometimes there are other considerations that come with high pixel density phones. In addition, you may also choose to set a default / max-min zoom level, and/or customise the default page width that you want to show. This introduction to meta-viewport and viewport discusses all of these issues and provides more resources. Google’s Set the Viewport page offers an easily understandable breakdown of the steps.

Slim the whole website down

Once your website is responsive, there’s a good chance that you’ll find it taking significantly longer to load on a mobile device than on a desktop. To make the load time on a mobile device tolerable (and the load time on the desktop site lightning fast):

Shrink image size: Images take up more bandwidth than any other element on a webpage. Always compress images, and follow Smashing Magazine’s steps to figure out the best way to choose a responsive image solution.
Consolidate CSS and JavaScript: It’s common to create a new JavaScript or CSS file by element; for example, you may have a CSS file that formats the header and another for the background/general styling of all pages. Both of those apply to the same pages, though, so it’s more efficient to combine them into one “all” file.
Minify CSS and JavaScript: In addition to consolidating your files, compress them by removing all line breaks and spacing to speed up load time still further. You can do this manually or use any of the number of tools out there.
Limit library usage: There may be one or two commands that you’d love to use from a given JavaScript library; but does that make it worth loading the entire library? Be careful about what libraries you load, and how much you’re actually using them. It may be more efficient to do without.

Development for separate mobile sites

If your mobile site has the same set of pages as your desktop site, you can choose to use a single URL for both, but serve the right content dynamically based on the user agent. If you’d prefer to have a completely separate mobile site with different URLs, it will take a little more work to tie everything together, but it will be just as understandable to search engines in the end.

Dynamically serving content on a single URL

User Agent DetectionCheck to make sure that mobile search engine crawlers can find your site, and that you can correctly figure out the user agents. Don’t serve content for Googlebot-Mobile specifically – this looks like cloaking. The Googlebot-Mobile user agent mimics an iPhone, so as long as your site has normal smartphone detection implemented it will be fine. You can implement this with a server-side language (such as PHP).
Use the Vary-HTTP Header to indicate to Googlebot and Googlebot-Mobile that a mobile user-agent gets served a different version (in order to avoid looking like you’re cloaking). The code looks like this:

GET /page-1 HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76B) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.133 Mobile Safari/535.19 (…rest of HTTP request headers…)
HTTP/1.1 200 OK Content-Type: text/html Vary: User-Agent Content-Length: 5710 (… rest of HTTP response headers…)

Development considerations for sites using different URLs

Detecting user agents

When mobile visitors arrive at the desktop version of your site, you’ll need to detect their device and redirect them to the mobile URL. You can use a server-side language like PHP to detect the user agent and to redirect mobile visitors to the correct version of the site by changing the HTTP request.

Using redirects

When you have a separate mobile site, redirects should be implemented on both the mobile and desktop versions to ensure that visitors are sent to the most appropriate version of the site. If you don’t have a one-to-one correlation between desktop pages and mobile pages, you should redirect to the most relevant options.

So for example, if the desktop site has individual jobs pages but the mobile site lists them all on a single page, you can redirect the individual pages to that central jobs page, rather than to the mobile homepage. If, however, there is no page about jobs on the mobile version, consider redirecting mobile users to a page which explains this, and offers to take mobile users to the desktop version. Alternatively you can skip using a redirect on that URL, and mobile users will simply be served the desktop page.

Some tips for setting up redirects correctly

Where possible, use a server-side 301 or 302 redirect, rather than Javascript. Javascript redirects will cause lags and longer load time.
Redirect mobile visitors landing on a desktop page to the relevant page of the mobile version, AND redirect desktop visitors landing on a mobile page to the desktop version. (This may change if your mobile and desktop versions are drastically different. See above.)
Include the option to override the redirect (e.g. “View desktop version”) and make sure that the user’s preference is remembered (you can use cookies for this, but make sure they don’t expire too quickly).

Mobile XML Sitemap

In order to help search engines find and understand your mobile site, the standard best practice is to create a mobile-specific XML sitemap of all your mobile URLs and submit it to Google and Bing through their respective Webmaster Tools interfaces. Google gives an example of what it should look like here. Make sure the sitemap updates automatically when you add new pages to your mobile site.An easy way to create your sitemap is to simply use the Google Sitemap Generator (currently in beta). This tool also automatically detects updates.

The Rel=“Canonical” Tag

When you build a separate mobile site, you’re technically building duplicate pages. To avoid duplicate content issues, acknowledge that the mobile and desktop versions of webpages have (near-)duplicate content with the mobile version of the rel=”canonical” tag. This will mean that only the “canonical” version of the page shows up in search results, but your user agent redirects will get mobile visitors where they need to go.

Canonical tags point from a duplicate page to the original. Assuming that you will want the desktop version of the site to be the canonical version, the mobile site should have this tag in its header:

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

Since the mobile page will point search engine crawlers to index only the desktop version of the page, the desktop version should explain the purpose of the mobile site with a rel= “alternate” tag:

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

Note that this tag implies that the content is (near-)duplicate. If you have created extra pages for your mobile site which do not relate to desktop content (or vice versa) you will not need to add the tag to these pages.

Cross-Channel/Platform Integration

It’s important to make sure that your website works equally well across multiple channels, platforms and/or devices. Progressive enhancement and cross-device syncing provide two complementary ways to implement this.

Progressive enhancement for a separate mobile site is similar to the ‘mobile first’ concept for responsive design. You start with the most basic limited browser/device and semantic HTML and build out from there in layers. For example, you can build the core of a site in standard HTML, but add extra HTML5 elements for browsers that support it. This article from Smashing Magazine walks you through the process. Before you invest in new technologies, though, check your analytics to make sure that your visitors use devices that can interpret your extra code.

Comprehensive listings of the different mobile screen resolutions

Cross-device Syncing

If your website includes a user login option, you should make sure that you are tracking and syncing an individual user’s account across devices in order to sync shopping baskets, favorites, wish lists, etc. The implementation of this will depend on how your site’s backend is set up.

Screen size and using “viewport”

If you design your mobile site to be 320px across and someone accesses the site on a phone that is only 240px across, they’ll only see 75% of the page width. Luckily, the viewport tag allows you to tell all devices to resize the page to the width of the browser.

Most browsers support an HTML meta viewport tag. To implement this tag, include this text in the of each page:

<meta name='viewport' content='width=device-width' />

It is also possible to state the width as a set number of pixels , but this is not recommended. By using ‘device-width’ instead of specifying the number of pixels, you allow recalculations based on the width of the screen. If the user tips the phone sideways, for example, the page can resize to fit the new width.

When the page resizes, however, the content on the page will also resize unless you disable the text-size-adjust CSS property:

html { -webkit-text-size-adjust : none; text-size-adjust : none; }

Using this code will ensure that the text remains the same size regardless of the device orientation. This meta tag is supported in iOS, Android and other common smartphone browsers. More recently it is being included in the @viewport CSS declaration, but this option is not yet widely supported by most browsers.

A note about testing

Make sure that you test your design on different devices and browsers. There are several mobile phone emulator tools available, both free and paid. We’ve compiled a list of our favourite free tools:

Inspect Element, on Chrome: Click the image of a phone on the upper right hand corner of the inspect element bar to launch.
Responsinator: A responsive tester which provides a quick way to see how your website will look on some of the most popular mobile devices. Also allows you to test a local URL (not just online pages). Try the bookmarklet!
Mobile Phone Emulator: A mobile emulator which enables you to test website displays on specific phones. A bit more functionality, honoring most of the device settings including user agents, behaviour and features. Covers Android, Apple iOS, Windows, and Blackberry.
Screenqueri.es: A mobile emulator which lets you set the pixel size on your own by dragging the borders. You can also test based on a specific device.

A couple extra resources

W3 Validator for Mobile: Useful resource for validating mobile site code
List of Device-Specific Emulators: Compilation of device-specific emulators and simulators
Google’s Mobile Friendly Test, to make sure you get that lovely “Mobile-friendly” tag on search engine results pages.

4. Technical search engine optimization

As you build your mobile site, you want to make sure that the content is readable by search engine crawlers. Google promotes mobile friendly site rankings and demotes unfriendly sites. Luckily, Google’s pretty good at recognizing mobile friendly sites. We just need to check in to make sure Google’s got it right with some SEO tips.

Tips for all mobile site builds

Local Search: 4 in 5 consumers with internet access search for information on local business. 88% use their smartphone and 84% use their PC or tablet. That’s right: local search is nearly as important on PCs and tablets as it is on mobile. Build pages with local information on it that works for both mobile and desktop sites.
Structured Data Markup: If you have certain types of content, like reviews, addresses, recipes, or embedded videos, both Google and Bing let you identify it using special HTML tags, and may use that information to display extra data, called rich snippets, on their search engine results pages. Schema.org gives you the proper markups for both search engines.

SEO for responsive design

A responsively designed site is the exact same site for desktop and mobile users from a search engine’s point of view (since the only thing that changes is the CSS, and Google pays minimal attention to that). If you’ve optimized your desktop site for search engines, you shouldn’t need to do anything extra for the mobile version. All you need to do is make sure that the desktop site is correctly optimized.

Double check that Google understands that your site is responsive and will load well on smartphones by taking the Mobile Friendly Test.

SEO for a separate mobile site

Because separate mobile sites use different HTML to their desktop counterparts, there is a bit more work involved in making them search engine friendly.

Separate mobile site using same URLs (dynamically served)

An adaptive, or dynamically served, site keeps the same URLs as the desktop version, but allows for variation in the underlying HTML code. While the basic SEO principles are the same as for a responsive site, there are a few extra things you can do to make sure that search engines realise what you are doing:

Avoiding Cloaking

Search engines may penalise sites which appear to be cloaking (i.e. displaying different content to users and to search engine crawlers). This shouldn’t be a problem in the case of a dynamically served site, because the mobile crawler will see what mobile users see, and the desktop crawler will see what desktop users see. However, to make it clear that this is what you’re doing, you should use the Vary-HTTP Header (for an example of this, see the Development for Dynamic Serving section under Development).

Using this header has two additional benefits:

It will let the mobile crawler know that there is separate mobile content on this URL, and therefore encourage it to crawl the site.
It will signal to caching servers that they should consider the user agent (e.g. the type of device) when deciding whether to serve a page from the cache.

Mobile-Specific Keywords

Because a dynamically served site can use different HTML, you are able to change targeted keywords both in the content and also in the meta titles and descriptions. You should only do this, however, if a keyword analysis shows a significant disparity between mobile searches and desktop searches. If you don’t yet have keyword data for your own site, the Google Adwords Keyword Tool allows you to filter keyword searches for ‘Web’ and ‘Mobile’.

Mobile-friendly page titles / meta descriptions

In addition to using different keywords in your meta titles and descriptions, you may also want to consider shortening these elements. Because of the smaller screen size, there are fewer characters displayed. Keep title tags within 40-60 characters and meta descriptions within 90 characters.

Separate mobile site using different URLs

A mobile site on a separate URL is effectively a different site, and so you can run a technical audit independently, the same way you would for your desktop site. We like to use Geoff Kenyon’s Technical Site Audit Checklist, plus a few extra points that are in our Mobile Site Audit Checklist.

Create a parallel URL structure:

Unless you’ve built your mobile site with very different content than your desktop site, the URL structure for your mobile site should mirror the relevant pages on your desktop site as closely as possible. So www.example.com/funny-story should become m.example.com/funny-story, not m.example.com/psq234.

Meta information and keywords

A separate mobile site can target mobile-specific keywords in your meta tags and content. Luckily, Google wraps title tags on mobile screens, so they’re actually slightly longer on mobile SERPs than desktops!

Duplicate content

A separate mobile site with the same or similar content as the desktop version could potentially be seen as a case of duplicate content, which may be penalised by search engines. Make it clear that your mobile site is an intentional duplicate of the desktop site. To do this you will need to use a the rel= “canonical” tag, which we’ve detailed in the development section of this document. This tag tells search engines that your desktop version is the primary source, but also indicates that the mobile page is a mobile-friendly version of the desktop page, rather than purely duplicate content.

User agent redirects

Many visitors will arrive at the wrong version of your site for their device, and you need to redirect them. U se server-side redirects rather than Javascript redirects, as Javascript causes a lag in the load time and a page with a Javascript redirect is less likely to be cached.

Tips for handling redirects to mobile site

Use either a 301 or a 302 redirect. 301s and 302s work the same way but communicate different messages to search engine crawlers. Normally 301 is recommended for SEO purposes, but for user agent redirects the rel=”alternate” overrides the meaning of the redirect, so in this case you can use either option.
Don’t redirect all desktop pages to the mobile homepage; instead, point them to a mobile page which is relevant to the original. If you don’t have a relevant mobile page, and building one isn’t an option, you should create a page explaining that the mobile version is not available and offering the option to view the desktop version of the desired page and/or alternate pages on the mobile site. This page can be on the mobile subdomain/folder, or it could be a page on your desktop site. Keeping it on your desktop site will avoid a double redirect (from a desktop URL to a mobile URL back to the desktop version). Alternately, you can skip the redirect for that URL and the visitor will arrive on the desktop version of the page.
Be sure to include a link to ‘view desktop version’ on your mobile site (and vice versa). Use cookies to ensure that if a user clicks on this option the user agent detection will be overridden and they will not be redirected again (unless they choose to switch back via the ‘view mobile version’ option).
The current recommendation is to send tablet users to the desktop site, rather than the mobile site. Tablet browsing patterns typically resemble desktop browsing patterns more than mobile. This may change, however, as tablet sizes become more varied. You can also consider creating a separate tablet site (e.g. t.example.com), but you should only do this if the desktop version of the site creates considerable browsing problems for tablet visitors. Having three sites will create much more work than having two.

Mobile XML sitemap

Google and Bing will index and notice updates to your site faster if you have a reliable sitemap, and both search engines’ Webmaster Tools will tell you how many URLs in your XML sitemap are in their indexes. Mobile sites get less traffic and are crawled by a different Googlebot, so it’s especially important to highlight this data for your mobile site. It’s also useful in helping search engines understand that your mobile site is a mobile site and not simply duplicate content. “Upload” your separate XML sitemap by putting it on your site and adding the URL to Bing and Google Webmaster Tools.

Robots.txt file

Make sure you’re not blocking the ‘Smartphone-Googlebot’ from your desktop version in robots.txt and don’t block regular Googlebot from the mobile version. Bing’s guidance is unclear on this issue, so we recommend that you follow the same practice and allow the Bing crawlers full access to both versions.

5. Setting up and using Google Analytics

Once your site is set up, you need to be able to track how your users interact with it. Google Analytics is a free tracking service (up to 10 million hits [ pageviews, transactions, items, and/or events ] per month), although there are other excellent paid services. This section will briefly discuss how to set up Google Analytics tracking for mobile, and what metrics you should look at.

Analytics for single URL sites (responsive and dynamically served sites)

If you have a responsive site, the Google Analytics implementation will be identical for mobile and desktop traffic. If you have a dynamic site, remember to include the same tracking code in your mobile HTML as on your desktop HTML. Since the file path of the URL will be the same on the mobile and desktop versions of the site, traffic to mobile and desktop versions of the site will be tracked together. This will give you a full overview of your traffic at a glance, but you will still be able to separate out mobile traffic with advanced segments.

Advanced: Set a custom variable that tracks which version of the site your server sent (this will be separate from the devices section of GA, since that will show the device that viewed the page, not which site was loaded). You can learn more about setting custom variables here.

Important metrics

Once you have your data, you should focus on:

Landing pages: Are people entering your site in the right place?
Conversion rate and where people leave the conversion funnel: Where are they getting stuck?
Bounce rate: Are people not finding what they’re looking for?
Site search and organic search keywords: What are people looking for to begin with?

For an overview of what else to look for, see on 3.1: Your Mobile Users in this great article by Aleyda Solis.

Analytics for separate mobile sites using different URLs

Once you’re happy with the structure of your mobile site, you need to be able to track its usage. As it is a separate site using its own URLs, you will need to add the tracking code to all the mobile version pages. If you haven’t added the tracking code to your mobile site, go do it now.

Advanced: Use crossdomain tracking to get both mobile and desktop data in the same web property:

You should track your mobile site on the same web property (i.e., using the same UA-XXXXX-Y account number) as your desktop site. This requires a simple tweak in the code on both versions in order to indicate to GA that your m.domain.com site is a subdomain of your main site. You should also set up a special profile exclusively for traffic to m.domain.com.

Extra tips for setting up separate mobile site tracking with Google Analytics

Should I use the special non-Javascript version?
Normally you should be able to ignore the special ‘tracking a mobile site’ option.

Instead, you should use the same Javascript code that you use on your desktop site.

The (rare) exception to this would be if you have a disproportionately high amount of traffic from feature phone (non-smartphone) users that you need to track. Feature phones don’t support Javascript, so the normal tracking code can’t track these visits. But this is an unlikely situation, as most websites don’t see much traffic from these types of phones. If you are worried about it, you can check the site’s server logs for visits from feature phone user agents.
Use crossdomain tracking to get both mobile and desktop data in the same web property:

You should track your mobile site on the same web property (i.e., using the same UA-XXXXX-Y account number) as your desktop site. This requires a simple tweak in the code on both versions in order to indicate to GA that your m.domain.com site is a subdomain of your main site. You should also set up a special profile exclusively for traffic to m.domain.com.
- How to set up crossdomain tracking
- How to set up a new profile
Important metrics: these will be roughly the same as for a single URL site.

6. The future of the mobile web

Where do we go from here?

Now that you’ve prepared your site for mobile visitors, you might be wondering, “Where do we go from here?” I t is always difficult to predict the future, particularly in such a fast-moving industry, but the overwhelming trends are pointing towards concepts that provide a seamless, personalised experience for visitors. Web users will be able to see the same content and access the same personalised information across all platforms and devices, and possibly even integrate it with their offline experiences.

Using devices interchangeably?

As the market for smartphones and tablets grows, they are also being used more like PCs (and vice versa). Will Critchlow noted that as mobile devices get more like PCs (faster, better at browsing, and easier to purchase on), PCs are becoming more like mobile devices (with features like Touch, App Stores and InstantOn):

People are increasingly using their various web-compatible devices interchangeably. A study by Google showed, surprisingly, that 77% of mobile searches occurred at home or at work; indicating that those users were actively choosing to use a mobile device over an available desktop device.

This blurring of the lines between mobile and desktop devices leads to new ways for people to use the internet. These new modes of usage in turn lead to new challenges for online marketers. One of the more common of these new forms of web browsing is “multi-screen browsing”.

Multi-screen browsing

Multi-screen browsing involves using more than one device to browse the internet. There are two principal ways in which this occurs: working between devices, or sequential screening, and simultaneous usage.

Working between devices

This is a particularly important behavior for marketers to be aware of, because it can skew attribution metrics (and campaign success tracking). An example of this would be when someone visits an ecommerce site on a smartphone, adds an item to their cart and returns later to purchase the item using a desktop.

[Data source and image inspiration: http://www.google.com/think/research-studies/the-new-multi-screen-world-study.html]

Simultaneous usage

Simultaneous usage is simply when someone is using multiple devices at once. A common example is when someone is watching a TV show and using their smartphone to look up information about a product that is advertized during a commercial break.

[Data source and image inspiration: http://www.google.com/think/research-studies/the-new-multi-screen-world-study.html]

Cross-device syncing

As users increasingly perform online tasks across multiple devices, and especially as they engage in sequential screening, the ability to sync activity between multiple devices will become more important than ever. The Amazon Kindle is a good example of this type of syncing. If you have multiple devices linked to your Kindle account, you can set it to remember where you last left off reading a book, even if you continue reading on a different device.

Cross-device syncing should become the norm for ecommerce. If I add an item to my shopping basket on a retailer’s mobile site while signed in, that item should stay in the shopping basket even if I return to that site on a different device. Debenhams is just one example of a retailer that does this. If both your mobile and desktop sites pull from the same user database, your site may already be cross-device syncing, but check to make sure.

Ideally, a site that requires a user login would also have an option to ‘remember me’, with a long-term cookie which allows for being logged in simultaneously on multiple devices. That way users don’t have to keep logging in every time they access the site, even if an account is open in multiple screens at the same time.

Content everywhere

As with syncing accounts, it is becoming increasingly important for users to be able to access content from anywhere, across platforms and devices. The concept of ‘content everywhere’ was created to describe a new system of content management which rejects the idea that content=web page. Rather, content is what is often displayed on a web page, but the same content can take many different forms.

A good way to think about ‘content everywhere’ is that it is like the responsive design of content. Responsive design structures a web page in the format of flexible building blocks which can be rearranged to fit the needs of the user. Content everywhere does the same for the actual content, breaking down each content type (blog posts, articles, reviews, etc.) into basic elements, or building blocks (teaser, headline, introduction, references, author) which can then be rearranged and reused as needed. This is especially important for mobile content, as there is so much variety in the way mobile users access and share content.

In December 2012, Sara Wachter-Boettcher published a book called Content Everywhere: Strategy and Structure for Future-Ready Content, in which she outlined a plan for creating content that you could ‘Create Once, Publish Everywhere’ (COPE). It has formed the basis for the theory behind the concept of ‘content everywhere’, and is a fantastic place to start for anyone who would like to implement these ideas into their content strategy.

Real world APIs

‘APIs’, or application programming interfaces, enable access to the data within a database. Public APIs allow developers to access other people’s databases and use the data for something else. A good example of this are the popular ‘mashup apps’. For instance, one very basic mashup app allows you to automatically post your Tweets directly to Facebook. This is done by allowing the app in Facebook to access Twitter’s API, and collect your Tweets, and then access your Facebook wall to repost.

What we can start to move towards with this type of data accessibility is the development of ‘ real world APIs ’: namely, a database which a program can access and use its data in relation to an offline interaction. A basic example of a real world API would be Twilio, which among other things allows you to send a text message when someone calls a number on your website. Another example might be the new Universal Analytics feature in Google Analytics, which allows you to track a customer’s offline interactions with your business (such as a checkout with a loyalty card) and relate them to the same person’s online interactions (such as a visit to your website). The possibilities for creating non-web-based uses for this kind of data is very exciting.

If you’re interested in these sorts of topics, but find the technical elements a bit overwhelming, the Content Everywhere book s a great place to start learning, as it’s designed for people with a less technical background.

Conclusion

Implementing a mobile-friendly website won’t mean that you’re done with mobile. As the mobile web develops, we have to be ready for it. There are some pretty exciting possibilities coming out of these developments. The more complex elements of ‘content everywhere’ theory and enhanced user experiences may not work for every business, especially for SMEs. That’s ok.

The important thing to remember is the end goals of implementing these concepts: to provide a high-quality user experience to visitors from all sorts of devices, and to ensure that they can access the information and services which you offer. If you can achieve that, you’ve succeeded.

The Guide to Mobile SEO

1. Choosing the right approach

A note about feature phones

Further reading on feature phone optimization

Basic option: use a CMS that does it for you

WordPress themes:

Or, for non-Wordpress users:

2. Designing the mobile version of your site

Organizing content

Recommended: mobile first

Designing a mobile site second

Universal mobile design concerns

Navigation on a small screen

Size variances of smartphones

Designing for touch

Further reading

Designing for responsive sites

Resizing websites – example

Shrinking content (all elements)

Reorganizing content (text or banner)

Reorganizing content (left navigation)

Removing content (right navigation)

Moving content into a single column layout

Further reading

Designing for a separate mobile site or dynamically served site

Include most of the content from the main site

A note about tablets

3. Development considerations

Building by screen size

Comprehensive listings of the different mobile screen resolutions:

Images

Development for responsive design

Change the CSS by screen width though media queries

Viewport

Further reading

Slim the whole website down

Development for separate mobile sites

Dynamically serving content on a single URL

Development considerations for sites using different URLs

Detecting user agents

Using redirects

Some tips for setting up redirects correctly

Mobile XML Sitemap

The Rel=“Canonical” Tag

Cross-Channel/Platform Integration

Comprehensive listings of the different mobile screen resolutions

Cross-device Syncing

Further reading

Screen size and using “viewport”

Further reading

A note about testing

A couple extra resources

4. Technical search engine optimization

Tips for all mobile site builds

Further reading

SEO for responsive design

Further reading

SEO for a separate mobile site

Separate mobile site using same URLs (dynamically served)

Avoiding Cloaking

Mobile-Specific Keywords

Further reading

Mobile-friendly page titles / meta descriptions

Separate mobile site using different URLs

Create a parallel URL structure:

Meta information and keywords

Duplicate content

User agent redirects

Tips for handling redirects to mobile site

Mobile XML sitemap

Robots.txt file

Further reading

5. Setting up and using Google Analytics

Analytics for single URL sites (responsive and dynamically served sites)

Important metrics

Analytics for separate mobile sites using different URLs

Extra tips for setting up separate mobile site tracking with Google Analytics

Further reading

6. The future of the mobile web

Where do we go from here?