Google doesn't see mobile site... Ways to handle mobile pages?

[smilie]

Hi guys,

I am sure this has been discussed, can't find it in a search on WebmasterWorld. So maybe you'll point me to the right direction or threads.

Google doesn't seem to see a mobile version of a site. Right now it is designed for users , and it is part of a larger platform (but I have access to make changes). The way it is implemented is in two different skins, when user clicks on "mobile site" the are redirected to the same page with a parameter, say:

www.example.com/thispage.htm?skin=2

to get to mobile, then in order to get back it is this:

www.example.com/thispage.htm?skin=1

The skin parameter then is in cookies, and all other URLs do not have it. So that may be a reason in GWT there's a big note, and it says "fix mobile usability issues".

I can probably make mobile appear on a new domain, like m.example.com , some coding will be required.

Any ideas?

[edited by: not2easy at 7:14 pm (utc) on Aug 19, 2016]
[edit reason] please use "example.com" for examples [/edit]

[londrum]

presumably the mobile version has its own CSS. you just need to make sure that it has it's own <link> in the HTML, and a mobile viewport set.

something like this:

<meta name="viewport" content="width=device-width">
<link rel=stylesheet type="text/css" media="screen and (max-width: 760px)" href="blah/blah.css">

you don't really need to do it with cookies (i think that would cause you extra problems, if that was the only way you were checking it), but i suppose you could check for the cookies with PHP, if you wanted, and then auto-include those lines

[smilie]

It's actually more than it's own stylesheet. It's the whole folder of stuff, separate skin.

All includes change, such as on main site they are
/skin1/style.css
/skin1/somejs.js
etc. while on mobile they are:
/skin2/style.css
/skin2/somejs.js

Similar to wordpress skins (it is not WP).

I do need cookies to know which skin is called because URLs stay the same. The only way to know which skin is it is by looking at cookies, skin id value.

[smilie]

Here's what I have now on the main site:
<link rel="alternate" media="only screen and (max-width: 640px)" href="http://www.example.com/mobile.aspx?skin=2">

and on mobile:
<meta name="viewport" content="width=device-width, initial-scale=1">

Still G doesn't see mobile in GWT

[londrum]

I don't know whether this will work, but try changing that rel=alternate to rel=stylesheet

The file hasnt got a .css extension, so maybe google's thing isn't recognising it as a stylesheet. Maybe that's why they think the site hasnt changed

[smilie]

It's really not a stylesheet. It is a redirect to the same URL with a different skin id.

System internally then recognizes skin id and loads a completely different template from a different physical folder.
This doesn't change page URL, only visually page itself. Like a Dynamic Serving:
[developers.google.com...]

Except we don't auto-redirect to mobile when we see mobile request, we provide links at the bottom of our site. In our experience true mobile users consist of less than 10% of our visitors, makes no sense to mess it up for 90% of the rest.

[londrum]

If it takes a cookie to load it, then that must be what it is — googles test doesn't bother acting on cookies. So it never loads.
If that's what it is, then maybe there's no solution

[smilie]

Yeah. It assumes it's normal skin when there's no cookies. So Google's "mobile page test" obviously fails.

It's annoying to see these warnings from G even if we have mobile site. And I am seeing some tools to show drops in traffic after last two Google's mobile updates. We did not notice this, but now I am researching . Always with G you need to make sure not to step into any mines on the minefield to stay alive.

[londrum]

Cookies aren't a good way of doing it anyway, so maybe they are doing you a favour.

You can load new CSS and JS just checking for screen size. Theres no need to change the URLs. Once you've done the work of changing it over i'm guessing you will be much happier with it because you will only have one template to look after - and it will solve this problem.

[smilie]

>> Cookies aren't a good way of doing it anyway, so maybe they are doing you a favour.

Actually this has been done since the first day of the internet. And you can't do a checkout without cookies anyway on any ecommerce site.That's the way the web works.

It is a classic template-driven engine. If you ever worked with Wordpress (WP) - as an example - that's a MODERN template-driven engine. An admin sets up in the skin, which there are thousands of out there. Your URLs REGARDLESS OF SKIN are the same, just the skin changes. There may be skins that are responsive and not.

In our case, the way it works is there's regular skin and mobile skin, and user is delivered a regular skin unless they click "mobile" , in which case the cookie is set in their browser and they are delivered mobile skin on every subsequent request.

This is by design of the World Wide Web, setting something for that user on the server is actually worse (session) because what happens if you need to go to server farm? It's a whole headache, now you'd have to store it on the "main" server or DB etc. , and even then user may be coming from pool of mobile IPs and change it on subsequent requests, etc.. becomes a programming issue, and we have no built in functionality and 0 tech resources. But based on WWW standards, you can set a cookie in user's browser and then no matter which server they request next they get correct skin. If it's the USER who wants mobile skin, the USER better have ability to store cookies, which 100% of all modern browsers do.

And if they don't accept cookies like a Googlebot, then tough luck, they can't even login yet alone checkout. Only bots and spammers typically don't accept cookies, great way to filter those.

[londrum]

using cookies for shopping carts is one thing, but using cookies to display a mobile skin is needlessly missing out a load of people, because there are other ways of doing it

lots of people block cookies. and there is no workaround for that. you also said that people have to click on the mobile link in the first place before the cookie kicks in and takes over. so you're losing some more people there — the ones who don't bother to click the link. some people clear their browser cookies when they shut down as well, or after a few days, so they'll have to click the mobile link every time.

but if you check the size with CSS (you don't even need javascript) then every single person will see the mobile skin, every time, without them having to find the link first. you'll be giving your customers the best experience every time.
and google will start seeing that you have a mobile friendly site as well — and hopefully you'll get that bit of traffic back.
it's a win-win. it will make your site better.
you've obviously done all the design work already on the mobile version, so it's probably only a day or two's work at most

setting something for that user on the server is actually worse (session) because what happens if you need to go to server farm?

this doesn't apply because it's just a stylesheet. you don't have to mess around with sessions either. the <link> line that you put in your <head> will check for the size, and display the mobile stylesheet. he will then cache that at his end — in exactly the same way that he does with all your other CSS. his browser will download the mobile stylesheet once, and it's job done — forever (assuming that you put a long expiry date on the stylesheet). there is no need for you to store anything about him on your server

check it out — it really is easy peasy. i don't think you realise how easy it is. it's easy peasy lemon squeezy

[bwnbwn]

using cookies is a bad way to do a redirect I will confirm this. I am not sure if your using a webhosting build or what but the way your doing it isn't good. What are you using for the website build?

[FranticFish]

if they don't accept cookies like a Googlebot

... or Facebook and LinkedIn etc, so people can't share your stuff with a preview unless you add the social bots to your white list.

If your site is intended for the public and requires cookies enabled just so the user (agent) can render a page then you're making life more complicated than it needs to be IMO.

[JS_Harris]

The best way to serve mobile is on the same URLs using detection if/when possible. Different URLs are a potential ranking nightmare and even if done right still dilute your pages just by virtue of existing(increasing the # of URLs).

Is the site wordpress? I ask because I noticed that Google is able to do some things they shouldn't. I launched a wordpress site with a custom template and a hard coded index page. In the settings the homepage was set to show a page with the url of "/home" but that didn't matter because the hard coded index page cannot pick up any settings, it's permanently set to "/".

All links sitewide point to home as being "example.com/" and NONE contain "example.com/home" and NEVER have... yet Google ranked "example.com/home" ahead of the real base url instantly. The only place they could have even found that URL is inside the admin dashboard... it NEVER existed on site. It's possible something similar is confusing Google is the site is wordpress based.

I'm investigating which wordpress file URL is providing Google with info, they try to retrieve several common wordpress files presumably to test to see if it's wordpress... such as the remote publishing page that is never linked to that is also stripped from the header file.

[smilie]

Guys, I dropped a discussion as you sort of don't understand where I am coming from.

I've been doing web dev. almost 20 years. The software is one of the leading ecommerce web platforms available for that particular Server. It is a dedicated hosting, with large DB etc. This isn't some small site.

>> @Francisfish ... or Facebook and LinkedIn etc, so people can't share your stuff with a preview unless you add the social bots to your white list.


Robots who don't accept cookies view our main skin. And not others. Tough luck. People can't do a login or a checkout anywhere online if they block cookies, that's how ALL ecommerce works. Even on WebmasterWorld, check your browser, WebmasterWorld sets cookies when you login, way more than 1 by the way, maybe 10 cookies. That's a web STANDARD.

Please don't post here just to post.

[smilie]

>> @londrum : but if you check the size with CSS (you don't even need javascript) then every single person will see the mobile skin, every time

As I mentioned , it is not just one css. There's maybe hundred files involved. It is a whole new skin - images are different, js is different, a LOT. I just checked , 660 files (majority are images though and are the same).

[Robert Charlton]

Here's what I have now on the main site:
<link rel="alternate" media="only screen and (max-width: 640px)" href="http://www.example.com/mobile.aspx?skin=2">

and on mobile:
<meta name="viewport" content="width=device-width, initial-scale=1">

Something you don't mention. On each mobile URL you also need...

link rel="canonical" tag pointing to corresponding desktop URL

Essentially, as you're aware, you need to have something to tell a mobile user/bot that the desktop url exists, and the desktop user/bot that the mobile url exists. For the whole setup to work, though, there's got to be two consistent and parallel sets of urls.

It assumes it's normal skin when there's no cookies.

That's correct.

If you want separate mobile and desktop sites... and from the UX standpoint I've seen separate vs responsive argued both ways... I think you'd be much better off using the "m." subdomain for the mobile, as in m.example.com ...and set up all the mobile pages to use one set of style sheets, images, etc, and not have the page styling reflected in an ID generated by a cookie and placed in the URL.

>>Cookies aren't a good way of doing it anyway, so maybe they are doing you a favour.

Actually this has been done since the first day of the internet. And you can't do a checkout without cookies anyway on any ecommerce site.That's the way the web works....

Yes and no. The use of cookies is not really the issue. The issue is what's going on in visible URLs.

You would not in fact want to make, say, the session ID in an ecommerce site visible in a spiderable URL. That would be inherently insecure, which is why checkout is put behind a sign-in or some form of access control.

Making a cookie-driven skin-ID inconsistently visible in some URLs and not others, though, is ingenious, but probably not the best way to make the web "work".


See Google's more detailed recommendations on separate mobile and desktop versions of site here...

Separate URLs
Google Search > Webmasters > Mobile Friendly Websites
[developers.google.com...]

Includes: signalling the relationship between mobile and desktop URLs with annotations for the urls; annotations in the HTML; annotations in Sitemaps; etc.

[smilie]

@RobertCarlton: link rel="canonical" tag pointing to corresponding desktop URL

Interesting point. I have rel="canonical", and it points to canonical URL. To a generally canonical URL.

Example. URL:
http://www.example.com/page1.htm
http://www.example.com/page1.htm?someparameter=123
Canonical URL:
http://www.example.com/page1.htm

Mobile URL:
http://www.example.com/page1.htm?skin=2
When user loads this page, it will load mobile page and set a cookie "skin=2". Then all subsequent pages will be mobile without ?skin=2 parameter. They will look identical on both, desktop and mobile.

Canonical URL is
http://www.example.com/page1.htm
not
http://www.example.com/page1.htm?skin=1
(the later would switch back to desktop skin).

>> For the whole setup to work, though, there's got to be two consistent and parallel sets of urls.

Not necessarily. Even Google says you can have identical URLs for both desktop and mobile. The issue is though, they can't distinguish between two. Or so it seems. See "Dynamic Serving":
[developers.google.com...]

From G link, they are basically forcing me to have a separate mobile subdomain, m.example.com. I.e. build for Google, not for users. Because on Dynamic Serving they can't figure out which is mobile and which isn't. I don't see any way around it.

[rainborick]

But Google's approach on Dynamic Serving assumes the server is checking the User-Agent for mobile devices to serve the appropriate content because Googlebot doesn't support cookies. Have you considered using that approach?