Google To Expand Mobile Friendliness As A Ranking Signal

[travelin cat]

The time to make sure your site is mobile friendly is approaching!

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.

[googlewebmastercentral.blogspot.com...]

[keyplyr]

Right now, if you do a google search using a smartphone or similar, do you get some kind of indication on the SERP about mobile-friendliness?

A lot of work was done to enable my mobile responsive site to display pretty much the same on desktop or tablet, even small 7" tablets (just a little thinner.) I even use the same Ad campaigns. Likewise, searches from tablets give me much the same SERP as those done on desktop AFAIK. I don't notice any change *yet* and don't know if there will even be much of a change. I know tablets are considered "mobile" but IMO they are more like a smaller screen desktop than a phone.

Smartphone are a completely different result. My mobile responsive site changes significantly from phone to phone depending on screen resolution and/or size. Searches from my phone, and other phones I have tested on, give a different SERP than desktop/tablet on both Google & Bing, however Google seems to give more weight to mobile friendly pages and displays the "mobile friendly" tag (or whatever the exact wording in) next to those results that qualify. Note: listings with the mobile friendly tag are not always high ranking but I do notice this tag more in the high ranking sites. This is what I see now from SoCal.

Now the question is, how to make Google re-crawl my new mobile friendly code. Any ideas?

Remove your cache-control (ideally it should have been removed 30 days ago) then update the dates in your sitemap.xml and resubmit it to GWT, wait a couple weeks until you see SERP update all pages, reinstall cache-control :)

[graeme_p]

In fact I went to great pains to be sure my site looked and behaved identically across desktop and mobile browsers. Now I'm effectively being required to maintain 2 versions of my site instead of 1 version that works everywhere.

Why? I do not understand this at all. A responsive site works everywhere.

Me too. That's why I don't want to set a meta viewport. As long as I don't set one, the page fits the browser window perfectly every time. No horizontal scrolling needed. But not setting one means I fail Google's mobile-friendliness test.

It fits perfectly and the content is readable?

[keyplyr]

That's why I don't want to set a meta viewport. As long as I don't set one, the page fits the browser window perfectly every time. No horizontal scrolling needed. But not setting one means I fail Google's mobile-friendliness test.

Then try: <meta name="viewport" content="initial-scale=1">

[Kratos]

keyplyr, what do you mean by cache-control? I don't think that's anything to do with WMT, so are you referring to any 3rd party script installed in the website of the person you wee responding?

Also, is it really that important to resubmit the sitemap.xml considering that Google is fast to re-crawl the site after making the site mobile friendly? It only takes a couple of days to re-crawl a whole site in some cases that I have.

Would appreciate an answer to the above. Thanks!

[keyplyr]

keyplyr, what do you mean by...

Nutterum asked for suggestions, YMMV.

[EmptyRoom]

I run an informational site. 97% of my visits come from desktops and only 3% are mobile. Should I worry if I don't change anything? My site is not mobile friendly.

I don't quite understand... does this change affect only mobile searches, or it's going to affect desktop searches as well (SERP's, that is)?

[Tonearm]

That's why I don't want to set a meta viewport. As long as I don't set one, the page fits the browser window perfectly every time. No horizontal scrolling needed. But not setting one means I fail Google's mobile-friendliness test.

Then try: <meta name="viewport" content="initial-scale=1">

Same problem there unfortunately.

[EditorialGuy]

I don't quite understand... does this change affect only mobile searches, or it's going to affect desktop searches as well (SERP's, that is)?

Mobile searches. (Not desktop.)

[lucy24]

cache-control

And then, of course, you'll get other tools yapping at you about not caching content to save download time ;)

:: idly wondering why Tool That Shall Remain Nameless persists in thinking that /piwik.php with a query string eight miles long is "static content" on a parallel with images and stylesheets ::

[keyplyr]

I run an informational site. 97% of my visits come from desktops and only 3% are mobile. Should I worry if I don't change anything? My site is not mobile friendly.

Your traffic may be 97% desktop BECAUSE you don't support mobile :)

Note: The cache-control suggestion is just *slightly helpful* with browsers getting new content, that which now is mobile. The validation tool may fault you, but this is temporary as you will reinstall the cache-control setting soon. Besides, the tool demotions do not hurt ranking, only if the page is not mobile friendly AFAIK.

[londrum]

Same problem there unfortunately.

Try <meta name="viewport" content="width=device-width">

[lucy24]

Try <meta name="viewport" content="width=device-width">

I think that's where we came in.

If you don't set a viewport meta at all, you can rely on the mobile-friendliness tool to yap about touch targets being too close together. Sure, people hold their tablets close and their phones even closer-- but that doesn't make their fingers correspondingly skinnier.

:: vague mental association with Hansel and Gretel ::

[keyplyr]

Try <meta name="viewport" content="width=device-width">

Well if you are not sniffing for device width & don't have the corresponding CSS then device-width is irrelevant IMO.

[Tonearm]

Try <meta name="viewport" content="width=device-width">

Same thing. If I set any of these then my design breaks, but it works great without setting a viewport at all:

<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="viewport" content="width=device-width" />
<meta name="viewport" content="initial-scale=1" />

[keyplyr]

Same thing. If I set any of these then my design breaks, but it works great without setting a viewport at all

These suggestions were to possibly get past the mobile friendly test. Obviously there is a lot more to it to get your site *actually* mobile friendly. When all else fails, sometimes ya just gotta do the work :)

[Nutterum]

@keyplyr - thanks for the suggestion. Might consider trying it out if Google Bot does not pay me a visit over the weekend.

What I did was manually submitting 100 or so pages and all the main category pages being submit + crawl direct link option on. This will hopefully speed up the process.

As for the viewport problem being discussed try :
<meta name="viewport" content=width=device-width, initial-scale=1, minimum-scale=1" />

works like a charm for me.

[Tonearm]

<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1" />

This also zooms way in on the upper-left hand corner of the page for me. Is there any way to set the viewport and tell it to behave the same way it does when unset? Then I could satisfy Google's "configure the viewport" requirement and my design wouldn't break.

[rish3]

Is there any way to set the viewport and tell it to behave the same way it does when unset?

<meta name="viewport" content="" />

Or, you could set it in the html, and empty the content on page load with javascript. An example...assumes you use jquery already.

<script> 
$( document ).ready(function() { 
 $('meta[name=viewport]').attr('content', ''); 
}); 
</script> 

[keyplyr]

zooms way in on the upper-left hand corner of the page

That's probably what most mobile users see at your page if you have not designed specifically for mobile. How many different size mobile devices have you tested on? Clearing cache and reloading page each time?

[ecommerceprofit]

The data is in for 7 days...my mobile ad conversions are in the tank. For 4 months I reduced my mobile cost per click by 50% as compared to desktop. Now I am reducing it to 100% for the weekend. I'll then make my site "non mobile friendly" again and see what happens.

The interesting thing though is my organic conversions for the week are higher than normal...will be interesting to see if organic conversions go down and mobile ad conversions go up after the change...

[keyplyr]

my mobile ad conversions are in the tank... I'll then make my site "non mobile friendly" again and see what happens.

Why? Just change your mobile ad campaigns to ones that return better numbers.

I use 3 different campaigns. One for desktop/tablet, one mobile-responsive and one 320x100 mobile banner.

[Tonearm]

<meta name="viewport" content="" />

That doesn't fool Google unfortunately.

That's probably what most mobile users see at your page if you have not designed specifically for mobile. How many different size mobile devices have you tested on? Clearing cache and reloading page each time?

It renders great even on Google's mobile renderer at developers.google.com/speed/pagespeed/insights. Google says:

"Your page does not have a viewport specified. This causes mobile devices to render your page as it would appear on a desktop browser, scaling it down to fit on a mobile screen. Configure a viewport to allow your page to render properly on all devices."

I was actually able to pass mobile-friendliness by increasing font sizes. Now if I could somehow set the viewport to satisfy Google and keep the current rendering behavior then I could increase my score above 85.

[keyplyr]

Well you never know just how your pages look/perform on the various mobile devices until you actually test on them. Unfortunately the online mobile simulators aren't very good, even Google's.

Just to reiterate: If I open a page on my phone that requires horizontal scrolling or the small text size requires zooming-in, I will immediately go to another site. This high bounce rate is exactly the behavior I used to see in my site's logs prior to rebuilding as mobile-responsive.

[RedBar]

Just to reiterate

I agree, I will maybe use a one finger double screen tap to see if it works however usually I'm gone.

[guggi2000]

...mobile-friendliness as a ranking signal...

Looking beyond April 21st!

A few questions:
1. Do you think it is a binary signal (friendly or not friendly) or that Google actually uses the score from Pagespeed Insights (or any internal, equivalent tool that they have) to fine-tune the SERP?

2. What about the "Page Layout Algorithm"? Do you think 1/3 of space taken by ads on mobile will hurt ranking or even result in a penalty in the near future?

3. Hiding content: With responsive design you usually hide content compared to the Desktop version. Will the difference in visible content (between Desktop and Mobile) have an impact on mobile ranking? (As in: "Hey, this is a completely different page on mobile")

Thoughts?

[lucy24]

or any internal, equivalent tool that they have

I'm not sure how we ended up with two parallel threads [webmasterworld.com] on the same topic. PSI is just informational, kinda like the assorted Previews they've used in recent years. The real version is the Mobile-Friendly test [google.com] based on what the mobile googlebot sees. That's according to google themselves. (The MFT link is a little obscure; you only see it when they warn that your PSI score for a particular page is not-too-good.)

Although PSI gives you a numerical "score", the Mobile-Friendly Test comes down to Yes or No.

---

Is this the first time in Google's history that they have gone to great lengths to contact individual webmasters far ahead of time before launching a change?

[keyplyr]

The real version is the Mobile-Friendly test [google.com] based on what the mobile googlebot sees.

Where does it say this tool is "based on what the mobile googlebot sees." I don't believe it is. However, I guess any parsing tool built by Google could be described as Googlebot based in a sense.

(The MFT link is a little obscure; you only see it when they warn that your PSI score for a particular page is not-too-good.)

I see a huge difference between the mobile-friendly tool and PSI, so to throw them together in an explanation doesn't work for me.

IMO the mobile-friendly tool is mediocre at best. A page can pass its scrutiny with a superfluous meta tag and a couple font size & max-width tweaks, yet look and perform badly on various mobile devices. It is also my opinion the so called mobile-friendly tool was made this forgiving as to entice more webmasters into taking the plunge, that once started, we would continue to improve mobile support. So in the end, this tool is a good thing (maybe.)

The PSI tool OTOH is a great help and much more diagnostic. However it has a lot of shortcomings itself - like warnings about too much CSS or JavaScripts in the HEAD slowing down load time but not considering the benefit of caching (just one example.)

[keyplyr]

I see the mobile-friendly tool page has added more context and a cute mobile phone graphic "How Googlebot sees this page" which wasn't there the last time I looked at it. The resource links are a good addition as well but the tool itself remains little more than a basic check, which IMO can mislead a webmaster into a false sense of compliance if no real world testing is done to ensure support for the many mobile devices in use today.

[lucy24]

I see a huge difference between the mobile-friendly tool and PSI

Well, yes, that's the irony: PSI gives more and better information. But it's based on what a human sees-- always assuming the human user's system has only one font* installed-- and therefore by definition can't be used in a global automated process. The key difference imo is that the MFT is constrained by robots.txt:

This page uses one resource which is blocked by robots.txt. The results and screenshot may be incorrect.

Thanks to piwik, all my pages everywhere get this message. What, exactly, "results ... may be incorrect" means is a little worrying, though. It's all well and good if it leads to false positives (thinking a page is mobile-friendly when it isn't); false negatives (failing a page that's actually fine) would be bad. They seem to work on the assumption that unavailable assets would have no effect, which I guess is the only assumption they can make. I think webmasters would be up in arms if any search engine-- even Google-- decreed that all pages will count as failing the test unless you let our robot run wild.

a false sense of compliance if no real world testing is done to ensure support for the many mobile devices in use today

If webmasters wanted to be mobile-friendly they would be, google or no google. This is just about search-engine rankings.

Where does it say this tool is "based on what the mobile googlebot sees."

It's easier to test this if, like me, you have a small infrequently-crawled site. I just ran the test on a randomly selected page that never changes. Logs show a visit by

Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

immediately preceded by a robots.txt request (from, interestingly, the vanilla googlebot).


* Possibly Roboto ;)

[keyplyr]

Thanks for the confirmation regarding Googlebot.

Thanks to piwik, all my pages...

Never used piwik, but in the past I have used several different 3rd party site activity report services, even Google Analytics (GA.) Some were actually pretty good and furnished a quick glimpse of traffic, but I stopped using them because of the ever impending issue with additional HTTP connections. IMO the fewer connections needed, the better. This is especially true for mobile.

GA would sometimes hinder the page from loading until that HTTP connection completed. Some reports services would cause other problems because of the JavaScript. The additional JavaScript is another issue for mobile where the fewer scripts, the better.

All in all, I now keep it off my pages and just run the raw server logs through a bit of my own code on my local machine and get everything I need.