It’s no secret that smartphone usage is now big, and still growing. Affordability of the latest cutting-edge smartphones has obviously played a significant part in this growth. Looking at today’s mouthwatering smartphone specifications and they sound more akin with budget to mid-range PC’s of last year (quad-core processors, dedicated graphic, 2GB RAM etc. remember the care free days of rocking an Nokia 8210, anyone??), with screen sizes to match. The better experience, and translated increase in mobile usage, has created a demand in smartphone-optimised websites; there’s a level of consumer expectation for sites to be mobile compatible, at the very least. If it’s not, then kiss that conversion goodbye.
Where does this leave us if we’re thinking of building a mobile optimised website? Google recommends using one of the following 3 options:
Although a single option to work across all devices would be great, in reality, different website stakeholders have different needs. For example, a CRO Specialist may be wary of the impact a responsive design site will have on conversions, or a User Experience Expert might fear their site’s UX will be compromised as it’s text heavy. The topic of mobile SEO is not a new one, but even today we see clients who are not aware of the mobile setups available to them and how each one actually caters to each need quite nicely. Let’s explore the first option, Responsive Web Design.
Responsive Web Design
Want your website to work well across all devices? Responsive Web Design (RWD) is your answer. RWD is an approach that uses CSS Media Queries, fluid grids and fluid/adaptive elements based on the user’s behaviour and device specifications, such as screen width and height, resolution, pixel density and orientation. In layman terms, RWD uses CCS3 media queries to adapt webpages for mobile devices. If you want to see if a site has a responsive layout, download the Web Developer Toolbar for either Firefox or Chrome, click on “Resize” and then hit “View Responsive Layouts”. You’ll see something like this:
Ayima’s very own site is responsive, so try accessing the site on your mobile, or resize your browser to see how it looks.
How does this technique benefit SEO? Simple. The stand-out benefit is that the URLs don’t need to change to serve mobile content – they remain the same whatever device you’re using.
This means that the site receives maximum link value as you’re only giving webmasters one URL to link to, and not split over to a subdomain URL, as it would be if a mobile subdomain were to be created.
From a crawling and indexing perspective, using RWD results in a more efficient crawl. Because neither the HTML or the URL change, Google only needs to crawl one instance of the site, rather than sending over various Googlebot-Mobile bots to crawl additional mobile content, which may cause indexing issues. Of course, this also negates any potential page duplication issues, keeping the Pandas at bay.
From an experience point of view, it’s that much more streamlined. Imagine you bookmark a webpage on your mobile and sync it to your desktop, the same URL is accessed from all devices. From a development point of view, there’s no mapping out your redirects, deciding what redirect header response to implement and no latency issues.
|No risk of duplicate content – same HTML – rankings maintained||Requires additional code re-working|
|One URL, one crawler. No need for mobile crawlers||Can’t differentiate mobile content|
|One URL = Maximum link value. No risk of split link value||Could affect usability/CRO, depending on the nature of the site|
|No redirection needed, helping latency & reducing user-agent redirect errors||Creating a new responsive site (and changing the code) may affect rankings|
Serving Content Depending on the Device (Dynamic Serving)
Let’s assume you have a text heavy website and you’re concerned that usability and conversion rate may suffer if you go with RWD. Perhaps you want a way to change the HTML/CSS to present cut-down copy with stronger call-to-actions, depending on the device. This is possible, but how do you let Google know that the content may differ depending on the user-agent?
Google recommend using the Vary HTTP header. The header is normally used to help caching proxies decide which version of a webpage to return – cached or the original document. In this instance, Google says the Vary HTTP header can also be used as a signal for Googlebot-Mobile to crawl the page, as it’s not blatantly clear that the HTML may change depending on the user-agent. But that’s not to say we can go off creating wildly different content, Google wants content where “desktop and mobile content are equivalent in purpose”, so the intent is the same on both pages.
So, how do we implement this? Let’s request https://www.ayima.com, the header request will look like this:
GET / HTTP/1.1 Host: www.ayima.com Connection: close User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31 Accept-Encoding: gzip Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 [rest of the HTTP header requests]
With the Vary: User-Agent added to the HTTP headers, the header response should look this:
Status: HTTP/1.1 200 OK Server: nginx/1.1.19 Content-Type: text/html; charset=UTF-8 Content-Encoding: gzip Vary: User-Agent [rest of the http header response]
As the URL does not change, this option inherits the key benefit from the RWD solution – links going to one URL.
With the HTML changing, your users may enjoy a better mobile experience, having a positive knock-on effect on metrics such as conversions. However, there are several drawbacks, such as the time spent creating mobile-optimised content, implementing the Vary header, and perhaps most importantly, potential caching issues with some Content Delivery Networks (CDNs). There have been some reports of CDNs ignoring the Vary header altogether, meaning all requests get sent to the site’s own servers, rather than the CDN (http://ayi.ma/rponr). This could result in your server being unable to handle the additional requests, bringing the site to it’s knees.
|One URL – maximum value from inbound links||Potential caching issues with CDNs|
|Content optimised and targeted for mobile users||Can be tricky to set up|
|One URL – no content duplication|
Creating New URLs for Mobile Content
m.example.com, mobile.example.com, mob.example.com…we’ve seen them all before on mobile sites, the most recognisable being an m. subdomain. Google state they do not have a preference as to what URL format you use, just as long you give them a signal to the location of the mobile content.
Mobile subdomains have their positives and negatives, but let’s get the glaringly obvious negative out the way first – 2 URLs.
From a linking perspective, subdomains don’t pass much link value over to the main domain, therefore the value of any inbound link to the mobile subdomain is lost on the main domain. From a technical implementation point-of-view, using dedicated mobile URLs means you will need to provide Google with a signal for the location of your mobile content. Successfully doing this allows for Googlebot to crawl your mobile content using Googlebot-Mobile and treat them as one and the same as the content is equivalent to the desktop URL.
If not implemented correctly, the site will be at risk of having the desktop crawler crawling your mobile pages or the mobile crawler crawling your desktop pages. This confusion could lead to both equivalent URLs (www.example.com and m.example.com) appearing in the search results, potentially leading to lower rankings. It’s a risky pitfall that we’d be keen to avoid and there a couple of ways we can: “alternate” and “canonical” annotations in either the HTML or an XML sitemap. It’s worth noting that the mark-up below can be used if your mobile site is located within a folder e.g. example.com/mobile.
In this example, let’s assume “Hanna’s Cakes” have a branch in Farringdon. The desktop URL would be http://www.hannascakes.com/farringdon, but we need to let Google know where our equivalent mobile URL is located. The rel=”alternate” tag does this for us:
<link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.hannascakes.com/farringdon" >
Great. But we also need to let Google know what the main URL is, the one that we want to keep in the index. The rel=”canonical” tag (required) does this for us:
<link rel="canonical" href="http://www.hannascakes.com/farringdon" >
XML sitemap method
The rel=”alternate” tag can also be added to each URL in the XML sitemap:
<?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml"> <url> <loc>http://www.hannascakes.com/farringdon</loc> <xhtml:link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.hannascakes.com/farringdon" /> </url> </urlset>
Google still make it a requirement for the canonical tag to be coded into the mobile site’s HTML. There’s no documentation on whether Google supports the canonical tag pointing to the desktop URL in mobile XML sitemaps (e.g. m.hannascakes.com/sitemap.xml). In theory, it should work in this scenario, but it would be helpful if Google could confirm this.
Once you have your mobile site setup on separate URLs, you’ll need to think about where to send mobile users. In it’s simplest form, all you would need to do is redirect your users to the appropriate mobile URL if they are using a mobile device. Google requests that you treat their bots the same, as you would treat users.
However, things can become fairly complex if you create mobile content specific for several devices, for example, different content is served if a you’re using a featurephone, such as a Nokia 301, and different content is served if you’re using a smartphone, such as an iPhone 5. The user-agents for these devices differs, so this redirection policy needs to be replicated for Googlebot and Googlebot-Mobile.
301 or 302?
It doesn’t matter if you use a 301 or 302 to redirect your mobile users to the mobile site, according to Google. I would have thought that once Googlebot-Mobile has found your mobile content, you would want to permanently 301 redirect your users, as well as Googlebot-Mobile in light of the above, to the mobile URL. Afterall, this is where you’re telling Google where you mobile content resides, permanently. However, many redirect implementations I’ve seen use 302 redirects. Download our very own redirect path tool (shameless plug!), switch your user-agent in your browser and check out bbc.co.uk or johnlewis.com, to see examples.
Generally, the technicalities and risks attached means we wouldn’t normally recommend this setup. However, we do understand the benefits. For example, if you only ever plan to build a stripped-down mobile site, containing minimal text and only a handful of pages, then a mobile subdomain might be better suited. There’s also familiarity with m. subdomains hosting mobile content. However, if you choose to only build mobile pages for a handful of pages, this would mean the mark-up detailed above could only be applied to those pages, meaning desktop versions appearing in mobile results.
|Opportunity to create mobile optimised content||Split link value between subdomain and main domain|
|m. subdomains synonymous with mobile content||Time resource implementing bi-directional and uni-directional redirects|
|Could affect usability/CRO, depending on the nature of the site|
|Complexity in implementing featurephone and smartphone specific redirects|
In summary, it’s clear to see that Responsive Web Design carries far fewer risks than the other two options. With the code and URLs remaining static, there is no risk of keyword rankings being negatively affected. As customers become familiar with your new mobile-optimised site, site metrics may improve, such as an increase in traffic and a decrease in bounce rates. These factors combine to ultimately provide a better experience for users, something that Google strives to bring to it’s users. In the future, well-executed RWD could become a ranking factor, if not already. Afterall, it is Google’s recommended option.