Building Smartphone-Optimized Websites

Google supports smartphone-optimized sites in three configurations:

  1. Sites that use responsive web design, i.e. sites that serve all devices on the same set of URLs, with each URL serving the same HTML to all devices and using just CSS to change how the page is rendered on the device. This is Google’s recommended configuration.
  2. Sites that dynamically serve all devices on the same set of URLs, but each URL serves different HTML (and CSS) depending on whether the user agent is a desktop or a mobile device.
  3. Sites that have separate mobile and desktop URLs.

On this page we will look at how to implement each of these configurations.

Responsive web design

Responsive web design is a setup where the server always sends the same HTML code to all devices and CSS is used to alter the rendering of the page on the device using media queries. Our algorithms should automatically detect this setup if all Googlebot user agents (both Googlebot and Googlebot-Mobile) are allowed to crawl the page assets (CSS, javascript, and images).

A CSS media query we recommend to use for smartphones is:

    @media only screen and (max-width: 640px) {...}

The max-width value of 640px shown above is an example, not a requirement. Our algorithms look for max-width values that can be reasonably expected to refer to smartphone screen resolutions, and we will try to monitor what typical mobile websites use and may update our algorithms accordingly in the future.

As for how to specify the media query, Google supports all the different ways the standards allow for using media queries in your code. Each implementation technique has pros and cons and you can use the one that works best for your site and users. As a general rule, if your site works in a recent browser such as Google Chrome or Apple Mobile Safari, it would work with our algorithms.

For more help about responsive web design, you can start with our blog post on Webmaster Central (Google Developers).

Why responsive design

We recommend using responsive web design because it has many good aspects:

  • Using a single URL for a piece of content makes it easier for your users to interact with, share, and link to your content, and a single URL for the content helps Google’s algorithms assign the indexing properties for the content.
  • No redirection is needed for users to get to the device-optimized view, which reduces loading time. Also, user agent-based redirection is error-prone and can degrade your site’s user experience (see “Pitfalls when detecting user agents” section for details – Google Developers).
  • It saves resources for both your site and Google’s crawlers. For responsive web design pages, any Googlebot user agents needs to crawl your pages once, as opposed to crawling multiple times with different user agents, to retrieve your content. This improvement in crawling efficiency can indirectly help Google index more of the site’s contents and keep it appropriately fresh.

Crawling requirement

Be sure not to block the crawling of any Googlebot of the page assets (CSS, JavaScript, and images) using robots.txt or otherwise. Being able to access these external files fully will help our algorithms detect your site’s responsive web design configuration and treat it appropriately.

Dynamically serving different HTML on the same URL

Dynamic serving is a setup where the server responds with different HTML (and CSS) on the same URL depending on the user agent requesting the page. As it is not immediately apparent in this setup that the site alters the HTML for mobile user agents (the mobile content is “hidden”), we recommend that the server send a hint to request that Googlebot-Mobile should crawl the page, too, and thus discover the mobile content. This hint is implemented using the Vary HTTP header.

The Vary HTTP header

The Vary HTTP header has two important and useful implications:

  1. It signals to caching servers used in ISPs and elsewhere that they should consider the user agent when deciding whether to serve the page from cache or not. Without the Vary HTTP header, a cache may mistakenly serve mobile users the cache of the desktop HTML page or vice versa.
  2. It helps Googlebot discover your mobile-optimized content faster, as a valid Vary HTTP header is one of the signals we may use to crawl URLs that serve mobile-optimized content.

The Vary HTTP header is part of the server’s response to a request, like this:

GET /page-1 HTTP/1.1
( of HTTP request headers...)

HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 5710
(... rest of HTTP response headers...)

Which means that the contents of the response will vary depending on the user agent that requests the page. If your server already uses the Vary HTTP header, you can add “User-Agent” to the list that’s already served.

Please be sure to understand the common pitfalls when detecting user agents(Google Developers) that you should consider when setting up dynamic serving on your site.

Separate mobile URLs

In this configuration, each desktop URL has an equivalent different URL serving mobile-optimized content. A common setup would be pages on serving desktop users having corresponding pages serving mobile users. Google does not favor any particular URL format as long as they are all accessible to both Googlebot and Googlebot-Mobile.

Annotations for desktop and mobile URLs

To help our algorithms understand this configuration on your site, we recommend using the following annotations:

  1. On the desktop page, 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.
  2. On the mobile page, add a link rel=”canonical” tag pointing to the corresponding desktop URL.

We support two methods to have this annotation: in the HTML of the pages themselves and in Sitemaps. For example, suppose that the desktop URL is and the corresponding mobile URL is . The annotations in this example would be as follows:

Annotation in the HTML

On the desktop page, add:

<link rel="alternate" media="only screen and (max-width: 640px)" href="" >

and on the mobile page, the required annotation should be:

<link rel="canonical" href="" >

This rel=”canonical” tag on the mobile URL pointing to the desktop page is required.

Annotation in Sitemaps

We support including the rel=”alternate” annotation for the desktop pages in Sitemaps like this:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns=""
    media="only screen and (max-width: 640px)"
    href="" />

The required rel=”canonical” tag on the mobile URL should still be added to the mobile page’s HTML.

Annotation in detail

Notice the attributes of the link tag on the desktop page:

  • The rel=”alternate” attribute signals that this tag specifies an alternative URL to the desktop page.
  • The media attribute’s value is a CSS media query string that specifies the media features the alternative URL applies to. In this case, we’re using a media query that’s typically used to target smartphones.
  • The href attribute specifies the location of the alternative URL, namely on the page on

This two-way (“bidirectional”) annotation helps Googlebot discover your content and helps our algorithms understand the relationship between your desktop and mobile pages and treat them accordingly. When you use different URLs to serve the same content in different formats, the annotation tells Google’s algorithms that those two URLs have equivalent content and should be treated as one entity instead of two entities. If they are treated separately, both desktop and mobile URLs are shown in desktop search results, and their positions may be lower than they would otherwise be.

Redirects and the HTTP Vary header

Please note that if your site automatically redirects mobile visitors coming to the desktop site to the mobile site, or vice versa, please be sure to configure your server to include the Vary HTTP header as described in this page(Google Developers).