The current GoogleBot Smartphone agent, as tested with the 'Fetch as Google' Tool is essentially a fake iPhone using a headless Webkit Engine, running on a Linux x86_64 desktop machine.
The default non-responsive viewport width is that of an iPhone at 980px.
With a viewport
<meta name="viewport" content="width=device-width, initial-scale=1"> applied, ...
I had 6 instances of "other errors" (4 images and 2 stylesheets) and continually hitting the refresh button didn't help. here's what I think finally fixed it for me:
I switched 2 of the images from relative to absolute paths. that fixed both of those.
I removed the type="text/css" from my css head tags that called the 2 stylesheets. so, they now have only ...
According to this support thread, "Other error" may be that Googlebot reached the limit of the number of requests it is willing to make to a server to prevent it from overwhelming the website with requests.
There was not a definitive answer, but that appears to be the response. If this is true, I wish the "error" message was changed to something like "Rate ...
Google's bots do not view a page in any resolution due to the fact they do not render the page as you would expect from a browser, therefor resolution is irevelant but you should aim for standard media queries that support a range of devices. Google's mobile bot will view the media queries you have in the CSS file and estiblish from the Max-width resolution ...
You are already telling them because you have one site using a single set of URLs.
They visit twice because each bot evaluates differently. In the end it goes in the same index but the metadata is different which lets them serve different results to standard and mobile queries.
"load 23 page resources" that sounds like your page has a Lot of resources to load.
The mobile tester doesn't like 'heavy' pages.
There are many ways this mimics what it might be like loading it a real mobile device that might have a unstable data connection.
Make the page 'lighter' - loading less 'crud' & the page will load quicker, and hence more ...
The canonical tag is enough, as it lets Google know which page should be indexed. It is basically a way of saying "Hey, these pages are extremely similar. Here is the page that should take precedence."
Preventing Google from crawling your mobile links will cause more harm than good. Example: If a mobile user shares a mobile link to your website, you don't ...
As you know the major problem here is that you tables are causing the lower part of the page to overflow. While this may only seem a problem until you get to the bottom it actually becomes a problem on some devices the moment they stroke their screen. This is because they may stroke the touch screen at an angle and will result in shifting the page to the ...
Googlebot crawls your website with a mobile user agent:
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)
It uses that crawl to determine how your site is configured for mobile users. Because the user agent ...
There's a script called MobileDetect, if checks if the visitor is a user via the browser headers. Requires updating from time to time, but other than that is works very easy:
$detect = new Mobile_Detect();
define(IS_MOBILE_USER, $detect->isMobile() && !$detect->isTablet() );
if( $onDesktopSite && IS_MOBILE_USER && !isset($...
Using a sitemap specific to your mobile content will help Google crawl and index URL's for mobile content. This should be a separate sitemap from your non-mobile content, as stated by Google here.
A sample mobile sitemap supplied by Google is:
<?xml version="1.0" encoding="UTF-8" ?>
Ok, this was tricky because Google's suggestions are deceitful: Google talks about "clickable elements too close to each other" and "small text", but looking at the screenshot, the problem is that the video container is too big (despite the responsive wrapper).
Considering that there's an error type in the tool called "content bigger than the screen", I ...
John Mueller, Webmaster Trends Analyst at Google, stated in April 2015:
you don't need - and shouldn't have! - a mobile sitemap if your site doesn't have a feature-phone (WAP/WML, etc) version. If your site is responsive and works well on smartphones, that's enough for us
If you employ a mobile site on a subdomain with same content, pointing to its ...
Adding a mobile sitemap won't hurt anything, though as you have canonical tags pointing to the desktop version of the pages then you won't see proper index stats in Webmaster Tools. Also, the site:search might be showing no pages because they have already been consolidated into the desktop versions. Your log files would show if Google had crawled these pages ...
I am responding as answer as i managed to figure out what exactly was happening.
MFT and PageSpeed Test were using 2 different user agents. PageSpeed's mobile user agent was detected correctly by 51dgree but MFT. So based on, this and this i have updated code base to detect MFT user agent. Now it works fine.
In my opinion it is best to move towards ...
You have to understand that there are not two indexes; one for desktop and one for mobile. There is just one.
If a page is found to be mobile friendly, it is marked within the index. If it is not, then it is marked with a reason code for Search Console to report. It is that simple.
Google hits your site just once per-page and assesses whether the page ...
I do not know a great deal about Search Engine Optimization, but I do know enough about HTML parsing to know that whitespace is mostly ignored to the parser. HTML parsers and SEO parsers should work in a similar manner. As a rule of thumb I would expect this to be true: If a website's source code is changed and it renders the same, it should rank the same.
Google on occasions has been known to ignore robots.txt, it should never be treated as a guarantee. Sensitive pages should always some of form of authentication, or you could opt to block those user agents by returning a 403 forbidden status.
However, this is not the issue.
Googlebot is known to probe sites with different user ...
I found the answer here : https://developers.google.com/search/mobile-sites/mobile-seo/separate-urls
When a website is configured to serve desktop and mobile browsers using different URLs, webmasters may want to automatically redirect users to the URL that best serves them. If your website uses automatic redirection, be sure to ...
I can't read the language the report is in, but I am guessing from what I can gather that the reason is that the default YouTube embed method involves an iframe which is a default number of pixels.
While this is fine for a computer's browser to handle, it's not best practice for mobile devices. It is possible to embed in a responsive way, so that the video ...
Hm, I'll take the shot, so we can discuss this little bit more. Interesting question.
I'd do this:
On the desktop page I'd add rel=”alternate” tag pointing to the mobile URL. This will help bot to discover the location of site’s mobile pages.
On the mobile page, I'd add a rel=”canonical” tag pointing to the desktop URL.
If HTTP redirection is difficult ...
You will not have any problems with this at all and Google recommends you remove such space when possible.
Minification refers to the process of removing unnecessary or
redundant data without affecting how the resource is processed by the
browser - e.g. code comments and formatting, removing unused code,
using shorter variable and function names, ...
Looking at your setup...
Identical desktop and mobile URLs, no subdomain or sub-folder:
<link rel="canonical" href="index.php?/...">
<link rel="canonical" href="index.php?/...">
I see an issue. you're confusing the heck out of google. you need to create an association between desktop and ...
If you have the "same URL for both desktop and mobile content, but changes their format according to User-agent" then all pages available to desktop users will also be available for the mobile users.
Google will crawl your desktop site and then determine what happens when viewing those pages from a mobile device. It's the ones which aren't optimised that ...
I want to mention that the page-speed insights tool made by Google allows individual pages to be checked for speed and mobile usability and provides results for both desktop and mobile devices. It will provide detail on what you can do to make the site mobile friendly. It may also give a yellow warning message to those sites that might not pass the mobile ...
The blocked resources are not generally a problem. These messages are just informational most of the time. These messages are not why your site is deemed to be mobile unfriendly since they are not included in the test. In fact, you can just plain ignore blocked resources unless they are not intended to be blocked. Since you are running WP and these are in /...
I would pare that down to:
You should certainly remove wp-content from that list. That has your themes, plugins, and images. For mobile friendly you want all these crawled.
If you want more info on what each of the other pieces do, here is a guide to the WordPress directory structure.
This is what Google calls the "separate URLs" configuration.
In the desktop site, you should add a special <link rel="alternate" ...> tag pointing to the corresponding mobile URL. This helps Googlebot discover the location of your site's mobile pages.
In the mobile site, you should add a <link rel="canonical" ...> tag pointing to the ...
I would wrap the tables in a scrollable div. That way they do not affect the 'width' of the page and on mobile it stays at 'device-width'. Something like:
For the 'click targets' issue I would suggest adding some ...
What you're looking for is setting a header value for Vary.
The following PHP example will add a header value for:
Vary: Mozilla/1.22 (compatible; MSIE 5.01; PalmOS 3.0) EudoraWeb 2
$httpRequest->setHeaders(array('Vary' => 'Mozilla/1.22 (compatible; MSIE 5.01; PalmOS 3.0) EudoraWeb 2'));
You will want to use PHP's $_SERVER['...