Are Higher Education Websites Mobile Friendly?

image of mobile phone with application icons on screen

Mobile First

The proportion of website traffic from mobile devices has been growing for the past decade and likely forms the majority of visits to websites in many countries. In May 2015, Google disclosed that for a sample of ten countries (including the US and Japan) a higher proportion of searches originate on mobile devices than from desktop computers. Google's disclosure followed the company's April 2015 update to its search algorithm boosting the rank of mobile friendly websites in search results.  Bing added further support to the shift to mobile when, in May 2015, it announced a similar, albeit progressive, roll out of search results favouring mobile friendliness.

To strengthen the importance of mobile, Google recently announced that from May 2016 search results from mobile friendly websites will be given even greater weighting. 

But, in our view, being mobile friendly isn’t about search results. It isn’t even about the technicalities of website design and construction. Being mobile friendly is a strategic choice to recognise and respond to how visitors now access websites. It's Google's rationale: its customers use mobile devices so Google has shifted to meet their needs. 

When Google made its April 2015 algorithm announcement, many higher education websites were already mobile friendly.  And, with Google signalling the need to change, it is reasonable to hypothesise that institutions that weren't mobile friendly have responded by making their sites so. 

We decided to test the hypothesis and see just how mobile friendly higher education websites are as of mid-March 2016.

Our Testing Protocol

Given that Google is upping the urgency to be mobile friendly and setting the 'rules', it makes sense to use Google's criteria for mobile friendliness. We can readily test compliance using Google's online testing tool: the Google Mobile Friendly Test (GMFT).

We submitted 206 Canadian higher education and online course provider website home page URLs to Google's Mobile Friendly Test. The GMFT generates three outcomes: Pass, Fail and Failed to fetch the requested URL. The latter indicating that Google can't fetch the page using Googlebot (Google's automated indexing software), which may indicate wider issues with site indexing for the affected sites.

We ran the 'Failed to fetch the requested URL' sites through two additional tests. First, accessing the page with a smartphone to inspect the page display and then using diagnostic tools to understand why Google experienced difficulties fetching the page, in the first place.

For the fail group we recorded the associated failure diagnostic messages, which we discuss in more detail below. We also sample tested pages on a smartphone to confirm that Google's results had a reasonable match with the experience of a typical site visitor.

The pass group can be divided into two. About 15% of the sites analysed passed without qualification, but a much larger number had what might be called 'qualified passes'. We discuss the qualified cases in more detail below.

The GMFT only analyses individual pages - now, while this is a limitation, we believe it is a reasonable assumption that a site's home page is the most carefully configured page and the test results should be indicative of a site's overall mobile friendliness.  On balance, our sampling suggests that a positive result for the home page may well flatter the performance of pages elsewhere on the site, whereas a home page failure tends to reflect site-wide issues.

Are Higher Education Websites Mobile Friendly?

As of mid-March 2016 the home pages for two-thirds of the higher education websites we tested successfully passed the GMFT. The balance of the sites have significant opportunities to improve their mobile friendliness and generally improve the experience of visitors.

Graph 1 summarises the results of the 206 sites submitted to the GFMT: 63.1% passed and 36.9% failed or a result could not be reported by the test. Graph 2 reports further details about the 48% of sites that passed, but generated warnings along the lines: 'This page uses n resources which are blocked by robots.txt'. We have segmented the value of n into 5 groups, as shown in the graph.  Almost 80% of the sites reporting resource blocking had fewer than 10 items of CSS or JavaScript being blocked by the settings in the site's robots.txt file. The remaining 20% of sites reporting this issue had anywhere up to 45 files needed to display page content, but access to the directories storing these files by Google's indexing bot was blocked by the settings in the site's robots.txt file. In terms of user experience, even one blocked resource may have a dramatic impact on the difference between the intended display and the actual display as interpreted by Google's test.

Graph 3 summarises the diagnostic messages reported by the GMFT for those sites that failed the test. All of the sites that failed were adjudged by Google as having links displayed on the page that were too close together to be selected by a finger on a touch screen.  Graph 4 splits out the number of diagnostic criteria reported for the sites that fail. Almost three-quarters of the sites that failed the GMFT did so with four or more of the diagnostic criteria being reported.

Graph 3 shows the diagnostic messages reported by the GMFT for sites that fail.  Resolving these issues can be complex, so we've linked each of the diagnostics to the relevant posts we published last year, when Google made its first announcement:

  • Mobile Viewport Not Set  - the site doesn’t tell devices how to handle content;
  • Content Wider Than Screen – the content doesn’t automatically adjust to different screen dimensions;
  • Links Too Close Together – links rendered on a mobile device screen are too close together to be accurately differentiated by a finger;
  • Text Too Small To Read – the text size does not dynamically adjust to recognise that content is being presented on a smaller screen; and,
  • Resources Blocked By robots.txt – a widespread problem, even on sites that otherwise pass the test. Google’s indexing bot is used as part of the test and if it can’t access files it provides a warning or fails the page outright. 


In many jurisdictions a majority of website visitors use mobile devices and sites need to accommodate their visitor's choice of device.  The GMFT uses 'Googlebot' as part of its testing process, because part of Google's motivation for encouraging mobile friendliness is delivering the best search results and accurate indexing of content is needed to fulfil this goal. As a result, files that are loaded on a page (such as CSS and JavaScript), but are not accessible to Googlebot will be reported as blocking.  This is the case for pages that pass and fail the test.  In either case, it will be worthwhile reviewing the robots.txt file to ensure that Googlebot is permitted to access all relevant locations for files associated with displaying content.

Search traffic may not be particularly important for any particular site (which can be confirmed by consulting Google Analytics) - and especially not for the home page - but, mobile friendliness is more that optimising search results. It is about delivering content to site visitors so that they enjoy the experience of using the site as was intended.  In practice, there will be content deeper in a site that is surfaced as a result of search queries and a site's visitors are best served if all content is accessible and can be displayed appropriately on mobile devices.

What to Do Next

The first step is to submit a page to the GFMT and review the feedback provided with the results.  Even pages that otherwise pass are likely to indicate resource blocking, which in turn may be indicative of issues with how effectively Google is indexing the entire site.  We will address opportunities to improve indexing of higher education websites in a subsequent post.

Once you identify the opportunities for improvement, we encourage you to read our set of blog posts describing how to implement them.


Sign Up for Email Delivery:

We collect the following solely to email you new blog posts.

* indicates required

MailChimp stores your details. We do not share data with third parties.



Don’t have accurate and current information on all the websites you own? Not able to monitor and check each website’s content quality and risk status? Let’s talk about how we can help.


Blog photo image: