Don’t let large code examples break Google’s mobile-friendly test
The ever-expanding importance of mobile search is beyond debate. That’s why you don’t want Google to think that your website is not mobile friendly—although it actually is. Long lines in code examples (typically found in webdesign blogs) can be a problem in respect of what Google regards as mobile-friendly. Learn how you can easily fix this with a bit of CSS.
Recently I was searching for my article “How—and why—to pimp your CMS with modular content blocks” on Google, just to check how it is displayed in the SERPs. Everything was OK, except one line wich didn’t belong there:
I was baffled because I put a lot of effort into making this website responsive, fast and easy to navigate on small screens. So I used Google’s mobile-friendly test tool, hoping to get deeper insights. Unfortunately the tool is rather vague about the reasons why a page doesn’t pass the test. The tool told me that it found content on the page which was wider than the viewport. No hint which part of the content it referred to. I had to find a solution without the tool’s help.
The solution itself is very simple. But let me explain the basics first.
Long lines in code examples can be a problem
The only extra-wide content I had on the page was a big code example with very long lines. It looked OK on all screens, since the code block had the width of the main text column and offered a horizontal scrollbar if required. That’s the standard for code examples. So why was this a problem for Google? I removed this code block—while leaving all other code examples on the page untouched—and the error message in Google’s mobile-friendly test tool went away. I reinserted the code block, and the “too wide content” error message was there again.
To cut a long story about trial and error short: Google’s mobile-friendly test tool doesn’t look at your content the same way you do it with your browser. In some cases it proclaims errors which you cannot reproduce using the browser on your smartphone. The problem discussed in this article is one of these strange cases.
The code which didn’t sit well with Google
Since I use Prism for code highlighting, I followed Lea Verou’s recommendation on code structure: a
<pre> element with a
<code> element inside, the latter with a class
language-[name], e. g.
The default Prism CSS styling adds the horizontal scrolling ability to the
<pre> container and leaves the
<code> element untouched in terms of the CSS properties
Here is the respective excerpt from prism.css:
It turned out that—at least in my case—the overflow setting for the
<pre> element didn’t impress Google’s mobile-friendly test tool at all. Because the
<code> element inside the
<pre> element had no CSS definitions for
overflow-x the default values came into effect:
display: inline and
overflow-x: visible. In combination with the surrounding
<pre> element and with code example lines exceeding a certain lenght threshold this obviously makes Google think that the content is wider than the viewport—with no taming mechanism present because the
overflow: auto of the
<pre> element is ignored.
Phew, that was a complicated explanation. In a nutshell: Google’s mobile-friendly test tool thought that I had super-wide untamed content on my page because it ignored my CSS.
Usual CSS declarations didn’t work
My first idea was: If the mobile-friendly test tool ignores the
overflow setting of the
<pre> element, then perhaps shifting the horizontal scrollbar to the
<code> element and making it
display: block could be a solution. I saw this on other websites like CSS-Tricks and thought it would be a good starting point.
In the browser and on my smartphone the above CSS worked as expected. But Google’s mobile-friendly test tool was as unimpressed as before. The error message remained the same.
Inline styles do the trick
I have no idea why the tool has problems with loading these assets. All files exist and are accessible. The SSL certificates of all used sub-domains are valid. But as long as the site works for human users, I don’t really care much.
But I still wanted Google to rate my page as mobile-friendly to avoid any possible ranking disadvantages associated with a bad mobile-friendly rating. After I added the above mentioned two CSS properties as inline styles, Google’s mobile-friendly test tool stopped complaining about the page. It’s not a very elegant solution. But at least it works.
Reviving the example from above:
Finally I got the result I was looking for:
What are your experiences with Google’s mobile-friendly test tool? Have you had similar loading problems with assets that led to a bad rating? Please tell me, preferably using the social media links for comments.