Inspired by Search London Meetup on recommendations for smartphone sites, I decided to put a post together to clear up any doubts or myths regarding Mobile Website Development and it’s impact on SEO.

At this point, everybody should already know how important it is to develop a mobile website, and how much more important mobile optimisation will become in the immediate future.

So, let’s dig in!

Google and the top search engines currently support three different configurations to target mobile traffic:

Responsive web design for mobile devices: one URL to serve the same HTML to both mobile and desktop devices but using CSS to alter the page rendering according to the device. Dynamic serving sites: one URL that serves different HTML and CSS depending on the user agent. Separate mobile URLs: every desktop URL would have an equivalent mobile-optimised URL; for example, www.example.com and m.example.com.

Myth Busting Alert: if you want to use a mobile URL, you don’t have to use a m. subdomain. If it suits you best, you could use any subdomain, subfolder (example.com/mobi) or TLD (example.mobi) you want.

Despite Google’s recommendation for responsive design, each of the above configurations have pros and cons, and need to take into account costs and gains.

1. Responsive Design Websites

Responsive web design uses CSS3 media queries to look at the capability of the device and re-architect the content. Amongst the others, you can use the screen’s width and height, resolution or orientation.

A CSS3 media query Google recommends is:

In-between the curly brackets goes the alternate CSS for small width devices like iPhones. This section should be at the bottom of your CSS, so that it overwrites any rules set earlier for desktop browsers.

Setting the max width at 640px, the orientation of the device doesn’t affect the style. In fact in portrait mode, iPhones have a pixel width of 480px, 640px in the landscape. Hint: these pixels do not correspond to the actual pixel density of the device, but to CSS pixels.

If you want to go more granular, you can also set min-width and max-width intervals, so that you target different devices accordingly.

In order for Google to detect responsive web design, its bots (Googlebot and Googlebot Mobile) should be allowed to crawl a website’s CSS, Javascript and images. So, please do NOT disallow the bots in the robots.txt file!

Rearranging content according to the screen size is amazing, but what if your pages had sidebars? That would make pages far too long! Don’t worry: you can use display: none for the HTML block that needs to be hidden. And this IS NOT cloaking.

For more info, have a look at this amazing resource for responsive design.

Responsive design normally requires a certain level of technical knowledge, unless you go for the quick solution. If you are running a website on WordPress, you may want to use WP Touch, a free plugin that serves a very simplified mobile theme to smartphones. It does the job pretty well but it’s very standardised, so I would only recommend it for blogs with a small readership.

Pros:

A single URL is better for the users, as it’s easier to share and interact with

No need to redirect users using user agents, therefore less margin for mistakes

The bots need to crawl the pages only once, and not for each user agent. This saves crawling resources, helping them index a website more efficiently and more often

Cons:

Less differentiation of mobile content

It may take more time and technical resources to be implemented than other configurations. And time is money!

Myth Busting Alert: even though this is Google’s recommended configuration, choosing one of the alternatives will not hurt your rankings in any way!

2. Dynamic Serving Websites

In this scenario, user agent detection is used to serve different CSS and HTML according to the user agents that are requesting them; the desktop version is the default. The server uses user agents to do this.

Keep in mind that user-agent detection could lead to mistakes, as the list of smartphone user-agent strings to be matched needs to be updated as soon as a new smartphone model is on the market. This is often not possible and the list is doomed to become stale very soon. And it’s often difficult to find out what the user-agent string is for a new mobile, at least until it becomes popular. And by that time you may have already lost precious traffic.

When serving different HTML to smartphone users, a hint should be sent to search engines to help them understand that there’s ALSO hidden mobile content.

This hint is given at the server level, by using the Vary HTTP header.

Pros:

There’s only one URL

No need for redirection

Cons:

Bots need to crawl pages with different user agents

User agent redirection is prone to mistakes

3. Mobile URLs

Using this method, each desktop URL has an equivalent URL serving mobile-optimised content. Once again, user agent detection is employed to redirect mobile users landing on the desktop version.

Each page’s desktop version should have a rel=”alternate” tag pointing at the mobile version in the <head> section. This would help search engine bots understand that there is a mobile version and crawl it. Check the example below:

On the mobile version, there should instead be a good old canonical tag pointing at the desktop version. That would make Google and the other bots understand that those two pages are just two versions of the same page, and should be considered as one entity.

Whether the rel=canonical has to be in the HTML of the mobile page, rel=alternate on the desktop pages can also be done at the sitemap level. See below:

Myth Busting Alert: if the rel=canonical is implemented, having two separate URLs doesn’t cause any link dilution and hurt rankings.

So, how you redirects users to the mobile URLs? There are two ways:

HTTP Redirection, based on the device’s user-agent in the HTTP headers JavaScript Redirection, which is slower as the device has to execute the script before redirecting to the mobile URL, and some (smart)phones don’t support it

Remember to always provide a link to the alternative version; just in case the version served wasn’t the one the user wanted.

If you want to go down this route, you may make your life easier by using the JS-Redirection-Mobile-Site library. In order to get it, you only need to download the “redirection-mobile.js” file from the “dist” folder. Once you’ve done that, you can add a script tag referencing the file in your <head> tag. You can find the full documentation on how to use the library on the library’s github page https://github.com/sebarmeli/JS-Redirection-Mobile-Site.

By the way, this is their javascript file:

You may have already noticed that Googlebot Mobile is not among the user-agents detected. You should not actively look for it. Don’t take my word for granted, though. Check for yourself:

You know where this is taken from? Google’s own guidelines for smartphone sites.

Pros:

A mobile URL can serve mobile-dedicated content

Easy to implement

Cons:

Waste of crawling resources. The indexed content for the mobile version therefore risks not to be fresh

Redirection is prone to mistakes.

What About Feature Phones and Tablets?

Feature phones do not support CSS media queries, therefore responsive web design cannot be used. The other two configurations are supported. Google put together a list of possible cases here.

And in regards to tablet users, always show them the desktop version, no matter which configuration you are using.

Now What?

Aleyda Solis provides some excellent advice on evaluating your needs and setting a mobile website development strategy in her article on State of Search. Put it into practice, or you will miss out on precious traffic!

Image credit: www.verite.com/library/media/MobileWebsiteDesignBanner.png