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 SEO.
At this point, everybody should already know how important it is to have mobile optimised websites, and how much more it 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:
1. Websites with responsive design: 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.
2. Dynamic serving sites: one URL that serves different HTML and CSS depending on the user agent.
3. 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.
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.
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
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.
There’s only one URL
No need for redirection
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:
1. HTTP Redirection, based on the device’s user-agent in the HTTP headers
Remember to always provide a link to the alternative version; just in case the version served wasn’t the one the user wanted.
Now you can put the code in the <head> tag and stop worrying about maintaining your list of user agents up-to-date because the guys at Duda Mobile will do it for you J
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.
A mobile URL can serve mobile-dedicated content
Easy to implement
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.