Flawed Google Mobile Usability Test Results

SMS Text
Flawed Google Mobile Usability Test Results

UPDATE: Google Webmasters and Maile Ohye responded to our request for comment on this article:

As many of you know, Google recently announced a major change related to how sites show up in mobile search results, beginning on April 21st.

The official Google Webmaster announcement stated:

Starting April 21, we will be expanding our use of mobile-friendliness as a ranking signal. This change will affect mobile searches in all languages worldwide and will have a significant impact in our search results. Consequently, users will find it easier to get relevant, high quality search results that are optimized for their devices.

The announcement then went on to suggest two different ways site owners could find out whether their site might be impacted:

If you want to test a few pages, you can use the Mobile-Friendly Test. If you have a site, you can use your Webmaster Tools account to get a full list of mobile usability issues across your site using the Mobile Usability Report.

Note how that second option was for site owners who have GWT set up. Many do these days.

Flawed Testing Service

Since I do extensive testing for sites, I routinely rely upon GWT, GA, and several other tools, one of which is Google Page Speed Insights tool (GPSI). Part of the process Google themselves recommends for testing mobile usability is GPSI, which presents conflicting information that is already confusing some site owners and developers.

My Discovery Process

One of the sites I’ve previously audited received a GWT generated alert about how the client’s site currently fails mobile usability.

Google Webmaster Mobile Usability Alert

According to this automatically generated notice, this site has eight hundred and twenty pages with errors that “severely affect how mobile users are able to experience your website.

The notice then goes on to state “These pages will not be seen as mobile-friendly by Google Search and will therefore be displayed and ranked appropriately for smartphone users.” (emphasis mine)

That’s a big deal. Nearly HALF of that site is supposedly suffering from mobile usability problems and this notice specifically states those pages will lose rankings because of it.

That alert then goes on to offer help:

GWT Alert issue fix link

When you click on that “inspect mobile issues” link, it takes you to the recently added “Mobile Usability” report right in GWT.

That’s a great resource (well it will be, when they fix the conflicting messages I discovered) because it lists what appear to be the various flaws in mobile usability.

GWT Mobile Usability Issue ListClicking on one of those listed issues takes you to a list of the pages on the site that failed that particular test.

Clicking on one of the URLs listed gives you a pop-up with more information:

Mobile Usability Error Explanations

The Vortex of Crazy Begins

Note how on the right there’s a button that says “Check live version”? That button launches Google Page Speed Insights tool.

If you’re unfortunate enough to have at least one “challenge” with your site’s framework the current Google mobile usability system is NOT capable of dealing with yet, you’ll end up seeing this:

Google Page Speed Insights Flawed Data

Wait. How did THAT happen?

I clicked on the link to do a live test directly from an entry in GWT that had been included in the errors list.

Except GPSI says “Nope, you’re golden!” This obviously isn’t going to help webmasters.

Here’s where everything went off the rails:

  1. GWT says “Your site sucks, and we’re going to slap you into the mobile search grave-yard for those pages we think suck the most!”
  2. GPSI says “Your site is awesome! Kick back, relax, and laugh all the way to the bank because for mobile usability, your site is going to continue to rank well while sites some other suckers own are going to the mobile search grave-yard!”

This means some developers will think this means there’s NOTHING to fix!

Developers I have worked with on many sites offered the opinion that this is nothing to worry about – that Google is just “working things out” as they approach April 21st, and that since “GPSI says it’s good to go,” there’s NO NEED TO TAKE ACTION.

Now, in all my history of observing how Google’s systems are continually tweaked, changed, modified, improved, and otherwise re-calibrated, I know they do a LOT of testing. And I know that sometimes they make mistakes in their assessments, only to later recant, after sending out notices by mistake.

So maybe they’re right, I thought…

But what if they aren’t?

Ask Someone Who Knows

After I blasted a half-dozen rant-tweets on Twitter, with no response from the GWT team (not sure if they were too busy that day or just didn’t like my tone – a common challenge I face when I rant), I posted this up on my Facebook page with a cc to a few people at Google:

A call for help

No, I don’t have an “inside connection”. I’ve just worked hard over years of time to build trust with people I respect. So this was one of those rare situations where I pinged them, hoping one of them would be able to find out what’s up and provide some answers.

Maile Ohye Responds

I <3 Maile. She’s Developer Teams Program Lead at Google. She’s not usually someone SEOs go to for info – it used to be Matt Cutts, and more recently, it’s mostly been John Mueller.

However Matt is out of the loop these days (and I am ecstatic that he’s living a more complete life), and John does the best he can, however, he’s been bombarded non-stop since Matt stepped down.

Maile though – she’s amazing. Always goes right to the advanced stuff when it comes to her own posts and guidelines to help site owners. So I really appreciate that she checked into this for me.

The Core Problem

Google Page Speed Insights is not currently set up to process pages the same way GWT’s other internal systems are.

The specific problem? GPSI doesn’t emulate Googlebot.

That’s a really big deal. Because for Mobile Usability, if any of your pages are blocked in the robots.txt file, GPSI won’t know it.

And since GWT is RELYING on respecting the robots.txt file, if you have any critical layout or display files blocked there, GWT won’t find them, and that can result in your site FAILING the Mobile Usability test.

Here’s Maile’s exact response confirming that:

Maile's Response

I highlighted the two critical points:

“Some of the examples’ files are blocked to Googlebot” and

“And you’re totally right — PSI doesn’t fetch with Googlebot so not possible for you to tell.”



So GWT is currently communicating to site owners when there are errors on the site.

Except if files vital to site functionality exist so as to ensure THE SITE WORKS FOR MOBILE USERS are blocked by robots.txt file, Google is now (at least for now) taking the position that your site is NOT MOBILE FRIENDLY.

All because Googlebot is involved, REGARDLESS of whether a site renders properly for mobile visitors or not.

Google Shoots First, Sometimes Never Asks Questions

So what I interpret that to mean is: Google is, at this point, of the opinion that “either you do what we demand you do, regardless of whether its important for any other reason OTHER than our use, or we’ll penalize you or filter your pages out, which might as well be a penalty.”

We can argue six ways to next summer whether that’s right, wrong, fair, unfair, or whatever. I can only hope Google will make a retraction and give innocent site owners the benefit of the doubt, if mobile layout scripts are behind the robots.txt file’s protection system, and not be harmed on April 21st.

I DOUBT they’ll retract, though. Just like so many other issues, at this point it’s probably full steam ahead.

So what do we do?

Google Mobile Friendly Testing Tool

One of the testing methods they suggest (and that Maile says is the best way to test now) is to run individual URLs through Google’s Mobile Friendly Testing Tool.

When I ran that same page previously tested and “100% good to go” in GPSI, here’s what I got:

Mobile Friendly Testing Tool Results

Note that the first thing you see here is along the lines of, “NO, THIS PAGE SUCKS FOR MOBILE.”

Except we know that it may or may not be true in this situation.

Fortunately, that screen does communicate the possibility that their test was flawed.

Mobile Friendly Test Caveat

Sadly, even though the report states this may be due to a robots.txt file issue, (and that means “not necessarily an actual flaw in your site design”), even this screen statement goes on to link to GPSI!

Which would just generate more confusion.

Just Confirming Facts

Just to confirm what I thought I found to this point, and what Maile stated was an issue, I went back to this client’s site and looked into the source on an example page. And sure enough I found this:

Some of the scripts blocked from Googlebot

That’s just two of the many files I found at the code level used for site functionality.

Note how they’re both in the /wp-includes/ folder.

Robots.txt File Layout Blocking Entry

And sure enough – there you have it – the /wp-includes/ folder is blocked in the robots.txt file.

So Is It Or Isn’t It Mobile Friendly?

Until we open up the robots.txt file or change where .js and css files are located to give Googlebot accessibility, we can only assume. And that’s dangerous.

The “Google’s Playground” Question

So at this point, I’ve communicated with the dev. Of course we’re in agreement that this should NEVER have had to happen.

Not because .js files shouldn’t have been blocked from search engines. Because until Google decided they want to do everything they can algorithmically to emulate users, this wouldn’t have been a problem.

And because of that I can’t blame them. I’ve been saying for a couple of years “SEO is the search engines attempt to emulate user experience through formulaic methods”.

So from THAT perspective, yeah, sure – give them access to JavaScript and CSS files.

Except now it’s the bully on the block issue again – where site owners will likely be forced to “comply or suffer” and how many site owners won’t know this until it’s too late?

How many site owners will suffer in mobile search and never have a clue why?

How many sites will lose real revenue, have to lay off employees, cut back on quality of life activities at home, or go out of business altogether because of this?

Cover Your Assets

Bottom line, though, is this – at this moment, we cannot rely on GPSI anymore regarding its Mobile Usability data, at least in situations where files may be blocked from access in the robots.txt file.

Except that leaves all sorts of “what if” other questions. If GPSI doesn’t rely on Googlebot, what other flaws exist in GPSI specific to page speed data? And what OTHER tools Google provides are like that? How many other flawed data results points exist across the entire sphere of their testing system?

Hopefully, we’ll get more information at some point and with any luck, April 21st may NOT be the day they bang the “unfriendly sites” up against the wall.

Alan Bleiweiss
Alan Bleiweiss is a Forensic SEO audit consultant with audit client sites consisting of upwards of 50 million pages and tens of millions of visitors... Read Full Bio
Alan Bleiweiss
Get the latest news from Search Engine Journal!
We value your privacy! See our policy here.
  • Wow, Alan, this is a great example of investigative SEO reporting. I’ve barely heard a word of this elsewhere, and you manage to provide a pretty comprehensive solution here. Thanks a lot for this article.

    • Thanks Ethan
      As soon as I sat with what I found, I realized I hadn’t seen any other report about it so I jumped into action.

  • I noticed Google’s mistake on mobile friendliness on one of my sites as well. Might be a deeper problem then just robots.txt exclusions. I hope to investigate soon.

    • Dustin
      Please share what you discover – we need to understand the scope of this…

  • Ramesh Singh

    Hi Alan, this is good analysis but just curious to know do you have a responsive/dynamic or a separate site? As per my observation you see such errors when you have to separate sites like m.domain and domain.com. Google show your mobile usability issue in desktop version too. And if you have no issues in your mobile version then I think you are good.

    • Ramesh, in this case its one site that serves mobile and desktop visitors.

  • I just tried a site I made mobile friendly with the js and css folder blocked in the robots.txt and got the “Awesome! This page is mobile-friendly.” message. It does note some resources are blocked underneath that message but it doesn’t fail…

    I have seen some website owners testing for themselves and getting grief messages about no access to Google’s own resources that they (Google themselves) have blocked.

    Quite a mess….

    • oh that definitely makes it more of a mess! That’s not good at all…

  • To add more confusion: One must not forget that the GWMT Report lags some days behind. So i switched a page i left “mobile unfriendly” for testing purposes lately, have full scores in GPSI and MFTT, still the errors keep being listed in GWMT. I guess they will be gone next week.
    And: great investigation, thanks!

    • Richie,

      Yes – thank you for mentioning the GWT lag, which brings yet one more layer of crazy to the puzzle!

  • Hats off to you Alan for your comprehensive research on mobile usability test results. It has made me clear many elements you have pointed out in your detailed post. Google can made mistakes but we should know at the end we will have to bow them no matter who is right or wrong. I can feel a big mess coming in April similarly as happened in 2012 after Penguin Launch.

    • Sabeeh,

      Yes, it’s going to be a mess at least for some people. I don’t know if it will be on a scale anywhere near as big as the MayDay update, any of the big Panda updates, or Penguin – all I know is some sites will be hit by this and we may never know about the extent of it.

      • I’m sure Google will offer more suggestions for anyone who is worried about this. After all, this is a HUGE change and Google has been pretty accommodating overall when it comes to big changes for webmasters.

  • it is better to work on responsive layout. in most cases , it is considered mobile friendly tested on many tools

    • Vikas,

      Responsive design has its value, however just having a responsive design is not automatically a guarantee that a site will be faster or completely mobile friendly. Also, many designers and developers who create responsive design sites cause new SEO problems when they add features like “endless scroll”, as just one example.

      So yes, responsive design can be a good thing. However in all cases, responsive or not, it requires serious understanding of the implications and impact all actions will have, and now this needs to also include blocking CSS and JavaScript.

  • Thanks a lot for sharing such a knowledgeable script on mobile usability test results, now my all doubts are clear after reading this article.

    • Neha,

      You’re welcome – this is why I wrote this article!

  • Great share/post Alan. I had a responsive WP theme trigger a mobile issue alert in GWT two weeks ago. I couldn’t understand how Google was saying the ‘text viewport’ was too small when it obviously wasn’t. I hope they get this fixed by April 21st. The only thing Google fears is searchers going to Bing if they jack up their own SERPs. From the SEO side, robots.txt changes are simple to fix. I guess part of being a good SEO these days is understanding where Google can’t keep up with themselves.

    • Kevin,

      I agree that the change is straight forward for anyone who knows about this. And it’s not like Google hasn’t been warning site owners about robots.txt file blocking. It’s just confusing when site owners don’t have the expert resources to deal with it or when they do, when those experts don’t know about the flawed reports.

  • Steve Wiideman

    Thanks Alan,

    This is has been plaguing our team a bit as well. Bottom line, webmasters should use the new Google Mobile-Friendly tool as a priority for April’s mobile search ranking update. All other tools are just a bonus to maximizing compatibility for browsers, devices and bandwidth.

    Awesome share and glad Maile is still around (and still my personal hero).

    • Steve,

      Even better, Maile tweeted tonight that she appreciates this info and that they’re working on making things better. That’s the best news so far!

  • Wow, great insights. I’m glad you got a response in order to figure this whole thing out. Seems like Google has some figuring out to do on their end.

    • Nick
      We can only hope Google will even bother to put time in to figure this one out…

  • Yavor Milchev

    This tools sucks. Obviously it has problems connecting to some CDNs. If you try top5.com you see a broken page since the tool didn’t load any static resources and the result is “Not mobile-friendly”. Then enter top5.com/entertainment and you get the same broken page except this time the message says “Awesome! This page is mobile-friendly.”

    Naturally, the difference is in how the bottom part of the page renders without a stylesheet but in the end of the day this entire website is responsive!

    Be careful if you’re on a CDN that Google can’t crawl!!!!

    • Yavor,

      Thank you for mentioning CDNs – this is yet one more very important factor to consider!

  • Stephen Ostermiller

    At least it is possible for you to discover how the metrics that Google is using are flawed. This is about the only time that Google have given enough information to webmasters to be able to do that. I applaud Google for releasing this much information about the factors that will be used for this ranking change.

    Usually Google implements ranking factors without informing webmasters that they are coming. They regard the entire ranking factor state secret. Even if they do say that something is a ranking factor, they don’t say what the components, let alone the parameters.

    Take for example the “top heavy” algorithm. I so wish that they had treated webmasters as well for that as they are with this mobile update. How many ads are too many? Is it a content to ad ratio that is important? What counts as content? Google should answer those questions, notify webmasters about problematic pages, and release tools to check pages.

    The same goes for Panda and Penguin. Google should have done a lot more to ensure that webmasters have the tools to make their site compliant.

    Although there are problems with their metrics for mobile friendliness, this is a big departure from the usual Google way of doing things. Usually there are problems with their completely secret algorithms. Webmasters are not adequately informed ahead of time. There are usually no tools to check sites. Webmasters only get a nasty surprise drop in their analytics after the algorithm launches.

    • Stephen,

      You are spot on about how big an opportunity this is regarding the unprecedented advanced communication. I believe this is a major shift that I can only pray will become a standard procedure.

  • Great insights Alan (pun intended).

    Appreciate the thoroughness and candor. Obviously no point in fighting this, just need to comply. You’ve made that process a lot easier to understand and implement.

    AND I appreciate seeing how quickly you respond to comments! Nice.

    • Oh James! Now you’ve forced me to monitor comments 24/7! 🙂

      Seriously though – I believe it’s important to be as responsive and timely as possible when people are willing to take the time to not only read my content but to take the additional time to reply with thoughtful additional perspective.

      As the days go on however, I do have my work that inevitably distracts me and sometimes I can’t respond so fast. 🙂 Human after all…

  • Thanks so much for this solid bit of reporting. Far too many SEO articles are full of fluff, but this one is packed like a sausage with lots tasty bits. (with apologies to the vegans in the room…)

    There are times when I feel like Google has truly lost its way. AdWords is a UX disaster and the constant changes to Places/Business/Whatever drives my clients nuts.

    And here’s a related query; if we’re all supposed to go HTTPS in the near future, but also be as FAST as possible, how exactly is that going to work? All the additional calls involved in SSL will naturally slow load times down. Will that factor that into the algo, or not?

    Again, many thanks.


    • Ron,

      Thanks for that compliment. I do my best to always only write when I think its going to be significant enough to be of real value. So getting that acknowledgement means a lot to me.

      As far as Google goes overall, the bigger they’ve gotten, the more hands have been put into every project, and the less control they have at quality. Ironically, the User Experience they care so much about is a secondary consideration for much of what they themselves offer. While some of it is outstanding (core reporting features in GA, GWT and AdWords for example), the botched functionality that crops up across these different platforms really causes confusion and frustration.

      As far as SSL goes, well, that’s a good one. I’ve got clients who have horrific page processing speed delays, and many of them have been able to shave as much as three seconds off of individual page loads by REMOVING Google’s own retargeting code mess.

      Others have shaved significant speed by eliminating Google Font calls, Google API calls…

      Clearly there is no cohesiveness across goals and teams there. Heck even within individual teams…

  • Very helpful! I had looked at the Mobile friendly test just today and thought something must be off. A quick Google search and you shed light onto the issue. Let’s just hope Google gets a fix for this ASAP.

    • Jonathan,

      For now, Google is taking the position that if you don’t comply with their wanting to crawl robots.txt files, and if your pages fail the mobile friendly tool test, its your problem, not theirs. They have now added a new “blocked resources” report in Google Webmaster Tools to help site owners do this.

      (Thanks to Kevin Pike for notifying me about the new GWT report)

      • Let’s hope this helps everyone be as prepared as they can with the upcoming changes!

  • Jeff Hunt

    In my case I got the email, clicked “Inspect mobile issues”, saw the three categories of problems – “touch elements too close”, etc. and then I drilled down on those to see the URL’s.

    That’s when I discovered the all the problems Google had found were in the /wp-content/uploads/ directories. And of course those URL’s are not “pages” at all, just directories of file listings.

    So now I have to figure out how to block URL’s in robots.txt but not block too much. For example to make these messages go away I would like to block /wp-content/uploads/2015/05/ but not block /wp-content/uploads/2015/05/image1.jpg because that image file may need to be picked up in Google images.

    Why bother to make fix Google messages for pages that don’t matter? Because it may be that the messages may have a negative effect overall whether or not they are related to pages I care about.

    • Jeff,

      Since the mobile ranking changes would apply on an individual page to page basis, or in this case individual URL (each image having its own URL) basis, you need to decide whether you want those images as part of mobile search results or not.

      If they are that important to you in that regard, allowing access to their root folders shouldn’t be a problem, other than increasing crawl counts. Its not ideal, yet it would be better than keeping everything blocked entirely.

      I am in dialogue with Google about these kind of unique scenarios so we’ll see if we can get clarification from their perspective because I have seen this exact issue.

      • Sam R

        Hi Alan,

        Great article – wish I had found it earlier.

        I’m curious if you have heard any more regarding these unique scenarios. I ran into the same issue with a client and we decided to add “Options – indexes” to the top of the htaccess file to keep Google from indexing these directories. Goal here was to keep these directories off Google’s radar…somewhat of a test that I plan to track after tomorrow.

        My other question – I have pages on a site which are rendered incorrectly within the MFT and ARE considered mobile-friendly, while I have others which render the same and ARE NOT mobile-friendly. There are files I’ve blocked within robots.txt but for this reason I can’t say with confidence these blocked files are directly the issue. Any input here is appreciated. Thanks!

      • Sam,

        I don’t have more clarity on these specific scenarios – unfortunately even though Google now provides several tools and reports for mobile insight, it’s such a complex system and conflicts that come up are so unique where nobody’s yet seen what the actual impact will be, or how to address those situations specifically based on real world work and testing, its just not an easy thing to know how to proceed.

  • Ira Vick


    I am so glad I found this article. I’ve been investigating and running tests for the past few days for multiple sites I manage. I get that the main resource to use here for testing is: the mobility friendly test. Insights and GWT offer great suggestions but ultimately, it seems that the mobile friendly test is what’s going to count. https://www.google.com/webmasters/tools/mobile-friendly/

    My issue is that I am getting inconsistent results using that tool on the same page. I will test a page and it will say “Awesome….” Then, the next day, I will test the same page and it will say that it is not mobile friendly. This really makes testing difficult. I understand that the Insights and Mobile Testing Tool will have different results but is anyone getting different results simply using the Mobile Friendly Test multiple times on the exact same url?

    • Ira,

      That’s the first I’ve heard of a single testing tool giving noticeably different results and yes, that would be a real problem. I haven’t encountered that yet.

  • Hi Alan,

    Alan, can you tell me what would be better. A mobile site or mobile app.

  • Andrew

    This is a great post that lays out different scenarios for the mobile test!

    I tested a site that has responsive design and renders fine on mobile devices and re-sizes in desktop browsers as well. No CSS and JS appears to be blocked, but I received the following error when I test for mobile friendly:

    “The URL was fetched, but nothing was rendered. Ensure that the URL points to an HTML page that loads successfully in a web browser.”

    It only has that message and no further information about what specifically went wrong. Pretty much a blank page.

    Any ideas as to what could be causing this? Thanks!

    • Andrew,

      That’s a 1st for me – I’ve sometimes seen error messages of different types, however they always go away on reload, and no message like that. Do you have Google Webmaster Tools set up? If so have you gone there to look within the “Search Traffic” section, and the brand new “Mobile Usability” report to see if that page is listed?

      Also have you run the page through the “Fetch as Google” tool in GWT (found in the “Crawl” section of GWT)? They’ve just recently updated that tool as well.

      • Andrew


        Thank you for the reply an suggestions. Yes, GWT has been running on the site for many years. There are only 2 page errors in the Mobile Usability Report and they are include content pages for snippets that were recently blocked by robots. No major pages listed in this section as errors.

        I performed Fetch as Google and render as a smartphone and it’s showing that internal pages are redirecting to the homepage.

        This is very odd, because that’s not what’s happening when you actually visit the site on a phone. It’s responsive and Google even shows it as “mobile friendly” in SERPs. The only place I am seeing it as not being mobile friendly is in Google’s Mobile Friendly Tester.


      • Andrew, That’s another one I’ve never seen – where it shows those pages redirect to the home page. Since I’m not a developer I wouldn’t know where to begin to understand how that is possible. I would think that issue would show up in a test with a tool like URIValet.com perhaps, though I just don’t know.

  • I redesigned a site for mobile and launched it 2-26-15 – and it was visited by Googlebot the same day (and I tested it in google’s own mobile testing tool). Today (March 19th) I get a message from Google re 56% of the pages not being mobile friendly. I checked GWT and ALL THOSE BAD LINKS were from BEFORE the date of launch.

    I checked the current cache of the site and last date was yesterday. I also checked indexing of the new site which has all the new pages indexed. However the old pages are also listed even though they have all been 301’s to the new pages (no surprise the way Google has failed at indexing).

    So there might be a bug in GWT re Mobile usability feature that is way behind the indexing of pages.

    • Lori,

      Thanks for leaving this comment. It would not be the 1st time there’s a lag in data.

  • This is a nightmare. We have several of our clients hosted on WP Engine and have discovered that all resources (such as stylesheets and js files) hosted on their CDN are blocked from googlebot. So of course every one of these websites is failing the Google Mobile-Friendly Test regardless of whether there any real issues with the responsive styles we’ve created.

    Truly a mess.

    • Mike
      Is this a WP Engine default setting at the code level? If so, that’s massive on a scale I can’t even begin to comprehend.

    • Hi Mike,

      I’m WP Engine’s web strategist, I’ve chatted with our support team and this is something we can get fixed for you if you contact our team and open up a ticket in our support portal. There’s several things that could be going on and our team would be happy to help troubleshoot. This is not something we do by default, and we’re happy to help it get fixed up.


      • John-Henry
        Thank you for jumping in and offering to help, confirming that WP Engine is a great system with outstanding support!

  • Pete Bruhn

    wow! Great find Alan. I was experiencing a similar conundrum and this competely clears up my issue. Thanks for sharing!

    • Peter

      I’m glad that you found the article and it cleared up your issue!

  • Robb Edwards

    Fantastic information – thank you it explains a lot.

    Now if large men in white trench coats and sunglasses show up at your door – do not answer!!!

  • Alan,
    Love the depth and detail of your article. Do you happen to know how to clear the issues from Webmasters once the “mobile usability issues” (access granted to Googlebot) have been addressed?

    • Havi,

      Once changes have been made on the site to allow access, it is only a matter of time for Google to come back to the site, and discover the changes. There’s no way to speed that up specifically to mobile resource access.

  • Alan,

    Thanks for the article. I’ve been struggling to understand why GWT was saying that I have problems, while GPSI was telling me that my pages are Awesome!

    After tweaking a few Disallows in my robot.txt file, the only resource that is being reported as blocked are now Google’s. I run Adsense and saw 2 resources reported as blocked on all my pages.

    I sure hope they know enough to ignore these resources in the future.

    • Daniel,

      If those are the resources blocked, you’re good to go. They only care about rendering and presentation impact stuff. Ad scripts and other such code is not what they want or need for this evaluation.

  • You can pretty much ignore Page Speed Insights for mobile usability. It only gives you suggestions how to optimize your site in general for speed (in most cases these improvements will be very minor anyway). Just bother about the ‘Mobile Friendly’ test (to which Google now defaults anyway when you click on the corresponding link for the page in the list of pages with Mobile Usability errors.

    • Thomas,

      Yes, it is true that the “mobile friendly” testing tool is the more “accurate” of the two specific to the new factors, however it is not accurate to say that GPSI is actually invalid for mobile “usability” since page speed is a critical aspect of usability. And if a site suffers from speed issues consistently enough, those too will harm its ranking in mobile search as well.

      • I would be the last person to ignore page speed issues. But Google’s GPSI does not address any real issues when for instance it suggests

        “Optimize the following images to reduce their size by 14KiB”

        with the total page size 380KiB. As it is, the page downloads is 1.75 sec (tested with Pingdom speed test) and has a speed index of 82% (both on GPSI and Pingdom). After applying all of Google’s optimizing suggestions (apart from one, see below), the page downloads now in 1.72 sec (so it is practically unchanged) but the speed index is now up to 92%. So it is quite clear that the actual speed improvement (considering the overall size of the page) is not taken into account at all here.

        Most amusing (and revealing as far as the relevance of the GPSI suggestions is concerned) is actually the following suggestion by Google :

        “Leverage browser caching for the following cacheable resources:
        http://www.google-analytics.com/analytics.js (2 hours)”

        I guess I have to take GA off my website if I want to be in Google’s favour.

      • Thomas,
        Obviously, GPSI is far from perfect.

        However on scale, it can be very helpful when Google Analytics shows consistently slow page speeds across actual visitor data.

        Pingdom is the LAST TOOL ON EARTH to trust for page speed evaluations beyond total item weight and a few other helpful insights.

        That’s my opinion, based on evaluations across several web site audits where I tested various tools in a comparison process.

        Pingdom does NOT emulate the same full page process in a way that even comes close to the typical average data Google has.

        The two tools I rely on for actual comparative speed data are URIValet.com (1.5mbps emulator) and WebPageTest.org (DSL and Mobile emulators across multiple different server locations).

        While those systems aren’t perfect either, they are the ones that most consistently reflect averages I find as shown directly in Google Analytics under the Page Speed data charts.

  • I’ve been noticing this same thing, although I don’t think the reason is the same, as I don’t really block much in the robots.txt file. I updated my site be to mobile friendly, however, two weeks later, they show the same number of mobile issues as before. When I check a few pages, they pass and are awesome. However, that tool fails to load most of the time on the Mobile Friendly Test. I just tried the Mobile Friendly Test again, so I could tell you the exact error, and it is “failed to fetch the requested URL”. When I go to this page, it works fine. Either way, I’ve fixed all the errors, and they just keep saying nothing has changed.

    • Steve,

      I too have seen many pages tested that the system comes back with a “failed to fetch” type error. It’s just as troubling because if we can’t test a page we can’t know what Google’s system “thinks” of the page.

  • Niall

    Good report, but to clarify, if a website is ultimately mobile-friendly, regardless of GPSI saying it is or not, does that mean it will be ranked appropriately? Is it simply that we can’t accurately judge for ourselves if a website is mobile-friendly or not, or is it the case that even if a website is ultimately mobile-friendly that it will not rank correctly due to GPSI blocking the robot.txt files?


    • Niall,

      If a page fails the “mobile friendly” test, that, based on all of the information provided at this point, is the determining factor regarding those issues specific to that test. If it fails for speed in GPSI, it may also be negatively impacting mobile ranking, however Google is not (yet) providing clear, specific info on that aspect.

      However since we know speed IS a ranking factor (regardless of device type), it still matters even if the “mobile friendly” test doesn’t account for it.

  • sterg

    My page passed all the online mobile site tests, but still shows up as an error in Webmaster Tools Mobile Usability report.

    I checked fetch as google, to make sure the mobile bot was not blocked by robots.txt and its not. Every tool i use to check it says that its 100% mobile friendly. But just the Webmaster tools Mobile Usability reports says its not.

    Why is this?

    • Sterg

      I’ve seen examples where the data in the GWT Mobile Usability report were based on older versions of pages that had since been worked on. That’s one possibility, however you don’t say that you made any changes so I don’t know if that’s the case for your situation.

      Another possibility is if the Google “Mobile Friendly” test (which has been updated in its messaging since this post went live) shows a page passes even if that page is listed in the GWT Mobile Usability report, check the Mobile Friendly test page to see if, even though it shows as passing, whether it shows on that report page that some assets are blocked.

      I’ve seen some recently where some files are blocked in the robots file or are 3rd party processes where THOSE sites block various files and where the page still passes the mobile friendly test. In those situations, you’re safe – that report is just communicating that some files are blocked, however in that specific scenario, files that are blocked are not negatively impacting mobile friendly status.

      • I’ve tried mobile testing the same website several times in a row, literally one test after the other
        once in a while i get a failed result saying my site is not mobile friendly

        it is a flawed system indeed.

      • Octavio

        I’m not surprised – I too still get a hit and miss situation where an initial test is a fail, then a subsequent test is a pass without logic.

  • Thank you for your excellent article. I have for a month or more had the “Fix mobile usability issues affecting your site”. Each and every time I do the “Confirm that the error still exists” by using the “Check live version” button, I get the”Awesome! This page is mobile-friendly” result. As per your suggestion, I have made sure that my robots.txt isn’t blocking any files related to layout etc. My site is fully ‘Responsive’ and works perfectly on any mobile device. So in summary:
    1. Webmaster Tools says I have Mobile Usability issues.
    2. When I use the provided tool to check if the error remains, Google say’s everything is fine.
    3. Google keeps updating the date (Status) of the last time it saw the error, yet overtime I do the Google Mobility Test, it continues to report everything is fine.

    Can someone please advise what I need to do to resolve this.

    • Anthony,

      The mobile friendly test is the final authority at this point. If that test shows a page is good, there’s nothing else to do. As frustrating as it is to see GWT report problems even though their own testing system shows a page is good, that’s an annoyance we need to accept at this point.

      • Thank you very much Alan. I really appreciate you taking the time to reply.

      • Paul

        Wow Alan, thanks for this great investigative report. I was going crazy trying to figure out why I keep getting the “Fix mobile usability issues” in my GWT when the Mobile-Friendly Test keeps saying “Awesome! This page is mobile-friendly.” Great work! Keep it up!!

      • Just thought I’d update you. After doing little more than simply waiting……GWT now has removed all messages pertaining to my site NOT being “Mobile Friendly”. All my pages now show as “Mobile Friendly” when doing a Google search on a Mobile device. Your article put my mind at ease when I first noticed the issue, and you were 100% correct that the issue would eventually resolve itself. Thank you again.

      • Anthony

        Thank you for updating on your situation. Glad it worked out for you!

  • Excellent article. Although this wasn’t what solved my problem with poor mobile usability according to google.
    In my case it was our Java user agent detector (uadetector) that couldn’t detect googlebot as a mobile unit. Sadly uadetector has not been updated since November 2014 but a quick and dirty fix solved it (at least temporarily). Maybe this will help someone else experiencing similar problems.

    Another thing I’ve noticed is that the test tool provided by google is insanely slow and does not always load all resources, resulting in more errors. I wonder how much affect this can have….

    • Fascinating issue – glad you were able to figure it out and thank you for sharing it here for others who might have a similar unusual challenge!