| 7:17 pm on Jun 8, 2013 (gmt 0)|
Can you describe exactly how and where this is happening?
-- Google Preview arising from a search?
-- searching on a desktop or on a mobile device?
-- ordinary search or a mobile app?
There are currently THREE separate Googlebot-Mobiles, all with recognizable UAs such as "iPhone". So they've certainly got no excuse for not being able to find the mobile version of a site.
Feature detection is one of the big failings of Preview. It shows what the googlebot-- of some kind-- would see, not necessarily what the human user would see.
And when you're done, come back and tell us what your native language is. I sometimes see g### called "he", but can't remember seeing "she" before. Unless the implication is that G, like Mother Nature, is a you-know-what.
| 7:54 pm on Jun 8, 2013 (gmt 0)|
This problem occurs when a mobile device user clicks through from a Google SERP.
Searching Google on a mobile device, then by clicking through to our website, Google changes, distorts, and renders both the primary site and the mobile site quite differently from their intended designs.
And forget the detection coding which normally works fine to redirect mobile users to our mobile site. Google stops that function from working at all.
| 8:22 pm on Jun 8, 2013 (gmt 0)|
|And forget the detection coding which normally works fine to redirect mobile users to our mobile site. Google stops that function from working at all. |
Out-on-a-limb possibility: google is setting a cookie under your site's name that overrides your user-agent detection. This is conceptually possible, but would only work if (a) g knows the cookie exists and (b) the visitor accepts third-party cookies. And even then, it can't make your site do something the site is not already programmed to do.
Study the server logs and possibly also the request headers to see what's happening behind the scenes.
| 11:09 pm on Jun 8, 2013 (gmt 0)|
If you go directly to the main site on a mobile device, detection redirects you instantly to the mobile version. Click through from a Google SERP and detection/redirection is blocked - and both the primary and mobile site are held in a sort of 'Google wrapper' from which you cannot escape.
| 12:17 am on Jun 9, 2013 (gmt 0)|
welcome to WebmasterWorld, waxworks789!
you need to examine the requests - direct vs referred from G SERP.
this is what your server sees and the request is made by your browser.
there's no "wrapper" involving google.
how are the headers different between the requests?
| 1:01 am on Jun 9, 2013 (gmt 0)|
Unfortunately I don't have the requisite savvy to view the server logs and/or ascertain the nuances between request headers to find the problem. All I know is that the issue is happening now in real time.
And sure, I concede the correct term might not be "wrapper" - that's just how I describe the situation. Delivered via Google on a mobile phone, both our main site and the mobile site looks like it's framed. At the top frame it says, "Page shown from here. Go to page 1 - Zoom out."
You have to scroll all the way to the bottom of the page to the reach the second bottom frame - where it has a Google search field and reads, "Formatted for mobile viewing by Google View page directly."
I can assure you without any doubt whatsoever that clicking through to our site from a Google SERP (on my mobile phone) results in this Google "wrapper." And if I were a user or potential customer visiting the site, I'd leave right there and I'd never bother coming back again.
How can I - lowly Web surfer - notice this problem with Google, while no one else can?
| 1:54 am on Jun 9, 2013 (gmt 0)|
i guess i've never noticed this when using mobile search.
i assume google is linking to its own page that is scraping and transcoding the content.
perhaps there is a setting on your mobile browser to appear as a desktop visitor.
in general, the solution provided by google is to include a link rel alternate element in your document referring to the mobile content.
How does Google modify web pages for mobile viewing? - Webmaster Tools Help:
|If you do not want Google to transcode your web page, you may request that Google redirect the user to an alternate page whenever the user attempts to view the page through the transcoder. You can do so by including the following line in the <HEAD> section of the HTML file for your page: |
<link rel="alternate" media="handheld" href="alternate_page.htm" />
| 2:07 am on Jun 9, 2013 (gmt 0)|
Wow, talk about synergy - I just found the same fix!
Thanks - it solved the problem. :)
| 2:44 am on Jun 9, 2013 (gmt 0)|
Well, ###. Is THAT what the Wireless Transcoder is for? I see it periodically in logs, but thought it was a user option left over from when phones were not so smart. Is it made perfectly clear to users (not webmasters) that they're not seeing the real site? Do the users themselves have the option of bypassing the Transcoder?
|To ensure that the highest quality and most useable web page is displayed on your mobile phone or device, Google may resize, adjust, or convert images, text formatting and/or certain aspects of web page functionality. |
For a given definition of "highest quality", I guess.
waxworks, you don't need to know anything in particular to read your logs. Just find where your host keeps them, download and read offline. It's educational.
Headers are a little trickier because you first have to make a script that keeps a record of them. Or, ahem, wait around for someone else to post their version, which you can then swipe. (I think mine came from incrediBill. If I'm mistaken, he will heatedly deny responsibility.)
| 3:00 am on Jun 9, 2013 (gmt 0)|
Thank you lucy for your considerate suggestions and attempts to help me. I may someday soon go through the logs; I know where they are now.