Google Mobile Search

Google is a search engine. It’s supposed to index the web. instead, is it in effect dictating how your website should look. Although I have a fundamental disagreement with this, and more than a little suspicion about Google, I present here the research I’ve done on this subject for our mutual benefit. I may have made mistakes at various points. Feel free to point them out.

This is a tweak that is being done in Google search for web sites, rolling out 21 Apr 2015, and for a few weeks thereafter. This tweak only affects mobile search results. That is, if you search for something on a mobile device, Google will rank “mobile-friendly” sites above others. If you perform the same search on a non-mobile device, there will be no changes to the normal Google rankings.

To test for mobile weaknesses, use the Google tester at this URL:

This site approaches the target website as Google would, using the googlebot. So sites may appear differently than they do in a desktop search (when viewed on the site).

There are 4 primary reasons for failure of a site to be “mobile-friendly”:

Incidentally, all our corporate sites fail this test, for what it’s worth.

Mobile Viewport Not Set

This is a meta attribute. The viewport controls how a site is displayed on a mobile device. Without a viewport specification, a mobile device will render a page at the typical desktop screen width, scaled to fit the screen. Typical specification looks like this:

<meta name=viewport content="width=device-width, initial-scale=1">

Apparently the first part ensures that the width displayed conforms to the width of the mobile device, not what’s specified for the screen. The second part of this specification has this purpose: Windows and iOS will keep a page’s width constant when rotating to landscrape mode, and zoom rather than reflow to fill the screen. The latter control above tells the browser to establish a 1:1 relationship between CSS pixels and device independent pixels, regardless. I interpret this to mean it now would reflow as needed.

Mobile Site Architecture

There are three primary ways to architect a site for mobile:


This is constructing a site so that it “degrades” gracefully, something designers have been talking and recommending for years. There are three chief components to this type of styling:

The guy who came up with the term “responsive” in this context wrote a book: Responsive Web Design by Ethan Marcotte (PB 2011) $17.79 on Amazon. Beware that his idea of professional design involves original mock-up design in Photoshop, and then turning the mock-up over to HTML coders. This is in contrast to taking care of the whole design process in a package like Dreamweaver. Judging from what I’ve seen in job requirements for designer jobs, it appears that Marcotte is in line with industry standards.

One of the major advantages of this type of design is that it may not any changes to the original site, and ultimately only one version of the site needs to be maintained. CSS does the rest.


Uses a combination of server-side (PHP) and client-side (Javascript) scripting to point the user at a mobile page instead. Problem is that many mobile devices offer either no or weak support for Javascript.

Mobile Domain

This can be used on its own or as part of other schemes. More or less, it means a different page or domain/subdomain built just for mobile users. Often if the main site is, the mobile version will be

Detecting Mobile Devices

In some cases above, it is necessary for the coder to attempt to figure out whether a site is mobile or not. In addition, mobile sites can be detected automatically, to some extent. There are various ways of detecting mobile devices.

Do nothing

Yes, you read that right. In this case, you simply provide a link at the top of the page to allow mobile users to click on to get to a mobile subdomain or some such. This would result in your site being considered “mobile-unfriendly” and slipping in search ranking by Google (at least on mobile searches). It’s not adequate for Google to consider a site mobile-friendly.

Javascript browser detection

Detecting the browser (and thus the platform) in use via Javascript. Two problems with this scheme:

Use CSS @media handheld

I’m sketchy on how exactly this is done in relation to the other elements in the CSS. That is, I know how to set this up:

@media handheld { ... }

I’m just not sure how other elements nest inside those brackets.

Server Side Detection

Using a combination of server-side (PHP) and client-side (Javascript) languages, you query the device being used to determine if it is mobile or not. Same answer as Javascript above, though. It’s hit or miss, Javascript may not have good support, there are thousands of platforms and ultimately, you’d redirect to a different page (multiple page maintenance).


This is an XML file of platforms, user-supported and being added to all the time. You pick your programming language of choice, and use the API for that language to query the WURFL file you download. You’d need to download the file periodically to update it. Then you’d redirect as needed.

Miscellaneous Notes

To allow automatic selection of mobile or desktop device, you can set your CSS up this way:

<link href="styles.css" rel="stylesheet" media="screen" type="text/css">
<link href="mobile.css" rel="stylesheet" media="handheld" type="text/css">

There are other ways of doing this if you find “handheld” doesn’t work well. But these generally involve setting some arbitrary screen width, below which the system selects the handheld CSS. This option means that with minimum redesign of the site, the CSS handles the whole selection and styling issue itself; no separate site (or site maintenance) needed.

You can use a single stylesheet which handles both mobile and screen environments by @media {} attributes inside your CSS file, but I believe this would be confusing and require a lot of duplicative code in one stylesheet.

CSS3 introduced some relative units:

Another issue which can be of concern when putting up a separate page for mobile is how the screen site shares search “goodness” with the mobile version and vice versa. We have discussed this before, I believe in the context of Auto Exellence’s site. It involves attaching a meta tag to the mobile page which points to the original site, as rel=canonical, and attaching a meta tag to the screen or main site like rel=alternate. We would need to research exactly how this would be done, if we chose to do a mobile version of the site.

Site Repair Alternatives

Site-owner alternatives to provide site modification.

Call your web host

Apparently, some have tools to transition your site. Godaddy has a tool that completely rebuilds your site and charges $1 a month for the service. Bluehost has a tool that’s less time-consuming and potentially cheaper. The tool is called goMobi and costs a one-time USD 25. Does Fluid Hosting (where he’s hosted) have such a tool, and does it cost? Not that I can see.

Other services

They mention one company,, which will generate a “more robust yet smaller version of your website”, starting at $5 a month. I’m inclined to wonder if all such services don’t charge by the month forever. If such, I can’t imagine them doing a responsive site, which should be a one-time expense.

Call a local web host

That’s us.

Repair/Original Design Notes

First, we need to abandon the idea that a mobile site will closely resemble the original site. Screen width is at a premium on mobile devices and left/right scrolling may not even be available. Moreover, it’s doubtful that a mobile device user will dawdle on a site to read everything. The mobile version of a site should contain all the essential information, minus a lot of the “designer touches” of the original site. Many items, lacking the onscreen width of the original site, will need to be stacked. I would consider the mobile version of a site to be an information-only site.

Regarding Sizes

In refactoring existing stylesheets for mobile, I’m concerned about two factors. First is anything having to do with font sizes and line-heights. Any measurements for those must be changed to (preferably) ems. Second is sizes of containers. More modern sites often contain container divs which are sized so that they fit within each other or next to each other, etc. Those measurements have hitherto been in pixels, for the most part. These need to be converted to percentages.

Container Sizes

In refactoring of container sizes, you’ll probably find that a number of measurements repeat themselves down the page in the CSS file. These are standard sizes you’re using over and over. For example, on our sites I see a lot of 780px measurements. You’re going to see a lot of fractions of this in the CSS, but it will generally be the largest container measurement you see.

So here’s a question: On my screen (which is probably typical for this day and age), what percentage is 780 of the whole width of my screen? The answer depends on the width of my screen. Let’s say it’s 1024 pixels. So if I want to find out 780’s percentage of the overall 1024 width, I would divide 780 by 1024. The answer is 0.7618. Multiply this by 100 to get a percentage and you get 76.18 percent. So 780 is 76.18 percent of 1024. So if you want to convert the overall container size of the site (780) to a percentage, you can use 76.18 as your percentage. (Don’t worry about the number of decimals after the period; PC CPUs have special instructions for handling floating point (as opposed to integer) math. They can, in effect, do this stuff in their sleep.)

Pixel measurements are absolute. You want relative. That’s why you’re doing this percentage calculation. If the other containers on your page are taking their size from the percentage of the overall screen size, then you can simply divide each one of them by your screen size. If, on the other hand, other measurements are relative to your container, then you’ll have to divide by the container’s size to get a percent. For example, if you have a side bar that needs to be measured relative to your overall container, then the calculation may be slightly different. As an example, a 180 px sidebar, relative to your 780 px container would be 180 / 780, or 23.0769 percent of your container.

I bring this subject of container sizes and percentages up because you’ll see a lot of these measurements in your CSS, and a lot of them will be repeated. So my best advice is get a piece of paper and a pencil. Go down the whole length of your CSS document and write down each of these numbers you may have to convert to percentage, one per line. Get a calculator and do the calculations and write out the percentages next to the original pixel counts. Once done, go back to the top of the page and start changing your pixel counts to percentages, based on what you’ve written on your sheet. That way you won’t have to redo calculations all the time. They’ll all be there each time you have to do a substitution.

Actually, a better piece of advice is to eliminate container sizes altogether, and let the mobile browser do the work of resizing containers, as needed. If necessary, provide an overall container for everything which specifies a width of 100%.

Font Sizes

Font sizes on mobile devices will need to be relative instead of absolute, as in pixels. (Actually, this should be standard practice by default.) For this purpose, ems make the most sense. Incidentally, in doing research for this subject, I repeatedly came across the complaint that designers specified their font sizes too small from the beginning. Apparently, designers appear to prefer body copy to be 12px, when the standard size for body copy in browsers is 16px.

The following is a table put together from web research.

HTML Size Tag W3C Recommended Typical in PX Firefox Typical in PX

H1 2em 24px 32px H2 1.5em 22px 24px H3 1.17em 18px 18px H4 1.12em 16px N/A (body copy = 16px) H5 0.83em 12px 13px H6 0.75em 10px 11px

On the assumption that font sizes have already been specified in pixels, it will be necessary to re-specify them in ems, preferably using the above as guidelines. The easiest way to do this is to inspect the CSS for font sizes specified in pixels, and write down all the numbers you find. Then do the math to convert them to ems all in one place. Then as you go down, you can simply look up the original numbers on your list, and substitute the correct em size, based on your original calculations. There’s no sense in doing math more than once.

An example of font-recalculation follows. The basic assumptions is that your body copy should ultimately be 1em size but was originally sized at 12px. Let’s say that you have a piece of type which you’ve sized at 18px. That’s larger than your body copy by half. The calculation would be 18/12 = 1.5. So it’s half again as large as your original body copy. If you want to retain that ratio, then your calculation is over: 1.5em. Similar calculation it possible all the way down the CSS document. It would be like this:

original_size_in_pixels / base_font_size_in_pixels = font size in ems.

The following are attributes which may likely need to be adjusted, based on my experience.


It should be noted that images, particularly as called out in CSS, may need to be deleted. This is one of the points which can cause a site to be mobile-unfriendly. They can consume excessive bandwidth in downloading to mobile devices. You’ll need to check for them in the HTML files as well. Unless they’re important to understanding or clarifying the other content, they are best avoided.

Another suggestion that appears to work to ensure that images do not overflow their containers:

img {
max-width: 100%;

Other Measurements

Other measurements generally are of less importance, but may still need to be adjusted. The following are measurements which should be examined.

For the most part, these things needn’t be adjusted, but width and margin-left can be problematic. Widths can often be eliminated entirely. Margin-lefts are often used to space a container over from the left margin. These should normally be eliminated.

Firefox’s “Responsive” Mode

Firefox in later versions has a programmer/web designer feature which is invaluable in refactoring websites for mobile. Go to the “Tools” drop-down in FoxPro, and click “Web Developer”. Under this menu, there a choice called “Responsive Design View”. Click this and you will see your site as mobile devices see it. This can save you endless hours going back and forth to Google’s mobile evaluation site. You can make changes to the CSS, refresh the page, and see the changes right away in this view.