Alan Perkins

Alan Perkins

8th March 2013

Next Generation Site Architecture - a report from SES 2013

At Search Engine Strategies 2013 I was privileged to be sharing a platform with Google's Maile Ohye.  Maile is Google's Developer Programs Tech Lead and (like most techie Googlers I've met) is both a very smart person and a very friendly person.

The panel was "Next Generation Site Architecture" and Maile and I shared the various components of this topic across our two presentations resulting in what was, I hope, a rounded and complete hour on the topic, ably moderated by Will Critchlow of Distilled.

Maile started off by asking you to ask yourself whether you and your team were committed to your user experience, wherever those users were, whatever language they spoke, whatever device they happened to be using.  Her talk went on to tell you how Google fitted into the picture.

If your site ranks well in one language and country, it won’t automatically rank well in all languages and countries.  There are some coding signals you can use to let Google know the countries and languages you are targeting.

rel=canonical/prev/next

The first two coding signals that Maile covered are the rel=canonical tag for signalling the preferred URL among duplicates, and the rel=prev and rel=next tags for indicating the component pages of a series.  I’ve covered those tags before, in the following posts:

Maile also offered guidance on how to specify a canonical tag for a non-HTML object (such as a PDF).  This can be done through the HTTP response header for the object, for example like so:

HTTP/1.1 200 OK
Content-Type: application/pdf
Link: ; rel="canonical"
Content-Length: 785710

The technique is specified in more detail on Google’s Webmaster Blog entry “Supporting rel="canonical" HTTP Headers” but the Google blog doesn’t tell you that this technique can also be used to provide canonical alternative URLs for multiple objects of the same type.  For example:

GET /white-paper.pdf?referrer=ABC123 HTTP/1.1
Host: www.example.com
(...rest of HTTP request headers...)
HTTP/1.1 200 OK
Content-Type: application/pdf
Link: http://www.example.com/white-paper.pdf>; rel="canonical"
Content-Length: 785710
(... rest of HTTP response headers...)

rel=alternate hreflang=x

Maile then presented the code for language or regional markup of a page, the “hreflang” attribute.  I’ve not covered that previously on the blog, but have done so at previous SES conferences.  Google covers the mechanics of it quite well in their help document, “rel="alternate" hreflang="x" - Help Google serve the correct language or regional URL” but, despite this, there is much confusion around how to use this tag properly.  The situation has become even more confusing as mobile websites have taken off.  Here’s why: previously, a publisher may have found themselves in a position where they had a duplicate content issue, which rel=canonical was designed to address – now that issue is compounded by multiple languages, multiple regions and multiple platforms (mobile, tablet and desktop).  rel=alternate hreflang=x addresses the multiple languages and regions issue, but it’s quite clumsy code – if you wish to implement it, I would recommend doing so through the sitemaps mechanism described here.  Maile listed a couple of benefits of using rel=alternate hreflang=x:

  • Helps discovery of new URLs – URLs that were previously unknown to Google could be added to the crawl schedule once discovered via rel=alternate hreflang=x
  • More targeted URLs for searches – it’s more likely that a co.uk domain would be listed for UK searchers, rather than the generic com domain, meaning your visitors get to see appropriate content without you having to implement geo-targeting yourself

Building A Smartphone Site

The remainder of Maile’s presentation went on to explore the multiple platform issues that have become more prevalent since the recent proliferation of mobile sites.  Recent SilverDisc blog posts have touched on this, e.g. “Responsive Website Development Using A Mobile-First Strategy”, but Maile’s approach was subtitled “Building A Smartphone Site” and that’s the angle she took.

Maile began this part of her talk by looking at the difference between feature phones and smartphones, the key differences being:

  • Feature phones use cHTML (iMode), WML and WAP, whereas smartphones tend to support HTML5 and can therefore render normal desktop pages
  • Feature phones normally have keyboards whereas smartphones normally have a touch UI.

Maile then went on to list the three types of smartphone site – responsive, dynamic, and separate URL – and showed the decision tree for it, which I’ll convert into a table here:

Type of Site

Same URLs

Same HTML

Responsive

Yes

Yes

Dynamic

Yes

No

Separate mobile site

No

No

 

Maile listed the Googlebot user agents that are relevant to mobile:

  • Feature phones
  • Smartphones
    • Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

This is helpful to know if you’re coding a dynamic or separate mobile site as it allows you to predict which HTTP response and content that the mobile Googlebot will see.

Maile defined a responsive web design as one which used the same HTML at the same URL, and CSS media queries to vary the layout according to the screen size, e.g.

@media only screen and (max-width: 640px) { … }

Note - in practice we’ve found that some common browsers don’t handle media queries well, e.g. IE8, so you’ll find yourself implementing some hacks if you go for a purely responsive design.

Maile cited the BBC FOUR channel as a good example of responsive web design:

 

When it comes to dynamic-response mobile sites, typically this is done through detecting the user agent and serving appropriate content.  So that Google knows you’re delivering dynamic content, your HTTP response header should include a Vary field as described in Google’s Building Smartphone-Optimized Websites document, e.g. as follows:

GET /page-1 HTTP/1.1
Host: www.example.com
(...rest of HTTP request headers...)
HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 5710
(...rest of HTTP request headers...)

The third type of mobile web design, the separate URL, needs relationship annotation code to tell Google the connection between the various different pages.  The two pieces of code needed are rel=alternate and rel=canonical.  For example, suppose we have www.example.com and m.example.com. On www.example.com we would place the following code in the HTML section to indicate that alternative, mobile content was available for devices of limited screen width:

 

On m.example.com we would place the following code in the HTML section to show that the www version was the canonical:

 

If automatic redirects take place between the m. and www. domains, the redirect should be served with a HTTP Vary field in the response header, for example:

HTTP/1.1 301 Moved Permanently
Vary: User-Agent
Location: http://m.example.com/
(... rest of HTTP response headers...)

Google’s SkipRedirect for mobile searches

Maile then went on to describe Google’s SkipRedirect for mobile searches.  In a nutshell, how this works is as follows

  1. a user searches Google on a smartphone
  2. Google may display the desktop version of a particular URL, title and snippet in its search results
  3. the user clicks that particular result
  4. Google automatically redirects that user to the mobile equivalent URL i.e. without ever sending the user to the desktop URL.

This is something you need to be aware of, especially when implementing your own mobile redirects as you could find it very confusing when searchers aren’t hitting the desktop domain/URL you expect them to.

Best Practices For Next Generation Site Architecture

Maile’s advice, when selecting an architecture for your smartphone site, was to consider your users first.  Think about the context they’re in and what their expectations are.  Use responsive web design if it’s right for your users, as it’s good for Google too.  If you can’t use a responsive design, understand the tradeoffs and pitfalls of the dynamic or separate alternatives and make sure you implement them correctly.

Each URL should deliver the same content regardless of the user’s IP or language preferences.  Maile described this as “shareable URLs”, i.e. if you send a URL to a friend in a different country, they should be able to look at the same content as you.  My rule of thumb for this is “Each piece of unique content, indexed once, at the best URL for it.”  It has stood me in good stead for many years.

Think about page speed – this is especially important for mobile users, of course.  The architecture you use must scale to new users and network distances.

Don’t redirect lots of different desktop URLs to one smartphone URL.  If you don’t have a smartphone version of a URL, then show the desktop version instead.

Summary

Maile summarised her talk as follows:

  1. Be as educated as possible when making technical site architecture decisions
  2. Use signals such as those described in this post to help Google understand your site
  3. Test continually!

Thanks to Maile and Will for a great session.

Free eBook For Online Retailers

Download our Navigating the Biggest Challenges for Online Retailers eBook now for insights into AI and Machine Learning, Personalisation, Automation, Voice Search, Big Data and more.

Download eBook
x

Like What You've Read?

Subscribe to our monthly newsletter to receive our latest blog posts and our take on the latest online marketing news