Ooh forgot to mention you can test your site here

[google.com...]

I'm for it. First of all, all my sites are responsive (though some of my clients are still working on theirs) and second of all, I hate like all getout searching from my phone and ending up someplace that won't render properly. It's as bad as being attacked by popups in my book.

I'm for it too, not only have I got two rebuilds to do because of it but also it just makes sense to do this from a user perspective.

One point needs clarifying:

The "mobile-friendly" imprimatur is for pages, not sites. (That's an important difference for sites where some pages are designed for mobile devices and others aren't.)

A site doesn't have to be responsive to be mobile friendly. You could have different pages under a different sub domain or directory, and it can still be mobile friendly.

you can test your (page) here

Except that as far as I can make out, the only thing this version looks for is the presence of an @media rule involving max-width. Otherwise there's no conceivable reason why every page I tested should come back as "Awesome!" Coincidentally I was in the neighborhood earlier today after deciding after 3+ years that That Table Has Got To Go. In fact I was looking for a thread to ask about it.

There's a bunch more stuff in wmt. Beware of oddly formatted links, so you don't realize everything is clickable. I suppose I missed an announcement; the data only goes back a few weeks.

Edit: OK, I finally found a page that wasn't "awesome!" But it's archived content, so I'm not sure it would even be appropriate to fix it.

You could have different pages under a different sub domain or directory, and it can still be mobile friendly.

Sure. But g### has been saying with increasing insistency that they prefer responsive.

have never found googles page scores are very relevant/accurate

At last! Some recognition by G that mobile search is different from the normal search. Well done G. It has my 100% support.

Yay, half my sites are "Awesome", the other half I knew about and am currently steadily converting them using the same template so within a couple of months I'll be "Totally Awesome" :-)

If you want to see what your site looks like on some phones have a look here:

[mobiletest.me...]

A little boot in the behind from Google, in this case it's not a bad thing. My biggest site is responsive and I am (very slowly) working toward making them all responsive. I guess I will speed up my plans LOL.

I went back and checked some Bad Pages (that is, pages that I know are bad, in some cases intentionally so). Here are all the issues I can find:

-- Mobile viewport not set
-- Content wider than screen
-- Links too close together
-- Text too small to read

Are there any others?

"Mobile viewport" is easy. It just means there's a viewport meta. It only has to say device-width; they don't care about initial-scale even though it's included in all their examples. In fact it's possible that the meta only has to be present, period, and they don't actually check for content.
"Content wider than screen" is a little perplexing. It obviously means images of some explicit pixel width-- but what's the cutoff? It isn't simply the width of a phone screen in portrait mode. Is it the width in landscape mode? (A 640px div triggers the warning, while images that visibly don't fit in their screenshot are accepted.)
"Links too close together" is explained pretty clearly in one of their wmt pages (which I can't find now, but it goes into much detail about pixels and millimeters).
"Text too small". This one's a complete mystery to me. I've never, ever, anywhere expressed font sizes in any absolute value (points or pixels), but evidently I've done something to offend them. It shows up even in pages that don't mention anything about font-size at all.

Further experimentation shows that the last two items-- "links" and "text"-- disappear if you simply add a viewport meta while changing nothing else. So there would appear to be a few bugs to work out.

This is a good move... it really is all about user experience.

I have to admit I had been sitting on this idea for at least a year. Rolled out a responsive design in September. Timing worked out well.

@Lucy24 320px is the cut off. That's from WMT...

I currently have 8 different client sites running that I built from scratch and which their owners still allow me to watch over, and none of them are responsive. All, though, were also built from scratch always keeping in mind how common sense foundational structure plays from the very beginning into the mobile picture. I don't even bother anymore, really, to check my builds in a mobile editor as I'm developing.

The 9th site will launch day after tomorrow and I took advantage of the OP's Google mobile friendly link to see how it looks on a mobile for the very first time - it's gorgeously perfect. I also ran the other 8 through and they all came back quick and AWESOME!

One of these days I'm going to run across a client who wants to almost fully focus on a mobile site and I can't wait 'cause I think I already have half the job done. :)

I went back and checked some Bad Pages (that is, pages that I know are bad, in some cases intentionally so). Here are all the issues I can find:

-- Mobile viewport not set
-- Content wider than screen
-- Links too close together
-- Text too small to read

Are there any others?

I cheated and found the json response. The call returns the same 5 rules/scores for every site, even passing ones. The UI only displays failing rules. It appears to be a very small subset of the larger pagespeed API.

You only missed one rule.


"ConfigureViewport": {
"localizedRuleName": "Mobile viewport not set",
"groups": [ "USABILITY" ]
},
"UseLegibleFontSizes": {
"localizedRuleName": "Text too small to read",
"groups": [ "USABILITY" ]
},
"AvoidPlugins": {
"localizedRuleName": "Uses incompatible plugins",
"groups": [ "USABILITY" ]
},
"SizeContentToViewport": {
"localizedRuleName": "Content wider than screen",
"groups": [ "USABILITY" ]
},
"SizeTapTargetsAppropriately": {
"localizedRuleName": "Links too close together",
"groups": [ "USABILITY" ]
}

In my test result I get the message: "Awesome! This page is mobile-friendly." but never received any notice from Google to that effect.

The problem is, for my vertical mobile users are not my targeted audience and are typically not buyers. As all of us lemmings race over the cliff to comply, G will likely soon announce a penalty related to your use of a responsive site. Not sure what that might be, but I've been conditioned to expect the worst.

The problem is, for my vertical mobile users are not my targeted audience and are typically not buyers.

Google has said that mobile-friendliness may become a ranking factor in mobile search. If you don't care about traffic from mobile searchers, why "race over the cliff" when you don't have to?

Responsive means that G only have to keep one version of the site / page in their data bases, and thus rank and search etc just the one version..

A separate version for Desktop and another for Mobile means they have to keep two..

Keeping two versions per site / page costs them far more than keeping one ( memory, access , algos, DCs,power etc etc )..multiply by all the sites / ages that they crawl and index...

Pushing everyone to use responsive is good for G's accounts..and "what is good for M&M enterprises, is good for everyone"..

Pushing everyone to use responsive is good for G's accounts..and "what is good for M&M enterprises, is good for everyone"..

If Google wanted to save money on crawling, storing, and indexing, it could find far simpler and more effective ways to do that than encouraging people to use responsive layouts. And if Google really wanted to force responsive layouts down Webmasters' throats, it wouldn't offer the "two-URL" option.

In any case, responsive layouts aren't the optimum solution for every site or every kind of content. On our main site, which is designed largely for people who like to read and are looking for in-depth content, having dedicated, hand-edited mobile versions of our most popular pages is a more useful and practical approach, because it eliminates the need to "dumb down" content or make other compromises that might disappoint desktop, laptop, and table users. On our newer (and specialized) ancillary site, which is geared to smartphone users and people who prefer a Cliff's Notes-style editorial approach, a responsive layout is ideal. Different audiences, different sites, different approaches.

I did not say forcing, I said pushing..the two words do not mean the same thing..

My sites are responsive ( and have been since long before G began "pushing" responsive ) but I didn't see the need to talk about my sites at length to make my point..which is that G are pushing responsive in order to help themselves for many reasons, they have, for example the dominant* mobile platform / OS..which has their search engine ( data gathering, ad platform ) installed as default..which is another reason why they would prefer "responsive sites"..G search is far more "dominant" on mobile than it is on desktop, despite their huge share of the desktop search market worldwide.

*85 % market share Q 2014 ..

[en.wikipedia.org...]

+1 to Google for this. In this day, I don't see why any serious website owner would not allow their website to render properly in mobile browsers.

Different audiences, different sites, different approaches.

Yep, it took me two years of html5 responsive template experimentation before I was finally happy with what I'd got for my multi page sites. For my splash page sites I found a beautiful template which works perfectly across all devices as well...I dread to think just how many hours I spent on research and testing, it must be well into the hundreds, and then the construction of them adding loads more hours!

I couldn't have afforded to outsource this work plus those I did talk to definitely knew a lot, lot less than me.

On September 2014 Android's global market share rose to 85%

I suppose we "have" to assume from that that most people use their default Google search, not me I'm on a Win8 Lumia with Bing:-)

What made me move to responsive originally was watching how people "window shop" on mobile devices, while doing other things..suits my ecom sites..sites / carts have to be streamlined to work on mobile devices ..But as with many other things "Less is more"..

Responsive adsense sites ?..Yes, but, I'm still convinced ( even though they work ) that most clicks on ads are accidental..I like the revenue..But I would hate to be paying for ads displayed on mobile..may as well burn money..

G pushing responsive is good for them ..and website owners..

Yep, it took me two years of html5 responsive template experimentation before I was finally happy with what I'd got for my multi page sites.

One challenge (for informational sites with heavy text content) is paragraph length. A paragraph that looks fine on a desktop, laptop, or tablet may be hard to read on a typical mobile phone, and a paragraph that looks fine on a mobile phone may look like a verse from the King James Bible on a larger device.

This really isn't much different from the situation in print. Paragraphs in a book can be readable at a length of several hundred words, but in an eight-column newspaper layout, paragraphs become hard to read if they're more than a few sentences long.

I suppose it would be possible to have a program that arbitrarily chopped paragraphs into shorter chunks for mobile devices, but the result would be horrible editorially. Sometimes, hand-editing for each type of device is the best solution.

G only have to keep one version of the site / page in their data bases, and thus rank and search etc just the one version

It is not always the case that what's good for g### is good for webmasters. But here I think they're right. From the search engine's point of view it's just a few one-time directives sent out to assorted robots and computers. For a webmaster, there really is a lot of extra work involved in maintaining multiple sites-- where "extra work" means either money to a developer, or more of your own human time. If you do want something mobile-specific, may as well go whole hog and build an app.

"AvoidPlugins": {
"localizedRuleName": "Uses incompatible plugins",
"groups": [ "USABILITY" ]
}

Well, no wonder I missed the fifth option. This is a CMS thing, right? In practice you're left with two things: include a "viewport" meta, and do something about oversized images (so far, they don't seem to care about backgrounds, regardless of size).

I suppose it would be possible to have a program that arbitrarily chopped paragraphs into shorter chunks for mobile devices, but the result would be horrible editorially. Sometimes, hand-editing for each type of device is the best solution.

.linebreak {display: none;}
@media screen and (max-width: 480px) {
.linebreak {display: block}
}

That's just off the top of my head. There are probably half a dozen other approaches.

To fix the complaint "Content wider than screen" I changed

#container {margin:0 auto;width: 1024px;text-align: left;}
to
#container {margin:0 auto;max-width: 64em;text-align: left;}

Changing from px to em was just a nod to modern times; it didn't have an influence on the outcome.

I suppose it would be possible to have a program that arbitrarily chopped paragraphs into shorter chunks for mobile devices, but the result would be horrible editorially. Sometimes, hand-editing for each type of device is the best solution.

There are algorithm-based text summary tools. The most popular open source one is called "Open Text Summarizer". It's hosted here: [libots.sourceforge.net...]

Text summary tools don't (at least the ones I've used) actually paraphrase the text. Rather, they select a few sentences from the body that can be put together and form a reasonable summary.

They can produce bad results, but I was pleasantly surprised how well OTS did.

Not saying it's the right approach for mobile, but it can be handy for things like creating meta descriptions, provided you review and edit anything that's off.

To fix the complaint "Content wider than screen" I changed

Heh. I never, ever set text element widths in pixels. Never did, never will. Percent or em only. So the content-width issue for me is strictly limited to actual image sizes, where width and height declarations have to be retained for the sake of overall rendering efficiency. Still trying to work out the appropriate cascading of width and max-width, short of shifting all images to background, which would be a pretty grotesque workaround. (I actually did do this on one-and-only-one page, but there it was for motives of reduced download.)