Google Emailing Non-Mobile Friendly Sites

[ZydoSEO]

Not sure if anyone here has seen one (first I've heard of it), but Google has emailed a friend of mine basically telling him that his site was a non-responsive site and that as a result it would do poorly in search results for searches performed from mobile devices.

I wonder if emails will go out about HTTPS as well.

Trying to get a copy of the exact email.

[minnapple]

Robert,

I really don't remember what I paid for cs6, I updated my old Photoshop version at the same time.

For ecommerce sites I have worked with bigcommerce.

I think the key for ecommerce is offering a package of consulting and hands on work. Teach them how to add products, and you build the structure of the site and suggest roi improvements using Analytics and testing.
And the product research.

Tomorrow, I will be working with a very old client on setting a game plan how they can take on the management of their site and defining their responsibilities and mine.

The need for responsive design is obvious, today one of my larger ecom clients did 60% of their through mobile.

[MikeNoLastName]

As far as using <FONT... it ain't broke, and you can certainly write "responsive" pages with it (you just need to be a little smarter than the average bear and use [let me know if you cringe] <IMG/TABLE ALIGN=LEFT/RIGHT a little more) so why change...

Many (I'm talking 1000's) of our pages were written in the 90's from scratch (before Dreamweaver, etc) with 640x480 and later 800x600 as our standard and we greatly resisted large bulky graphics, so we weren't AS far off from 320 as some sites. A lot of pages change daily, so we have made an effort to bring those pages up to G's latest standards (though it doesn't seem to help ranking any.) Making separate pages for desktop vs mobile would mean maintaining all the info changes in two places (or using file includes - are those still allowed/considered good form these days?) G keeps insisting we should create GOOD, NEW content, why do they go around making us waste time constantly rewriting the old? Especially when the NEW equipment is inferior to the old (e.g. 320 vs 640 - learn to turn your d--- device 90 degrees and stop whining). G will soon come to their senses, when the next generation of higher res tech comes out. Like someone said, it's not necessarily a penalty, simply a strong suggestion if you want to get in on the CURRENT mobile rankings. I don't have too much trouble hopping over an iteration and instead being ready for the next big thing with more and better content.

Our industry in particular, by it's very nature, would probably benefit a lot from catering to hand-helds, but most of our clients/affiliates are resisting the change (many big corps are slow in listening to their more up-to-date marketing reps, especially when they are in high turn-over industries.)

WE didn't receive any e-mail letters about this, that I know of, but DID notice the multi-screen notice on our Adsense dash-board at 4 dots instead of 5, got curious and proceeded from there. Which is why I dropped into this thread. In fact upon running many of our older pages through G's pagespeed insights for mobile, over half came out in the low greeen/high organge rank, and mostly only needed the "Configure the viewport" line added. Nowadays the biggest ranking devaluator we seem to get (on both mobile and desktop) appear to be from the speed side with GAdsense graphics and scripts needing optimization and minifi-zation which we have no control over, like:
"Optimize images
Properly formatting and compressing images can save many bytes of data.
Optimize the following images to reduce their size by 925B (5% reduction).
Losslessly compressing ht tp://pagead2. googlesyndication. com/.......... could save 925B (5% reduction)."
and
" Minify JavaScript for the following resources to reduce their size by 515B (2% reduction).
Minifying ht tp://pagead2. googlesyndication. com/..../expansion_embed. js could save 515B (2% reduction) after compression."

[keyplyr]

As far as using <FONT... it ain't broke, and you can certainly write "responsive" pages with it (you just need to be a little smarter than the average bear and use [let me know if you cringe] <IMG/TABLE ALIGN=LEFT/RIGHT a little more) so why change...

Why change? Because at some point deprecated tags will no longer be supported by browsers. This is especially true for mobile browsers. Let go of archaic thinking, move to HTML5, use divs instead of tables, etc. You will be glad you did.

[EditorialGuy]

Why change? Because at some point deprecated tags will no longer be supported by browsers.

We'll see. There's a lot of content on the Web that was created before CSS came along. Much of it is still useful, and much of it will remain useful for years or even decades to come. If the search engines find such legacy content worth indexing, then why would a browser maker (especially one that, like Google or Microsoft, owns a search engine) be so arrogant as to ignore it?

Let go of archaic thinking, move to HTML5, use divs instead of tables, etc. You will be glad you did.

It isn't quite that simple. Many information sites, especially those that existed before Content Management Systems and blogging platforms became commonplace, have static pages from 10, 15, or even 20 years ago. Those older pages may not attract enough traffic or revenue to justify updating them to today's Web standards, but if some readers find them useful or interesting, then it would be a shame to discard them. Besides, those pages are part of the Web's history. (I'm sure that my 28-year-old son will someday get a kick out of the Star Trek fan site that he wrote when he was 10 years old, and which is still on the Web.)

[RedBar]

Let go of archaic thinking, move to HTML5

Awhile back I knew that I would have to do this, I spent a couple of years playing with it, I had some disastrous in-house explosions!

However I persevered, what I had seen was fabulous, what I didn't know was how to do it and fit it in with my agendae.

Being a siver surfer geek I needed to know, I learnt it and I have to say to anyone wondering about the switch, do it since you will regain so much of your coding life you will simply not believe it.

I do everything html5 in a text pad, it rocks, honestly, plus dragging files into a browser and seeing the site:-)

Yes EditorialGuy, all the older stuff still, for me, works on new and older browsers, even my html5 sites I still test on Navigator and they all work perfectly, that surprised me.

[ning]

The email is genuine, but on all my sites it's false positives, all my sites are responsive design. Just my 2 cents.

[nomis5]

use divs instead of tables, etc

#

As of now, there are many instances where tables are the appropriate and best way to code some content.

You'll be waiting a very, very long time before using a table has any detrimental effect on how a page ranks, displays in the major browsers etc.

Effort put into html5 is not inherently beneficial, only where it warrants the effort.

[EditorialGuy]

There's a tendency among tech people to obsess about the "how" at the expense of the "what."

The "what" is what searchers (and search engines) are interested in.

[IanCP]

Many information sites, especially those that existed before Content Management Systems and blogging platforms became commonplace, have static pages from 10, 15, or even 20 years ago. Those older pages may not attract enough traffic or revenue to justify updating them to today's Web standards, but if some readers find them useful or interesting, then it would be a shame to discard them.

My sites fall into that category.

When they are found to be no longer useful - no traffic - then I'll remove them.

All the gee, whizz, bang setting out isn't going to change the content value one iota. Most pages are printed out by visitors as references.

[keyplyr]

You'll be waiting a very, very long time before using a table has any detrimental effect on how a page ranks, displays in the major browsers etc.

Tables do not display well on mobile browsers with various screen sizes/resolutions. Considering the huge amount of mobile traffic nowadays, I consider mobile browsers to be major browsers (and the reason for this thread.) Google has indicated the search ranking will be affected for sites that are not mobile friendly (email.) I am seeing this already.

However, there is a way to make tables mobile responsive somewhat (scroll) but the page would also need to be mobile responsive.

Effort put into html5 is not inherently beneficial, only where it warrants the effort.

One can always justify/rationalize why currency is unnecessary, meanwhile things move forward and leave you behind. Your site, your choice.

[EditorialGuy]

One can always justify/rationalize why currency is unnecessary, meanwhile things move forward and leave you behind. Your site, your choice.

It's worth noting that Google indexes pages, not sites.

If some low-traffic, low-revenue legacy pages get left behind in mobile search, that may be just fine.

[minnapple]

I can see keeping old content coded as is. Consider it historical. Create new content using the current standards. That is my opinion on this subject.

[IanCP]

Sensible.

[keyplyr]

It's worth noting that Google indexes pages, not sites.

It's worth noting I didn't say Google indexed "sites."

[lucy24]

Tables do not display well on mobile browsers with various screen sizes/resolutions.

Here, too, semantics and presentation are different things.
<tr> != {display: table-row;}
<td> != {display: table-cell;}
I have a lot of stuff involving parallel translations or parallel MS readings. Most of the time it would be just plain silly to put the text in something other than a table; you'd lose all information about relationships. But that doesn't mean the columns have to be half an inch wide when viewed on a telephone in "portrait" mode.

[keyplyr]

Here, too, semantics and presentation are different things.

However, there is a way to make tables mobile responsive somewhat (scroll) but the page would also need to be mobile responsive.

The point is, many archaic pages are built using tables as page structure. This doesn't work well for smaller mobile devices.

Most of the time it would be just plain silly to put the text in something other than a table

Tables used as charts, information comparison, etc on mobile friendly pages is still doable but need to be responsive to screen/resolution size. However, a better choice for mobile pages would be to use divs with the presentation defined in CSS. You can make them look exactly like a table if you absolutely have to or you can be much more creative.

[lucy24]

You can make them look exactly like a table if you absolutely have to or you can be much more creative.

I don't see why I should go to the extra work-- including extra overhead in the source code-- of making nested divs look exactly like a table, when I can just use a table in the first place. The table can then easily be made to look like something else if a different layout is needed.

:: still waiting for browsers to support five-dimensional display, which I badly need for certain types of grammatical material ::

[keyplyr]

I don't see why I should go to the extra work-- including extra overhead in the source code...

Because divs work better (and IMO easier) in a mobile responsive layout, this is about responsive mobile support. If you are not making your pages mobile, then I wouldn't change your tables either.

However, if you are making mobile responsive pages and still wish to use tables, there's good info if you search for "Responsive Data Tables CSS-Tricks"

But you are correct, having a page that is responsive to desktop, various size tablets and various size phones does increase source code, increases CSS and adds a couple scripts. However, I have not seen any negative issues whatsoever. My pages load very fast and Google Pagespeed gives the highest rating.

[nomis5]

One can always justify/rationalize why currency is unnecessary, meanwhile things move forward and leave you behind. Your site, your choice.

Currency is of course necessary, but html5 is not the currency of the web. Web pages that attract users and keep them engaged are the currency of the web.

I still use the wheel even though it is thousands of years old because ... in many circumstances it is the best solution.

[keyplyr]

I still use the wheel even though it is thousands of years

I think the wheel will be included in HTML5.5

[EditorialGuy]

Just for old time's sake, does anyone want to argue about hand-coding vs. WYSIWYG authoring tools, whether or not to use frames, or whether pages assembled on the fly are better than flat files?

[lucy24]

Another day, another wild conjecture: They're sending the emails alphabetically. I just got one for a site whose name begins in F. (Dunno what this says about the art studio's site, whose name predictably starts in A. It's a dot org. Maybe they come later.)

Google systems have tested 92 pages from your site and found that 35% of them have critical mobile usability errors.

Once again I am at a loss to understand Google's arithmetic, since GWT claims the various issues were found in 14, 19 or 24 pages.

As I expected, most gripes involve ebooks and archival pages which I can hardly change, since in many cases the whole point of the archive is "look how awful this page used to be". But I'd actually forgotten that one directory doesn't share styles and was therefore missing a max-width declaration on images. Er, thanks, Google. I guess.

I do have an extraordinarily strong mental image of people in Mountain View sitting around cackling insanely and rubbing their hands.

[Bluejeans]

I never received a message or email but nevertheless I implemented a redesign at the end of last year to make most pages pass the "mobile-friendly" test. All was well and I changed nothing but today found that the same pages with the same design are suddenly not mobile-friendly, according to the tool. Have they moved the goalposts? Very discouraging.

[keyplyr]

IMO the goal is not whether your page can pass the mobile friendly test, but whether your pages are truly friendly to your visitors who may be using a variety of mobile devices.

First thing I did after launching a few redesigned pages was to go to my local Best Buy store and view my pages on a dozen different mobile appliances. I then stopped by the Apple store & did the same.

IMO the free online mobile emulator tools can help, but to really see how your mobile pages display & behave, I needed to use the actual device.

[lucy24]

Wait, I've got another question. Earlier in this thread there were people who got The Email in spite of not having GWT.

In the version I got, there are two clickbuttons. One for "inspect mobile issues" and one for "follow our guidelines". Both are in the form
[google.com...]
followed by a bunch more stuff looking suspiciously like Base64. The first one ends up on GWT for the site named in the email. The second ends up on the Web Fundamentals page. Where does the first link take you if you don't have GWT? And, for that matter, what's all the stuff in the second link for, if you're just going to end up on a generic page? Do you suppose they're first logging the fact that you, specifically, have clicked on these links?

[nomis5]

Another day, another wild conjecture: They're sending the emails alphabetically.

That matches what I'm seeing with my sites, they are up to J now! Might just be coincidence but that's how it looks here.

[EditorialGuy]

That matches what I'm seeing with my sites, they are up to J now!

My first name, last name, and main domain all come before "J" in the alphabet, but I haven't received the e-mail. Nothing in Webmaster Tools, either. I feel like the kid who didn't get invited to the birthday party.

[keyplyr]

I haven't received the e-mail

That's what I thought

[RedBar]

I feel like the kid who didn't get invited to the birthday party.

That makes two of us, let's organise our own!

[Brian]

What's worrying by the message - at least the way I interpret it - is that Google appears to be threatening to rank what it regards to be "mobile unfriendly" pages differently on phones than it ranks them on PCs.